HTTPS协议

由于HTTP协议是采用明文传输的方式，因此带来了很大的数据安全隐患，所以在最近几年的时间内，大部分平台都采用了HTTPS逐渐取代了HTTP，但HTTPS并不是一种全新的协议，而是建立在HTTP协议的基础之上，为其添加了一层TLS/SSL，从而实现数据的加密传输，确保足够的安全性，区别如下：

相较于HTTP而言，HTTPS则拥有更高的安全性，例如数据加密传输、报文完整性效验、身份认证判断等。解决了HTTP协议中一直存在的安全问题，如明文传输数据会遭受窃听风险、不验证报文完整性会导致数据被篡改、不效验通信方身份会导致“他人”伪造通信对端劫持客户端等。

1.1、SSL与TLS加密层

   在HTTPS中最关键的是数据安全传输，而负责这块的则是SSL/TLS层，而该层中的功能实现主要依赖于三类加密算法：哈希散列加密、对称加密及非对称加密算法，其中常用的算法如下：

• 哈希散列加密算法：MD5、SHA1、SHA256等。
• 对称加密算法：AES-CBC、AES-GCM、DES、3DES等。
• 非对称加密算法：RSA、DSA、ECC、DH等。

上述简单了解了一些SSL/TLS基本内容后，再一步步的从0开始推导HTTP→HTTPS的演变过程。

在之前的HTTP协议中，数据都是明文传输的，如下：

前面提及过，这种明文传输的方式安全性很低，因此如果要提高安全性，最简单有效的方式就是对传输的数据进行加密，如HTTPS中的传输方式：

在这个模型中，双方采用相同的密钥、加/解密算法处理数据，这种方式则被称为对称加密。

对称加密：是指加密通信的双方加/解密的方式都是相同的，类似一个天平，两边都是“对称”的。

不过显然这种方式存在天然的弊端，因为通信的双方都采用相同的加密方式，一般服务端与客户端通信都是1-N的模式，那么一个客户端的加密方式被“破解”，就会导致所有客户端的数据都能够通过这种方式解密，从而被窃取真实数据。

此时为了防止“第三者”破解加密数据又该怎么办呢？对于每个客户端通信采用不同的加密算法，但这显然不可能，因为性能够好、加密性够强的算法就那么些，而客户端理论上是无穷尽的，因此没有那么多的加密算法来满足这个方案。

既然没有那么多的加密算法，那能不能换个思路呢？给每个客户端发送不同的密钥，每个客户端都采用不同的密钥加密数据，然后再放在网络上传输，这样是不是就解决了原本的问题呢？答案是Yes，不过此刻又引出了一个新的问题：又该如何向每个客户端发送不同的密钥呢？

因为客户端与服务端之间加密通信，那必然需要双方各持相同的密钥后，才能够解密对方的数据，所以通信的密钥必然是在一端生成后发送给另一端的，此时又该如何保证传输密钥时，密钥不会被“第三者”窃取呢？因为毕竟密钥被窃取后，所谓的安全性也自然成了空谈。

• 熊猫：嗯？等等！传输密钥不安全，加个密不就好啦？
• 竹子：确实如此，但，如何确保密钥的加密方式不被破解呢？
• 熊猫：简单啊，采用不同的加密方式传输密钥不就好啦？
• 竹子：嗯，对，那么用何种方式确保发送给每个客户端的密钥加密方式不同呢？
• 熊猫：用不同的密...钥.....啊.....
• 熊猫：完了，芭比Q了，进死循环出不来了。

确实，如果再以对称加密的思维去思考这个问题，确实进死胡同无解了，此时我们得换种思考方式，即切换到大名鼎鼎的非对称加密方式去解决这个问题。

非对称加密：对称加密算法在加/解密时采用的密钥都是相同的，而非对称加密算法则恰巧相反，非对称加密方式中存在两个密钥：公钥、私钥。
如果用公钥加密的数据，只有用对应的私钥才能解密；如果用私钥加密的数据，那只有用对应的公钥才能解密。因为加/解密使用两个不同的密钥，最终则被称为：非对称加密。

采用非对称加密方式的服务端，会首先生成两个密钥，将其一把作为公钥发送给所有客户端，另一把则当作私钥仅自己保存：

但其实非对称加密也存在一个经典的问题，也就是依旧无法避免“第三者”介入，先上图：

先仔细观察上图中的步骤，万一“第三者”将服务端返回的“真公钥”替换成了自己的“假公钥”，从而最终导致了数据的泄露又该怎么办呢？

其实这本质上是两个问题：
①数据遭受篡改。这个问题发生的原因是：客户端没有效验数据完整性，因此对于对端发送的数据无条件信任，最终就导致了客户端无法区分数据究竟是第三者发出来的，还是真正的服务端返回的。
②第三者将公钥掉包。这个问题的主要原因在于：客户端没有效验通信对端，即服务端的身份，因此无法区分传回的究竟是服务端，还是第三者的公钥。
要解决上述中的两个问题，那必须从问题的根源「客户端」着手解决，该怎么解决呢？可以引入「数字签名、数字证书」的概念。
其中数字签名主要防止了数据被篡改问题，数据证书解决了公钥被掉包问题。

不过在讲述具体如何解决的流程之前，我认为有必要先讲述清楚「数字签名、数字证书」的概念，「数字签名、数字证书」是从权威的第三方机构中申请的，这类机构被称为CA机构申请流程一般为：

• ①服务端先在本地生成一对密钥，然后携带公钥、网站信息、企业信息等数据去CA机构申请；
• ②CA机构根据提交的信息核实身份后，会通过单向的哈希算法（如MD5）对这些信息进行加密，加密后的内容被称为“信息摘要”，因为单向哈希算法的不可逆特性，所以只要被加密的内容发生了丁点改变，加密后得到的内容也会存在天差地别，因此可以有效防止信息被篡改；
• ③紧接着CA机构会通过自己的密钥对“信息摘要”进行再次加密，加密后的内容被称为「数字签名」，而「申请信息、服务器公钥、数字签名」组合在一起，最终被称为「数字证书」。

而客户端一般在加密通信前，会先向服务端获取公钥，服务器则会将「数字证书」返回给客户端，客户端拿到证书后，会首先通过CA机构的公钥解密证书中的「数字签名」，能够解密成功则代表该证书来自于值得信赖的权威机构，最终就得到了CA哈希后的“信息摘要”，然后客户端会使用与CA机构相同的Hash算法对「数字证书」中的「申请信息、服务器公钥」再次生成一份“摘要”，最后拿着生成的“信息摘要”与解密后的“信息摘要”对比，如果一致则代表数据未被篡改过，最终客户端就可以使用证书中的公钥进行加密通信，流程如下：

注意：客户端OS与浏览器中都会提前预装CA机构的根证书，这些根证书中已包含了CA公钥、当前CA机构使用的Hash算法等。

   由于数字签名是采用单向哈希算法，生成的“信息摘要”是不可逆的，当服务器返回的证书内容被篡改后，客户端在生成摘要比对时，结果肯定不匹配，因此客户端会拒绝连接。
但仅这样也无法避免公钥被掉包，也就是“第三者”也去CA机构申请证书，然后在中间直接将整个证书替换成自己的，最终客户端获取的依旧是“第三者”的公钥，所以为了解决这个问题，CA机构颁发的数字证书中，还会涵盖网站信息（如域名、所有者等），当证书被掉包后，客户端发现返回的证书与请求的网站信息并不同，那么依旧会拒绝连接。

为什么会有第三者呢？因为网络传输数据的通信链路是不可预计的，因此数据会经过很多节点的中转，同时在实际开发过程中也有不少请求需要走代理，也包括会存在网络攻击者，因此多方面的原因都有可能导致“第三者”介入。

经过上述一系列手段后，解决了非对称加密传输公钥时的不安全问题，但非对称加密方式，由于加/解密过程复杂，因此性能会比对称加密要低不少，因此在HTTPS中是非对称加密与对称加密混合使用的模式，其中数据是对称加密方式传输的，而对称加密的密钥是通过非对称加密方式传输的。

1.2、HTTPS工作原理

   上面叭叭一大堆，各位看到这里难免有些头大，所以接下来结合完整的HTTPS流程梳理一下，先上图：

• ①客户端先向服务端请求公钥，其实就是与服务端443端口建立连接的过程。
• ②服务端接收到请求后，会将数字证书返回给客户端。
• ③客户端收到证书后，会经过图中的几步效验操作，确认证书合法后，会先生成一个对称密钥，然后通过证书中的公钥对其加密，并发给服务端。
• ④服务端收到公钥加密后的对称密钥后，通过自己的私钥对其解密。
• ⑤最终客户端、服务端都拥有了一把对称密钥，接下来则通过对称密钥传输数据。

整个HTTPS的大体逻辑如上，但实际生成对称密钥的过程却并非如此，在HTTPS中是需要经过RSA握手的步骤。

1.3、TLS层的握手过程

   前面谈及的过程其实简化了很多，主要是为了便于理解HTTPS的整体流程，但实际HTTPS远比前面所赘述的流程复杂很多，接下来则详细阐述一下其中的TLS握手过程。

TLS/1.2之前的版本都是采用RSA算法进行密钥交换，但TLS/1.2及之后的版本中主要采用ECDHE算法实现。

一般而言，TLS层在交换密钥时都会经历多个步骤，其中可分为11个小阶段，4次握手阶段，如下：

下面我们通过Wireshark抓包工具实际分析一下具体过程。

1.3.1、TLS第一次握手

①客户端：Client Hello

在TLS一次全新的握手流程中，客户端会首先发出一条Client Hello的信息，并会附带传递一些客户端的信息，如下：

Handshake Protocol: Client Hello 
  Handshake Type: Client Hello (1) 
  Length: 223 
  Version: TLS 1.2 (0x0303) 
  Random: bh21b273g32de8b0e4f13de22d33f24e6a671e62f82hgc2fdh1f2hbabe4326 
  Session ID Length: 0 
  Cipher Suites Length: 92 
  Cipher Suites (46 suites) 
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256 (0xc030) 
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02c) 
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc028) 
    ... 

• Length：报文长度。
• Version：客户端支持的最佳TLS版本号。
• Random：随机数，后续用于生成对称密钥，为了区分则称为client-random。
• Session ID：第一次握手时该值为空，后续请求中会有会话ID(用于恢复)。
• Cipher Suites：客户端支持的密码套件，优先级从高到低排序。

解读密码套件：

套件由密钥交换算法+签名算法+对称加密算法+摘要生成算法四部分组成，其中：

• ECDHE为密钥交换算法，用于TLS握手阶段。
• RSA为签名算法，用于效验数字证书阶段时的身份验证。
• AES为对称加密算法，长度及为256位，分组模式为GCM，用于数据传输阶段。
• SHA256为摘要生成算法，用于消息认证及产生随机数（稍后分析）。

1.3.2、TLS第二次握手

②服务端：Server Hello

服务端收到客户端的Client Hello信息后，会给予一个Server Hello的信息响应：

Handshake Protocol: Server Hello 
    Handshake Type: Server Hello (2) 
    Length: 89 
    Version: TLS 1.2 (0x0303) 
    Random: 21ds544sda21vcsqaaa124dsac2za2bc6472c45b54c0a21c666d2sda2q14514d555f6f 
    Session ID Length: 32 
    Session ID: 676fb1435152124ef4ce41af4cb77s5w13aa1c2e6w7c3e5c45da16cdf414f22c2 
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) 

在服务端响应的Server Hello信息中，主要会确认自己是否支持TLS版本、从客户端支持的密码套件中选择一套以及也会生成一个随机数server-random。

③服务端：Certificate

在响应了客户端信息后，紧接着服务端会将自己的数字证书发给客户端：

Handshake Protocol: Certificate 
    Handshake Type: Certificate (11) 
    Length: 2781 
    Certificates Length: 2778 
    Certificates (2778 bytes) 
        Certificate Length: 1407 
        Certificate: 证书1....
        Certificate Length: 1365 
        Certificate: 证书2....
        .......

客户端收到服务端的这个响应后，会先去验证证书的证实有效性，如果有效则继续，如果证书无效则会发出警告信息并中断TCP连接，例如www.baidu.com的证书如下：

④服务端：Server Key Exchange

向客户端发送了数字证书后，紧接着服务端会通过一条Server Key Exchange消息，将密钥交换算法需要用到的数据/参数携带上去，并向客户端发送：

Handshake Protocol: Server Key Exchange 
    Handshake Type: Server Key Exchange (12) 
    Length: 329 
    EC Diffie-Hellman Server Params 
        Curve Type: named_curve (0x03) 
        Named Curve: secp256r1 (0x0017) 
        Pubkey Length: 65 
        Pubkey: 6615dc2a1a2a4d482efc777cf1d804d...
        Signature Algorithm: rsa_pkcs1_sha512 (0x0601) 
            Signature Hash Algorithm Hash: SHA512 (6) 
            Signature Hash Algorithm Signature: RSA (1) 
        Signature Length: 256 
        Signature: 5a1dc12ds152b4a7445t2....

上面即是ECDHE密钥交换算法的消息内容，不同的密钥交换算法，其具体的内容也会不同，这些内容发送给客户端的主要目的是：提供给客户端计算主密钥需要的另一个值：“预主密钥(premaster secret)”。

⑤服务端：Certificate Request

Certificate Request这个消息是服务端要求客户端上报证书，这一步是可选的，因为HTTPS可以选择双向验证，对于安全性要求高的场景会用到，默认是不发送这条信息的。

⑥服务端：Server Hello Done

在传输完上述中的所有信息后，服务端最后会发送一条Server Hello Done的信息，通知客户端Server Hello阶段结束，即告知客户端“第二次握手”完成。

1.3.3、TLS第三次握手

⑦客户端：Client Key Exchange

在第二次握手阶段，客户端根据服务端发来的信息：公钥、算法、参数等生成了第三个随机数premaster secret（预主密钥），Client Key Exchange这条信息就是将该值通过公钥加密，然后传给服务端：

Handshake Protocol: Client Key Exchange 
    Handshake Type: Client Key Exchange (16) 
    Length: 66 
    EC Diffie-Hellman Client Params 
        Pubkey Length: 65 
        Pubkey: o1deca231a1x123eeq12c6bb786.....

服务端收到该消息后，会通过自己的私钥解密，然后得到第三个随机数，到此刻为止，客户端和服务端之间都各自拥有了三个随机数：client-random、server-random、premaster secret，两边再根据相同的算法计算，就可以生成一个密钥，后续的应用层的数据传输就是通过该密钥作为对称密钥进行加密传输。

⑧客户端：Change Cipher Spec

Change Cipher Spec这条消息是一条事件消息：

TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec 
    Content Type: Change Cipher Spec (20) 
    Version: TLS 1.2 (0x0303) 
    Length: 1 
    Change Cipher Spec Message

表示通知服务端密钥已经计算出来了，后续的数据传输都会通过前面协商出的密钥进行加密传输，代表后续切换到对称加密模式。

⑨客户端：Encrypted Handshake Message

Encrypted Handshake Message这条消息作用是：用于测试对称密钥是否能够正常工作：

TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message 
    Content Type: Handshake (22) 
    Version: TLS 1.2 (0x0303) 
    Length: 60 
    Handshake Protocol: Encrypted Handshake Message 

这是客户端第一条通过对称密钥加密传输的信息，如果服务端接受后，也能够通过计算出的密钥解开，即代表前面协商计算出的对称密钥没有问题。

1.3.4、TLS第四次握手

⑩服务端：Change Cipher Spec

和客户端的Change Cipher Spec消息作用相同：

TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec 
    Content Type: Change Cipher Spec (20) 
    Version: TLS 1.2 (0x0303) 
    Length: 1 

至此，客户端和服务端双方能够正常加密通信，TLS握手阶段结束。

1.3.5、TLS1.2之前及TLS1.3中的握手区别

其实TLS/1.2版本对比之前的TLS版本，握手过程中唯一不同点在于：采用的密钥交换算法不同，在之前的版本中都采用RSA算法生成对称密钥，而1.2版本中用的是ECDHE算法。

在TLS/1.3版本中，主要是缩减了TLS握手的次数，从原本的“四次握手”缩减到了三次握手，同时也减少了整个握手流程中的步骤，如下：

从图中可以明显看出，客户端计算出第三个随机数后，并未将其传回给服务端，服务端这边也是自己通过已有的参数计算得到的，然后双方之间再根据三个随机数计算出最终的对称密钥，最后再发一条测试信息，能够正常加解密则代表密钥可用，从而完成了整个握手流程。

1.3.6、HTTPS中对于TLS握手的优化

由于TLS握手过程比较繁杂，因此在HTTPS中也有一些优化策略，如会话复用，而会话复用即恢复会话，主要有两种方式，一种是Session-ID，另一种则是Session Ticket，先聊聊Session-ID。

在TLS握手的第一步Client Hello中，会附带session id值，如果是新的客户端第一次建立连接时，该值为空，但如果是之前建立过安全连接的客户端，那么在这个信息中会附带上次的ID，如果上次在服务端中存储的Session还未过期，那么则会直接复用上次的会话，并不需要再次经过复杂的握手步骤建立连接。

但这种方式的缺陷也很明显，一方面是对服务端会造成比较大的存储压力，第二方面则是如果服务端做了负载均衡，那么还需要解决session一致性的问题。

因此在这种方式之外，TLS/1.3版本中，出现了另外一种策略：Session Ticket。这种方式的原理时，在握手完成并建立加密通信成功后，会将当前的通信对称密钥、加密方法等会话信息，通过Session Ticket发送给客户端保存。通过这种方式，因为会话信息是存储在客户端，所以不管请求被分发给哪台机器，当服务器将其解密后，如果会话未过期的情况下，那最终都能够获取上次会话的信息，这样就无需重新生成密钥了，而且还能大大减轻服务器的存储压力。

三、总结

   到目前为止，整体的篇幅已经较长了，因此对于一些其他内容就不再展开赘述，如HTTP/2.0及后续版本新特性的详细内容、HTTPS证书链、证书吊销、HTTPS接入优化等。

最后再附上HTTP与HTTPS的对比：