浅析TLS 1.2协议

转自：https://segmentfault.com/a/1190000014740303

一、TLS 1.2 简介

• TLS概述：TLS和他的前身SSL，都是提供在计算机网络上安全通信的密码学协议，最常见就是用于HTTPS中，用来保护Web通信的。

• 发展史：网景公司开发了原始的SSL协议，SSL 1.0因为本身存在着严重的安全问题，所以从未被公开发布。只有SSL 2.0和SSL 3.0是被公开发布和使用的。后来为了对SSL进行标准化，推出了TLS，TLS 1.0就对应着SSL 3.0。TLS后来又有了1.1版本和1.2版本，1.3版本目前还在草案中。现在除了TLS 1.2和TLS 1.3草案之外，所有早期的协议都存在安全性问题，不建议使用。

• 我们今天的话题是TLS 1.2，首先分析TLS 1.2的整个体系结构，然后会借助其通信的报文进行详细分析。

二、TLS 1.2 的体系结构

• 首先TLS是一个高层协议，工作在计算机网络五层模型的上面两层，也就是Transport层（传输层）和Application层（应用层）。

• 今天主要介绍的是TLS 1.2在HTTPS环境下的应用。TLS 1.2不止可以用于Web通信，还可以用于其他的通信方式，只是今天以Web通信为例介绍。

• 整个TLS 1.2的概述：TLS 1.2实际上目的是在Web服务器和客户端浏览器之间建立安全连接。要想建立安全连接，必须通过密钥交换协议协商出一个共同的密钥（一般我们称为Handshake），然后再利用对称密码进行加密传输 [1]。这个过程中为了避免中间人攻击，还需要通过数字证书保护公钥 [2]。这些就是TLS 1.2的基本任务，即——证书认证、密钥协商以及加密传输。

[1] 对称密码体制要求通信双方必须有一个两方都知道的密钥，这个密钥必须通过保密的方式传送，而实际上计算机网络本身并不保密。所以如何在不安全的网络上“协商”出一个安全密钥，这是个很大的问题。详见密钥交换协议。

[2] 通过公钥密码体制，允许双方各持有公钥和私钥进行通信，但是密钥的协商过程中依旧可能被欺骗，这称为中间人攻击。数字证书是为了解决这个问题。详见数字证书。

• 所以从整体来看，TLS 1.2做了以下的工作：在TCP连接建立之后，首先客户端验证服务器的证书，在安全性要求高的情况下服务器还会验证客户端的证书。然后两者开始协商加密密钥，协商完成之后，就利用这个密钥开始加密通信了。我们通过实际的报文来看看这个过程。

三、借助Wireshark分析TLS 1.2的通信流程

1. 环境说明

• 服务器IP地址：10.5.24.129

• 服务器操作系统：openSUSE Linux (Leap 42.3)

• 服务器软件：Apache

• 服务器应用层协议：HTTP 2.0、TLS 1.2

• 客户端IP地址：10.5.24.130

• 客户端操作系统：openSUSE Linux (Leap 42.3)

• 客户端软件（浏览器）：Mozilla Firefox 57.0

• 网络拓扑：客户端和服务器直接通过交换机连接，不经过任何路由。

• 捕获软件：Wireshark 2.2

2. TCP的三次握手

• 前三个报文是TCP建立连接的过程，本例中客户端首先发起连接，客户端向服务器发送SYN报文，服务器接收到之后回复SYN ACK确认，之后客户端再向服务器发送ACK确认。通过三次交互，一个TCP连接就建立起来了。

• 本文无意讨论TCP三次握手的过程，读者如果不理解的可以查阅相关资料，这里只需要理解这三次握手是通过TCP协议通信的必经之路就好了。

• 需要注意的是，如果按照HTTP协议的规定，建立TCP连接之后，就可以正式开始通信了，客户端可以构建HTTP请求，来请求服务器上的页面，服务器也会按照要求进行响应。但是这个过程是完全不进行加密的，并没有安全性可言。这部分属于TCP的范畴，下面我们才真正开始讨论TLS 1.2。

3. Client Hello

• 客户端发送的，属于TLS握手协议（TLS handshake）的一部分，其内容包括客户端的一个Unix时间戳（GMT Unix Time）、一些随机的字节（Random Bytes），还包括了客户端接受的算法类型（Cipher Suites），本例中Mozilla Firefox 57.0允许15种算法，浏览器认为这些算法是可以被信任的。这是最基本的部分，同时还有其他的扩展参数，这里就不做介绍了。

• Client Hello的目的就类似于SYN，客户端对服务器公布自己支持的算法等等，同时也附带请求服务器证书的意思。这里不验证客户端证书，所以Client Hello就只有这些内容。

4. Server Hello

• 服务器发送的，同样属于TLS handshake，内容包括服务器的GMT Unix Time以及Random Bytes，和上面类似就不再解释。这时候服务器会将自己支持的算法类型发送给客户端，以便于客户端进行验证，这里我的服务器使用的是TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，也就是使用AES-128的GCM模式进行对称加密，同时以带SHA-256的RSA作为签名算法，用ECDHE做密钥交换的一整套协议。我的服务器也算是主流安全啦～

• Server Hello目的就是服务器对客户端公布自己的算法，以便于后续操作。

5. Certificate

• 服务器或者客户端发送的，依旧属于TLS handshake，它一般和Server Hello在同一个TCP报文中传送。显然的，这里服务器将自己的数字证书发送给客户端，客户端就会进行证书验证，如果不通过的话，客户端会中断握手的过程。如果也要求客户端提供证书的话，Client Hello后面也会紧跟着该报文，形式完全一样，就不再解释了。

6. Server Key Exchange

• 服务器发送的，属于TLS handshake，一般也和Server Hello与Certificate在一个TCP报文中。服务器将自己的公钥参数传输给了客户端，因为使用的是ECDHE，这里传输的内容有：椭圆曲线域参数，以及公钥的值。

• 这个就是密钥交换协议的一部分，最终协商出密钥来。

7. Server Hello Done

• 服务器发送的，属于TLS handshake，一般也和Server Hello、Certificate和Server Key Exchange在一个TCP报文中，介于Server Hello和Server Hello之间的是服务器想要给客户端的东西。所以这里面客户端没有发送Client Hello Done

8. Client Key Exchange

• 客户端发送的，属于TLS handshake，客户端收到了服务器的证书进行验证，如果验证通过了，就会继续密钥交换的过程，向服务器发送自己的公钥参数。待服务器收到之后进行数学计算，就可以协商出密钥了，这里客户端实际上已经计算出了密钥。

9. Change Cipher Spec

• 客户端或者服务器发送的，属于TLS handshake，紧跟着Key Exchange发送，代表自己生成了新的密钥，通知对方以后将更换密钥，使用新的密钥进行通信。

10. Encrypted Handshake Message

• 客户端或者服务器发送的，属于TLS handshake，也是紧跟着Key Exchange发送。这里是进行一下测试，一方用自己的刚刚生成的密钥加密一段固定的消息发送给对方，如果密钥协商正确无误的话，对方应该可以解密。这段加密内容的明文一般是协议中规定好的，双方都知道。

11. New Session Ticket

• 服务器发送的，属于TLS handshake，服务器给客户端一个会话，用处就是在一段时间之内（超时时间到来之前），双方都以刚刚交换的密钥进行通信。从这以后，加密通信正式开始。

12. Application Data

• 应用层的数据，是加密的，使用密钥交换协议协商出来的密钥加密。因为我们的Wireshark不知道服务器的私钥，所以这段通信是安全的，我们在Wireshark中也无法解密这段信息。

13. Encrypted Alert

• 客户端或服务器发送的，意味着加密通信因为某些原因需要中断，警告对方不要再发送敏感的数据。

四、总结

• 本文粗略的介绍了TLS协议的1.2版本的通信过程，重点是handshake的过程，以上部分完成了证书认证、密钥协商以及加密传输的任务。

• 在我看来，计算机网络有一种独特的魅力，那就是人们在设计网络协议的时候，也完全是按照人类的思维进行的设计。实际上在各种各样的网络协议中，处处流淌着人类的思想，体现着人类的文化。就比如本文介绍的TLS，就好像服务器和客户端是两个人在对话一样。事实就是如此，计算机网络就是计算机之间“对话”的科学。这也是我对计算机网络的兴趣所在。