WireShark 抓包理解 TLS 建立加密连接的过程

最新推荐文章于 2024-10-09 23:02:26 发布

庚庚911

最新推荐文章于 2024-10-09 23:02:26 发布

阅读量8.9k

点赞数 9

分类专栏：网络 wireshark 文章标签： WireShark抓包 TLS加密连接

本文链接：https://blog.csdn.net/yetugeng/article/details/100554653

版权

本文详细介绍了使用WireShark抓包工具理解TLS加密连接建立的过程，包括实验环境、服务端证书、TLS握手原理、操作步骤和具体的握手阶段。通过对Client Hello、Server Hello、Certificate等步骤的分析，揭示了TLS如何确保身份验证、密钥交换和数据加密的安全性。

摘要由CSDN通过智能技术生成

一、实验环境

服务端：web容器 glassfish 部署了一个可以访问的web包

keystore.jks里添加的SSL证书，可参见 https://blog.csdn.net/yetugeng/article/details/81416320

客户端：一台笔记本，安装好wireshark

二、服务端的证书

在服务端keystore.jks内容如下，主要省略了Extensions部分内容

[dev@localhost config]$ keytool -list -v -keystore keystore.jks -storetype jks -storepass changeit
Keystore type: JKS
Keystore provider: SUN

Your keystore contains 2 entries

Alias name: glassfish-instance
Creation date: Dec 24, 2018
Entry type: PrivateKeyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=localhost.localdomain-instance, OU=GlassFish, O=Oracle Corporation, L=Santa Clara, ST=California, C=US
Issuer: CN=localhost.localdomain-instance, OU=GlassFish, O=Oracle Corporation, L=Santa Clara, ST=California, C=US
Serial number: 78ef63eb
Valid from: Mon Dec 24 12:12:29 HKT 2018 until: Thu Dec 21 12:12:29 HKT 2028
Certificate fingerprints:
	 MD5:  6C:5C:F1:FA:79:65:7F:1B:09:9F:D7:91:5B:63:C9:D5
	 SHA1: 78:B6:B9:27:9D:31:5B:D6:C1:24:04:A8:AD:F3:46:71:CA:30:C7:72
	 SHA256: 9F:06:23:E9:30:FB:3E:E5:AC:3A:01:40:12:78:56:72:36:38:62:C2:C2:0F:64:45:12:65:6A:88:2E:4E:2F:54
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions: 
....此处略.....

*******************************************
*******************************************

Alias name: s1as
Creation date: Jul 21, 2019
Entry type: PrivateKeyEntry
Certificate chain length: 3   #表明证书链有三条
Certificate[1]:               #第一条证书
Owner: CN=*.axxxxxxxxing.com, OU=PositiveSSL Wildcard, OU=Domain Control Validated
Issuer: CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salford, ST=Greater Manchester, C=GB
Serial number: 488f8b186f0fc7b5949f566e5cd6a1c2
Valid from: Sat Jul 20 08:00:00 HKT 2019 until: Mon Jul 20 07:59:59 HKT 2020
Certificate fingerprints:
	 MD5:  25:C0:F6:C3:5A:41:BF:B6:B2:A9:7A:B4:6B:DD:9A:DC
	 SHA1: 22:7A:AD:A6:2F:5A:A5:C1:C9:E0:C6:B6:35:55:56:14:D1:CC:5F:6E
	 SHA256: 38:81:F8:0B:FD:9F:97:F2:68:C1:53:7F:32:5F:AB:D3:C6:A0:86:7F:A3:8A:10:CB:98:F1:CD:93:BF:7E:34:09
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions: 

....此处略.....


Certificate[2]:           #第三条证书
Owner: CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salford, ST=Greater Manchester, C=GB
Issuer: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
Serial number: 7d5b5126b476ba11db74160bbc530da7
Valid from: Fri Nov 02 08:00:00 HKT 2018 until: Wed Jan 01 07:59:59 HKT 2031
Certificate fingerprints:
	 MD5:  AD:AB:5C:4D:F0:31:FB:92:99:F7:1A:DA:7E:18:F6:13
	 SHA1: 33:E4:E8:08:07:20:4C:2B:61:82:A3:A1:4B:59:1A:CD:25:B5:F0:DB
	 SHA256: 7F:A4:FF:68:EC:04:A9:9D:75:28:D5:08:5F:94:90:7F:4D:1D:D1:C5:38:1B:AC:DC:83:2E:D5:C9:60:21:46:76
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Extensions: 

....此处略.....


Certificate[3]:        #第三条证书
Owner: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
Issuer: CN=AddTrust External CA Root, OU=AddTrust External TTP Network, O=AddTrust AB, C=SE
Serial number: 13ea28705bf4eced0c36630980614336
Valid from: Tue May 30 18:48:38 HKT 2000 until: Sat May 30 18:48:38 HKT 2020
Certificate fingerprints:
	 MD5:  DB:78:CB:D1:90:95:27:35:D9:40:BC:80:AC:24:32:C0
	 SHA1: EA:B0:40:68:9A:0D:80:5B:5D:6F:D6:54:FC:16:8C:FF:00:B7:8B:E3
	 SHA256: 1A:51:74:98:0A:29:4A:52:8A:11:07:26:D5:85:56:50:26:6C:48:D9:88:3B:EA:69:2B:67:B6:D7:26:DA:98:C5
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions: 

....此处略.....


*******************************************
*******************************************
[dev@localhost config]$

我们重点需要看的是别名为s1as的这部分，其中s1as下包含了3条证书

分别是泛域名*.axxxxxxxxing.com的证书以及上两级的签名授权商的证书。

三、TLS握手原理

（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）原理类似下图（实验步骤中会详细介绍）

表 3-1
握手消息	动作描述	消息内容
1. Client —> Server Client Hello	客户端(浏览器)发送一个hello消息给服务端，发起建立SSL会话的请求。并告诉服务端，自己支持哪些加密算法(Cipher Suite List)。除此之外，还需要产生一个随机数（第一个随机数，用于以后生成对称密钥），发送给服务端。	1）支持的协议版本，如TLS 1.0版 2）由客户端生成的随机数，用于生成后面的“对称密钥” 3）支持的加密方法，比如RSA公钥加密 4）支持的压缩方法 5）请求的域名
2. Server —> Client Server Hello	服务端的首次响应，会确定加密协议版本，以及加密的算法，也会生成一个随机数（第二个随机数）给客户端。	1）协议的版本 2）加密的算法 3）服务端生成的随机数
3. Server —> Client Certificate	还会把自己的证书发送给客户端，让客户端进行校验。服务端证书中的公钥也可被用于加密后面握手过程中生成的对称密钥。	1）服务端证书证书颁发机构的名称证书本身的数字签名证书持有者公钥证书签名用到的Hash算法
4. Server —> Client Server Key Excha