网络协议-HTTP协议详解-HTTPS

HTTP的缺点

HTTP 协议设计的初衷就是简单方便，但是随着 Web 的发展和交互的复杂，也引入了一些安全性问题：

• 通信使用明文，内容可能会被窃听：HTTP 协议本身不具备加密功能，所以无法对通信整体（请求和响应的内容）进行加密，即 HTTP 报文使用明文方式发送。按照 TCP/IP 协议族的工作机制，通信内容在所有线路上都有可能被窃听。
• 不验证通信方的身份，因此有可能遭遇伪装：HTTP 协议中的请求和响应不会对通信方进行确认，所以任何人都可以发起请求，另外，服务器只要接收到请求，不管对方是谁都会返回一个响应，即使是伪装的客户端。另外，即使是无意义的请求也会处理，无法阻止海量请求下的 DoS 攻击。
• 无法证明报文的完整性，所以有可能已遭篡改：没有任何办法确认发出的请求/响应和接收到的请求/响应是前后相同的，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Main-in-the-Middle attack，MITM）。

针对 HTTP 协议的以上问题，想必你已经知道了目前的解决方案，那就是使用 HTTPS 协议来传输内容，HTTPS 的英文全名是 HTTP Secure 或 HTTP over SSL，即基于 SSL 的安全 HTTP 协议。SSL 会建立一个安全的通信线路，在此线路上传输的内容都会经过加密处理，此外 SSL 还通过证书的方式来确认通信双方的身份，这样就可以从源头上杜绝了通信方被伪装以及信息被窃听和篡改的可能性，从而确保 HTTP 通信的安全。

HTTPS 简介

HTTPS 协议并非是应用层的一种新协议，只是将 HTTP 通信接口部分用 SSL 协议代替。通常，HTTP 会直接和 TCP 通信，当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和 TCP 通信。所以，所谓的 HTTPS，就是身披 SSL 协议外壳的 HTTP 而已，以下是普通的 HTTP 通信和 HTTPS 通信的架构对比图：

采用 SSL 后，HTTP 就拥有了 HTTPS 的加密、证书和完整性保护等功能。

SSL 是独立于 HTTP 的协议，所以不光是 HTTP 协议，其它运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是当今世界上应用最为广泛的网络安全技术。

在具体介绍 HTTPS 的底层工作原理之前，我们有必要先介绍几个 Web 安全相关的术语。

对称加密和非对称加密

对称加密

在对称加密算法中，加密和解密使用的密钥是相同的。在互联网上转发密钥，如果通信被监听那么密钥就会落入攻击者之手，存在安全隐患，另外还得设法安全地保管接收到的密钥。

非对称加密

在非对称加密算法中，加密使用的密钥和解密使用的密钥是不相同的。一把是作为公开的公钥，另一把是作为谁都不能给的私钥。公钥加密的信息，只有私钥才能解密；私钥加密的信息，只有公钥才能解密。

使用这种加密方式，发送密文的一方使用公钥进行加密，对方收到加密信息后，使用私钥进行解密。利用这种方式，不需要发送用来解密的私钥，也不必担心密钥被攻击者窃听而盗走，故而安全性更高，但与对称加密相比，算法和实现更加复杂，处理速度更慢。

HTTPS 充分两种加密方式的优势，在交换密钥环节使用非对称加密，之后的建立通信交换报文阶段则使用对称加密，后面我们介绍 HTTPS 底层工作原理时还会详细介绍。

数字证书

通过 OpenSSL 提供的命令就可以生成私钥和公钥，但是需要权威机构颁发证书（Certificate）才能被承认，否则我们无法判断通信中传递的公钥是否是目标服务器返回的。

生成证书需要发起一个证书请求，然后将这个请求发给一个权威机构（客户端和服务端都信任的第三方结构）去认证，这个权威机构我们称之为 CA（Certificate Authority）。权威机构会给证书敲一个章，也就是所谓的签名算法。

签名算法大概是这样工作的：一般是对信息做一个 Hash 计算，得到一个 Hash 值，这个过程是不可逆的，也就是说无法通过 Hash 值得出原来的信息内容。在把信息发送出去时，把这个 Hash 值通过 CA 的私钥加密后，作为一个签名和信息一起发出去。

CA 用自己的私钥给网站的公钥签名，就相当于给网站背书，形成了网站的证书。

CA 的公钥需要更牛的 CA 给它签名，形成 CA 的证书，要想看 CA 的证书是否可靠，要看 CA 的上级证书的公钥，能不能解开这个 CA 的签名。这样层层上去，直到全球皆知的几个著名大 CA，称为 root CA，做最后的背书。通过这种层层授信背书的方式，从而保证了非对称加密模式的正常运转。

服务器会将这份 CA 颁发的公钥证书（也可以叫做数字证书）发送给客户端，以进行非对称加密方式通信。

接到证书的客户端可使用 CA 提供的公钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：

• 认证服务器公钥的是真实有效的数字证书认证机构；
• 服务器的公钥是值得信赖的。

此处 CA 的公钥必须安全转交给客户端，如何安全转交是件很困难的事，因此，大多数浏览器开发商发布版本时，会事先在内部植入常见 CA 的公钥。

HTTPS 的底层实现原理

非对称加密在性能上不如对称加密，但是安全性上要更好，因此 HTTPS 综合运用了这两种加密方式的优势，使用非对称加密传输对称加密需要用到的密钥，而真正的双方大数据量的通信都是通过对称加密进行的，结合数字证书（包含公钥信息）验证服务端公钥的真实性，HTTPS 的底层原理如下：

• 当我们访问一个 HTTPS 网站的时候，客户端通过发送 Client Hello 报文开始建立与服务器的 SSL 通信，报文中包含了 SSL 协议版本、加密组件、压缩算法等信息，另外，还有一个随机数，用于后续对称加密密钥的协商。
• 服务器可以进行 SSL 通信时，会以 Server Hello 报文作为应答，和客户端一样，在报文中包含 SSL 协议版本、加密组件、压缩算法等信息，同时还有一个随机数，用于后续对称加密密钥的协商。
• 接下来，服务器会以 Certificate 报文的形式给客户端发送服务端的数字证书，其中包含了非对称加密用到的公钥信息。最后，服务器还会发送 Server Hello Done 报文告知客户端，最初阶段的 SSL 握手协商部分结束。
• 客户端当然不相信这个证书，于是从自己信任的 CA 仓库中，拿 CA 证书里面的公钥去解密 HTTPS 网站的数字证书（证书是通过 CA 私钥加密的，所以要用公钥解密），如果能够成功，则说明 HTTPS 网站是可信的。
• 证书验证完毕之后，觉得这个 HTTPS 网站可信，于是客户端计算产生随机数字 Pre-master，用服务器返回的数字证书中的公钥加密该随机数字，再通过 Client Key Exchange 报文发送给服务器，服务器可以通过对应的私钥解密出 Pre-master。到目前为止，无论是客户端还是服务器，都有了三个随机数，分别是：自己的、对端的，以及刚生成的 Pre-master 随机数。通过这三个随机数，可以在客户端和服务器生成相同的对称加密密钥。
• 有了对称加密密钥，客户端就可以通过 Change Cipher Spec 报文告知服务器以后都采用该密钥和协商的加密算法进行加密通信了。
• 然后客户端还会发送一个 Encrypted Handshake Message 报文，将已经商定好的参数，采用对称加密密钥进行加密，发送给服务器用于数据与握手验证。
• 同样，服务器也可以发送 Change Cipher Spec 报文，告知客户端以后都采用协商的对称加密密钥和加密算法进行加密通信了，并且也发送 Encrypted Handshake Message 报文进行测试。当双方握手结束之后，就可以通过对称加密密钥进行加密传输了。

这个过程除了加密解密之外，其他的过程和 HTTP 是一样的，过程也非常复杂。

上面的过程只包含了 HTTPS 的单向认证，也即客户端验证服务端的证书，大部分场景下使用的都是单向认证，也可以在更加严格安全要求的情况下，启用双向认证，双方互相验证证书，比如银行的网银系统就是这样，需要客户端安装数字证书后才能登录，其实就要服务端要要验证客户端的合法性。

SSL 与 TLS

TLS（Transport Layer Security，传输层安全）是 SSL 的升级版（Secure Socket Layer，安全套接层），建立在 SSL 3.0 协议规范之上，由于 SSL 这一术语非常常用，所以通常我们把 SSL 和 TLS 统称为 SSL，从这个角度来说，不管是基于 TLS 还是 SSL 实现的 HTTPS，将其描述为 HTTP over SSL 并没有什么问题。