实验六 TLS协议报文解析

一、实验目的

1.访问一个https://....的网站，捕TLS包并分析报文序列。

2.分析连接建立的完整过程，如：TCP三次握手、SSL安全连接，使用TLS协议连接、协商过程，加密传送的状态、TCP挥手等。

3.分析包中handshake握手、协商过程，说明完成了什么功能。

二、实验准备

1.笔记本电脑一台，安装wireshark软件。

2.实验参考了几篇csdn博客：https://www.cnblogs.com/Anker/p/6082966.html；http://m.blog.csdn.net/liangyihuai/article/details/53098482；http://m.blog.csdn.net/ppdyhappy/article/details/68061238。

三、实验原理

1.基本概念

（1）SSL（Secure Socket Layer，安全套接字层）

位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。

（2）TLS(Transport Layer Security，传输层安全协议)

用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。

（3）TLS是在SSL的基础上标准化的产物，目前SSL3.0与TLS1.0保持一致，二者是并列关系。SSL/TLS位于传输层和应用层之间，应用层数据不再直接传递给传输层，而是传递给TLS层，TLS层对从应用层收到的数据进行加密，并增加自己的TLS头。

2.TLS设计目标

TLS的设计目标是构建一个安全传输层（Transport Layer Security ），在基于连接的传输层（如tcp）上提供：

（1）保密性，message privacy (保密通过加密encryption实现，所有信息都加密传输，第三方无法窃听 )

（2）完整性，message integrity（ 通过MAC校验机制，一旦被篡改，通信双方会立刻发现 ）

（3）认证， mutual authentication （双方认证，双方都可以配备证书，防止身份被冒充 ）

（4）互操作、通用性 （ 根据公开的rfc，任何符合rfc的软件实现都可以互操作，不受限于任何专利技术）

（5）可扩展性 ( 通过扩展机制 tls_ext可以添加功能，有大量的新功能，都是通过扩展添加的)

（6）高效率 （通过session cache，恰当部署cache之后，tls的效率很高）

3.TLS发展历史

1995: SSL 2.0, 由Netscape提出，这个版本由于设计缺陷，并不安全，很快被发现有严重漏洞，已经废弃。

1996: SSL 3.0. 写成RFC，开始流行。目前(2015年)已经不安全，必须禁用。

1999: TLS 1.0. 互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。

2006: TLS 1.1. 作为 RFC 4346 发布。主要fix了CBC模式相关的如BEAST攻击等漏洞。

2008: TLS 1.2. 作为RFC 5246 发布 。增进安全性。目前(2015年)应该主要部署的版本。

2015之后: TLS 1.3，还在制订中，支持0-rtt，大幅增进安全性，砍掉了aead之外的加密方式。

由于SSL的2个版本都已经退出历史舞台了，所以本文后面只用TLS这个名字。 一般所说的SSL就是TLS。

4.握手原理

（1）为了在握手协议解决降级攻击的问题，TLS协议规定：client发送ClientHello消息，server必须回复ServerHello消息，否则就是fatal error，当成连接失败处理。ClientHello和ServerHello消息用于建立client和server之间的安全增强能力，ClientHello和ServerHello消息建立如下属性：

Protocol Version

Session ID

Cipher Suite

Compression Method

（2）另外，产生并交换两个random值 ClientHello.random 和 ServerHello.random

（3）密钥协商使用四条： server的Certificate，ServerKeyExchange，client的Certificate，ClientKeyExchange 。TLS规定以后如果要新增密钥协商方法，可以订制这4条消息的数据格式，并且指定这4条消息的使用方法。密钥协商得出的共享密钥必须足够长，当前定义的密钥协商算法生成的密钥长度必须大于46字节。

（4）原理类似下图（实验步骤中会详细介绍）

四、实验步骤

（一）wireshark捕包

1.选择https://www.baidu.com/网站，首先通过ping语句获得百度ip地址61.135.169.125。

2.wireshark捕包，使用ip.src==61.135.169.125&&ssl过滤包。在浏览器中访问https://www.baidu.com/，结果如下图所示：

（二）握手过程

首先我们了解一下建立握手连接的目的：（1）身份的验证，client与server确认对方是它相连接的，而不是第三方冒充的，通过证书实现；（2）client与server交换session key，用于连接后数据的传输加密和hash校验。

其次分析简单的SSL握手连接过程(仅Server端交换证书给client)：

1.Client发送ClientHello，指定版本，随机数random，所有支持的密码套件(CipherSuites)。

（1）ContentType指示SSL通信处于握手阶段。除此之外，还有开始加密传输(ChangeCipherSpec)还是正常通信(Application)等，如图：

（2）Version是TLS的版本1.2。其他版本见下表：

（3）Handshake Type是在handshake阶段中的client hello。其它具体阶段见下表：

（4）ClientHello附带的数据随机数据random，会在生成session key时使用(会话密钥)。

（5）Cipher suite列出了client支持的所有加密算法组合，不同的cipher 决定了握手的交互过程。

cipher的格式为：认证算法_密钥交换算法_加密算法_ 摘要算法。可以看出每一组包含3种算法，一个是非对称算法，如RSA，一个是对称算法如AES，3DES等，一个是Hash算法，如SHA等。server会从这些算法组合中选取一组，作为本次SSL连接中使用。

2.Server回应ServerHello。指定版本，random，选择CipherSuites，会话ID(Session ID)，确认使用的加密方法（RSA公钥加密），如图所示：

3.Server发送Certificate。

（1）服务器发一个证书给客户端，该证书用于向客户端确认服务器的身份。如果配置服务器的SSL需要验证服务器的身份，会发送该消息（多数电子商务应用都需要服务器端身份验证。（服务器如果需要验证客户端的身份，那么服务器会发一个“Certificate Request”给浏览器，而在很多实现中，服务器一般不需要验证客户端的身份）。

（2）server的证书信息，只包含public key，server将该public key对应的private key保存好，用于证明server是该证书的实际拥有者，验证原理很简单：client随机生成一串数，用server这里的public key加密(RSA算法)，发给server，server用private key解密后返回给client，client与原文比较，如果一致，则说明server拥有private key，也就说明与client通信的正是证书的拥有者，因为public key加密的数据，只有private key才能解密。利用这个原理，也能实现session key的交换，加密前的随机数就可用作session key，因为除了client和server，没有第三方能获得该数据。但在实际使用时会复杂很多，数据经过多次hash，伪随机等的运算，前面提到的client和server端的RN都会参与计算。

4.Server发送ServerKeyExchange。

（1）这个包告诉我们服务器和客户端是通过Diffie-Hellman算法来生成最终的密钥（也就是Sessionkey会话密钥），pubkey是Diffie-Hellman算法中的一个参数，这个参数需要通过网络传给客户端，即使它被截取也没有影响安全性。

（2）此外，在网上一些资料中没有ServerKeyExchange这个过程，在certificate后就是ServerHelloDone过程，我认为是将ServerKeyExchange包含在certificate过程中了。

5.Server发送ServerHelloDone。

6.Client发送ClientKeyExchange,change cipher spec, encrypted handshake message(Finishd)，用于与server交换session key。

（1）客户端收到服务器发来的ServerKeyExchange包来之后，运行Diffie-Hellman算法生成一个pubkey，然后发送给服务器。通过这一步和上面ServerKeyExchange两个步骤，服务器和客户端分别交换了pubkey，这样他们就可以分别生成了一个一样的sessionkey（具体的实现过程可以参考Diffie-Hellman算法的实现）。服务器和客户端向对方发送了pubkey之后，双方就可以计算出相同的密钥了，并且这个过程没有安全问题。

（2）发送ChangeCipherSpec，指示Server从现在开始发送的消息都是加密过的。

（3）client发送的encrypted handshake message加密数据非常关键，一是能证明握手数据没有被篡改过，二也能证明自己确实是密钥的拥有者(这里是单边验证，只有server有certificate，server发送的Finished能证明自己含有private key，原理是一样的)。client将之前发送的所有握手消息存入handshake message缓存。

完成上面的步骤，可以说TLS的握手阶段已经完成了。但是，服务器还会发送一个Session Ticket给浏览器。

7.server发送Session Ticket给client。

这个sessionticket包含了这个ticket的生命周期、长度、id等等信息。sessionticket包的作用是：握手阶段用来建立TLS连接。如果出于某种原因，对话中断，就需要重新握手。客户端只需发送一个服务器在上一次对话中发送过来的sessionticket。这个sessionticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到sessionticket以后，解密后就不必重新生成对话密钥而是可以继续使用上一次的连接。

8.server发送ChangeCipherSpec给client。

Server指示client从现在开始发送的消息都是加密过的。

9.server发送encrypted handshake message（Finishd）给client。

与client发送Finished方法一致，server发送的Finished里包含hash给client，client会进行校验，如果通过，说明握手过程中的数据没有被第三方篡改过，也说明server是之前交换证书的拥有者。现在双方就可以开始后续通信，进入Application data了。

五、实验补充

当前TLS安全问题：

2016年1月，Computer Science and Automation (INRIA)的安全研究人员在TLS 1.2协议的实现过程中发现一个新漏洞，并将该新型攻击命名为“SLOTH”。中间人攻击者可利用SLOTH以下列方法攻击加密流量：解密加密的流量、冒充合法的客户端、冒充合法的服务器。之所以称之为SLOTH，是因为攻击者强迫目标使用弱的哈希算法，这是首例公开的针对TLS、IKE和SSH协议的原像/碰撞攻击。

SLOTH攻击揭示了TLS协议的最新版本中的一些安全问题。即使在安全协议栈中禁用弱密码套件，该攻击仍能发生。在TLS 1.2以后的版本中，TLS协议实现中的许多响应都会删除MD5支持。因此，在大多数情况下，更新现有的TLS栈可以有效的解决此类问题。但是，该更新操作不能仅限于TLS协议，因为SSH和VPN服务也会受到SLOTH攻击的影响。安全人员可以检查TLS、SSH和VPN相关的所有配置，并禁用MD5支持。同时，如果使用的是第三方通信设备，那么应该检查当前配置和供应商更新信息。