仕事で TLS 接続がなぜか強制RSTされる調査をするときに、TLS negotiation に関する知識不足で死にました。結局 Java の bug だったということで解決はしたのですが、後学のためにパケットを読めるようにしておきます。

test case

Mac Chrome Version 103.0.5060.53 から https://example.com へのアクセスを wireshark でキャプチャしました。ひとつずつパケットを見ていきます。HTTPSとは言っても最初は暗号化されていなかったりします。そういったところも勉強していきます。（と思いましたが、ClientHelloだけで終わりました）

all packets

今回の全パケットはこちらです。わかりやすいように src/dest IP address は名前にしてあります。

#	time	src	dest	protocol	length	TCP flags	seq	ack	info
130	2.487113	localhost	example.com	TCP	78	····CE····S·	0	0	58364 → 443 [SYN, ECN, CWR] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=107391323 TSecr=0 SACK_PERM=1
133	2.641277	example.com	localhost	TCP	74	·····E·A··S·	0	1	443 → 58364 [SYN, ACK, ECN] Seq=0 Ack=1 Win=65535 Len=0 MSS=1382 SACK_PERM=1 TSval=2936265566 TSecr=107391323 WS=512
134	2.641642	localhost	example.com	TCP	66	·······A····	1	1	58364 → 443 [ACK] Seq=1 Ack=1 Win=131520 Len=0 TSval=107391476 TSecr=2936265566
135	2.642373	localhost	example.com	TLSv1.3	583	·······AP···	1	1	Client Hello
139	2.805043	example.com	localhost	TCP	66	·······A····	1	518	443 → 58364 [ACK] Seq=1 Ack=518 Win=67072 Len=0 TSval=2936265726 TSecr=107391476
140	2.805047	example.com	localhost	TLSv1.3	165	·······AP···	1	518	Hello Retry Request, Change Cipher Spec
141	2.805283	localhost	example.com	TCP	66	·······A····	518	100	58364 → 443 [ACK] Seq=518 Ack=100 Win=131392 Len=0 TSval=107391638 TSecr=2936265727
142	2.80656	localhost	example.com	TLSv1.3	409	·······AP···	518	100	Change Cipher Spec, Client Hello
145	2.967469	example.com	localhost	TCP	66	·······A····	100	861	443 → 58364 [ACK] Seq=100 Ack=861 Win=68096 Len=0 TSval=2936265895 TSecr=107391639
146	2.96767	example.com	localhost	TLSv1.3	1436	·······A····	100	861	Server Hello, Application Data
147	2.972801	example.com	localhost	TCP	1436	·······AP···	1470	861	443 → 58364 [PSH, ACK] Seq=1470 Ack=861 Win=68096 Len=1370 TSval=2936265897 TSecr=107391639 [TCP segment of a reassembled PDU]
148	2.972935	example.com	localhost	TLSv1.3	1436	·······A····	2840	861	Application Data, Application Data
149	2.97294	example.com	localhost	TLSv1.3	117	·······AP···	4210	861	Application Data
150	2.973082	localhost	example.com	TCP	66	·······A····	861	2840	58364 → 443 [ACK] Seq=861 Ack=2840 Win=128768 Len=0 TSval=107391804 TSecr=2936265897
151	2.973117	localhost	example.com	TCP	66	·······A····	861	4261	58364 → 443 [ACK] Seq=861 Ack=4261 Win=127296 Len=0 TSval=107391804 TSecr=2936265897
152	2.997266	localhost	example.com	TCP	66	·······A····	861	4261	[TCP Window Update] 58364 → 443 [ACK] Seq=861 Ack=4261 Win=131072 Len=0 TSval=107391828 TSecr=2936265897
153	2.998117	localhost	example.com	TLSv1.3	140	·······AP···	861	4261	Application Data
154	2.998521	localhost	example.com	TLSv1.3	158	·······AP···	935	4261	Application Data
155	2.998889	localhost	example.com	TLSv1.3	534	·······AP···	1027	4261	Application Data
173	3.151537	example.com	localhost	TCP	66	·······A····	4261	935	443 → 58364 [ACK] Seq=4261 Ack=935 Win=68096 Len=0 TSval=2936266078 TSecr=107391828
174	3.15154	example.com	localhost	TLSv1.3	321	·······AP···	4261	935	Application Data
175	3.151542	example.com	localhost	TLSv1.3	321	·······AP···	4516	935	Application Data
176	3.151543	example.com	localhost	TLSv1.3	162	·······AP···	4771	935	Application Data, Application Data
177	3.151817	localhost	example.com	TCP	66	·······A····	1495	4516	58364 → 443 [ACK] Seq=1495 Ack=4516 Win=130816 Len=0 TSval=107391979 TSecr=2936266078
178	3.151817	localhost	example.com	TCP	66	·······A····	1495	4771	58364 → 443 [ACK] Seq=1495 Ack=4771 Win=130560 Len=0 TSval=107391979 TSecr=2936266078
179	3.151817	localhost	example.com	TCP	66	·······A····	1495	4867	58364 → 443 [ACK] Seq=1495 Ack=4867 Win=130432 Len=0 TSval=107391979 TSecr=2936266078
180	3.152917	localhost	example.com	TLSv1.3	97	·······AP···	1495	4867	Application Data
181	3.158304	example.com	localhost	TLSv1.3	97	·······AP···	4867	1027	Application Data
182	3.158506	localhost	example.com	TCP	66	·······A····	1526	4898	58364 → 443 [ACK] Seq=1526 Ack=4898 Win=131008 Len=0 TSval=107391985 TSecr=2936266080
183	3.171335	example.com	localhost	TLSv1.3	981	·······AP···	4898	1495	Application Data, Application Data, Application Data
184	3.171566	localhost	example.com	TCP	66	·······A····	1526	5813	58364 → 443 [ACK] Seq=1526 Ack=5813 Win=130112 Len=0 TSval=107391998 TSecr=2936266087
185	3.326376	example.com	localhost	TCP	66	·······A····	5813	1526	443 → 58364 [ACK] Seq=5813 Ack=1526 Win=69120 Len=0 TSval=2936266254 TSecr=107391980
1098	48.839818	localhost	example.com	TCP	54	·······A····	1525	5813	[TCP Keep-Alive] 58364 → 443 [ACK] Seq=1525 Ack=5813 Win=131072 Len=0
1108	48.992493	example.com	localhost	TCP	66	·······A····	5813	1526	[TCP Keep-Alive ACK] 443 → 58364 [ACK] Seq=5813 Ack=1526 Win=69120 Len=0 TSval=2936311918 TSecr=107391998
1369	64.549821	example.com	localhost	TCP	66	·······A····	5812	1526	[TCP Keep-Alive] 443 → 58364 [ACK] Seq=5812 Ack=1526 Win=69120 Len=0 TSval=2936327237 TSecr=107391998
1370	64.55017	localhost	example.com	TCP	66	·······A····	1526	5813	[TCP Keep-Alive ACK] 58364 → 443 [ACK] Seq=1526 Ack=5813 Win=131072 Len=0 TSval=107452954 TSecr=2936311918
2417	109.887607	localhost	example.com	TCP	54	·······A····	1525	5813	[TCP Keep-Alive] 58364 → 443 [ACK] Seq=1525 Ack=5813 Win=131072 Len=0
2418	110.041827	example.com	localhost	TCP	66	·······A····	5813	1526	[TCP Keep-Alive ACK] 443 → 58364 [ACK] Seq=5813 Ack=1526 Win=69120 Len=0 TSval=2936372958 TSecr=107452954
2790	125.889367	example.com	localhost	TCP	66	·······A····	5812	1526	[TCP Keep-Alive] 443 → 58364 [ACK] Seq=5812 Ack=1526 Win=69120 Len=0 TSval=2936388677 TSecr=107452954
2791	125.889583	localhost	example.com	TCP	66	·······A····	1526	5813	[TCP Keep-Alive ACK] 58364 → 443 [ACK] Seq=1526 Ack=5813 Win=131072 Len=0 TSval=107513834 TSecr=2936372958
4317	171.346262	localhost	example.com	TCP	54	·······A····	1525	5813	[TCP Keep-Alive] 58364 → 443 [ACK] Seq=1525 Ack=5813 Win=131072 Len=0
4318	171.522983	example.com	localhost	TCP	66	·······A····	5813	1526	[TCP Keep-Alive ACK] 443 → 58364 [ACK] Seq=5813 Ack=1526 Win=69120 Len=0 TSval=2936434446 TSecr=107513834
4366	183.843569	example.com	localhost	TLSv1.3	123	·······AP···	5813	1526	Application Data
4367	183.843575	example.com	localhost	TLSv1.3	90	·······AP···	5870	1526	Application Data
4368	183.843577	example.com	localhost	TCP	66	·······A···F	5894	1526	443 → 58364 [FIN, ACK] Seq=5894 Ack=1526 Win=69120 Len=0 TSval=2936446685 TSecr=107513834
4369	183.844156	localhost	example.com	TCP	66	·······A····	1526	5870	58364 → 443 [ACK] Seq=1526 Ack=5870 Win=131008 Len=0 TSval=107571319 TSecr=2936446685
4370	183.844157	localhost	example.com	TCP	66	·······A····	1526	5894	58364 → 443 [ACK] Seq=1526 Ack=5894 Win=130944 Len=0 TSval=107571319 TSecr=2936446685
4371	183.8442	localhost	example.com	TCP	66	·······A····	1526	5895	58364 → 443 [ACK] Seq=1526 Ack=5895 Win=130944 Len=0 TSval=107571319 TSecr=2936446685
4372	183.846191	localhost	example.com	TCP	54	·······A·R··	1526	5895	58364 → 443 [RST, ACK] Seq=1526 Ack=5895 Win=131008 Len=0

各 TLSパケットの後にTCPでackが返ってきてますね。

解読開始

TCP 3-way handshake

冒頭は TCP 通信が３つ入ります。かの有名な 3-way handshakeで syn, syn+ack, ack で TCP接続を確立します。ここは TLS layerではないので本記事ではスキップします。当たり前ですが、localhostから通信が始まっています。

#	src	dest	type	length	info
130	localhost	example.com	TCP	78	58364 → 443 [SYN, ECN, CWR] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=107391323 TSecr=0 SACK_PERM=1
133	example.com	localhost	TCP	74	443 → 58364 [SYN, ACK, ECN] Seq=0 Ack=1 Win=65535 Len=0 MSS=1382 SACK_PERM=1 TSval=2936265566 TSecr=107391323 WS=512
134	localhost	example.com	TCP	66	58364 → 443 [ACK] Seq=1 Ack=1 Win=131520 Len=0 TSval=107391476 TSecr=2936265566

ClientHello

さあ、TLS通信の始まりです。まずはお互いに「どうやって暗号化するか」をネゴシエーションしていきます。ここはまだ平文通信というところがポイントです。最初に client が送るのが ClientHello です。

#	src	dest	type	length	info
4	localhost	example.com	TLSv1.3	583	Client Hello

ClientHello 中身全部

Frame 135: 583 bytes on wire (4664 bits), 583 bytes captured (4664 bits) on interface en0, id 0
Ethernet II, Src: Apple_3f:65:ae (38:f9:d3:3f:65:ae), Dst: da:46:f8:db:b2:0a (da:46:f8:db:b2:0a)
Internet Protocol Version 4, Src: 192.168.61.86, Dst: 93.184.216.34
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
    Total Length: 569
    Identification: 0x0000 (0)
    Flags: 0x40, Don't fragment
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 64
    Protocol: TCP (6)
    Header Checksum: 0x04e4 [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 192.168.61.86
    Destination Address: 93.184.216.34
Transmission Control Protocol, Src Port: 58364, Dst Port: 443, Seq: 1, Ack: 1, Len: 517
    Source Port: 58364
    Destination Port: 443
    [Stream index: 6]
    [Conversation completeness: Complete, WITH_DATA (63)]
    [TCP Segment Len: 517]
    Sequence Number: 1    (relative sequence number)
    Sequence Number (raw): 4163027035
    [Next Sequence Number: 518    (relative sequence number)]
    Acknowledgment Number: 1    (relative ack number)
    Acknowledgment number (raw): 2279611937
    1000 .... = Header Length: 32 bytes (8)
    Flags: 0x018 (PSH, ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgment: Set
        .... .... 1... = Push: Set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
        [TCP Flags: ·······AP···]
    Window: 2055
    [Calculated window size: 131520]
    [Window size scaling factor: 64]
    Checksum: 0x97d4 [unverified]
    [Checksum Status: Unverified]
    Urgent Pointer: 0
    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
        TCP Option - No-Operation (NOP)
            Kind: No-Operation (1)
        TCP Option - No-Operation (NOP)
            Kind: No-Operation (1)
        TCP Option - Timestamps: TSval 107391476, TSecr 2936265566
            Kind: Time Stamp Option (8)
            Length: 10
            Timestamp value: 107391476
            Timestamp echo reply: 2936265566
    [Timestamps]
        [Time since first frame in this TCP stream: 0.155260000 seconds]
        [Time since previous frame in this TCP stream: 0.000731000 seconds]
    [SEQ/ACK analysis]
        [iRTT: 0.154529000 seconds]
        [Bytes in flight: 517]
        [Bytes sent since last PSH flag: 517]
    TCP payload (517 bytes)
Transport Layer Security
    TLSv1.3 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 512
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 508
            Version: TLS 1.2 (0x0303)
            Random: a990959f0793ba1ff5a09d1a5eec06e87706c88ea969457fa59d9ba9dc0f0e32
            Session ID Length: 32
            Session ID: b1c8e600556b5561ceda33e4c9c0b59221e45d11fb5cc03de4c165861b34f642
            Cipher Suites Length: 32
            Cipher Suites (16 suites)
                Cipher Suite: Reserved (GREASE) (0x6a6a)
                Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
                Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
                Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
                Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
                Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
            Compression Methods Length: 1
            Compression Methods (1 method)
            Extensions Length: 403
            Extension: Reserved (GREASE) (len=0)
                Type: Reserved (GREASE) (64250)
                Length: 0
                Data: <MISSING>
            Extension: server_name (len=16)
                Type: server_name (0)
                Length: 16
                Server Name Indication extension
                    Server Name list length: 14
                    Server Name Type: host_name (0)
                    Server Name length: 11
                    Server Name: example.com
            Extension: extended_master_secret (len=0)
                Type: extended_master_secret (23)
                Length: 0
            Extension: renegotiation_info (len=1)
                Type: renegotiation_info (65281)
                Length: 1
                Renegotiation Info extension
                    Renegotiation info extension length: 0
            Extension: supported_groups (len=10)
                Type: supported_groups (10)
                Length: 10
                Supported Groups List Length: 8
                Supported Groups (4 groups)
                    Supported Group: Reserved (GREASE) (0xcaca)
                    Supported Group: x25519 (0x001d)
                    Supported Group: secp256r1 (0x0017)
                    Supported Group: secp384r1 (0x0018)
            Extension: ec_point_formats (len=2)
                Type: ec_point_formats (11)
                Length: 2
                EC point formats Length: 1
                Elliptic curves point formats (1)
                    EC point format: uncompressed (0)
            Extension: session_ticket (len=0)
                Type: session_ticket (35)
                Length: 0
                Data (0 bytes)
            Extension: application_layer_protocol_negotiation (len=14)
                Type: application_layer_protocol_negotiation (16)
                Length: 14
                ALPN Extension Length: 12
                ALPN Protocol
                    ALPN string length: 2
                    ALPN Next Protocol: h2
                    ALPN string length: 8
                    ALPN Next Protocol: http/1.1
            Extension: status_request (len=5)
                Type: status_request (5)
                Length: 5
                Certificate Status Type: OCSP (1)
                Responder ID list Length: 0
                Request Extensions Length: 0
            Extension: signature_algorithms (len=18)
                Type: signature_algorithms (13)
                Length: 18
                Signature Hash Algorithms Length: 16
                Signature Hash Algorithms (8 algorithms)
            Extension: signed_certificate_timestamp (len=0)
                Type: signed_certificate_timestamp (18)
                Length: 0
            Extension: key_share (len=43)
                Type: key_share (51)
                Length: 43
                Key Share extension
                    Client Key Share Length: 41
                    Key Share Entry: Group: Reserved (GREASE), Key Exchange length: 1
                        Group: Reserved (GREASE) (51914)
                        Key Exchange Length: 1
                        Key Exchange: 00
                    Key Share Entry: Group: x25519, Key Exchange length: 32
                        Group: x25519 (29)
                        Key Exchange Length: 32
                        Key Exchange: ab83faa28c812c3237c264b8d213968dadf7450bcc0c69d9f37fe6775f1fe015
            Extension: psk_key_exchange_modes (len=2)
                Type: psk_key_exchange_modes (45)
                Length: 2
                PSK Key Exchange Modes Length: 1
                PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1)
            Extension: supported_versions (len=7)
                Type: supported_versions (43)
                Length: 7
                Supported Versions length: 6
                Supported Version: Reserved (GREASE) (0x2a2a)
                Supported Version: TLS 1.3 (0x0304)
                Supported Version: TLS 1.2 (0x0303)
            Extension: compress_certificate (len=3)
                Type: compress_certificate (27)
                Length: 3
                Algorithms Length: 2
                Algorithm: brotli (2)
            Extension: application_settings (len=5)
                Type: application_settings (17513)
                Length: 5
                ALPS Extension Length: 3
                Supported ALPN List
                    Supported ALPN Length: 2
                    Supported ALPN: h2
            Extension: Reserved (GREASE) (len=1)
                Type: Reserved (GREASE) (39578)
                Length: 1
                Data: 00
            Extension: padding (len=204)
                Type: padding (21)
                Length: 204
                Padding Data: 000000000000000000000000000000000000000000000000000000000000000000000000…
            [JA3 Fullstring: 771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513-21,29-23-24,0]
            [JA3: cd08e31494f9531f560d64c695473da9]

TLS Record Layer

まず見ていくのは TLS Record Layerです。
これはたぶん　rfc5246　で定まったあたりの内容です。TLSの中でなんの処理をするのか、などの指定がされていると思われます。

https://www.ietf.org/rfc/rfc5246.txt

version negotiation

TLS1.3の特徴として、下位互換のためにversionが読み取りづらいという点があります。下の画像には３つのversionがあることがわかるでしょうか。

もっとも特徴的なのは Handshake Protocol の version が TLS1.2 なところです。さらに下に行くと、 Extention: supported_versions の中で、 TLS 1.2 とともに 1.3 を候補に上げています。これでこの client(Chrome)が TLS 1.3 に対応していることをserverに要望しています。

なお、私が持つ TLS 1.3 の全知識をここで披露し終わったことと、そもそもまともにpacket見るのがこれが初めてということをここに宣言させていただきます。

さて、Handshake protocol の中には server_name という項目があり、私がリクエストした example.com が記載されています。server側はこれを見て、SNIなどのチェックを経て ServerHelloに繋げていきます。

重要なのは ここは平文 ということです。HTTPSでも、同一ネットワークにいる Mallory(悪役) にはどのドメインに通信しようとしたかがモロバレってことです。

さぁ、パケットを見ていきます。Hex dumpはこちら。最終的にはこの中が壊れていても読めるようになりたい。

0000   da 46 f8 db b2 0a 38 f9 d3 3f 65 ae 08 00 45 02
0010   02 39 00 00 40 00 40 06 04 e4 c0 a8 3d 56 5d b8
0020   d8 22 e3 fc 01 bb f8 22 c0 5b 87 e0 1e 21 80 18
0030   08 07 97 d4 00 00 01 01 08 0a 06 66 a9 f4 af 03
0040   db 5e 16 03 01 02 00 01 00 01 fc 03 03 a9 90 95
0050   9f 07 93 ba 1f f5 a0 9d 1a 5e ec 06 e8 77 06 c8
0060   8e a9 69 45 7f a5 9d 9b a9 dc 0f 0e 32 20 b1 c8
0070   e6 00 55 6b 55 61 ce da 33 e4 c9 c0 b5 92 21 e4
0080   5d 11 fb 5c c0 3d e4 c1 65 86 1b 34 f6 42 00 20
0090   6a 6a 13 01 13 02 13 03 c0 2b c0 2f c0 2c c0 30
00a0   cc a9 cc a8 c0 13 c0 14 00 9c 00 9d 00 2f 00 35
00b0   01 00 01 93 fa fa 00 00 00 00 00 10 00 0e 00 00
00c0   0b 65 78 61 6d 70 6c 65 2e 63 6f 6d 00 17 00 00
00d0   ff 01 00 01 00 00 0a 00 0a 00 08 ca ca 00 1d 00
00e0   17 00 18 00 0b 00 02 01 00 00 23 00 00 00 10 00
00f0   0e 00 0c 02 68 32 08 68 74 74 70 2f 31 2e 31 00
0100   05 00 05 01 00 00 00 00 00 0d 00 12 00 10 04 03
0110   08 04 04 01 05 03 08 05 05 01 08 06 06 01 00 12
0120   00 00 00 33 00 2b 00 29 ca ca 00 01 00 00 1d 00
0130   20 ab 83 fa a2 8c 81 2c 32 37 c2 64 b8 d2 13 96
0140   8d ad f7 45 0b cc 0c 69 d9 f3 7f e6 77 5f 1f e0
0150   15 00 2d 00 02 01 01 00 2b 00 07 06 2a 2a 03 04
0160   03 03 00 1b 00 03 02 00 02 44 69 00 05 00 03 02
0170   68 32 9a 9a 00 01 00 00 15 00 cc 00 00 00 00 00
0180   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0190   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01a0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01b0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01c0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01d0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01e0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01f0   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0200   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0210   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0220   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0230   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0240   00 00 00 00 00 00 00

まず、wiresharkはデフォで hex 表示しますが、今回はこれを bitにして見ていきたいと思います。どこで切れてるか意識したいためです。右クリックで as bits を選びます。

bitになりました。先頭の 3bytes を選んだら、 Ethernet layerのaddress周りが選択されました。こうして互いの関連がわかります。めっちゃ便利。まあ、今回問題になったのはパケット壊れてるからこの関係性がわからず、ここはなんのフィールド？？でかなり詰みました。そのためにこの勉强をしています。

で、ここで wiresharkの初歩に気づきました。上のセクションと下のbitセクションは連携してて、bitセクションもethernet frameからtlsまで全部ひとつづきに書かれてます。まず TLS layerを選んでから、下のbitsを見るようにします。

Centent Type

青く光った最初の 1 bypte を選ぶと、 Content Type: Handshake (22) が光りました。

Content Typeは20, 21, 22, 23 があります。

   enum {
       change_cipher_spec(20), alert(21), handshake(22),
       application_data(23), (255)
   } ContentType;

https://www.ietf.org/rfc/rfc5246.txt

ここでは handshakeが送られてますね。ちなみにハマったパケットは 21 alert(ただし中身はこわれてる) でした。

Version

その次の 2bytes は version. これは TLS1.0の頃の表記なんだろうか。major version で1バイト、マイナーで1 byteです。TLS1.2/1.3ではここは使われないと思います。

   struct {
       uint8 major;
       uint8 minor;
   } ProtocolVersion;

Length

次の 2bytesは length. 今回は 512 （単位は bytes) です。packet全体は 583 bytes なので、そことは一致しません。これは 583 の方には Ethernet frame, tcp header などの領域が含まれているからです。

そして確認すると、Content Type 22 で送る Handshake protocol で送信するデータ内容が 512 bytes ということでした。TLS record全体のlengthではないんですね。パケットの構造は、こうして「後続する領域がどれくらいあるか」を示すためにlengthが使われます。

Handshake Protocol: Client Hello

さあ、ここから深淵に足を踏み入れます。長い Handshake protocolの始まりです。

Handshake Type

次の 1byte はどんな handshake か、です。

Handshake Typeは様々なものがあります。こちらは TLS 1.2 の例です。

   struct {
       HandshakeType msg_type;
       uint24 length;
       select (HandshakeType) {
           case hello_request:       HelloRequest;
           case client_hello:        ClientHello;
           case server_hello:        ServerHello;
           case certificate:         Certificate;
           case server_key_exchange: ServerKeyExchange;
           case certificate_request: CertificateRequest;
           case server_hello_done:   ServerHelloDone;
           case certificate_verify:  CertificateVerify;
           case client_key_exchange: ClientKeyExchange;
           case finished:            Finished;
       } body;
   } Handshake;

https://www.ietf.org/rfc/rfc5246.txt

対して、 TLS 1.3 にはさらにかなりの追加がされています。TLS 1.3 がいかに複雑になったかが、ここからもよくわかると思います。パット見で明らかに追加されたものに矢印を付けました。

B.3.  Handshake Protocol

      enum {
          hello_request_RESERVED(0),         <------- (+)
          client_hello(1),
          server_hello(2),
          hello_verify_request_RESERVED(3),         <------- (+)
          new_session_ticket(4),         <------- (+)
          end_of_early_data(5),         <------- (+)
          hello_retry_request_RESERVED(6),         <------- (+)
          encrypted_extensions(8),         <------- (+)
          certificate(11),     
          server_key_exchange_RESERVED(12),  
          certificate_request(13),
          server_hello_done_RESERVED(14),    
          certificate_verify(15),
          client_key_exchange_RESERVED(16),  
          finished(20),
          certificate_url_RESERVED(21),         <------- (+)
          certificate_status_RESERVED(22),         <------- (+)
          supplemental_data_RESERVED(23),         <------- (+)
          key_update(24),         <------- (+)
          message_hash(254),         <------- (+)
          (255)
      } HandshakeType;

https://datatracker.ietf.org/doc/rfc8446/

TLS 1.2 の Handshake typeと見比べると、結構な違いがありますね。

これこそが handshake の全貌です。恐ろしい。

Length

その次の 3 bytes は length = 508 bytes. なんのlengthかはよくわからないけどこの handshake protocol のこれから始まるdata周りの合計でしょう。

Version

次の 2bytes は version. TLS 1.2 は 0x0303 = 771 です。TLS 1.3でもここは 1.2 になります。

Random

次の 32 bytes は random. これはとても大事なんですが説明は割愛。詳しくは Professional SSL/TLS を御覧ください。末尾4 bytes はclientの時刻情報が入るはずなんですが、browser finger printとして使われる恐れがあることから今は形骸化してただのランダムらしいです。なので、値を調べるのはやめときます。

TLS 1.2 の説明ですが、randomは鍵交換で重要な役割を果たします。この乱数に脆弱性があると通信が読み取られることになります。

ServerHello～ClientKeyExchangeの通信過程で、クライアントとサーバの両方にClientHello初期乱数、ServerHello初期乱数、pre_master_secretの３つの乱数が手に入ったことになります。ここからmaster_secret（48バイト）を算出し、そこからさらにkey_blockを計算します。key_blockは理論上無限長の疑似乱数列で、必要な長さだけ計算し、そこからアプリケーションデータの暗号通信に使う共有鍵を取り出します。
https://qiita.com/n-i-e/items/41673fd16d7bd1189a29

Session ID Length

1byteで、32が入っている

Session ID

32bytesありました。TLS 1.2の説明ですが

SessionIDは、これがクライアント値とサーバ値で一致すれば、双方にキャッシュされた計算済みパラメータを利用して、ハンドシェイク手順をすっとばしてChangeCipherSpecまで進めるというものです。
https://qiita.com/n-i-e/items/41673fd16d7bd1189a29

Cipher Suites Length

2 bytes

Cipher suites

Cipher suitesはclientが使いたい暗号化の種類です。先のlength通り 32bytesあり、ひとつの suiteにつき 2bytes使われていました。つまり 32 /2 = 16 の cipher suitesをブラウザは候補としてサーバにお伺いしています。

ここで clientが提案したのは１６個。後述する Hello Retry Request では TLS_AES_256_GCM_SHA384 が選ばれ、採用されていました。

Cipher Suites (16 suites)
    Cipher Suite: Reserved (GREASE) (0x6a6a)
    Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
    Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)              <---------
    Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
    Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
    Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
    Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

clientによって対応しているcipher suitesが違うので、ここは可変領域（lengthがついている）んですね。パケットパーサーが、どこまでを可変領域か判断できるようにするために、lengthは必ずdata領域の先頭に配置されます。「Cipher suites lengthが来るはずだ」「32bytesが入ってるぞ」「じゃあ、この後の32bytesは cipher suitesだ」「その次からは、次のComporession Methods lengthが来るはずだ」と感じでパケットが読まれていくわけです。

Compression Method Length

1 byte
そのとおり、次のfieldがcipher suitesの32bytesの直後に来ました。

Compression Method

Compression Method は 1 BYTE で NULL(00000000) です。

これはTLSの圧縮には攻撃がされた過去があり(CRIME脆弱性)、現在では使われないオプションとなっています。似た文字列を圧縮しつづけることで内容を推測できることが理由です。

むちゃくちゃな例

知らない文字列 x (1 byte) があるとする。末尾に3 bytes足して xabc を送ると、4 bytes になるはず。しかし圧縮されて結果が 3 bytes になったら、abcのどれかが x に一致していると推測できる。そんなんで x がわかっちゃったりする。

現在のTLSでは圧縮できないので、データを圧縮したかったら application dataの中でする（そもそも zip ファイルを送るとか）んだと思う。

Extention Length

2bytes. ここから地獄の Extentionが始まります。403 bytesあるそうです。

Extention Padding

Extentionの詳細は飛ばして、最後のpaddingを見ます。全体では 208 bytes ありますが、len=204とあります。これはさらに細かく見れるからです

Extention Padding: Type = 2 bytes

まず 2bytes で extentionの種類が paddingだと宣言されてます。

Extention Typeは想像の通り目がくらむほどあります。paddingは RFC 7685 に書いてあるという優しさが見えます。

enum {
        server_name(0),                             /* RFC 6066 */
        max_fragment_length(1),                     /* RFC 6066 */
        status_request(5),                          /* RFC 6066 */
        supported_groups(10),                       /* RFC 8422, 7919 */
        signature_algorithms(13),                   /* RFC 8446 */
        use_srtp(14),                               /* RFC 5764 */
        heartbeat(15),                              /* RFC 6520 */
        application_layer_protocol_negotiation(16), /* RFC 7301 */
        signed_certificate_timestamp(18),           /* RFC 6962 */
        client_certificate_type(19),                /* RFC 7250 */
        server_certificate_type(20),                /* RFC 7250 */
        padding(21),                                /* RFC 7685 */
        RESERVED(40),                               /* Used but never
                                                       assigned */
        pre_shared_key(41),                         /* RFC 8446 */
        early_data(42),                             /* RFC 8446 */
        supported_versions(43),                     /* RFC 8446 */
        cookie(44),                                 /* RFC 8446 */
        psk_key_exchange_modes(45),                 /* RFC 8446 */
        RESERVED(46),                               /* Used but never
                                                       assigned */
        certificate_authorities(47),                /* RFC 8446 */
        oid_filters(48),                            /* RFC 8446 */
        post_handshake_auth(49),                    /* RFC 8446 */
        signature_algorithms_cert(50),              /* RFC 8446 */
        key_share(51),                              /* RFC 8446 */
        (65535)
    } ExtensionType;

Extention Padding: Length = 2 bytes

後続する Padding data の中身が 204 bytes と 2bytes で書かれてます。

Extention Padding: Padding Data = 最大 n bytes

paddingなので全部0です。これはblockの長さを固定化するために使われます。たぶん。

謎の JA3 文字列

extention, TLS record の末尾にある JA3 という２行は謎でした。選択してもbitsが反転しないので、Wiresharkがつけた付加情報なんでしょうか。

Extention: key_share

key_shareは鍵交換のキモらしいです。

TLS1.3では、鍵交換の方法はPSK/DHE/ECDHE/PSKのいずれかとなっており、どれを使うかをClient Helloの key_share パラメーターで選んでいます。
その際DH/ECDHEを使うなら key_share に共有値を詰めて送信します。(共有鍵は互いのkey_shareが完了後に内部で計算して生成。
https://qiita.com/developer-kikikaikai/items/055a344c847379b471f7

ClientHello(1回目) by the client

Extension: key_share (len=43)
    Type: key_share (51)
    Length: 43
    Key Share extension
        Client Key Share Length: 41
        Key Share Entry: Group: Reserved (GREASE), Key Exchange length: 1
            Group: Reserved (GREASE) (51914)
            Key Exchange Length: 1
            Key Exchange: 00
        Key Share Entry: Group: x25519, Key Exchange length: 32
            Group: x25519 (29)
            Key Exchange Length: 32
            Key Exchange: ab83faa28c812c3237c264b8d213968dadf7450bcc0c69d9f37fe6775f1fe015

恐らく下４行がclientの重要な部分ではと推測します。 Group: x25519 は ECDH用のカーブでした。
Key Exchange の乱数 32 bytes が(EC)DHEでmaster_secretを計算するためのclient側共有値。ちなみに、この後 Client Hello Requestで返ってくるのは共有値なしで、 Selected Group だけ。

Hello Retry Request by the server

            Extension: key_share (len=2)
                Type: key_share (51)
                Length: 2
                Key Share extension
                    Selected Group: secp256r1 (23)

server側から secp256r1 を使え、と言われているように思います。更にその後、clientはサーバのretry requestを受けてclient helloをもう一度送ります。そのときの key_shareは以下のように、 secp256r1 が指定されていました。

ClientHello(2回目) by the client

Extension: key_share (len=71)
    Type: key_share (51)
    Length: 71
    Key Share extension
        Client Key Share Length: 69
        Key Share Entry: Group: secp256r1, Key Exchange length: 65
            Group: secp256r1 (23)
            Key Exchange Length: 65
            Key Exchange: 042c60dacb51f9139a814981fe52c830f990fb739ba98ac993ef19b823cfb5be2ab0371f…

共有値も再生成されています。

そのさらに後、サーバは server hello でやっとサーバの共有地を返してきます。

Server Hello by the server

Extension: key_share (len=69)
    Type: key_share (51)
    Length: 69
    Key Share extension
        Key Share Entry: Group: secp256r1, Key Exchange length: 65
            Group: secp256r1 (23)
            Key Exchange Length: 65
            Key Exchange: 0457a797dc210b089cbe0b74106050b96b022f58a8c68862d10823c10cc624946eea4c59…

これで ECDHEの鍵交換ができて、お互いに共有鍵を計算できるようになったんだと思います。

Extension: psk_key_exchange_modes

もう一つ気になったのが psk_key_exchange_modes.

PSKを使う場合はpre_shared_keyに共有鍵を詰めて送信します。
https://qiita.com/developer-kikikaikai/items/055a344c847379b471f7

pre_shared_key は見当たらなかったですが、PSKを (EC)DHEで行うように要望しているように見えました。

Extension: psk_key_exchange_modes (len=2)
    Type: psk_key_exchange_modes (45)
    Length: 2
    PSK Key Exchange Modes Length: 1
    PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1)

Extension: signature_algorithms

ここは動的な長さ。今回は22 bytes. どうやらサーバのSSL/TLS証明書の種類(RSA/ECC)をclientからリクエストできるようです。

以下、自信ない話

知らなかったんですが、webサーバはクライアントのリクエストに応じて、同じcommon nameでも、異なる証明書を返せるそうです。

Apacheサーバでは、RSAとECCで署名した証明書を出し分ける事が出来る。confファイルに、RSAとECCで署名されたサーバ証明書と鍵をそれぞれ記述するだけです
https://asnokaze.hatenablog.com/entry/20141013/1413194597

証明書をCAから買う際、実は我々は RSA証明書を買っています。手元で openssl -genkey で秘密鍵を作る、それを使ってCSRを作る。CSRをCAに提出すると公開鍵が発行されます。このとき、秘密鍵を openssl ecparams -genkey すると、 ECCに対応した証明書を申請できます。

https://jp.globalsign.com/support/ssl/about-ecc.html

RSA証明書のメリットは計算量が少ないこと、ECC証明書のメリットはサイズ(転送量)が小さくなること。まだECC証明書はそんなに広まってないという認識です。

例えば amazon.co.jp や example.com の証明書は RSA/SHA256で、もっともpopularなものだと思います。これは今回 CLientHelloにあるsignature_algorithmsでは rsa_pkcs1_sha256 として指定されているようです。

Extension: signature_algorithms (len=18)
    Type: signature_algorithms (13)
    Length: 18
    Signature Hash Algorithms Length: 16
    Signature Hash Algorithms (8 algorithms)
        Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
            Signature Hash Algorithm Hash: SHA256 (4)
            Signature Hash Algorithm Signature: ECDSA (3)
        Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
            Signature Hash Algorithm Hash: Unknown (8)
            Signature Hash Algorithm Signature: SM2 (4)
        Signature Algorithm: rsa_pkcs1_sha256 (0x0401)           <-------
            Signature Hash Algorithm Hash: SHA256 (4)
            Signature Hash Algorithm Signature: RSA (1)
        Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
            Signature Hash Algorithm Hash: SHA384 (5)
            Signature Hash Algorithm Signature: ECDSA (3)
        Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
            Signature Hash Algorithm Hash: Unknown (8)
            Signature Hash Algorithm Signature: Unknown (5)
        Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
            Signature Hash Algorithm Hash: SHA384 (5)
            Signature Hash Algorithm Signature: RSA (1)
        Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
            Signature Hash Algorithm Hash: Unknown (8)
            Signature Hash Algorithm Signature: Unknown (6)
        Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
            Signature Hash Algorithm Hash: SHA512 (6)
            Signature Hash Algorithm Signature: RSA (1)

実際に example.com が返してきた証明書は、RSA SHA256でした。

現状ECC証明書がほとんど使われてない気がするので、 signature_algorithms はあまり意味がない気がする。

なお、サーバ側は対応した証明書をServerHelloで返すだけなので、サーバがsignature_algorithmsを返答することはない様子でした。

Extension: application_layer_protocol_negotiation (len=14)

application_layer_protocol_negotiation は ALPN と略されます。ALPNを使うと、TLSの上でHTTP/1.1とHTTP/2の両方を使う、というようなことが可能になります。

今回は全体では 18 bytes あります。 h2, http/1.1 という文字が見えますね。

Extension: application_layer_protocol_negotiation: Type: application_layer_protocol_negotiation (16)

2 bytes で application_layer_protocol_negotiation

続いて 2 bytes で lengthがあります。この先は動的な領域です。14bytesあるそうです。

Extension: application_layer_protocol_negotiation: ALPN Extension Length: 12

さらに ALPN Extention Lengthが 2bytes来ました。lengthだけじゃだめなのか。14-2で12bytesになってます。

Extension: application_layer_protocol_negotiation: ALPN Protocol

まず ALPN string length: 2 が 1 byte あります。この2bytesは、続く文字列 h2 が2bytesという意味を表しています。

ALPN Next Protocl で h2 が指定されています。2 bytesです。
http/2 では文字が多すぎたのでしょうか。HTTP2の不思議です。

その次の ALPN string length = 8 bytes は、http/1.1 の 8bytes ですね。

これにより、この client は ALPNとして http/2 と http/1.1 の利用を求めていることがわかります。http/3はありませんね。ないのか。さすがにまだないのか。

application_settingsにも似たようなのがあって、そこでは h2 だけが指定されてました。

Extension: signed_certificate_timestamp (len=0)

CT logに関するrequestをclientからもできるらしいのですが、len=0でした。使ってないみたい。

supported_groups

手元の書籍では elliptic_curves というextentionで楕円曲線の指定ができるらしいのですが見当たりませんでした。その代わり、ここらへんがそれっぽかったです（調べてない）。ec_point_formats で楕円曲線上の点を圧縮できるらしいのですがあまり効果がないらしく、uncompressedになってました。

Extension: supported_groups (len=10)
    Type: supported_groups (10)
    Length: 10
    Supported Groups List Length: 8
    Supported Groups (4 groups)
        Supported Group: Reserved (GREASE) (0xcaca)
        Supported Group: x25519 (0x001d)
        Supported Group: secp256r1 (0x0017)
        Supported Group: secp384r1 (0x0018)

挫折

ServerHelloにすらたどり着けず数時間が溶けました。続きはいつかやりたいと想います。