1.6.5 HTTPS
在谍战剧里，情报如何不被截获，不被破译，几乎是全剧的主线剧情之一。某电台通过某个频道发送一串数字，然后潜伏人员一般会拿密码本，译码后得到原文。这个密码本就是对称加密中的密钥，发送方和接收方按照密码本分别进行加密和解密工作。如果密码本被敌人截获，则后果极为严重，通常能够做的也就是更换密码本。
早期计算机都是单机状态，保证数据的安全依赖于加密算法的可靠性。如果加密算法可靠，即使存储介质被窃取，对方想把密文恢复明文也是十分困难的。DES 加密算法是一种对称加密算法，它几乎让破解者无法找到规律，即使暴力破解也很难还原出明文。
发展到网络时代，整个网络中最频繁、最重要的操作就是网络中各终端之间的通信。在传输层本身不会做任何的加密，这就好比一辆满载黄金的马车在驿道奔驰，很难不让网络上的黑客视而不见。如何保证通信之间数据传输的安全性，成为了计算机网络时代最重要的安全课题。说到对网络传输数据的加密，必须要先说安全套接字层（Secure Socket Layer，SSL）。SSL 协议工作于传输层与应用层之间，为应用提供数据的加密传输。而HTTPS 的全称是HTTP over SSL，简单的理解就是在之前的HTTP传输上增加了SSL 协议的加密能力。
我们可以通过对称加密算法对数据进行加密，比如DES，即一个主站与用户之间可以使用相同的密钥对传输内容进行加解密。是否可以认为这样就完全没有风险呢？答案显然是否定的。因为密钥几乎没有什么保密性可言，如果与每一个用户之间都约定一个独立的密钥，如何把密钥传输给对方，又是一个安全难题。在互联网上，IP 报文好比官道上运送粮草、黄金、物资的载体，很容易被人盯上，密钥本身如果被盗，那么再复杂的密钥也是摆设。自然的想法是在密钥之上再加密，这就是递归的穷举问题了。
有没有一种方式，使报文被截取之后，黑客依然无计可施呢？一种全新的算法RSA 出现了。它把密码革命性地分成公钥和私钥，由于两个密钥并不相同，所以称为非对称加密。私钥是用来对公钥加密的信息进行解密的，是需要严格保密的。公钥是对信息进行加密，任何人都可以知道，包括黑客。
非对称加密的安全性是基于大质数分解的困难性，在非对称的加密中公钥和私钥是一对大质数函数。计算两个大质数的乘积是简单的，但是这个过程的逆运算（即将这个乘积分解为两个质数）是非常困难的。而在RSA 的算法中，从一个公钥和密文中解密出明文的难度等同于分解两个大质数的难度。因此在实际传输中，可以把公钥发给对方。一方发送信息时，使用另一方的公钥进行加密生成密文。收到密文的一方再用私钥进行解密，这样一来，传输就相对安全了。
但是非对称加密并不是完美的，它有一个很明显的缺点是加密和解密耗时长，只适合对少量数据进行处理。回到前面的例子中，我们担心对称加密中的密钥安全问题，那么将密钥的传输使用非对称加密就完美地解决了这个问题。实际上，HTTPS 也正是通过这样一种方式来建立安全的SSL 连接的。按照上述逻辑，用户甲与用户乙进行非对称加密传输的过程如下：
（1）甲告诉乙，使用RSA 算法进行加密。乙说，好的。
（2）甲和乙分别根据RSA 生成一对密钥，互相发送公钥。
（3）甲使用乙的公钥给乙加密报文信息。
（4）乙收到信息，并用自己的密钥进行解密。
（5）乙使用同样方式给甲发送信息，甲使用相同方式进行解密。
这个过程，看起来似乎无懈可击，但是在TCP/IP 里，端到端的通信，路途遥远，夜长梦多。在（2）中，如果甲的送信使者中途被强盗截住，在严刑拷打之下，强盗知道使者是去送公钥的，虽然没有办法破解甲的加密信息，但是可以把这个使者关起来，自己生成一对密钥，然后冒充甲的使者到乙家，把自己的公钥给乙。乙信了，把银行卡密码、存款金额统统告诉了中间的强盗。
所以，在解决了加密危机之后又产生了信任危机。如何解决信任问题呢？如果有一个具有公信力的组织来证明身份，这个问题就得到了解决。CA（Certificate Authority）就是颁发HTTPS 证书的组织。HTTPS 是当前网站的主流文本传输协议，在基于HTTPS 进行连接时，就需要数字证书。如图1-28 所示，可以看到协议版本、签名方案、签发的组织是GlobalSign，这个证书的有效期至2018 年10 月31 日。
图1-28 CA 数字证书
访问一个HTTPS 的网站的大致流程如下：
（1）浏览器向服务器发送请求，请求中包括浏览器支持的协议，并附带一个随机数。
（2）服务器收到请求后，选择某种非对称加密算法，把数字证书签名公钥、身份信息发送给浏览器，同时也附带一个随机数。
（3） 浏览器收到后，验证证书的真实性，用服务器的公钥发送握手信息给服务器。
（4）服务器解密后，使用之前的随机数计算出一个对称加密的密钥，以此作为加密信息并发送。
（5）后续所有的信息发送都是以对称加密方式进行的。
我们注意到在证书的信息中出现了传输层安全协议（Transport Layer Security，TLS）的概念。这里先解释TLS 和SSL 的区别。TLS 可以理解成SSL 协议3.0 版本的升级，所以TLS 的1.0 版本也被标识为SSL 3.1 版本。但对于大的协议栈而言，SSL 和TLS 并没有太大的区别，因此在Wireshark 里，分层依然用的是安全套接字层（SSL）标识。
在整个HTTPS 的传输过程中，主要分为两部分：首先是HTTPS 的握手，然后是数据的传输。前者是建立一个HTTPS 的通道，并确定连接使用的加密套件及数据传输使用的密钥。而后者主要使用密钥对数据加密并传输。
首先来看HTTPS 是如何进行握手的，如图1-29 所示是一个完整的SSL 数据流和简单流程。
图1-29 HTTPS 连接建立过程
第一，客户端发送了一个Client Hello 协议的请求：在Client Hello 中最重要的信息是Cipher Suites 字段，这里客户端会告诉服务端自己支持哪些加密的套件。比如在这次SSL 连接中，客户端支持的加密套件协议如图1-30 所示。
图1-30 Cipher Suites
第二，服务端在收到客户端发来的Client Hello 的请求后，会返回一系列的协议数据，并以一个没有数据内容的Server Hello Done 作为结束。这些协议数据有的是单独发送，有的则是合并发送，这里分别解释下几个比较重要的协议，如图1-31 所示。
图1-31 SSL 协议
（1）Server Hello 协议。主要告知客户端后续协议中要使用的TLS 协议版本，这个版本主要和客户端与服务端支持的最高版本有关。比如本次确认后续的TLS 协议版本是TLSv1.2，并为本次连接分配一个会话ID（Session ID）。此外，还会确认后续采用的加密套件（Cipher Suite），这里确认使用的加密套件为TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。该加密套件的基本含义为：使用非对称协议加密（RSA）进行对称协议加密（AES）密钥的加密，并使用对称加密协议（AES）进行信息的加密。
（2）Certificate 协议。主要传输服务端的证书内容。
（3）Server Key Exchange。如果在Certificate 协议中未给出客户端足够的信息，则会在Server Key Exchange 进行补充，如图1-32 所示。比如在本次连接中Certificate未给出证书的公钥（Public Key），这个公钥的信息将会通过Server Key Exchange 发送给客户端。
图1-32 Server Key Exchange
（4）Certificate Request。这个协议是一个可选项，当服务端需要对客户端进行证书验证的时候，才会向客户端发送一个证书请求（Certificate Request）。
（5）最后以Server Hello Done 作为结束信息，告知客户端整个Server Hello过程结束。
第三，客户端在收到服务端的握手信息后，根据服务端的请求，也会发送一系列的协议。
（1）Certificate。它是可选项。因为上文中服务端发送了Certificate Request 需要对客户端进行证书验证，所以客户端要发送自己的证书信息。
（2）Client Key Exchange。它与上文中Server Key Exchange 类似，是对客户端Certificate 信息的补充，在本次请求中同样是补充了客户端证书的公钥信息，如图1-33所示。
图1-33 Client Key Exchange
（3）Certification Verity。对服务端发送的证书信息进行确认。
（4）Change Cipher Spec。该协议不同于其他握手协议（Handshake Protocol），而是作为一个独立协议告知服务端，客户端已经接收之前服务端确认的加密套件，并会在后续通信中使用该加密套件进行加密。
（5）Encrypted Handshake Message。用于客户端给服务端加密套件加密一段Finish 的数据，用以验证这条建立起来的加解密通道的正确性。
第四，服务端在接收客户端的确认信息及验证信息后，会对客户端发送的数据进行确认，这里也分为几个协议进行回复。
（1）Change Cipher Spec。通过使用私钥对客户端发送的数据进行解密，并告知后续将使用协商好的加密套件进行加密传输数据。
（2）Encrypted Handshake Message。与客户端的操作相同，发送一段Finish 的加密数据验证加密通道的正确性。
最后，如果客户端和服务端都确认加解密无误后，各自按照之前约定的Session Secret 对Application Data 进行加密传输。
