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连接建立之后，首先客户端验证服务器的证书，在安全性要求高的情况下服务器还会验证客户端的证书。然后两者开始协商加密密钥，协商完成之后，就利用这个密钥开始加密通信了。我们通过实际的报文来看看这个过程。
TLS 1.2的通信流程
1. TCP的三次握⼿ 前三个报⽂是TCP建⽴连接的过程，本例中客户端⾸先发起连接，客户端向服务器发送SYN报⽂，服务器接收到之后回复SYN ACK确认，之后客户端再向服务器发送ACK确 认。通过三次交互，⼀个TCP连接就建⽴起来了。 本⽂⽆意讨论TCP三次握⼿的过程，读者如果不理解的可以查阅相关资料，这⾥只需要理解这三次握⼿是通过TCP协议通信的必经之路就好了。 需要注意的是，如果按照HTTP协议的规定，建⽴TCP连接之后，就可以正式开始通信了，客户端可以构建HTTP请求，来请求服务器上的⻚⾯，服务器也会按照要求进⾏响 应。但是这个过程是完全不进⾏加密的，并没有安全性可⾔。这部分属于TCP的范畴，下⾯我们才真正开始讨论TLS 1.2。 2. Client Hello 客户端发送的，属于TLS握⼿协议（TLS handshake）的⼀部分，其内容包括客户端的⼀个Unix时间戳（GMT Unix Time）、⼀些随机的字节（Random Bytes），还包括 了客户端接受的算法类型（Cipher Suites），本例中Mozilla Firefox 57.0允许15种算法，浏览器认为这些算法是可以被信任的。这是最基本的部分，同时还有其他的扩展参 数，这⾥就不做介绍了。 Client Hello的⽬的就类似于SYN，客户端对服务器公布⾃⼰⽀持的算法等等，同时也附带请求服务器证书的意思。这⾥不验证客户端证书，所以Client Hello就只有这些内 容。 3. 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⽬的就是服务器对客户端公布⾃⼰的算法，以便于后续操作。 4. Certificate 服务器或者客户端发送的，依旧属于TLS handshake，它⼀般和Server Hello在同⼀个TCP报⽂中传送。显然的，这⾥服务器将⾃⼰的数字证书发送给客户端，客户端就会 进⾏证书验证，如果不通过的话，客户端会中断握⼿的过程。如果也要求客户端提供证书的话，Client Hello后⾯也会紧跟着该报⽂，形式完全⼀样，就不再解释了。 5. Server Key Exchange 服务器发送的，属于TLS handshake，⼀般也和Server Hello与Certificate在⼀个TCP报⽂中。服务器将⾃⼰的公钥参数传输给了客户端，因为使⽤的是ECDHE，这⾥传输 的内容有：椭圆曲线域参数，以及公钥的值。 这个就是密钥交换协议的⼀部分，最终协商出密钥来。 6. Server Hello Done 服务器发送的，属于TLS handshake，⼀般也和Server Hello、Certificate和Server Key Exchange在⼀个TCP报⽂中，介于Server Hello和Server Hello之间的是服务器想 要给客户端的东⻄。所以这⾥⾯客户端没有发送Client Hello Done 7. Client Key Exchange 客户端发送的，属于TLS handshake，客户端收到了服务器的证书进⾏验证，如果验证通过了，就会继续密钥交换的过程，向服务器发送⾃⼰的公钥参数。待服务器收到之 后进⾏数学计算，就可以协商出密钥了，这⾥客户端实际上已经计算出了密钥。 8. Change Cipher Spec 客户端或者服务器发送的，属于TLS handshake，紧跟着Key Exchange发送，代表⾃⼰⽣成了新的密钥，通知对⽅以后将更换密钥，使⽤新的密钥进⾏通信。 9. Encrypted Handshake Message 客户端或者服务器发送的，属于TLS handshake，也是紧跟着Key Exchange发送。这⾥是进⾏⼀下测试，⼀⽅⽤⾃⼰的刚刚⽣成的密钥加密⼀段固定的消息发送给对⽅， 如果密钥协商正确⽆误的话，对⽅应该可以解密。这段加密内容的明⽂⼀般是协议中规定好的，双⽅都知道。 10. New Session Ticket 服务器发送的，属于TLS handshake，服务器给客户端⼀个会话，⽤处就是在⼀段时间之内（超时时间到来之前），双⽅都以刚刚交换的密钥进⾏通信。从这以后，加密通 信正式开始。 11. Application Data 应⽤层的数据，是加密的，使⽤密钥交换协议协商出来的密钥加密。因为我们的Wireshark不知道服务器的私钥，所以这段通信是安全的，我们在Wireshark中也⽆法解密 这段信息。 12. Encrypted Alert 客户端或服务器发送的，意味着加密通信因为某些原因需要中断，警告对⽅不要再发送敏感的数据。
总结
本⽂粗略的介绍了TLS协议的1.2版本的通信过程，重点是handshake的过程，以上部分完成了证书认证、密钥协商以及加密传输的任务。
在我看来，计算机⽹络有⼀种独特的魅⼒，那就是⼈们在设计⽹络协议的时候，也完全是按照⼈类的思维进⾏的设计。实际上在各种各样的⽹络协议中，处处流淌着⼈类的
思想，体现着⼈类的⽂化。就⽐如本⽂介绍的TLS，就好像服务器和客户端是两个⼈在对话⼀样。事实就是如此，计算机⽹络就是计算机之间“对话”的科学。这也是我对计
算机⽹络的兴趣所在。