解密TLS协议全记录之TLS协议剖析记录
引言
这篇文章是学习TLS协议的学习总结， 根据奥卡姆剃刀原理， 文章会尽可能记录相对有价值的内容，
预备知识
想要解密TLS的首当其冲的点，便是要深入了解TLS中的RFC协议文档。
- 学习网络协议之前，必须先找对最基本的协议学习网站，
rfc协议官网 https://www.rfc-editor.org
ietf协议官网 https://www.ietf.org/ ，其实这个网站，我经常搜索不出比较理想的文件，标题不直观，杂七杂八的会议记录文件一大堆夹杂在规范文件之中。 - 通过上面的网站，我们可以获取到tls的几个协议说明链接.
TLS1.0: https://www.rfc-editor.org/rfc/rfc2246.html
TLS1.2: https://www.rfc-editor.org/rfc/rfc5246.html https://tools.ietf.org/html/rfc5246
TLS1.3草案:https://tools.ietf.org/html/draft-ietf-tls-tls13-23 - 本博客会以tls1.2为主， tls1.3协议为辅，毕竟tls1.3 毕竟还处于草稿设计阶段。
TLS1.2协议解析
在描述整体的通信流程之前，先了解tls中将会使用的一些协议描述。
报文中的前几个字段的描述， 这是每个TLS包文，都会拥有的参数
ContentType type：表示当前的协议类型， 比如握手协议，警告协议。
ProtocolVersion version：表示当前TLS的协议版本。
Length：表示接下来的数据段(fragment)的尺寸大小。
Fragment: 用于填充TLS协议的各类子协议内容和应用的通信数据。
并且，了解整体通信的时序图，也是相当有必要的。
Client ServerClientHello -------->ServerHelloCertificate*ServerKeyExchange*CertificateRequest*<-------- ServerHelloDoneCertificate*ClientKeyExchangeCertificateVerify*[ChangeCipherSpec]Finished -------->[ChangeCipherSpec]<-------- FinishedApplication Data <-------> Application Data
1. Handshake Protocol协议
Handshake Protocol: 会话状态(session state)的加密参数由TLS握手协议产生, 这个过程会选择加密套件，压缩方法， 做相互之间的证书认证，除此之外，将会产生客户端的随机数和服务器的随机数，使用加密技术去生成共享密钥， 目前主要是 RSA和DH加密技术。
notice: 在该协议下的多个子协议报文，服务器和客户端可以选择同时发送，也可以按序拆开发送，查阅wireshark报文的时候要注意这一点。
0. Client Hello消息中，客户端将会把自己支持的密钥套件发送给服务端， 服务端将会从中选择一个来进行通信，一般来说服务器都会支持，而且一般来说， 服务器一般会选择自己支持的或者说自己配置的(可查看下文的注意高亮文本)，不会去关注客户端的报文列表。
此处的版本信息指的是客户端支持的最新的协议版本号，官方说为了防止RollBack攻击。
注意: 在TLS中有规定， 客户端的加密套件只是参考选择， 服务器可以选择不选，而选择服务器配置和支持的加密套件。之前参考以下博客： https://blog.csdn.net/appletreesujie/article/details/54972999, 其中提到 通过命令 curl -k --ciphers rsa_rc4_128_sha https://10.1.1.1/url_sample可以设置客户端加密套件，可是抓包时，发现curl命令发出去的包并不会指定该加密套件，粗滤看了一下代码，觉得应该还不支持， 而且curl命令的cipher指定的名字特别不规范， 完全不按照openssl以及TLS规定的名字来，要另外去查看代码获得。
1.0 Client Key Exchange Message的报文一般跟随客户端的证书一起发送，如果服务端有请求的话， 这个报文最大意义在于，在这个过程中， 通信的预主密钥将会被设置，并根据密钥交换算法， 要么是通过RSA密钥算法来交换，要么是通过DH密钥算法来通过参数交换(还有PSK密钥交换算法，不做赘述)，然后计算得到密钥， 交换密钥算法的几种类型如下：
select (KeyExchangeAlgorithm) {
case rsa:
EncryptedPreMasterSecret;
case dhe_dss:
case dhe_rsa:
case dh_dss:
case dh_rsa:
case dh_anon:
ClientDiffieHellmanPublic;
} exchange_keys;
1. 理解RSA交换密钥之前，需要简单了解RSA算法，该算法可以通过openssl产生一个随机的私钥， 然后通过私钥，可以得到公钥， 这个过程是不可逆的， 也就是说只有私钥可以解密， 所以，RSA也是非对称加密算法的一种。
2. 那么DH算法的话，就是通信双方都有一套自己的公钥和私钥，通过交换公钥之后，利用协商好的参数，然后使用DH算法计算，可以得到一个一样的密钥。下面引用维基百科的一个例子。
3. 还有一种PSK密钥交换算法， 基本原理就是使用 PSK 时，AP 和客户端必须配置相同的密钥或加密密码。AP 发送一个随机字符串到客户端。客户端接受该字符串，根据密钥对其进行加密（或编码），然后发送回 AP。AP 获取加密的字符串，并使用其密钥解密（或解码）。如果从客户收到的字符串在解密后与原来发送给客户端的字符串匹配，就允许该客户端连接。
愛麗絲與鮑伯协定使用 p=23以及base g=5
(参数一般有服务器下发).
愛麗絲选择一个秘密整数a=6(类似私钥值), 计算A = ga mod p并发送给鮑伯。
A = 56 mod 23 = 8.(类似公钥值)
鮑伯选择一个秘密整数b=15, 计算B = gb mod p并发送给愛麗絲。
B = 515 mod 23 = 19.
愛麗絲计算s = B a mod p
196 mod 23 = 2(共享密钥).
鮑伯计算s = A b mod p
815 mod 23 = 2.
1.1 如果是 RSA加密算法来交换密钥的话， 客户端将会生成一个随机48字节的预主密钥， 然后通过服务器的证书中的公钥加密发送给服务器，RSA不仅可以用来加密解密， 还可以用来数字签名证书哦， 可以查看我的另一篇文章， openssl的使用详解。
报文内容如下图的Encrypted PreMaster所示。
1.2 如果是DH 加密算法来交换密钥的话，客户端将会生成DH密钥中所需的Public Key(Yc）发送给服务器，此处有一点疑问，在客户端DH算法每次都要重新生成密钥， 而没有类似RSA算法提前生成证书来进行握手的话，那么每次要额外去计算一个DH算法的key value，会不会很浪费时间？答：因为DH每次生成key的话，确实浪费时间，所以基于椭圆曲线的ECDH算法应运而生， 此外，DH握手每次都会去生成不同的密钥，具有前向保密，RSA一旦通过公钥和加密信息去破解服务器私钥的话，就可以从握手中得到对称密钥，之后客户端和服务端将分别使用自己的私钥和对方的公钥来计算预主密钥，也就是TLS协议中指的The negotiated key(Z) ，所以DH算法也算是对称加密算法的一种。 客户端的public key如下所示：
注意：可能有人会好奇，为什么有的报文只有client key exchange message，有的还有server key exchange message， 因为如果是DH加密算法来交换密钥，服务端还要发送一个server key exchange message的报文来下发DH算法计算需要的额外参数以及Pub key。如下图所示：
1.3 那么当客户端和服务端之间得到密钥之后， 如何计算主密钥：
疑问： 既然有预主密钥，为何还要再浪费计算主密钥？ 预主密钥一样可以达到一样的加密效果？ 没时间深究，有了解的人可以联系我
master_secret = PRF(pre_master_secret, “master secret”, ClientHello.random + ServerHello.random) [0…47];
1.4 当服务器发送server hello done的报文的时候， 表示服务端的握手通信已经完成，服务器将会等待客户端的回复， 如果服务器发送了CertificateRequest的消息的话， 客户端一定要将自身具有的证书回复给服务器
1.5 当建立会话之后，服务器将会产生new session ticket来表示当前的会话窗口号，那么， 当客户端和服务端需要进行之前的会话的时候，则将想要恢复对话的窗口号(session id)发送给服务器， 这样可以避免再做一次完整的握手通信过程，服务器和客户端直接使用先前得到的密钥进行网络通信即可，恢复通信的报文如下， 省略了很多报文通信，节约了时间：
疑问： wireshark 有时候无法解密是不是就是因为报文通信的密钥使用的是之前商议好的密钥？，
A: 确实如此，如果是使用RSA密钥交换算法，那么报文中一定要包含ClientKeyExchange的消息， 这样wireshark 才能拿到客户端产生的随机数(预主密钥)
2.Change Cipher Spec 协议
Change Cipher Spec Protocol ： 该协议是为了提示通信的对端， 接下来的报文通信，将会使用刚协商的新的加密策略以及加密密钥，这个协议会从握手协议独立出来的主要原因是为了避免通道拖延，通信滞后。
3. Alert 协议：
Alert Protocol： 该协议用来传达警报消息的严重性以及说明，比如， 证书过期， 证书未知等， 必要的时候，会中断链接，警告消息同样会使用当前的加密策略进行加密和压缩
4. 其他， 查看官方协议。
TLS1.3协议学习
- TLS1.3的协议暂时关注的不多， 毕竟还只是草稿协议。
- 个人认为最明显的一点在于， TLS 1.3 的握手不再支持静态的 RSA 密钥交换，这意味着可以使用带有前向安全的 Diffie-Hellman 进行全面握手。并且使用 TLS 1.3 协议只需要一次往返（ 1-RTT ）就可以完成握手，这句话看一下协议的时序图应该可以理解。
- 为什么TLS1.3 不再支持RSA密钥交换， 看下面的时序图，可以发现，客户端直接先发key出去， 之后，服务器才下发证书， 那么就意味着此时的key无法被RSA算法中提到， 必须利用证书的公钥进行加密, 那么就只能是时DH算法中的public value，才能直接暴露出来。
Client ServerInitial Handshake:ClientHello+ key_share -------->ServerHello+ key_share{EncryptedExtensions}{CertificateRequest*}{Certificate*}{CertificateVerify*}{Finished}<-------- [Application Data*]{Certificate*}{CertificateVerify*}{Finished} --------><-------- [NewSessionTicket][Application Data] <-------> [Application Data]Subsequent Handshake:ClientHello+ key_share*+ pre_shared_key -------->ServerHello+ pre_shared_key+ key_share*{EncryptedExtensions}{Finished}<-------- [Application Data*]{Finished} -------->[Application Data] <-------> [Application Data]
附录：
- MAC(message Authentication code) 用来保证信息的完整性。
- HMAC: Keyed-Hashing for Message Authentication
- PRF(This pseudorandom function)， PRF, based on HMAC. This PRF with the
SHA-256 hash function is used for all cipher suites defined in this
document and in TLS documents published prior to this document when
TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a
PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a
stronger standard hash function
解密TLS协议全记录之TLS协议剖析记录相关推荐
- HTTPS协议详解：TLS/SSL握手过程
1.握手与密钥协商过程 基于RSA握手和密钥交换的客户端验证服务器为示例详解TLS/SSL握手过程 再看一张手绘时序图 (1).client_hello 在发送的 Client Hello 中会带上自 ...
- TLS协议学习-第二篇-握手协议
TLS协议学习第二篇,内容来自:https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-200 ...
- 网络协议文档阅读笔记-TLS vs DTLS | Difference between TLS and DTLS
TLS是工作在除应用层协议外最顶层的协议.也就是传输层协议,这个协议,在有些文档中称为应用层的子协议.DTLS与TLS区别就在那个D,也就是Datagram TLS协议 TLS:提供了应用程序(如We ...
- 第二篇：可靠连接，TCP协议全解析
文章目录 一.前言 二.TCP报文结构 三.TCP连接(重点:三次握手和四次挥手) 3.1 三次握手建立连接 3.2 四次挥手释放连接 3.3 wireshark演示 四.TCP可靠连接 4.1 序号 ...
- 痞子衡嵌入式：无线通信技术协议全搜罗 - 索引
大家好,我是痞子衡,是正经搞技术的痞子.今天痞子衡给大家介绍的是无线通信协议. 背景 无线通信(Wireless communication)是利用电磁波信号可以在自由空间中传播的特性进行信息交换的一 ...
- RTP协议全解析（H264码流和PS流）（转）
源: RTP协议全解析(H264码流和PS流) 转载于:https://www.cnblogs.com/LittleTiger/p/10489247.html
- 网络协议分析 | 传输层 ：史上最全UDP、TCP协议详解，一篇通~
文章目录 UDP 概念 格式 UDP如何实现可靠传输 基于UDP的应用层知名协议 TCP 概念 格式 保证TCP可靠性的八种机制 确认应答.延时应答与捎带应答 超时重传 滑动窗口 滑动窗口协议 后退n ...
- java已解密的登录请求_使用https协议解决掉顽固不化的已解密的登录请求
1.1 已解密的登录请求概述 在应用程序测试过程中,检测到将未加密的登录请求发送到服务器.由于登录过程所用的部分输入字段(例如:用户名.密码.电子邮件地址.社会保险号码,等等)是个人敏感信息,建议通过 ...
- 最全的TCP/UDP 协议知识点整理
关于计算机网络的基础知识,我前面写的两篇文章是入门文章,可以帮你构建一个计算机网络的基础架构,有了这个基础架构,后面的学习会很简单.下面是两篇文章的连接~~ 计算机网络体系结构与参考模型(1) 计算机 ...
最新文章
- python yield yield from
- Nature综述：微生物构成的氮循环网络
- 【转】HTML5第一人称射击游戏发布
- 计算机应用基础山东省,2019年山东省中等职业学校对口升学考试：计算机文化基础+计算机应用基础模拟试卷...
- 浅学习使用Ribbon 和 Feign的理解和使用
- 《scikit-learn》SVM（一）
- 2009年12月8号漕宝路电信机房真是电信封的吗？
- Java中的Bean是什么？
- HDU1273 漫步森林【水题】
- 米尔电子zynq ultrascale+ mpsoc底板外设资源清单分享
- ProtoBuf与JSON
- 最新delphi7序列号和破解文件
- Randao 可证公平随机数(VRF)白皮书
- 【vbs消息轰炸代码】
- 用scratch编程打字游戏
- 基于链表的学生信息管理系统和基于MySQL的学生信息管理系统 -C语言
- 【Kaggle-House Price Prediction】代码参考
- java手机震动_Android实现手机震动抖动效果的方法
- linux设置网卡开机自启,centos系统怎么设置网卡开机自启
- 什么叫集群?如何实现集群?