【计网】SSL/TLS核心原理

序言

在HTTP协议中，信息是明文传输的，因此为了通信安全就有了HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer)协议。HTTPS也是一种超文本传送协议，在HTTP的基础上加入了SSL/TLS协议，SSL/TLS依靠证书来验证服务端的身份，并为浏览器和服务端之间的通信加密。HTTPS是一种通过计算机网络进行安全通信的传输协议，使用HTTP进行通信，借助SSL/TLS建立安全通道和加密数据包。使用HTTPS的主要目的是提供对网站服务端的身份认证，同时保护交换数据的隐私与完整性。TLS是传输层加密协议，前身是SSL协议，由网景(Netscape)公司1995年发布，有时候TLS和SSL两者不做太多区分。

SSL/TLS协议的版本演进

TCP是传输层的协议，但是它是明文传输的，是不安全的。SSL的诞生给TCP加了一层保险，为TCP通信提供安全及数据完整性保护。TLS只是SSL的升级版，它们的作用是一样的。TLS（Transport Layer Security，传输层安全协议）由两层组成：TLS记录(TLS Record)和TLS握手(TLS Handshake)。TLS协议是更新、更安全的SSL协议版本。SSL/TLS可以理解为安全传输层协议不同发展阶段的版本。1999年，SSL应用广泛，已经成为互联网上的事实标准。IETF（Internet Engineering Task Force，国际互联网工程任务组）在1999年把SSL标准化。完成标准化之后，SSL协议名称被改为TLS。SSL/TLS位于应用层和传输层之间，除了HTTP外，它可以为任何基于TCP传输层以上的应用层协议（如WebSocket协议）提供安全性保证。理论上，SSL/TLS协议属于传输层。从理论模型的维度来说，该协议在TCP/IP协议栈的分层结构中所处的层次位置大致如图12-1所示。但是，在具体的编码实现上，SSL/TLS协议属于应用层。从实现的维度来说，该协议在TCP/IP协议栈分层结构中所处的层次位置大致如图

在这里插入图片描述
综合起来可以表述为：SSL/TLS协议理论上属于传输层，却实现于应用层。

在客户端浏览器中，目前应用最广泛的是SSL 3.0、TLS 1.0（有时被标为SSL 3.1）、TLS 1.1（有时被标为SSL3.2）、TLS 1.2（有时被标为SSL 3.3）四个版本的协议。比如，在IE浏览器上，用户可以设置是否使用SSL/TLS协议，还可以设置支持哪一些版本的协议，具体如图

在这里插入图片描述

SSL/TLS协议的分层结构

SSL/TLS协议包括握手协议(Handshake Protocol)、密码变化协议(SSL Change Cipher Spec Protocol)、警告协议(Alert Protocol)、记录协议(Record Protocol)。

(1)握手协议：SSL/TLS协议非常重要的组成部分，用来协商通信过程中使用的加密套件（加密算法、密钥交换算法和MAC算法等）、在服务端和客户端之间安全地交换密钥、实现服务端和客户端的身份验证。

(2)密码变化协议：客户端和服务端通过密码变化协议通知对端，随后的报文都将使用新协商的加密套件和密钥进行保护和传输。

(3)警告协议：用来向对端发送告警信息，消息中包含告警的严重级别和描述。

(4)应用数据协议：负责将SSL/TLS承载的应用数据传达给通信对端。

(5)记录协议：主要负责对上层的数据（SSL/TLS握手协议、SSL/TLS密码变化协议、SSL/TLS警告协议和应用数据协议）进行分块计算、添加MAC值、加密等处理，并把处理后的记录块传输给对端。

在这里插入图片描述

SSL/TLS协议主要分为两层（上层的是握手协议、密码变化协议、警告协议和应用数据协议，下层的是记录协议），主要负责使用对称密码对消息进行加密。其中，握手协议(Handshake Protocol)是SSL/TSL通信中最复杂的子协议，也是安全通信所涉及的第一个子协议。

SSL/TLS运行过程

SSL/TLS协议实现通信安全的基本思路是：消息发送之前，发送方A先向接收方B申请公钥，发送方A采用公钥加密法对发出去的通信内容进行加密，接收方B收到密文后，用自己的私钥对通信密文进行解密。

(1)客户端向服务端索要并验证公钥。（公钥加密，私钥解密验证）
(2)双方协商生成“对话密钥”。
(3)双方采用“对话密钥”进行加密通信。

前两步又称为“握手阶段”，每一个TLS连接都会以握手开始。“握手阶段”涉及四次通信，并且所有通信都是明文的。在握手过程中，客户端和服务端将进行以下四个主要阶段：

(1)交换各自支持的加密套件和参数，经过协商后，双方就加密套件和参数达成一致。
(2)验证对方（主要指服务端）的证书，或使用其他方式进行服务端身份验证。
(3)对将用于保护会话的共享主密钥达成一致。
(4)验证握手消息是否被第三方修改。

SSL/TLS第一阶段握手

客户端与服务端通过TCP三次握手建立传输层连接后，通信双方需要交换各自支持的加密套件和参数，经过协商后，使通信双方的加密套件和参数达成一致。

SSL/TLS“握手”第一个阶段的工作为：由客户端发一个Client Hello报文给服务端，并且第一个阶段只有这一个数据帧（报文）。Client Hello数据帧的内容大致包括以下信息：

(1)客户端支持的SSL/TLS协议版本，比如TLS 1.2版。
(2)一个客户端生成的随机数，这是握手过程中的第一个随机数，称之为Random_C。
(3)客户端支持的签名算法、加密方法、摘要算法（比如RSA公钥签名算法）。
(4)客户端支持的压缩方法。

SSL/TLS第二阶段握手

SSL/TLS握手第二个阶段的工作为：服务端对客户端的Client Hello请求进行响应。在收到客户端请求(ClientHello)后，服务端向客户端发出回应，这个阶段的服务端回应帧（报文）一般包含4个回复帧：Server Hello帧、Certificate帧、Server Key Exchange帧、Server Hello Done帧。

Server Hello帧

服务端回复的Server Hello帧主要包含以下内容：
(1)回复服务端使用的加密通信协议版本，比如TLS 1.2版本。
(2)一个服务端生成的随机数，是整个握手过程中的第二个随机数，记为“Random_S”，稍后用于生成“对话密钥”。
(3)确认使用的加密方法，比如RSA公钥加密。
(4)服务端的证书。

Certificate帧

Certificate帧用于返回服务端证书，该证书中含有服务端的证书清单（包括服务端公钥），用于身份验证和密钥协商。在多数电子商务应用中，客户端都需要进行服务端身份验证，服务端通过Certificate帧发送自己的证书给客户端。

服务端通过Certificate帧给客户端提供身份信息，那么客户端是否需要提供自己的身份证书给服务端呢？

虽然大部分场景中服务端不需要验证客户端的身份，但是只要服务端需要验证客户端的身份，服务端就会发一个CertificateRequest证书请求给客户端。比如，在一些安全性要求较高的机构（如金融机构）往往需要验证客户端身份证书，这些机构只允许通过认证客户连入自己的网络，并且会给正式客户提供USB密钥，里面就包含了一张客户端身份证书，在通信握手时要求客户端提供证书。

Server Key Exchange帧

Server Key Exchange帧的目的是携带密钥交换的额外数据，其消息内容对于不同的协商算法套件都会存在差异。

在某些场景中，服务端不需要发送Server Key Exchange握手消息。如果在Server Hello消息中使用DHE/ECDHE非对称密钥协商算法来进行SSL握手，就将发送该类型握手消息。对于使用RSA算法的SSL握手，不会发送该类型握手消息。另外，使用DH、ECDH算法进行握手时也不会发送该类型握手消息。

Server Hello Done帧

Server Hello Done帧是第二阶段的最后一帧，标记服务端对客户端的Client Hello请求帧的所有响应报文发送完毕，Server Hello Done帧的长度为0。

客户端收到服务端证书后，进行验证，如果证书不是可信机构颁发的，或者域名不一致，或者证书已经过期，那么客户端会进行警告；如果证书没有问题，就继续进行通信。

SSL/TLS第三阶段握手

SSL/TLS握手(Handshake)第三个阶段的工作为：客户端进行回应。在这个阶段，客户端会发送Client KeyExchange、Change Cipher Spec、Encrypted Handshake三个数据帧。

客户端收到第二个阶段的服务端回应报文以后，首先验证服务端证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务端的公钥，然后向服务端发送三项信息：

(1)一个随机数。该随机数用服务端公钥加密，防止被第三方窃听。

此随机数是整个握手阶段出现的第三个随机数，又称Pre-master key。有了它以后，客户端和服务端就同时有了三个随机数，接着双方用事先商定的加密方法各自生成本次会话所用的同一把“会话密钥”。

(2)编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥加密后发送。

(3)客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的哈希值，用来供服务端校验。

服务端的证书信息会包含Public Key（公钥），稍后客户端进行证书验证（身份验证）的流程大致为：Client随机生成一串数，然后用Server发送的Public Key加密（RSA算法）后发给Server；而Server会用其对应的Private key（私钥）解密后再返回给Client; Client将其与原文比较，如果一致，则说明Server拥有Private key，与自己通信的对端Server正是证书的拥有者，因为Public key加密的数据只有Private key才能解密。在实际通信过程中，这个认证过程会复杂很多，包含多次哈希、伪随机等复杂运算。