SSL & TLS协议运行机制

概述

SSL&TLS协议背景介绍

我们生活在一个越来越依赖于联网的时代。从20世纪初开始，互联网的快速发展改变了我们的很多的生活习惯。过去，我们使用邮件来跟他人沟通交流。今天我们使用电话、电脑来进行通讯、购物、工作等等。很多人（包括我自己）现在都已经是“永久在线”了。可以这么说，我们现在不再需要特意连接到互联网了，因为我们就是互联网。

在互联网设计之初，设计者并没有太过于考虑安全方面的问题，这是由于他们相信网络上的每一个点都是诚实可信的，因此，在网络上传输的数据都是明文的，也就意味着，任何一个恶意的攻击者都可以得到我提交的数据，包括一些敏感信息：用户名密码、信用卡号等等。这种设计在网络规模比较小并且业务比较简单的时候是可以满足需求的。但是，随着越来越多相对比较敏感的业务放到网络上之后，数据的安全传输就变得非常重要了。 本文的主角：SSL（TLS）协议的出现正是为了解决这个问题。SSL协议允许我们在“不安全”的网络设备上提供安全的数据传输。

虽然现在SSL协议已经发展成为TLS协议，但是SSL这个名字相对认知度更高一些，所以在本文中会使用SSL来表示SSL/TLS协议。

SSL协议历史背景

互联网加密通信协议的历史，几乎与互联网一样长。

* 1994年，NetScape公司设计并实现了SSL协议（Secure Sockets Layer）的1.0版本，但是并没有正式对外发布。
* 1995年，NetScape公司发布了SSL协议2.0版本，并集成到自家的Netscape Navigator1.1中，但是很快被发现有严重的安全漏洞。
* 1996年，SSL协议3.0版本正式发布，并得到大规模应用。虽然新版本协议延续了SSL协议这个名字，但是可以这么说：3.0和2.0是完全不同的协议。
* 1999年，IETF发布SSL的升级版TLS协议1.0版本。（SSL协议的开发维护工作从NetScape迁移到IEFT这项工作从1996年就开始了，但是直到1999年IETF正式发布了TLS协议1.0版本，这项迁移工作才算是正式完成）
* 2006年和2008年，TLS进行了2次升级，分别是TLS1.1和TLS1.2。最新的TLS1.3还在开发中。

目前来说，应用最广泛的是TLS1.0，接下来是SSL3.0（其实TLS1.0和SSL3.0并没有太大的改动）。 TLS1.0通常在SSL握手流程中被标注的版本是SSL3.1， TLS1.1为SSL3.2， TLS1.2为SSL3.3。

协议作用

不使用加密传输的HTTP通信，通常来说就是不加密的通信。所有信息都是以明文的形式进行传播，这会带来3类风险： 1. 数据窃听（eavesdropping）： 第三方可以获知信息内容 2. 数据篡改（tampering）： 第三方可以修改通信内容 3. 身份冒充（pretending）： 第三方可以冒充他人身份参与通信

而加密传输协议就是为了解决这3类问题而出现的，希望可以达到： 1. 所有信息都是加密传输，第三方无法窃听 2. 具有校验机制，一旦被篡改，通信双方会立刻发现 3. 具备身份证书，防止身份被冒充

SSL协议限制

SSL协议本身是一个工具，它跟其它任何工具一样，都有其局限性。尤其是SSL协议提供的是安全服务，所以我们更应该明白协议本身不能做什么。

协议限制

虽然SSL协议在设计时考虑到了很多的应用场景，但是它依然不适用于所有的应用。因为SSL协议依赖于底层协议来实现可靠的数据传输（比如TCP协议），所以使用无连接传输协议的应用是无法使用SSL协议来提供安全传输的。

工具限制

由于SSL本身只是一个通信协议，并且任何一个SSL协议的具体实现都需要依赖于其它的组件、函数、类库等等。包括加密算法比如：RSA，SHA1等等。而这些算法是实现加密通信的基础，所以，一旦该SSL实现依赖的加密算法出现漏洞或者被攻破（比如较低位数的rsa可以在秒级被破解出来），那么这个实现本身也不再安全了。

环境限制

SSL协议只能提供在传输数据时对数据进行加密这么一项功能。但是没有任何网络协议可以保护数据服务器本身不被攻击。所以即使SSL协议本身并没有明显的漏洞。但是很多攻击者可以选择绕过SSL转而试图通过其它方法来获取想要的信息。比如：SQL注入等。

SSL协议交互流程

虽然SSL协议本身并不是一个非常复杂的协议，但是它也提供了一些选项和变化。本文将从一个最基本的案例：简历加密通信信道开始。之后会是2个稍微复杂一些的例子：在建立加密通信密道的时候加入了身份认证以及将身份认证和加密分开。最后会是一个会话服用的案例。通过这些案例，我们将初步体会到SSL的能力。 SSL协议本身由一系列消息和消息发送的规则组成。在本文中我们将会简单介绍一些这些消息是什么，以及消息本身所带的信息都是什么。具体的消息的格式以及加密算法的工作模式行自行百度。

SSL协议的结构

![] 图1-1， SSL协议的结构

图1-1展示了SSL协议的分层结构。从图中可以看到，SSL协议位于应用层和传输层之间。SSL协议本身分为2层：

1. 底层为SSL记录协议（Record Layer Protocol）
2. 上层为SSL握手协议（SSL Handshake Protocol）、SSL密码变换协议（SSL ChangeCipher Protocol）、SSL告警协议（SSL Alert Protocol）

SSL握手协议：

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

SSL密码变换协议：

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

SSL告警协议：

用来向通信对端报告告警信息，消息中包含告警的严重级别和描述。

SSL记录协议：

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

SSL角色

SSL协议为通信双方建立了2个不同的角色：客户端和服务端。这2者之间有非常大的区别。客户端是加密通信的发起者；服务端接受并响应客户端的请求。在比较常见的SSL应用场景：Web服务中，用户的浏览器就是client端，而对应的网站地址就是server端了。

SSL握手流程

SSL通过握手流程在客户端和服务器之间协商会话参数，并建立会话。会话包含的主要参数有会话ID、对方的证书、加密套件（密钥交换算法、数据加密算法和MAC算法等）以及主密钥（master secret）。通过SSL会话传输的数据，都将采用该会话的主密钥和加密套件进行加密、计算MAC等处理。 不同情况下，SSL握手流程存在差异。下面将分别描述以下三种情况下的握手过程：

1. 不验证身份，只开启加密通信的SSL握手流程
2. 只验证服务器身份的SSL握手流程
3. 验证服务器和客户端双方的SSL握手流程
4. 恢复原有会话的SSL握手流程

不验证身份，只开启加密通信的SSL握手流程

图1-2： 不验证身份，只开启加密通信的SSL握手流程

从图中可以看到，整个握手流程中，消息的交换流程如下：

1. 客户端发送一个ClientHello消息，消息体中带有必要的参数。
2. 消息参数如下：

	1. Version： 声明了客户端所支持的最高版本的SSL协议（比如SSL3）
	2. RandomNumber： 一个32-byte长的随机数，用来作为计算对称加密密钥的种子。
	3. SessionID： 指定一个之前的SSL会话（如果想复用会话就在该字段填充一个有效的SessionID，如果是一个全新的握手流程，那么该字段为空）
	4. CipherSuites： 包括了客户端锁支持的所有的加密套件。
	5. CompressionMethods： 包括了客户端锁至此回的所有的数据压缩算法列表。
3. 服务端返回给客户端一个ServerHello消息，并指定了后续握手流程中用到的参数（SSL版本，加密算法等）
4. 消息格式如下：

	1. Version： 通知客户端，后续通信使用指定的SSL协议的版本，如果客户端不接受该版本，可以选择终止握手。
	2. RandomNumber： 一个32-byte长的随机数，用来作为计算对称加密密钥的种子（跟ClientHello的随机数不是一个）
	3. SessionID： 指定一个合法的SessionID（如果需要复用Session时可以用）
	4. CipherSuite：服务端指定的本次通信使用的加密算法。
	5. CompressionMethod： 服务端指定本次通信使用的压缩算法。
5. 服务端返回给客户端一个ServerKeyExchange消息，包括了ServerHello消息中指定的加密算法所需要的参数。
6. 在本例中，服务端返回ServerHello消息之后会跟着返回一个ServerKeyExchange消息。ServerKeyExchange消息是对ServerHello消息中的CipherSuite字段的补充。在ServerKeyExchange消息中包含了公钥和公钥对应算法需要的参数。比如：RSA算法的话，服务端返回的信息中会包括公钥、模数等信息。此时的传输是明文的，所以只能包含公钥信息，否则会出现密钥泄露的风险。
7. 服务端返回给客户端一个ServerHelloDone消息，表示ClientHello消息对应的处理已经都处理完毕。
8. ServerHelloDone消息不包含其它信息，但是它却非常重要，因为客户端收到这个消息之后才会继续后续的流程。
9. 客户端发送给服务端一个ClientKeyExchange消息，包括对称加密算法需要的密钥（使用服务端ServerKeyExchange消息中附带的公钥加密）
10. 这个消息格式有点像服务端发送的ServerKeyExchange消息。ServerKeyExchange消息是由服务端发送给客户端包括了服务端指定密钥交换算法的密钥等信息。ClientKeyExchange是由客户端发送给服务端的消息，消息中包括了一个由服务端公钥加密的，客户端生成的第三个随机数。
11. 客户端发送给服务端一个ChangeCipherSpec消息，通知SSL服务端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
12. 在本例中，当客户端将密钥信息打包到ClientKeyExchange消息并发给服务端之后。SSL握手的主要流程就已经完成了。此时，握手双方都已经准备好使用它们之前沟通好的加密服务了。SSL协议定义了一个特殊的消息: ChangeCipherSpec消息来指定加密服务可以开启了。
13. 一旦其中一方发给对方这个消息，即表示本方已经准备好使用加密通讯了。
14. SSL客户端计算已交互的握手消息（除ChangeCipherSpec消息外所有已交互的消息）的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
15. 服务端发送给客户端一个ChangeCipherSpec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
16. SSL服务端计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL客户端。SSL客户端利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。

只验证服务器身份的SSL握手流程

图1-3： 只验证服务端身份的SSL握手流程

 图中黑色的2个消息是跟只开启加密通信案例中不同的部分。整个的流程如下：

1. SSL客户端通过ClientHello消息将它支持的SSL版本、加密算法、密钥交换算法、MAC算法等信息发送给SSL服务端。
2. SSL服务端确定本次通信采用的SSL版本和加密套件，并通过ServerHello消息通知给SSL客户端。如果SSL服务端允许SSL客户端在以后的通信中重用本次会话，则SSL服务端会为本次会话分配会话ID，并通过ServerHello消息发送给SSL客户端。
3. SSL服务端将携带自己公钥信息的数字证书通过Certificate消息发送给SSL客户端。
4. SSL服务端返回给客户端一个ServerHelloDone消息，通知SSL客户端版本和加密套件协商结束，开始进行密钥交换。
5. SSL客户端验证SSL服务器的证书合法后，利用证书中的公钥加密SSL客户端随机生成的premaster secret，并通过ClientKeyExchange消息发送给SSL服务端。
6. SSL客户端发送给服务端一个ChangeCipherSpec消息，通知SSL服务端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
7. SSL客户端计算已交互的握手消息（除ChangeCipherSpec消息外所有已交互的消息）的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
8. SSL服务端返回给客户端一个ChangeCipherSpec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
9. SSL服务端计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL客户端。SSL客户端利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。


 Certificate消息服务端返回一个包含以服务端公钥证书开始到服务端证书签发CA的根证书结尾的证书链 的Certificate消息给客户端来表明自己的身份。客户端可以验证这个证书的有效性：证书是否过期、证书废弃状态、签发证书的CA是否可信。如果验证不通过，那么说明客户端正在通信的服务端并不是它希望的服务端。

验证服务器和客户端双方的SSL握手流程

图1-4： 验证双方身份的SSL握手流程

在任何SSL的场景中，SSL服务端可以选择是否验证SSL客户端的身份，如果需要的话，那么在ServerHello消息之后，再发一个CertificateRequest消息通知客户端即可，之后客户端会将自己的证书发给SSL服务端。图1-5展示了双方验证的一个SSL握手的流程。 图中黑色的3个消息是跟只验证服务端身份的案例不同的部分。整个的流程如下：

1. SSL客户端通过ClientHello消息将它支持的SSL版本、加密算法、密钥交换算法、MAC算法等信息发送给SSL服务端。
2. SSL服务端确定本次通信采用的SSL版本和加密套件，并通过ServerHello消息通知给SSL客户端。如果SSL服务端允许SSL客户端在以后的通信中重用本次会话，则SSL服务端会为本次会话分配会话ID，并通过ServerHello消息发送给SSL客户端。
3. SSL服务端将携带自己公钥信息的数字证书通过Certificate消息发送给SSL客户端。
4. SSL服务端返回给客户端一个CertificateRequest消息，通知客户端将其证书发到SSL服务端。
5. 服务端返回给客户端一个ServerHelloDone消息，通知SSL客户端版本和加密套件协商结束，开始进行密钥交换。
6. SSL客户端在收到服务端发送的CertificateRequest消息和ServerHelloDone消息之后，通过Certificate消息将携带自己公钥信息的证书发送给SSL服务端，SSL服务端会验证证书的有效性。
7. SSL客户端验证SSL服务器的证书合法后，利用证书中的公钥加密SSL客户端随机生成的premaster secret，并通过ClientKeyExchange消息发送给SSL服务端。
8. SSL客户端计算已交互的握手消息、主密钥的Hash值，利用自己的私钥对其进行加密，并通过CertificateVerify消息发送给SSL服务器。
9. 客户端发送给服务端一个ChangeCipherSpec消息，通知SSL服务端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
10. SSL客户端计算已交互的握手消息（除ChangeCipherSpec消息外所有已交互的消息）的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
11. 服务端返回给客户端一个ChangeCipherSpec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
12. SSL服务器计算已交互的握手消息、主密钥的Hash值，利用SSL客户端证书中的公钥解密CertificateVerify消息，并将解密结果与计算出的Hash值比较。如果二者相同，则SSL客户端身份验证成功。
13. SSL服务端计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL客户端。

CertificateRequest消息CertificateRequest消息跟SSL服务端发过的ServerKeyExchange消息比较类似，但是有一点不同，当服务端自己的证书无法被验证时，SSL协议不允许服务端发送一个CertificateRequest消息。这个规则会让SSL客户端在提交自己证书之前确保服务端的证书是可信的。

恢复原有会话的SSL握手流程

图1-5： 复用SSL会话的流程

协商会话参数、建立会话的过程中需要使用非对称密钥算法来加密密钥、验证通信对端的身份。整个过程计算量较大，占用了大量的系统资源。为了简化SSL握手过程，SSL允许重用已经协商过的会话，图1-6展示了一个复用原有会话的SSL握手流程。 整个流程的过程如下：

1. SSL客户端通过ClientHello消息，消息中的SessionID设置为计划复用的Session的ID。
2. SSL服务端如果允许复用该会话，会在ServerHello消息中的SessionID设置为该SessionID。这样SSL的客户端和服务端就可以使用之前协商好的密钥和加密套件，不必重新握手协商。
3. 服务端返回给客户端一个ChangeCipherSpec消息，通知SSL客户端后续报文将采用原有的密钥和加密套件进行加密和MAC计算。
4. SSL 服务端 计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSL 客户端 ，以便SSL 客户端 判断密钥和加密套件是否正确。
5. 客户端发送给服务端一个ChangeCipherSpec消息，通知SSL服务端后续报文将采用原有的密钥和加密套件进行加密和MAC计算。
6. SSL客户端计算已交互的握手消息（除ChangeCipherSpec消息外所有已交互的消息）的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。

总结

至此，SSL协议中常见的握手流程都介绍完毕，接下来，客户端与服务端进入加密通信，这些完全是使用普通的HTTP协议，只不过用“会话密钥”对传输的数据进行了加密。

转载于:https://my.oschina.net/seraphln/blog/1581780