TLS-SSL
Intro(TLS/SSL) #
placeholder
协议规范(TLS-RECORD) #
参考 wiki: TLS_record
实例分析用到的 已经记录过的数据,一个是来自 bctls-debug-jdk15to18 结合 idea bug(Evaluate and log) 输出,另外一个是 wiresharkAttention
第一次整理好相关东西后,发现当时没有记录解密相关的东西,然后不得不重新进行第二版。所以下面实例分析中用到的数据是第二个版本。
TLS-Record 基本结构
图片引用自: 7: TLS record format
建立会话基本流程
TLS_record 通用格式如下表:
TLS record format, general Offset Byte+0 Byte+1 Byte+2 Byte+3 Byte
0Content type — Bytes
1–4Legacy version Length (Major) (Minor) (bits 15–8) (bits 7–0) Bytes
5–( m−1)Protocol message(s) Bytes
m–( p−1)MAC (optional) Bytes
p–( q−1)Padding (block ciphers only) Content type
如下表:Hex Dec Type 0x14 20 ChangeCipherSpec 0x15 21 Alert 0x16 22 Handshake 0x17 23 Application 0x18 24 Heartbeat Legacy version
表如下:Major version Minor version version type SSL 1.0UnpublishedSSL 2.0 / rfc6176 3 0 SSL 3.0 / rfc7568 3 1 TLS 1.0 / rfc2246 3 2 TLS 1.1 / rfc4346 3 3 TLS 1.2 / rfc5246 3 4 TLS 1.3 / rfc8446 Length
:表示 protocol message(s),MAC 和 padding 的长度,不超过 214 个字节(ob100000000000000 = 16384 = 16KB)。Protocol message(s)
:一个或多个消息在这个协议字段里面定义,这个属性或许被加密依赖于当前连接的状态。MAC and padding
:在所有密码算法和参数都进行了协商和握手,并且发送一个 CipherStateChange 记录(见下文)来确认这些参数生效之前,不能在TLS记录的末尾出现 MAC 或者 padding 字段。Handshake protocol #
Tip
在建立TLS会话期间交换的大多数消息都基于此记录,除非发生错误或警告,并且需要通过 Alert 协议 记录发出信号,或者会话的加密方式被其他记录修改(比如: ChangeCipherSpec 协议)。
TLS record format for handshake protocol Offset Byte+0 Byte+1 Byte+2 Byte+3 Byte
022 — Bytes
1–4Legacy version Length (Major) (Minor) (bits 15–8) (bits 7–0) Bytes
5–8Message type Handshake message data length (bits 23–16) (bits 15–8) (bits 7–0) Bytes
9–( n−1)Handshake message data Bytes
n–( n+3)Message type Handshake message data length (bits 23–16) (bits 15–8) (bits 7–0) Bytes
( n+4)–Handshake message data Message type
:如下表code description delimiter code description 0 HelloRequest 12 ServerKeyExchange 1 ClientHello 13 CertificateRequest 2 ServerHello 14 ServerHelloDone 4 NewSessionTicket 15 CertificateVerify 8 EncryptedExtensions (TLS 1.3 only) 16 ClientKeyExchange 11 Certificate 20 Finished Length
:这个使用 3 个字节表示握手数据的长度,不包括 header。注意:多个握手包可以包括在一个记录中。HP-ClientHello 实例分析 #
TLS record:
16
:Content type,(表示握手包);03 01
:Legacy version,(TLS 1.0);00 fd
:Length,(253);01 00 00 f9 03 ...... 0b 00 02 01 00
:Protocol message(s),因为类型 0x16 是一个握手包,所以按照握手包协议进一步解析。
Handshake protocol:01
:Message type,(ClientHello);00 00 f9
:Handshake message data length,(249);03 03
:Version,(TLS 1.2 [0x0303]);e3 e5 0a 0c c0 ...... 05 34 d6 4b c0
:Random;e3 e5 0a 0c
:GMT Unix Time,十进制值为 3823438348; 在线转换 为我们时区的值: Wed Feb 28 2091 02:12:28 GMT+0800 (中国标准时间)c0 f1 f7 49 4c 14 89 45 9c 28 05 39 fa b4 e9 ce 08 77 f0 94 1f 44 4e 05 34 d6 4b c0
:Random Bytes;20
:Session ID length,(32);e0 76 16 70 7f ac e1 53 5f 39 77 f3 98 b3 ff 2a 19 b6 76 08 3e 23 15 d2 10 78 c5 a8 c1 2a 65 3a
:Session ID;00 1e
:Cipher Suites Length,(30);13 03 13 01 cc a9 c0 2b c0 23 c0 09 cc a8 c0 2f c0 27 c0 13 cc aa 00 9e 00 67 00 33 00 ff
:Cipher Suites,(两个字节为一组,总共 15 个);13 03
:Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)13 01
:Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)cc a9
:Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)c0 2b
:Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)c0 23
:Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)c0 09
:Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)cc a8
:Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)c0 2f
:Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)c0 27
:Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)c0 13
:Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)cc aa
:Cipher Suite: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xccaa)00 9e
:Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)00 67
:Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)00 33
:Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)00 ff
:Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)01
:Compression Methods Length,(1);00
:Compression Methods,(Compression Method: null (0));00 92
:Extensions Length,(146);00 17 00 00 00 ...... 0b 00 02 01 00
:Extensions;00 17 00 00
:[Type: extended_master_secret (23) Length: 0]00 16 00 00
:[Type: encrypt_then_mac (22) Length: 0]00 2b 00 05 04 03 04 03 03
:[Type: supported_versions (43) Length: 5 Supported Versions length: 4,TLS 1.3 (0x0304),TLS 1.2 (0x0303)]00 0a 00 10 00 0e 00 1d 00 1e 00 17 00 18 01 00 01 01 01 02
:[Type: supported_groups (10) Length: 16]00 0a
:[Type: supported_groups (10)]00 10
:[Length: 16]00 0e
:[Supported Groups List Length: 14]00 1d
:[Supported Group: x25519 (0x001d)]00 1e
:[Supported Group: x448 (0x001e)]00 17
:[Supported Group: secp256r1 (0x0017)]00 18
:[Supported Group: secp384r1 (0x0018)]01 00
:[Supported Group: ffdhe2048 (0x0100)]01 01
:[Supported Group: ffdhe3072 (0x0101)]01 02
:[Supported Group: ffdhe4096 (0x0102)]00 33 00 26 00 24 00 1d 00 20 20 87 73 67 9a 1e 19 0a 9c 9e 04 b8 1d 49 60 6f a1 2e 6c 12 f0 f6 19 03 24 99 0c 77 11 ec 04 60
:[Type: key_share (51) Length: 38]00 33
:[Type: key_share (51)]00 26
:[Length: 38]00 24
:[Client Key Share Length: 36]00 1d
:[Group: x25519 (29)]00 20
:[Key Exchange Length: 32]20 87 73 67 9a 1e 19 0a 9c 9e 04 b8 1d 49 60 6f a1 2e 6c 12 f0 f6 19 03 24 99 0c 77 11 ec 04 60
:[Key Exchange]00 05 00 05 01 00 00 00 00
:[Type: status_request (5) Length: 5 Certificate Status Type: OCSP (1) Responder ID list Length: 0 Request Extensions Length: 0 ]00 0d 00 30 00 2e 08 07 08 08 04 03 05 03 06 03 08 04 08 05 08 06 08 09 08 0a 08 0b 04 01 05 01 06 01 04 02 05 02 06 02 03 03 03 01 03 02 02 03 02 01 02 02
:[Type: signature_algorithms (13) Length: 48]00 0d
:[Type: signature_algorithms (13)]00 30
:[Length: 48]00 2e
:[Signature Hash Algorithms Length: 46]08 07
:[Signature Algorithm: ed25519 (0x0807)]08 08
:[Signature Algorithm: ed448 (0x0808)]04 03
:[Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)]05 03
:[Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)]06 03
:[Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)]08 04
:[Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)]08 05
:[Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)]08 06
:[Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)]08 09
:[Signature Algorithm: rsa_pss_pss_sha256 (0x0809)]08 0a
:[Signature Algorithm: rsa_pss_pss_sha384 (0x080a)]08 0b
:[Signature Algorithm: rsa_pss_pss_sha512 (0x080b)]04 01
:[Signature Algorithm: rsa_pkcs1_sha256 (0x0401)]05 01
:[Signature Algorithm: rsa_pkcs1_sha384 (0x0501)]06 01
:[Signature Algorithm: rsa_pkcs1_sha512 (0x0601)]04 02
:[Signature Algorithm: SHA256 DSA (0x0402)]05 02
:[Signature Algorithm: SHA384 DSA (0x0502)]06 02
:[Signature Algorithm: SHA512 DSA (0x0602)]03 03
:[Signature Algorithm: SHA224 ECDSA (0x0303)]03 01
:[Signature Algorithm: SHA224 RSA (0x0301)]03 02
:[Signature Algorithm: SHA224 DSA (0x0302)]02 03
:[Signature Algorithm: ecdsa_sha1 (0x0203)]02 01
:[Signature Algorithm: rsa_pkcs1_sha1 (0x0201)]02 02
:[Signature Algorithm: SHA1 DSA (0x0202)]00 0b 00 02 01 00
:[Type: ec_point_formats (11) Length: 2 EC point formats Length: 1 EC point format: uncompressed (0)]HP-ServerHello 实例分析 #
TLS record:
16
:Content type,(表示握手包);03 03
:Legacy version,TLS 1.2 (0x0303);00 59
:Length,(89);02 00 00 55 03 ...... 04 03 00 01 02
:Protocol message(s),因为类型 0x16 是一个握手包,所以按照握手包协议进一步解析。
Handshake protocol:02
:Message type,(ServerHello);00 00 55
:Handshake message data length,(85);03 03
:Version,(TLS 1.2 [0x0303]);52 f6 1e a4 6d ...... 8f 28 5b e9 fe
:Random;52 f6 1e a4
:GMT Unix Time,十进制值为 1391861412; 在线转换 为我们时区的值: Sat Feb 08 2014 20:10:12 GMT+0800 (中国标准时间);6d 79 2e 2b 1b 94 70 d7 eb 21 5d 42 ed 4b a3 44 88 45 f2 b8 c1 4b 63 8f 28 5b e9 fe
:Random Bytes;20
:Session ID length,(32);0a 0e a0 a9 e9 88 4d 2d 07 c1 54 db 76 d3 9c e0 97 48 eb af 7e 54 ee 51 d1 bb 61 39 7a 80 53 d0
:Session ID;c0 2b
:Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b);00
:Compression Method: null (0);00 0d
:Extensions Length,(13);ff 01 00 01 00 00 0b 00 04 03 00 01 02
:Extensions;HP-Certificate 实例分析 #
TLS record:
16
:Content type,(表示握手包);03 03
:Legacy version,TLS 1.2 (0x0303);0b 77
:Length,(2935);0b 00 0b 73 00 ...... 78 90 6e bf f7
:Protocol message(s),因为类型 0x16 是一个握手包,所以按照握手包协议进一步解析。
Handshake protocol:0b
:Message type,(Certificate);00 0b 73
:Handshake message data length,(2931);00 0b 70
:Certificates Length: 2928;00 04 07 30 82 ...... 78 90 6e bf f7
:Certificates;00 04 07
:Certificate Length: (1031);30 82 04 03 30 ...... 65 83 a4 09 68
:Certificate;00 03 89
:Certificate Length: (905);30 82 03 85 30 ...... 14 a1 a5 95 ab
:Certificate;00 03 d7
:Certificate Length: (983);30 82 03 d3 30 ...... 78 90 6e bf f7
:Certificate;HP-ServerKeyExchange 实例分析 #
TLS record:
16
:Content type,(表示握手包);03 03
:Legacy version,TLS 1.2 (0x0303);00 94
:Length,(148);0c 00 00 8f 03 ...... d4 97 74 87 44
:Protocol message(s),因为类型 0x16 是一个握手包,所以按照握手包协议进一步解析。
Handshake protocol:0c
:Message type,(ServerKeyExchange);00 00 90
:Handshake message data length,(144);03 00 17 41 04 ...... d4 97 74 87 44
:EC Diffie-Hellman Server Params;03
:Curve Type: named_curve (0x03);00 17
:Named Curve: secp256r1 (0x0017);41
:Pubkey Length: 65;04 cf 1f 1d 3c ...... a3 9d 7e c1 a4
:Pubkey;06 03
:Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603);00 47
:Signature Length: 71;30 45 02 21 00 ...... d4 97 74 87 44
:Signature;HP-ServerHelloDone 实例分析 #
TLS record:
16
:Content type,(表示握手包);03 03
:Legacy version,TLS 1.2 (0x0303);00 04
:Length,(4);0e 00 00 00
:Protocol message(s),因为类型 0x16 是一个握手包,所以按照握手包协议进一步解析。
Handshake protocol:0e
:Message type,(ServerHelloDone);00 00 00
:Handshake message data length,(0);HP-ClientKeyExchange 实例分析 #
TLS record:
16
:Content type,(表示握手包);03 03
:Legacy version,TLS 1.2 (0x0303);00 46
:Length,(70);10 00 00 42 41 ...... 40 ab 94 b1 ef
:Protocol message(s),因为类型 0x16 是一个握手包,所以按照握手包协议进一步解析。
Handshake protocol:10
:Message type,(ClientKeyExchange);00 00 42
:Handshake message data length,(66);41 04 8e 74 54 ...... 40 ab 94 b1 ef
:EC Diffie-Hellman Client Params;41
:Pubkey Length: (65);04 8e 74 54 c4 ...... 40 ab 94 b1 ef
:Pubkey;HP-EncryptedMsg-Client 实例分析 #
TLS record:
16
:Content type,(表示握手包);03 03
:Legacy version,TLS 1.2 (0x0303);00 28
:Length,(40);00 00 00 00 00 ...... 6e 4e 12 56 8e
:Protocol message(s),因为类型 0x16 是一个握手包,但这个是在客户端 CCS 之后的,所以是加密过得,得解密之后才能看到消息内容。
加密参见 HP-Finished-Client 加密HP-EncryptedMsg-Server 实例分析 #
TLS record:
16
:Content type,(表示握手包);03 03
:Legacy version,TLS 1.2 (0x0303);00 28
:Length,(40);84 ef 8c ec 32 ...... 80 58 e6 6d a4
:Protocol message(s),因为类型 0x16 是一个握手包,但这个是在服务端 CCS 之后的,所以是加密过得,得解密之后才能看到消息内容。
解密参见 HP-Finished-Server 解密
ChangeCipherSpec protocol #
参考: rfc5246: Change Cipher Spec Protocol, ChangeCipherSpec Protocol in SSL
ChangeCipherSpec 消息在 SSL 中用于指示通信从未加密变为加密,从现在开始将使用协商的密钥和密码套件进行当前通信。
该消息由服务器和客户端发送,以通知对方"让我们开始使用我们刚刚协商的内容"。该消息仅有一个字节。
密钥交换和证书验证完成后,客户端立即向服务器发送此更改密码规范消息。服务器在收到密钥交换消息后,也会发回更改密码规范消息。
扩展资料:
Why is change cipher spec an independent protocol content type and not part of Handshake Messages?
TLS中ChangeCipherSpec为什么是个单独的协议类型Attention
如果服务器支持恢复旧的 SSL 会话(通过服务器 hello 消息中的“会话 ID”指示),并且客户端希望恢复旧的会话,则客户端会在“hello 消息”之后立即发送此更改密码规范消息。
TLS record format for ChangeCipherSpec protocol Offset Byte+0 Byte+1 Byte+2 Byte+3 Byte
020 — Bytes
1–4Legacy version Length (Major) (Minor) 0 1 Byte
5CCS protocol type — CCS protocol type
: Currently only 1.CCS 实例分析 #
TLS record:
14
:Content Type: Change Cipher Spec (20);03 03
:Legacy version,TLS 1.2 (0x0303);00 01
:Length,(1);01
:Protocol message(s),因为类型 0x14 是一个状态改变包,所以按照ChangeCipherSpec
协议进一步解析。
ChangeCipherSpec protocol:01
:Change Cipher Spec Message;
Application protocol #
placeholder
TLS record format for application protocol Offset Byte+0 Byte+1 Byte+2 Byte+3 Byte
023 — Bytes
1–4Legacy version Length (Major) (Minor) (bits 15–8) (bits 7–0) Bytes
5–( m−1)Application data Bytes
m–( p−1)MAC (optional) Bytes
p–( q−1)Padding (block ciphers only) Length
: Length of application data (excluding the protocol header and including the MAC and padding trailers)MAC
: 32 bytes for the SHA-256-based HMAC, 20 bytes for the SHA-1-based HMAC, 16 bytes for the MD5-based HMAC.Padding
: Variable length; last byte contains the padding length.AP-EncryptedMsg-Client 实例分析 #
TLS record:
17
:Content Type: Application Data,应用层数据 (23);03 03
:Legacy version,TLS 1.2 (0x0303);00 fa
:Length,(250);00 00 00 00 00 ...... ab 32 d2 0d 12
:Protocol message(s),因为类型 0x17 是一个应用层数据包,但这个是在客户端 CCS 之后的,所以是加密过得,得解密之后才能看到消息内容。AP-EncryptedMsg-Server 实例分析 #
TLS record:
17
:Content Type: Application Data,应用层数据 (23);03 03
:Legacy version,TLS 1.2 (0x0303);0a 04
:Length,(2564);84 ef 8c ec 32 ...... 05 98 5c f7 39
:Protocol message(s),因为类型 0x17 是一个应用层数据包,但这个是在服务端 CCS 之后的,所以是加密过得,得解密之后才能看到消息内容。
解密参见 AP-Server 解密
Alert protocol #
这种记录应该不会被发送在正常握手和数据交换的时候。然而,这种消息是可以在握手的任何时间发送的,直到会话结束。如果用于发送致命信号,则当前会话会在发送完这个 record 后立即关闭,所以这个记录也会携带关闭的原因。如果警告级别被标记为警告,远程可以关闭这次会话,在它认为对于自身需要不太可靠的情况下。这一端发送之前,另外一方也可以发送它的相关信号。
TLS record format for alert protocol Offset Byte+0 Byte+1 Byte+2 Byte+3 Byte
021 — Bytes
1–4Legacy version Length (Major) (Minor) 0 2 Bytes
5–6Level Description — Bytes
7–( p−1)MAC (optional) Bytes
p–( q−1)Padding (block ciphers only) Level
: 该字段标识警报级别. 如果级别是致命的,发送方应该立即关闭会话. 否则,接收方可以决定自身终止会话,发送自己的致命警报并在发送后立即关闭会话。Alert记录的使用是可选的,但是如果在会话关闭之前缺少Alert记录,会话可能会自动恢复(通过握手)。
在传输的应用程序终止后,会话的正常关闭最好至少使用Close notify Alert类型(带有简单的警告级别)发出警报,以防止这种新会话的自动恢复。在有效关闭安全会话的传输层之前显式地发出正常关闭的信号,对于防止或检测攻击是有用的(例如,如果安全传输的数据本质上没有安全数据接收者可能期望的预定长度或持续时间,则试图截断安全传输的数据)。Alert level types Code Level type Connection state 1 warning connection or security may be unstable. 2 fatal connection or security may be compromised, or an unrecoverable error has occurred. Description
: 该字段标识正在发送的警报类型。 具体描述参考 wiki:Alert description typesAlert-EncryptedMsg-Server 实例分析 #
TLS record:
15
:Content Type: Alert (21);03 03
:Legacy version,TLS 1.2 (0x0303);00 1a
:Length,(26);84 ef 8c ec 32 ...... a3 c8 ca 1f 77
:Protocol message(s),因为类型 0x15 是一个 Alert 包,但这个是在服务端 CCS 之后的,所以是加密过得,得解密之后才能看到消息内容。
解密参见 Alert-Server 解密Alert-EncryptedMsg-Client 实例分析 #
TLS record:
15
:Content Type: Alert (21);03 03
:Legacy version,TLS 1.2 (0x0303);00 1a
:Length,(26);00 00 00 00 00 ...... bb aa 34 65 a9
:Protocol message(s),因为类型 0x15 是一个 Alert 包,但这个是在客户端 CCS 之后的,所以是加密过得,得解密之后才能看到消息内容。
TLS报文解密 #
需要注意这次的记录报文是将和服务器通讯过程中 必要参数 想办法获取到后,才可以实现的解密。另外也不需要懂太多加解密和 hash 算法相关的高深知识,大致了解即可。
用到的参数如下:1).
: 首先本次服务器选择的 Cipher Suite 为TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
。2).
: 服务器ServerKeyExchange
中 EC Diffie-Hellman Server Params 的公匙为04 cf 1f 1d 3c ...... a3 9d 7e c1 a4
,具体参见 HP-ServerKeyExchange 实例分析3).
: 客户端中用来生成公私匙对的关键参数:41421376590410550347532242163556460089898812947798573278257512740784871055544
。4).
: 客户端随机数:e3 e5 0a 0c c0 f1 f7 49 4c 14 89 45 9c 28 05 39 fa b4 e9 ce 08 77 f0 94 1f 44 4e 05 34 d6 4b c0
。5).
: 服务器随机数:52 f6 1e a4 6d 79 2e 2b 1b 94 70 d7 eb 21 5d 42 ed 4b a3 44 88 45 f2 b8 c1 4b 63 8f 28 5b e9 fe
。
本次解密通过两种方式,一种是 代码解析,另外一个是 wireshak.Tip
完整代码参见: github: DecryptDemo.java
IDEA 控制台输出及 wireshark 抓包数据参见: md: tls-record-console-output。前置需求(material) #
包括 Cipher 构造,以及相关工具方法
代码解密 #
HP-Finished-Server 解密 #
这个对应的报文是首次使用协商好的算法进行加密过的,其实对应 HP-EncryptedMsg-Server 实例分析 中的加密报文,解密后就是服务端握手协议中的 Finished 报文。解密如下:
HP-Finished-Client 加密 #
就是我们需要对刚才协商好的算法通过发送一个 finished 报文让服务端进行验证,对应的数据是实例分析中的 HP-EncryptedMsg-Client 实例分析,对原文的加密过程如下:
Alert-Server 解密 #
这个对应 AP-EncryptedMsg-Server 实例分析 中的加密数据。
AP-Server 解密 #
这个对应 AP-EncryptedMsg-Server 实例分析 中的加密数据,也即服务器对 http response 的响应数据。
工具解密(wireshark) #
Note
wireshark 可以通过 预主密匙(Pre Master Secret) 或 主密匙(Master Secret) 来对报文进行解密,这两个密匙没太大区别,因为主密匙就是在知道 hash 算法和两端随机数后,通过预主密匙来生成的 。有一种叫 SSLKEYLOGFILE 的文件,一般web客户端都会遵循某种规则,如果存在环境变量 SSLKEYLOGFILE ,就会将会话过程的主密匙写入到这个文件中。比如 curl, 谷歌, 火狐, openssl-s_client, nodejs 等。
所以可以根据 SSLKEYLOGFILE 的格式,模拟一个类似的文件。因为本次使用的是 Java BC TLS 库,这次会话,即使存在环境变量,也没有写入任何数据。Warning
对于 chrome 有些版本可能环境变量不起作用,需要指定启动参数的时候,可以参考 chrome-not-firefox-are-not-dumping-to-sslkeylogfile-variable, run-chromium-with-flags 等。
chrome://quit
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --ssl-key-log-file=/Users/stevenobelia/Desktop/tls_secrets
。(版本 131.0.6778.205)验证没问题。
对于 curl 是否写入密匙到指定文件,也分情况。有可能和 curl 的启用特性有关系,也有可能是 TLS 版本的问题。
如下图所示的两个 curl 版本,都可以对 wtfu.site (TLSv1.2) 进行密匙写入,但是只有 brew 安装的才可以写入 music.163.com (TLSv1.3) 的密匙。解密展示 #
Reference #
- https://www.rfc-editor.org/rfc/rfc5246.html
- https://en.wikipedia.org/wiki/Transport_Layer_Security
- https://www.cloudflare.com/zh-cn/learning/ssl/what-happens-in-a-tls-handshake/
- https://httpd.apache.org/docs/2.4/ssl/ssl_intro.html
- https://fjhirsch.com/SSL/tlstut_html/index.htm
- TLS/SSL 测试报告
- https://www.ssllabs.com/ssltest/analyze.html?d=tech.wtfu.site&latest
- https://myssl.com/tech.wtfu.site?domain=tech.wtfu.site&status=q
- https://www.cdn77.com/tls-test
- https://domsignal.com/tls-test
- TLS-HP-finished decrypt
- https://osqa-ask.wireshark.org/questions/57384/tls-finished-packet-renamed-encrypted-handshake-message/
- https://crypto.stackexchange.com/questions/34754/what-does-the-tls-1-2-client-finished-message-contain
- SSLKEYLOGFIEL
- https://curl.se/libcurl/c/libcurl-env.html#:~:text=SSLKEYLOGFILE
- https://wiki.wireshark.org/TLS#using-the-pre-master-secret
- SSLKEYLOGFIEL format
- https://www.ietf.org/archive/id/draft-thomson-tls-keylogfile-00.html