Loading [MathJax]/jax/output/CommonHTML/config.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >SSL/TLS 通信过程

SSL/TLS 通信过程

作者头像
103style
发布于 2022-12-19 05:52:18
发布于 2022-12-19 05:52:18
1.1K0
举报

转载请以链接形式标明出处: 本文出自:103style的博客

目录

  • Wireshark抓包
  • Client Hello
  • Server Hello、Certificate、Server Key Exchange、Server Hello Done
  • Client 验证 Server 证书
  • Client Key Exchange、Change Cipher Spec、Encrypted Handshake Message
  • Server→New Session Ticket
  • Server→Change Cipher Spec、Encrypted Handshake Message
  • 握手结束
  • 加密通信–Application Data
  • 重建连接
  • 密钥计算
  • 参考文章

Wireshark抓包

首先是 TCP 的三次握手,然后就到 TLS的通信。

Source

Destination

Protocol

Info

Client

Server

TCP

[SYN] Seq=0

Server

Client

TCP

[SYN, ACK] Seq=0 Ack=1

Client

Server

TCP

[ACK] Seq=1 Ack=1

Client

Server

TLSv1.2

Client Hello

Server

Client

TLSv1.2

Server Hello Certificate Server Key Exchange Server Hello Done

Client

Server

TLSv1.2

Client Key Exchange Change Cipher Spec Encrypted Handshake Message

Server

Client

TLSv1.2

New Session Ticket Change Cipher Spec Encrypted Handshake Message

Client

Server

TLSv1.2

Application Data

Server

Client

TLSv1.2

Application Data


Client Hello

客户端发起请求,以明文传输请求信息,包含版本信息,加密套件候选列表,压缩算法候选列表,随机数,扩展字段等信息,相关信息如下:

  • 支持的最高 TSL协议 版本 version,从低到高依次 SSLv2 < SSLv3 < TLSv1 < TLSv1.1 < TLSv1.2,当前基本不再使用低于 TLSv1 的版本。
  • 随机数 Random, 用于后续的密钥的生成。
  • 客户端支持的加密套件 Cipher Suites 列表,每个加密套件对应前面TLS原理中的四个功能的组合:认证算法(身份验证)、密钥交换算法KeyExchange(密钥协商)、对称加密算法Enc(信息加密)和 信息摘要Mac(完整性校验)。
  • 支持的压缩算法 Compression Methods 列表,用于后续的信息压缩传输。
  • 扩展字段 Extension,支持协议与算法相关参数以及其它辅助信息等,常见的SNI就属于扩展字段。

Server Hello、Certificate、Server Key Exchange、Server Hello Done

  • Server Hello 服务端返回墒的信息结果,包括选择使用的协议版本Version(TLS 1.2),选择的加密套件 Cipher Suite(TLS_ECDHE_RAS_WITH_AES_128_GCM_SHA256),选择的压缩算法 Compression Method(null)、随机数 Random 等,其中随机数用于后续的密钥协商。
  • Server Key Exchange Server Hello中选择的 ECDHE 密钥交换算法 比 RSA 密钥交换算法多的一个步骤。
  • Server Hello Done 通知客户端 Server Hello 信息发送结束

Client 验证 Server 证书

客户端验证证书的合法性,如果验证通过才会进行后续的通信,否则根据错误情况做出不同提示和操作,合法性验证包括如下:

  • 证书链的可信性 trusted catificate path(上面Server 端配置的证书链)
  • 证书是否吊销revocation,有两类方式离线CRL与在线OCSP,不同的客户端行为会不同.
  • 有效期expiry date,证书是否在有效时间范围.
  • 域名domain,核查证书域名是否与当前的访问域名匹配,匹配规则后续分析.

Client Key Exchange、Change Cipher Spec、Encrypted Handshake Message

  • Client Key Exchange 合法性校验通过之后,客户端计算产生随机数字 Pre-master,并用证书公钥加密,发送给服务器。 此时客户端已经获取全部的计算协商密钥需要的信息:两个明文随机数 Random_CRandom_S 与自己计算产生的 Pre-master,计算得到协商密钥:enc_key=Fuc(random_C,random_S,Pre-Master)
  • Change Cipher Spec 客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信。
  • Encrypted Handshake Message 结合之前所有通信参数的hash值与其它相关信息生成一段数据,采用协商密钥session secret与算法进行加密,然后发送给服务器用于数据与握手验证。

Server:New Session Ticket

为了加快建立握手的速度,减少协议带来的性能降低和资源消耗,TLS协议有两类会话缓存机制:会话标识Session ID会话记录Session ticket

  • Session ID 由服务器端支持,协议中的标准字段,因此基本所有服务器都支持,服务器端保存会话ID以及协商的通信信息,Nginx1M 内存约可以保存 4000个 Session ID 机器相关信息,占用服务器资源较多。
    • 如果客户端和服务器之间曾经建立了连接,服务器会在握手成功后返回 Session ID,并保存对应的通信参数在服务器中。
    • 如果客户端再次需要和该服务器建立连接,则在 Client Hello 中 Session ID 中携带记录的信息,发送给服务器。
    • 服务器根据收到的 Session ID 检索缓存记录,如果没有检索到缓存过期,则按正常的握手过程进行。
    • 如果检索到对应的缓存记录,则返回 Change Cipher SpecEncrypted Handshake Message 信息,两个信息作用类似,Encrypted Handshake Message 是到当前的通信参数与 master_secret 的 Hash值。
    • 如果客户端能够验证通过服务器加密数据,则客户端同样发送 Change Cipher SpecEncrypted Handshake Message 信息。
    • 服务器验证数据通过,则握手建立成功,开始进行正常的加密数据通信。
  • Session ticket 需要服务器和客户端都支持,属于一个扩展字段,将协商的通信信息加密之后发送给客户端保存,密钥只有服务器知道,占用服务资源很少。
    • 如果客户端和服务器之间曾经建立了连接,服务器会在 New Session Ticket 数据中携带加密的 Session ticket 信息,客户端保存。
    • 如果客户端再次需要和该服务器建立连接,则在 Client Hello 中扩展字段 Session Ticket 中携带加密信息,一起发送给服务器。
    • 服务器解密 Session Ticket 数据,如果解密失败,则按照正常的握手过程进行;
    • 如果解密成功,则返回 Change Cipher SpecEncrypted Handshake Message 信息,两个信息作用与 Session ID中类似。
    • 如果客户端能够验证通过服务器加密数据,则客户端同样发送 Change Cipher SpecEncrypted Handshake Message 信息。
    • 服务器验证数据通过,则握手建立成功,开始进行正常的加密数据通信。

二者对比,主要是保存协议信息的位置与方式不同,类似于 httpsessincookie。 二者都存在的情况下,(nginx实现)优先使用 Session Ticket


Server:Change Cipher Spec、Encrypted Handshake Message

服务器用私钥解密加密的 Pre-master 数据,基于之前交换的两个明文随机数 Random_CRandom_S,计算得到协商密钥:enc_key=Fuc(random_C,random_S,Pre-Master)。 计算之前所有接收信息的hash值,然后解密客户端发送的 Encrypted Handshake Message,验证数据和密钥的正确性。

  • Change Cipher Spec 验证通过之后,服务器同样发送 Change Cipher Spec 以告知客户端后续的通信都采用协商的密钥与算法进行通信。
  • Encrypted Handshake Message 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 Session Secret 与算法加密并发送到客户端。

握手结束

客户端计算所有接收信息的 Hash 值,并采用协商密钥解密 Encrypted Handshake Message,验证服务器发送的数据和密钥,验证通过则握手完成。


加密通信–Application Data

开始使用协商密钥与算法进行加密通信。注意:

  • 服务器也可以要求验证客户端,即双向认证,可以在 Server Hello 过程要求发送 Client Certificate Request 信息,客户端在 Client Key Exchange 过程中先发送 Client CertificateCertificate Verify Message 信息,证书的验证方式基本相同, Certificate Verify Message 是采用 Client 的私钥加密的一段基于已经协商的通信信息得到数据,服务器可以采用对应的公钥解密并验证。
  • 根据使用的密钥交换算法的不同,如 ECC 等,协商细节略有不同,总体相似。
  • Sever Key Exchange 的作用是 Server Certificate 没有携带足够的信息时,发送给客户端以计算 pre-master,如基于 DH 的证书,公钥不被证书中包含,需要单独发送。
  • Change Cipher Spec 实际可用于通知对端改变当前使用的加密通信方式。
  • Alter message 用于指明在握手或通信过程中的状态改变或错误信息,一般告警信息触发条件是连接关闭,收到不合法的信息,信息解密失败,用户取消操作等,收到告警信息之后,通信会被断开或者由接收方决定是否断开连接。

重建连接

重建连接(renegotiation) 即放弃正在使用的 TLS 连接,重新进行 身份认证 和 密钥协商 的过程,特点是 不需要断开当前的数据传输 就可以重新 身份认证、更新密钥或算法,因此服务器端存储和缓存的信息都可以保持。客户端和服务器都能够发起重建连接的过程,当前 windows 2000 & XP 与 SSL 2.0不支持。

  • 服务器重建连接 服务器端重建连接一般情况是客户端访问受保护的数据时发生。基本过程如下:
    • 客户端和服务器之间建立了有效 TLS 连接并通信。
    • 客户端访问受保护的信息。
    • 服务器端返回 Hello Request 信息。
    • 客户端收到 Hello Request 信息之后发送 Client Hello 信息,开始重新建立连接。
  • 客户端重建连接 客户端重建连接一般是为了更新通信密钥。
    • 客户端和服务器之间建立了有效 TLS 连接并通信。
    • 客户端需要更新密钥,主动发出 Client Hello 信息。
    • 服务器端收到 Client Hello 信息之后无法立即识别出该信息非应用数据,因此会提交给下一步处理,处理完之后会返回通知该信息为要求重建连接。
    • 在确定重建连接之前,服务器不会立即停止向客户端发送数据,可能恰好同时或有缓存数据需要发送给客户端,但是客户端不会再发送任何信息给服务器。
    • 服务器识别出重建连接请求之后,发送 Server Hello 信息至客户端。
    • 客户端也同样无法立即判断出该信息非应用数据,同样提交给下一步处理,处理之后会返回通知该信息为要求重建连接。
    • 客户端和服务器开始新的重建连接的过程。

密钥计算

上节提到了两个明文传输的随机数 Random_CRandom_S 与通过加密在服务器和客户端之间交换的 Pre-master,三个参数作为密钥协商的基础。本节讨论说明密钥协商的基本计算过程以及通信过程中的密钥使用。

  • 计算 Key 涉及参数 Random ClientRandom Server, Pre-master, Master secret, key material, 计算密钥时,服务器和客户端都具有这些基本信息,交换方式在上节中有说明,计算流程如下:
  • 客户端采用 RSADiffie-Hellman 等加密算法生成 Pre-master
  • Pre-master 结合 Random_CRandom_S 两个随机数通过 PseudoRandomFunction(PRF)计算得到 Master secret
  • Master secret 结合 Random_CRandom_S两个随机数通过迭代计算得到 Key material

以下为一些重要的记录,可以解决部分爱深入研究朋友的疑惑:

  • PreMaster secret 前两个字节是 TLS 的版本号,这是一个比较重要的用来核对握手数据的版本号,因为在 Client Hello 阶段,客户端会发送一份加密套件列表和当前支持的 SSL/TLS 的版本号给服务端,而且是使用明文传送的,如果握手的数据包被破解之后,攻击者很有可能篡改数据包,选择一个安全性较低的加密套件和版本给服务端,从而对数据进行破解。所以,服务端需要对密文中解密出来对的 PreMaster 版本号跟之前 Client Hello 阶段的版本号进行对比,如果版本号变低,则说明被串改,则立即停止发送任何消息。
  • 不管是客户端还是服务器,都需要随机数,这样生成的密钥才不会每次都一样。由于 SSL 协议中证书是静态的,因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于 RSA 密钥交换算法来说,pre-master-key 本身就是一个随机数,再加上 hello 消息中的随机,三个随机数通过一个密钥导出器最终导出一个对称密钥。 pre master 的存在在于 SSL 协议不信任每个主机都能产生完全随机的随机数,如果随机数不随机,那么 pre master secret 就有可能被猜出来,那么仅适用 pre master secret 作为密钥就不合适了,因此必须引入新的随机因素,那么客户端和服务器加上 pre master secret 三个随机数一同生成的密钥就不容易被猜出了,一个伪随机可能完全不随机,可是三个伪随机就十分接近随机了,每增加一个自由度,随机性增加的可不是一。


参考文章


如果觉得不错的话,请帮忙点个赞呗。 如果看到有描述错误的地方,请指出来,感谢。

以上


本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2020-03-16,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
蚂蚁区块链第9课 SSL/TLS工作原理及在蚂蚁BAAS中的应用
辉哥在学习蚂蚁BAAS系统时,发现了一堆证书或者公私钥名称,包括trustCa,ca.crt,client.crt,client.key,pub.txt,MyPKCS12.p12等等文件,不知道干什么用,内心是奔溃的。后来在阿里专家孙善禄的指导下,输出了《蚂蚁区块链第8课 如何创建新的账户?》搞清楚了user.key和pub.txt文件的作用。 本文着重于介绍SSL/TLS工作原理,带着大家一起学习trustCa,ca.crt,client.key,client.crt,client.key等文件的作用。
辉哥
2019/04/14
1.8K0
SSL/TLS 原理及抓包详解
HTTP 本身不具备加密的功能,所以也无法做到对通信整体(使用 HTTP 协议通信的请求和响应的内容)进行加密。
因你是玫瑰色的
2022/01/04
10.5K0
全站 HTTPS 来了
阅读提示:全文较长,预计阅读时长:20分钟 各位使用百度、谷歌或淘宝的时候,有没有注意浏览器左上角已经全部出现了一把绿色锁,这把锁表明该网站已经使用了 HTTPS 进行保护。仔细观察,会发现这些网站已经全站使用 HTTPS。同时,iOS 9 系统默认把所有的 http 请求都改为 HTTPS 请求。随着互联网的发展,现代互联网正在逐渐进入全站 HTTPS 时代。 全站 HTTPS 能够带来怎样的优势?HTTPS 的原理又是什么?同时,阻碍 HTTPS 普及的困难是什么? 综合参考多种资料并经过实践验证,探究
腾讯Bugly
2018/03/23
1.2K0
全站 HTTPS 来了
SSL/TLS 双向认证(一) — SSL/TLS 工作原理
本文部分参考: https://www.wosign.com/faq/faq2016-0309-03.htm https://www.wosign.com/faq/faq2016-0309-04.htm http://blog.csdn.net/hherima/article/details/52469674
全栈程序员站长
2022/09/03
10.7K0
SSL/TLS 双向认证(一) — SSL/TLS 工作原理
SSL协议原理
SSL(Security Socket Layer)是一个安全协议,为基于TCP的应用层协议提供安全连接,SSL介于TCP/IP协议栈第四层和第七层之间。SSL可以为HTTP协议提供安全例案件。SSL为网络上数据的传输提供安全性保障。
全栈程序员站长
2021/04/16
1.3K0
SSL协议原理
SSL协议原理详解
SSL (Secure Sockets Layer)安全套接层。是由Netscape公司于1990年开发,用于保障Word Wide Web(WWW)通讯的安全。主要任务是提供私密性,信息完整性和身份认证。1994年改版为SSLv2,1995年改版为SSLv3.
全栈程序员站长
2022/09/05
2.5K0
SSL协议原理详解
抓包神器 Wireshark,帮你快速定位线上网络故障(5)
Wireshark 就像网络世界的显微镜,我们可以在它的帮助下了解网络中发生的一切。
一猿小讲
2020/12/31
1.2K0
Https、SSL/TLS相关知识及wireShark抓包分析
在HTTP协议中,所有报文的发送、接收都是以明文的形式进行的。也就是说,在TCP/IP五层网络模型中,数据直接以明文的形式从应用层(HTTP)发送给传输层(TCP),之间没有任何加密过程,如下图所示:
lyb-geek
2022/03/10
2.9K0
Https、SSL/TLS相关知识及wireShark抓包分析
Python Web学习笔记之SSL,TLS,HTTPS
一、 SSL 1. SSL简介 SSL协议位于TCP/IP协议与各种应用层协议之间,为数据通讯提供安全支持。SSL协议可分为两层: SSL记录协议(SSL Record Protocol):它建立在可靠的传输协议(如TCP)之上,为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议(SSL Handshake Protocol):它建立在SSL记录协议之上,用于在实际的数据传输开始前,通讯双方进行身份认证、协商加密算法、交换加密密钥等。 SSL协议提供的服务主要有:1)认证用户和服务器,确保
Jetpropelledsnake21
2018/07/04
1.3K0
一文读懂https中密钥交换协议的原理及流程
http与https区别:HTTP 由于是明文传输,所以在安全性上存在以下三个风险:
绿盟科技研究通讯
2022/06/06
9K0
一文读懂https中密钥交换协议的原理及流程
新特性解读 | 从 wireshark 看 MySQL 8.0 加密连接
爱可生 DBA 团队成员,负责项目日常问题处理及公司平台问题排查。热爱 IT,喜欢在互联网里畅游,擅长摄影、厨艺,不会厨艺的 DBA 不是好司机,didi~
爱可生开源社区
2020/04/27
2.3K0
新特性解读 | 从 wireshark 看 MySQL 8.0 加密连接
真正“搞”懂HTTPS协议17之TLS握手
  经过前两章的学习,我们知道了通信安全的定义以及TLS对其的实现~有了这些知识作为基础,我们现在可以正式的开始研究HTTPS和TLS协议了。嗯……现在才真正开始。
zaking
2023/02/16
3K0
真正“搞”懂HTTPS协议17之TLS握手
用WireShark简单看看SSL/TLS协议
HTTPS目前是网站标配,否则浏览器会提示链接不安全,同HTTP相比比,HTTPS提供安全通信,具体原因是多了个“S”层,或者说SSL层[Secure Sockets Layer],现在一般都是TLS[Transport Layer Security],它是HTTP明文通信变成安全加密通信的基础,SSL/TLS介于应用层和TCP层之间,从应用层数据进行加密再传输。安全的核心就在加密上:
看书的小蜗牛
2022/05/26
2.7K0
用WireShark简单看看SSL/TLS协议
图文结合,帮你理清HTTPS请求中的SSL加密过程
my.oschina.net/u/3412738/blog/3212116:来源
苏南
2020/12/16
2.8K0
图文结合,帮你理清HTTPS请求中的SSL加密过程
面试官你不要说我不懂TLS握手了
非对称加密主要用来保护对称加密密钥交换的安全性,一旦客户端和服务端交换密钥完成,即可使用密钥采用对称加密的方式进行通信。
shysh95
2021/11/25
7790
面试官你不要说我不懂TLS握手了
HTTPS的基础理论知识
首先推荐一本书,《HTTP权威指南》我就是看这本书入门的,对http协议有了更好的理解,学习https的理论知识我认为需要了解以下几点,需要一步步的深入学习:
星哥玩云
2022/07/24
2980
HTTPS的基础理论知识
网络协议(十二):HTTPS(SSL/TLS、TLS1.2的连接)
Java微观世界
2025/01/21
6600
网络协议(十二):HTTPS(SSL/TLS、TLS1.2的连接)
几幅图,拿下 HTTPS
我很早之前写过一篇关于 HTTP 和 HTTPS 的文章,但对于 HTTPS 介绍还不够详细,只讲了比较基础的部分,所以这次我们再来深入一下 HTTPS,用实战抓包的方式,带大家再来窥探一次 HTTPS。
小林coding
2021/01/12
7590
几幅图,拿下  HTTPS
Fiddler不为人知的小秘密(二)
第一步:客户端发起明文请求:将自己支持的一套加密规则、以及一个随机数(Random_C)发送给服务器 第二步:服务器选出一组加密规则和hash算法,并将自己的身份信息以证书(CA:包含网站地址、加密公钥、证书颁发机构等信息)和一个随机数(Random_S)发给客户端 第三步:客户端接到服务器的响应验证证书的合法性(颁发证书的机构是否合法,证书中包含的网站地址是否与正在访问的地址一致等)。如果证书受信任,则浏览器栏里面会显示一个小锁头,否则会给出证书不受信的提示。 如果证书受信任,或者是用户接受了不受信的证书,客户端做以下事情:
用户5521279
2020/09/23
5990
Fiddler不为人知的小秘密(二)
【腾讯TMQ】从 wireshark 抓包开始学习 https
腾讯移动品质中心TMQ
2017/02/22
6.8K0
相关推荐
蚂蚁区块链第9课 SSL/TLS工作原理及在蚂蚁BAAS中的应用
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档