Https协议详解

发表于 | 分类于

本文内容主要讲解Https协议，其他网络知识点作为理解Https协议的辅助。

首先，需要简单知道网络协议的四个层次，即：网络接口层，网络层，传输层，应用层。

Http协议

Http协议是一种超文本传输协议，是客户端浏览器与服务器之前的 应用层 通信协议。
Http协议不提供数据加密，以明文的方式发送内容，容易被攻击截取信息，不适合用于传输一些敏感信息。

Https协议

Https协议是以安全为目标的Http通道，在Http的基础上加入SSL层，简单来说就是Http协议的安全版。
Https协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

在进行详细解释Https之前，我们需要先简单了解一些Https协议使用到的关键技术。

关键技术

对称加密

对称加密使用加密和解密使用相同密钥的加密算法进行加密，也叫私钥加密。常见的对称加密有：DES, AES 等。

非对称加密

非对称加密与对称加密不同，使用非对称加密算法进行加密，需要两个密钥，即公钥和私钥。公钥和私钥是成对出现的，在加密和解密的过程中使用不同的密钥，所以也称为公钥加密。

数字摘要

数字摘要采用单项Hash函数将需要加密的明文 _摘要_ 成一串固定长度（128位）的密文，这个密文又称为数字指纹。不同的明文摘生成的数字指纹总是不同的，而同样的明文摘要生成的数字指纹必定一致。
数字摘要 是Https能确保数据完整性和防篡改的根本原因。

数字签名

数字签名是对 非对称加密 和 数字摘要 两项技术的应用。
它将 摘要信息 用发送者的私钥加密，与原文一起传送给接收者。
接收者只有使用发送者的公钥才能解密出被加密的 摘要信息；接着对接收到的原文用 数字摘要 生成 摘要信息；然后将两个 摘要信息 进行对比。若相同，说明收到的原文是完整的，在传输过程中没有被修改。因此，数字签名能够验证数据的完整性。

SSL

SSL是安全套接层，用以保障数据传输的安全，利用数据加密技术确保数据在传输过程中不会被截取。

SSL又可分为两层：

  • SSL记录协议建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装，压缩，加密等基本功能的支持。
  • SSL握手协议建立在SSL记录协议之上，用于在实际的数据开始传输前，通讯双方进行身份认证，协商加密算法，交换加密密钥等。

SSL/TLS握手流程

SSL/TLS握手过程流程图：
SSL握手流程图

  1. 客户端发起请求：在SSL/TLS协议传输过程中，客户端和服务端必须使用同一套加解密算法才能保证数据正常的加解密。由于客户端对一些加解密算法的支持程度不一样，所以客户端需要告知服务端自己支持的加密套件的列表传给服务端。此外，客户端还要生成一个随机数（第一个随机数），用于传送给服务端，在后面的步骤中与服务端生成的随机数结合起来产生 对话密钥。

    那么客户端需要提供的信息：

    • 支持的协议版本
    • 支持的加密算法
    • 支持的压缩方法
    • 随机数

  2. 服务端响应：服务端确定加密协议的版本和加密算法后，也生成一个随机数（第二个随机数），并将自己的证书一并发送给客户端。

    服务端需要提供的信息：

    • 确定支持的版本
    • 确定加密的算法
    • 随机数
    • 服务器证书，包含公钥

      注意：一些场景下，服务器需要确认客户端的身份，会要求客户端提供 客户端证书

  3. 客户端验证证书：客户端先对服务器下发的证书进行验证，验证通过后客户端再生成一个随机数（第三个随机数，也是最关键的随机数），并使用证书中的公钥对随机数进行加密，再加入一个 ChangeCipherSpec 即编码改变的消息和前面所有消息的Hash值，最后将所有的这些信息发送到服务器，确保在正式通信前无误。

    此时，客户端得到全部的三个随机数，客户端会用协商的加密方法，生成本次会话所用的同一把 会话密钥。

    ChangeCipherSpec是一个独立的协议，在数据包中就是一个字节的数据，用于告知服务端：客户端已经切换到了协商好的加密套件，准备好加密数据并进行传输了。

    客户端提供的信息：

    • 使用服务器证书中的公钥加密后的随机数（第三个）
    • ChangeCipherSpec 编码改变的通知
    • 握手结束的通知

      注意：如果服务端需要客户端证书，客户端会在这一步发送证书信息。

  4. 服务端生成秘钥：使用私钥对随机数（第三个）的加密数据进行解密，此时服务端得到全部的三个随机数，同样使用协商的加密方法，生成和客户端使用的同一把 会话密钥。准备好后，服务端也会给客户端一个 ChangeCipherSpec 即编码改变的消息，告知客户端已经切换到了协商好的加密套件，准备好加密数据并进行传输了。

    之后，服务端会使用 会话密钥 加密一段finish消息发送给客户端，以验证通过握手建立的加密通道是否成功。

  5. 客户端发送数据：确定 会话密钥 后，客户端与服务器之间就会使用对称加密加密数据后传输了。整个握手的过程也就基本完成了。

注意：SSL协议在握手阶段使用的是非对称加密，在传输阶段使用的是对称加密。
因为非对称加密的速度缓慢，比较耗费资源，所以在使用非对称加密建立连接后，客户端和服务器之间传输数据使用的是协商好的对称加密算法和对称加密密钥（即会话密钥）。这个数据传输过程本身是安全可靠的，也就是说对称加密密钥是不可能被窃取盗用的。
如果有人窃听通讯，他可以知道双方选择的加密方法，以及三个随机数中的两个，也就是说整个通话的安全，只取决于第三个随机数（客户端生成并加密）能不能被破解。

Session的恢复

两种恢复Session对话的方式：Session ID，Session ticket。

Session ID

客户端和服务器的每次对话都有一个编号。若对话中断，重连时只要客户端给出编号，并且服务器有该编号的记录，双方就可以使用已有的 对话密钥 重新建立连接，而不用重新走握手流程重新连接。

Session ID是目前所有浏览器都支持的方法，缺点是Session ID往往只保留在一台服务器上，如果客户端重连时请求发到另一台服务器上，就无法恢复对话。

Session ticket

客户端发送一个服务器在上次对话中发送过来的Session ticket，其中包括对话的主要信息，如：对话密钥和加密方法等。这个Session ticket是加密的，只有服务器才能解密，服务器在解密Session ticket后就不用重新生成对话密钥了。

目前只有部分浏览器支持，如：Chrome和Firefox

参考资料：