HTTPS 详解
背景
随着用户安全意识的增强，近两年网络协议已逐步从 Http 协议向 Https 协议开始过度，目前大多数 APP/Web 都开始使用 Https 协议，这里以 Http 逐步发展成 Https 协议的过程为导向，介绍 Https 的诞生过程。
HTTP 协议的缺点
通信使用明文；
不验证通信方的身份；
无法验证报文的完整性；
通信使用明文
通信使用明文意味着安全性大大降低，当通信过程被窃听后，无需花费额外的投入就可看到传输的数据。例如使用抓包工具，无需任何配置就可查看任何使用 HTTP 协议的通信数据；
不验证通信方身份
不验证通信方的身份，将导致通信过程被窃听后，可能会遭遇伪装，例如使用抓包工具抓取数据后，就可按照数据包的格式构造 HTTP 请求；
无法验证报文的完整性
不验证报文的完整性，数据在传输过程中就可能被篡改，本来想看喜洋洋呢，结果数据在传输过程中被换成了光头强。
解决方案
通信使用明文
既然明文不安全，那可以考虑使用密文，即：对通信数据进行加密。即便数据被窃听，对方依然需要花费一定的投入来破解，这种高昂的成本间接提高了安全级别。
不验证通信方身份
和服务端使用相同的算法，根据网络请求参数生成一个 token，请求/应答时根据 token 来确定双方的身份。
无法验证报文的完整性
使用 MD5/SHA1 等算法进行完整性验证, 对方接收到数据后，根据同样的算法生成散列值，比对发送方生成的散列值，即可验证数据的完整性。 解决了 HTTP 的以上问题，HTTPS 协议就诞生了：
Https = Http + 加密 + 认证 + 完整性验证
而对于加密，认证和完整性验证这些特点，TCP/IP 协议族中已经提供了一个用于数据安全传输的协议——SSL（Secure Socket Layer）安全套接层，虽然也是基于 TCP 实现的，但 SSL 并不是应用层协议，而是一个位于应用层与传输层之间的协议，（具体协议相关的理论知识可参考网络编程之理论知识。）其目的就是为上层的应用层协议提供安全的传输通道。这时 Https 协议就可用以下形式表示：
Https = Http + SSL
这样看来，HTTPS 并不是一个单独的应用层协议，而只是 Http 使用 SSL 通道进行数据传输的过程。那么对于 Https, 只需要了解 Http（参考HTTP详解）和 SSL 协议即可。而所谓的 HTTPS 报文也就是 SSL 报文：
SSL 协议
SSL（Secure Socket Layer）安全套接层，是一种位于应用层与传输层之间，为网络通信提供安全及完整性验证的一种网络协议。
相对于 TCP 或 HTTP 协议，SSL 协议要复杂很多。由于它也是建立在 TCP 协议之上的，所以在使用 SSL 传输数据之前需要先进行三次握手和服务器建立连接，具体的流程如图所示：
SSL 协议的握手过程
客户端先给服务端发送一个消息，消息内容包括：客户端支持的加密方式，支持的压缩方法，SSL 的版本号，客户端生成的随机数，文本内容“Hello”等；
服务端接收到消息后，也回发一个 Hello，并携带从客户端支持的加密方式中选择的加密方式，服务端生成的随机数，服务端的 SSL 版本号等信息；
随后服务器给客户端发送一个 Certificate 报文，报文中包含服务端的公钥证书；
紧接着服务器给客户端发送 Server Hello Done, 表示最初的协商握手过程结束；
客户端接收到服务端发送的握手结束的消息后，以 Client Key Exchange 作为回应，此报文中包含通信加密过程中使用的一种被称为 Pre-master secret 的随机密码串，并使用第三步接收到的公钥证书进行了加密；
接着客户端发送 Change Cipher Spec 报文，该报文告知服务端，此步骤之后的所有数据将使用第五步中生成的 master secret 进行加密（master secret 的生成过程看后面的介绍）；
随后客户端发送 Finish 报文，此报文中包含连接至今所有报文的整体校验值，用于完整性验证；
服务端接收到客户端发送的 Change Cliper Spec 报文后，同样以 Change Cliper Spec 报文作为回应；
接着服务端发送 Finish 报文给客户端，表示服务端已正确解析客户端发送的整体校验值，至此，SSL 握手的过程结束。
随后开始使用 HTTP 协议传输使用 master secret 加密过的数据。
说明
前两步是协商加密算法以及传输各自生成的随机数（为后续生成 master secret 做准备）的过程；
第三步服务端将自己的证书发送给客户端，这个证书中包含一个数字签名（CA 签名）和服务端 CA 证书的公钥，客户端对证书中包含的服务端信息进行 Hash, 同时使用接收到的公钥对数字证书解密，获取其中的 Hash 值，与前面计算得到的 Hash 值进行比较，即可验证证书的有效性（完整性 &真实性）；
服务端收到客户端发送的 Change Cipher Spec（第五步），会使用自己的私钥进行解密，获取报文中的 Pre-master secret，这时通信双方都拥有对方的 Random(前两步生成的)，Pre-master secret，以及自身的 Random, 将三个数作为种子通过算法生成 master secret, 用来加密后续 Http 请求过程中的数据。其中 master secret 的生成规则为:
master_secret = MD5(pre_master_secret + SHA('A' + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('BB' + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('CCC' + pre_master_secret + ClientHello.random + ServerHello.random));
更详细的有关 SSL 协议的内容可参考：RFC 6101 SSL
为什么需要这么复杂
两个方面的考量：安全，效率。如果直接使用对称加密的方式进行加密，如果密钥不被泄漏当然也是安全，但问题是：密钥如何传递给另一端呢，在数据传输过程中，如果通信被窃听，则密钥被窃取，那此时加密就没有任何意义了。那可不可以使用非对称加密的方式呢？理论上是可以的，数据传输之前，服务端只需要将自己的公钥传输给客户端，客户端在传输数据时，使用
接收的公钥进行加密，服务端接收到数据后使用私钥进行解密即可。但这里有个不容忽视的问题：效率。非对称加密需要大量计算，肯定会占用很多硬件资源，所以效率太低。所以为了解决安全和效率问题，SSL 使用了对称加密（加密和解密使用同样的密钥）和非对称加密（公钥加密，私钥解密）组合的方式：使用非对称加密的方式传输对称加密中生成密钥的种子（pre master secret）【对应上面的第五步】，然后使用对称加密的方式对通信数据进行加密【对应上面的第十步】，既保障了密钥的安全性，也提高了加密速度。
评论