浅析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,就好像服务器和客户端是两个人在对话一样。事实就是如此,计算机网络就是计算机之间“对话”的科学。这也是我对计算机网络的兴趣所在。

已发布

分类

来自

标签: