浅析TLS 1.2协议

0x01 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的整个体系结构，而后会借助其通讯的报文进行详细分析。

0x02 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链接创建以后，首先客户端验证服务器的证书，在安全性要求高的状况下服务器还会验证客户端的证书。而后二者开始协商加密密钥，协商完成以后，就利用这个密钥开始加密通讯了。咱们经过实际的报文来看看这个过程。

0x03 借助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

• 客户端或服务器发送的，意味着加密通讯由于某些缘由须要中断，警告对方不要再发送敏感的数据。

0x04 总结

• 本文粗略的介绍了TLS协议的1.2版本的通讯过程，重点是handshake的过程，以上部分完成了证书认证、密钥协商以及加密传输的任务。
• 在我看来，计算机网络有一种独特的魅力，那就是人们在设计网络协议的时候，也彻底是按照人类的思惟进行的设计。实际上在各类各样的网络协议中，到处流淌着人类的思想，体现着人类的文化。就好比本文介绍的TLS，就好像服务器和客户端是两我的在对话同样。事实就是如此，计算机网络就是计算机之间“对话”的科学。这也是我对计算机网络的兴趣所在。