TLS协议报文解析

原博网址:https://www.cnblogs.com/20179204gege/p/7858070.html

一、实验目的

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之后,双方就可以计算出相同的密钥(sessionkey)了,并且这个过程没有安全问题。

(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支持。同时,如果使用的是第三方通信设备,那么应该检查当前配置和供应商更新信息。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,240评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,328评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,182评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,121评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,135评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,093评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,013评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,854评论 0 273
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,295评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,513评论 2 332
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,678评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,398评论 5 343
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,989评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,636评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,801评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,657评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,558评论 2 352

推荐阅读更多精彩内容