认识HTTPS
HTTP在使用过程中会有一些不能避免的缺点，主要的几个不足如下：
- 使用明文传输，内容可能被监听
- 不验证通信方身份，可能遭遇伪装
- 无法证明报文的完整性，可能遭遇篡改
因此，为了解决上述问题，HTTPS应运而生。
HTTPS = HTTP + 加密 + 认证 + 完整性保护,其中的认证、加密、完整性保护（摘要）功能就是由SSL/TLS提供的,它将HTTP直接与TCP通信变为先建立SSL通信，然后由SSL与TCP通信。
加密
共享密匙加密（对称加密）
加密解密都是用同一个密匙。但如果转发密匙时被人监听，攻击方就能拿到密匙，也就失去了加密的意义。
对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。对称加密有很多种算法，由于它效率很高，所以被广泛使用在很多加密协议的核心当中。不足之处是，交易双方都使用同样钥匙，安全性得不到保证。常见的对称加密有 DES、AES 等。
公开密匙加密（非对称加密）
非对称加密的目的就是保护消息内容, 并且让消息接收方确定发送方的身份。
通信双方必须都有公钥和私钥，公钥任何人都可以获取，而私钥只有自己知道。
假设A与B进行通信，为了保护消息不会被他人窃听，A发送消息时会先用接B的公钥进行加密，然后再以A自己的私钥进行加密，来表明身份。B收到消息之后，首先用A的公钥进行第一层解密，如果解密成功表明消息来自于A，之后再用自己的私钥解密来读取内容。这样就算有人截取了A发送给B的消息，并且还获得了A的公钥，但也只能解开第一层，没有B的私钥仍然无法拿到真正的内容。
- 对于一个公钥，有且只有一个对应的私钥。
- 公钥是公开的，并且不能通过公钥反推出私钥。
- 通过私钥加密的密文只能通过公钥能解密，通过公钥加密的密文也只能通过私钥能解密。
非对称加密不需要共享同一份秘钥，安全性要比对称加密高，但由于算法强度比对称加密复杂，加解密的速度比对称加解密的速度要慢。常见的非对称加密有 RSA、ESA、ECC 等。
HTTPS采用混合加密的方式，由于非对称加密速度较慢，所以只在发送稍后会使用的对称加密的密匙的阶段采用，在密匙交换完成后就用对称加密的方式进行通信。
认证
虽然对称加密看起来已经很完善了，但是仍然存在不足，那就是无法证明公钥就是货真价实的公钥，极有可能在下发公钥的途中已经被掉包了。为了解决这个问题，可以采用数字证书认证机构（CA）颁发的公开密钥证书。下图很清晰的描述了整个流程。
完整性
网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢？通过校验数字签名，流程见下图：
首先来了解下哈希算法，哈希算法能够将任意长度的字符串转化为固定长度的字符串，该过程不可逆，可用来作数据完整性校验。
服务器在发送报文之前做了3件的事：
- 用哈希算法对报文提取定长摘要
- 用私钥对摘要进行加密，作为数字签名
- 将数字签名附加到报文末尾发送给客户端
客户端接收到报文后：
- 用公钥对服务器的数字签名进行解密
- 用同样的算法重新计算出报文的数字签名
- 比较解密后的签名与自己计算的签名是否一致，如果不一致，说明数据被篡改过。
同样，客户端发送数据时，通过公钥加密报文摘要，服务器用私钥解密，用同样的方法校验数据的完整性。
HTTPS通信过程
上图描述了HTTPS的通信步骤，在这个步骤中融合了上述所提到的加密、认证、完整性保护。
具体的过程如下。
客户端发送Client Hello消息开始SSL通信。消息里包含了一个由客户端生成的随机数Random1、支持的SSL version、客户端加密组件列表（即客户端支持的加密算法和密钥长度等）。
服务端能够进行SSL通信时，回复Server Hello消息。消息里包含SSL版本、服务端从接收到的客户端加密组件里选取的一份组件、服务端生成的随机数Random2。
服务端下发公开密钥证书。
服务端发发送Server Hello Done消息，表示最初阶段的SSL握手协商部分结束。
客户端收到服务端传来的证书后，先从 CA 验证该证书的合法性，验证通过后取出证书中的服务端公钥，再生成一个随机数 Random3，再用服务端公钥非对称加密 Random3生成 Pre-master secret。
Client Key Exchange 就是将这个 secret字串传给服务端，服务端再用自己的私钥解出这个 Pre-master secret 得到客户端生成的 Random3。至此，客户端和服务端都拥有 Random1 + Random2 + Random3，两边再根据步骤1、2中协商的算法就可以生成一份秘钥，握手结束后的应用层数据都是使用这个秘钥进行对称加密。为什么要使用三个随机数呢？这是因为 SSL/TLS 握手过程的数据都是明文传输的，并且多个随机数种子来生成秘钥不容易被暴力破解出来。
客户端发送消息提示服务器，之后的通信将使用Pre-master secret作为密钥加密。
客户端发送Finish消息，将前面的握手消息生成摘要（整体校验值）再用协商好的秘钥加密，这是客户端发出的第一条加密消息。服务端接收后会用秘钥解密，能解出来说明前面协商出来的秘钥是一致的。
同6，服务端通知客户端后面再发送的消息都会使用加密。
服务端发送Finish消息，也会将握手过程的消息生成摘要再用秘钥加密，这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密，能解出来说明协商的秘钥是一致的。
客户端和服务端Finish消息交换之后，SSL连接真正建立。从此开始就能进行应用层通信，即发送HTTP请求。
HTTP响应。
通信过程中完整性体现在应用层发送数据时会附加MAC报文摘要，可以理解为MAC=密钥+消息摘要。
比如客户端A想给服务端B发送一条消息，A需要把消息内容和对应的消息摘要都发给B；B通过同样的摘要算法，自然可以知道消息是否被篡改。比如攻击者C将A发送的原始消息和摘要，都篡改成新的消息和摘要，那么这个消息对B来说也是完整的，只不过不是A发的。因为MAC含有秘钥(只有A和B知道)，如果A将消息内容和MAC发给B，虽然C是仍然可以修改消息内容和MAC，但是由于C不知道秘钥，所以无法生成与篡改后内容匹配的MAC。
参考：
《图解HTTP》
713
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
