不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。

• 窃听风险（eavesdropping）：第三方可以获知通信内容。
• 篡改风险（tampering）：第三方可以修改通信内容。
• 冒充风险（pretending）：第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的，希望达到：

• 所有信息都是加密传播，第三方无法窃听。
• 具有校验机制，一旦被篡改，通信双方会立刻发现。
• 配备身份证书，防止身份被冒充。

https要知道的几个加密算法：

• 握手的时候使用的非对称加密算法 ，用来加密握手之后的请求和应答
• 传输信息的时候使用的对称加密，
• 保证数据的完整性用的是hash算法(数字签名)

Https采用混合加密机制
也就是说采用共享密钥加密（对称加密）和公开密钥加密（非对称加密）两者并用的混合加密机制。
首先，考虑如果密钥能够实现安全的交互，那么就会考虑只使用公开密钥加密。
但是，公开密钥加密与共享密钥加密相比，其处理速度要慢。
综上，应该充分发挥各自的优势。在交换密钥的环节使用公开密钥加密（非对称加密），之后的建立通信交换报文阶段使用共享密钥加密方式。

但是，公开密钥加密方式还是存在问题。那就是无法证明公开密钥本身就是货真价实的公开密钥。就是说要证明客户端收到的公开密钥就是原本预想的那台服务器发行的公开密钥（因为有可能公开密钥在传输过程中，被攻击者替换掉了）。

因此，要解决上面的问题，就可以试用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。

关于iOS证书：（大多数证书都会自动安装，因此通常不需要对证书执行任何操作，但是有些app是需要下载安装证书的）

• 在 iOS 10.3 及更高版本中，手动安装包含证书有效负载的描述文件时，这个证书不会自动受 SSL 信任。
• 在安装通过电子邮件发送给您或从网站下载的描述文件时，您必须手动开启受 SSL 信任。
• 要为这个证书开启受 SSL 信任，请前往“设置”>“通用”>“关于本机”>“证书信任设置”。在“针对根证书启用完全信任”下，开启对这个证书的信任。
• Apple 建议通过 Apple Configurator 或移动设备管理 (MDM) 来部署证书。通过 Apple Configurator 或 MDM 安装或者作为 MDM 注册描述文件的一部分安装的证书有效负载自动受 SSL 信任。

把Windows CA根证书安装到iPhone

• 在Ubuntu下，执行如下命令把.cer转换为.pem：
• openssl x509 -in 1.cer -inform DER -out 2.pem -outform PEM
• 把.pem放到IIS网站下， IIS添加Mime Type，.pem->application/x-pem-file，在iPhone上用Safari打开.pem的URL即可安装。

名词解释
1、签名
签名就是在信息的后面再加上一段内容，可以证明信息没有被修改过，怎么样可以达到这个效果呢？一般是对信息做一个hash计算得到一个hash值，注意，这个过程是不可逆的，也就是说无法通过hash值得出原来的信息内容。在把信息发送出去时，把这个hash值加密后做为一个签名和信息一起发出去。 接收方在收到信息后，会重新计算信息的hash值，并和信息所附带的hash值(解密后)进行对比，如果一致，就说明信息的内容没有被修改过，因为这里hash计算可以保证不同的内容一定会得到不同的hash值，所以只要内容一被修改，根据信息内容计算的hash值就会变化。当然，不怀好意的人也可以修改信息内容的同时也修改hash值，从而让它们可以相匹配，为了防止这种情况，hash值一般都会加密后(也就是签名)再和信息一起发送，以保证这个hash值不被修改。但是客户端如何解密呢？这就涉及到数字证书了。
2、公钥私钥
刚开始的时候以为https只能用公钥进行加密，私钥解密，后来看来“公钥密码体制”，才知道，其实两者都可以加密、解密。
3、RSA(非对称加密)
RSA是一种公钥密码体制，现在使用得很广泛。公钥公开，私钥保密，它的加密解密算法是公开的。 由公钥加密的内容可以并且只能由私钥进行解密，并且由私钥加密的内容可以并且只能由公钥进行解密。也就是说，RSA的这一对公钥、私钥都可以用来加密和解密，并且一方加密的内容可以由并且只能由对方进行解密。可用于验证hTTPS中各种密钥的加密。
4、对称加密
加密使用的密钥和解密使用的密钥是相同的。因此对称加密算法要保证安全性的话，密钥要做好保密，只能让使用的人知道，不能对外公开。

通信流程
为了搞清楚，https是怎样运转的，接下来是借鉴一篇博文，并稍加改动，形象易懂的解释了整个流程。step1： “客户”向服务端发送一个通信请求“客户”->“服务器”：你好
step2： “服务器”向客户发送自己的数字证书。证书中有一个公钥用来加密信息，私钥由“服务器”持有“服务器”->“客户”：你好，我是服务器，这里是我的数字证书
step3： “客户”收到“服务器”的证书后，它会去验证这个数字证书到底是不是“服务器”的，数字证书有没有什么问题，数字证书如果检查没有问题，就说明数字证书中的公钥确实是“服务器”的。检查数字证书后，“客户”会发送一个公钥加密的随机字符串给“服务器”，让服务器用私钥去加密（检查数字证书，后文介绍）“客户”->“服务器”：向我证明你就是服务器，这是一个随机字符串step4：服务器把加密的结果返回给“客户”。“服务器”->“客户”：{一个随机字符串}（用私钥进行RSA加密）
step5：“客户”用公钥解密这个返回结果，如果解密结果与之前生成的随机字符串一致，那说明对方确实是私钥的持有者，或者说对方确实是“服务器”。 验证“服务器”的身份后，“客户”生成一个对称加密算法和密钥，用于后面的通信的加密和解密。这个对称加密算法和密钥，“客户”会用公钥加密后发送给“服务器”，别人截获了也没用，因为只有“服务器”手中有可以解密的私钥。这样，后面“服务器”和“客户”就都可以用对称加密算法来加密和解密通信内容了。“服务器”->“客户”：{OK，已经收到你发来的对称加密算法和密钥！有什么可以帮到你的？}（用密钥进行对称加密）“客户”->“服务器”：{我的帐号是aaa，密码是123，把我的余额的信息发给我看看}(用密钥进行对称加密)“服务器”->“客户”：{你好，你的余额是100元}(用密钥进行对称加密)

握手与密钥协商真正过程
(1).client_hello
客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息，相关信息如下：
支持的最高TSL协议版本version，从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，当前基本不再使用低于 TLSv1 的版本;
客户端支持的加密套件 cipher suites 列表， 每个加密套件对应前面 TLS 原理中的四个功能的组合：认证算法 Au (身份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验);
支持的压缩算法 compression methods 列表，用于后续的信息压缩传输;
随机数 random_C，用于后续的密钥的生成;
扩展字段 extensions，支持协议与算法的相关参数以及其它辅助信息等，常见的 SNI 就属于扩展字段，后续单独讨论该字段作用。
(2).server_hello+server_certificate+sever_hello_done
(a) server_hello, 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 等，其中随机数用于后续的密钥协商;
(b)server_certificates, 服务器端配置对应的证书链，用于身份验证与密钥交换;
(c) server_hello_done，通知客户端 server_hello 信息发送结束;
(3).证书校验
客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证包括如下：
证书链的可信性 trusted certificate path，方法如前文所述;
证书是否吊销 revocation，有两类方式离线 CRL 与在线 OCSP，不同的客户端行为会不同;
有效期 expiry date，证书是否在有效时间范围;
域名 domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析;
(4).client_key_exchange+change_cipher_spec+encrypted_handshake_message
(a) client_key_exchange，合法性验证通过之后，客户端计算产生随机数字 Pre-master，并用证书公钥加密，发送给服务器;
(b) 此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，计算得到协商密钥;
enc_key=Fuc(random_C, random_S, Pre-Master)
(c) change_cipher_spec，客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;
(d) encrypted_handshake_message，结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证;
(5).change_cipher_spec+encrypted_handshake_message
(a) 服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master);
(b) 计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性;
(c) change_cipher_spec, 验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信;
(d) encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端;
(6).握手结束
客户端计算所有接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握手完成;
(7).加密通信
开始使用协商密钥与算法进行加密通信。

数字证书
主要包含这几大块：•证书的发布机构 •证书的有效期 •公钥 •证书所有者（Subject） •签名所使用的算法 这个数字证书的数字签名所使用的加密算法，这样就可以使用证书发布机构的证书里面的公钥，根据这个算法对指纹进行解密。解密结果就是签名。•指纹以及指纹算法 这个是用来保证证书的完整性的，也就是说确保证书没有被修改过。 其原理就是在发布证书时，发布者根据指纹算法(一个hash算法)计算整个证书的hash值(指纹)并和证书放在一起，使用者在打开证书时，自己也根据指纹算法计算一下证书的hash值(指纹)，如果和刚开始的值对得上，就说明证书没有被修改过，因为证书的内容被修改后，根据证书的内容计算的出的hash值(指纹)是会变化的。 注意，这个指纹会使用"SecureTrust CA"这个证书机构的私钥用签名算法(Signature algorithm)加密后和证书放在一起.　　注意，为了保证安全，在证书的发布机构发布证书时，证书的指纹和指纹算法，都会加密后再和证书放到一起发布，以防有人修改指纹后伪造相应的数字证书。这里问题又来了，证书的指纹和指纹算法用什么加密呢？他们是用证书发布机构的私钥进行加密的。可以用证书发布机构的公钥对指纹和指纹算法解密，也就是说证书发布机构除了给别人发布证书外，他自己本身也有自己的证书。证书发布机构的证书是哪里来的呢？？？这个证书发布机构的数字证书(一般由他自己生成)在我们的操作系统刚安装好时(例如windows xp等操作系统)，这些证书发布机构的数字证书就已经被微软(或者其它操作系统的开发机构)安装在操作系统中了，微软等公司会根据一些权威安全机构的评估选取一些信誉很好并且通过一定的安全认证的证书发布机构，把这些证书发布机构的证书默认就安装在操作系统里面了，并且设置为操作系统信任的数字证书。这些证书发布机构自己持有与他自己的数字证书对应的私钥，他会用这个私钥加密所有他发布的证书的指纹作为数字签名。　　首先应用程序(对方通信用的程序，例如IE、OUTLook等)读取证书中的Issuer(发布机构)为"SecureTrust CA" ，然后会在操作系统中受信任的发布机构的证书中去找"SecureTrust CA"的证书，如果找不到，那说明证书的发布机构是个水货发布机构，证书可能有问题，程序会给出一个错误信息。 如果在系统中找到 了"SecureTrust CA"的证书，那么应用程序就会从证书中取出"SecureTrust CA"的公钥，然后对我们"ABC Company"公司的证书里面的指纹和指纹算法用这个公钥进行解密，然后使用这个指纹算法计算"ABC Company"证书的指纹，将这个计算的指纹与放在证书中的指纹对比，如果一致，说明"ABC Company"的证书肯定没有被修改过并且证书是"SecureTrust CA" 发布的，证书中的公钥肯定是"ABC Company"

证书：

• jks为密钥仓库，存放公钥和私钥。
• pfx格式的数字证书是包含有私钥的 cer格式的数字证书里面只有公钥没有私钥。

公开密钥加密：使用一对非对称的密钥，一把叫做私钥，领一把叫做公钥，也叫非对称密钥加密。
共享密钥加密：加密解密同用一个密钥，也叫对称加密。