TLS 1.3: ServerHello 


# 146-152 : ServerHello フロー

ServerHelloはまずサーバから４つのパケットが送られている。それに対するclientからのackらしきものが３つしか見当たらず、よくわからない。


| #    | src               | dest              | type    | length | info |
| ---- | ----------------- | ----------------- | ------- | ------ | ----------------- |
| 146  | example.com       | \*\*localhost\*\* | TLSv1.3 | 1436   | Server Hello, Application Data |
| 147  | example.com       | \*\*localhost\*\* | TCP     | 1436   | 443 → 58364 \[PSH, ACK\] Seq=1470 Ack=861 Win=68096 Len=1370 TSval=2936265897 TSecr=107391639 \[TCP segment of a reassembled PDU\] |
| 148  | example.com       | \*\*localhost\*\* | TLSv1.3 | 1436   | Application Data, Application Data    |
| 149  | example.com       | \*\*localhost\*\* | TLSv1.3 | 117    | Application Data    |
| 150  | \*\*localhost\*\* | example.com       | TCP     | 66     | 58364 → 443 \[ACK\] Seq=861 Ack=2840 Win=128768 Len=0 TSval=107391804 TSecr=2936265897                                             |
| 151  | \*\*localhost\*\* | example.com       | TCP     | 66     | 58364 → 443 \[ACK\] Seq=861 Ack=4261 Win=127296 Len=0 TSval=107391804 TSecr=2936265897                                             |
| 152  | \*\*localhost\*\* | example.com       | TCP     | 66     | \[TCP Window Update\] 58364 → 443 \[ACK\] Seq=861 Ack=4261 Win=131072 Len=0 TSval=107391828 TSecr=2936265897 |



# 146: ServerHello + Application data


| #    | src               | dest              | type    | length | info |
| ---- | ----------------- | ----------------- | ------- | ------ | ----------------- |
| 146  | example.com       | \*\*localhost\*\* | TLSv1.3 | 1436   | Server Hello, Application Data |

## 中身すべて

```yaml
Frame 146: 1436 bytes on wire (11488 bits), 1436 bytes captured (11488 bits) on interface en0, id 0
Ethernet II, Src: da:46:f8:db:b2:0a (da:46:f8:db:b2:0a), Dst: Apple_3f:65:ae (38:f9:d3:3f:65:ae)
Internet Protocol Version 4, Src: 93.184.216.34, Dst: 192.168.61.86
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
    Total Length: 1422
    Identification: 0x8ba2 (35746)
    Flags: 0x00
    ...0 0000 0000 0000 = Fragment Offset: 0
    Time to Live: 55
    Protocol: TCP (6)
    Header Checksum: 0xbeec [validation disabled]
    [Header checksum status: Unverified]
    Source Address: 93.184.216.34
    Destination Address: 192.168.61.86
Transmission Control Protocol, Src Port: 443, Dst Port: 58364, Seq: 100, Ack: 861, Len: 1370
    Source Port: 443
    Destination Port: 58364
    [Stream index: 6]
    [Conversation completeness: Complete, WITH_DATA (63)]
    [TCP Segment Len: 1370]
    Sequence Number: 100    (relative sequence number)
    Sequence Number (raw): 2279612036
    [Next Sequence Number: 1470    (relative sequence number)]
    Acknowledgment Number: 861    (relative ack number)
    Acknowledgment number (raw): 4163027895
    1000 .... = Header Length: 32 bytes (8)
    Flags: 0x010 (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
        .... .... 0... = Push: Not set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
        [TCP Flags: ·······A····]
    Window: 133
    [Calculated window size: 68096]
    [Window size scaling factor: 512]
    Checksum: 0xabf6 [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 2936265897, TSecr 107391639
            Kind: Time Stamp Option (8)
            Length: 10
            Timestamp value: 2936265897
            Timestamp echo reply: 107391639
    [Timestamps]
        [Time since first frame in this TCP stream: 0.480557000 seconds]
        [Time since previous frame in this TCP stream: 0.000201000 seconds]
    [SEQ/ACK analysis]
        [iRTT: 0.154529000 seconds]
        [Bytes in flight: 1370]
        [Bytes sent since last PSH flag: 1370]
    TCP payload (1370 bytes)
    TCP segment data (1173 bytes)
Transport Layer Security
    TLSv1.3 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 155
        Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 151
            Version: TLS 1.2 (0x0303)
            Random: 7dcf490bbb38d0f83ad0c979d7dbc1684b6c7efe4fc1dc813514c88dd033ef5f
            Session ID Length: 32
            Session ID: b1c8e600556b5561ceda33e4c9c0b59221e45d11fb5cc03de4c165861b34f642
            Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
            Compression Method: null (0)
            Extensions Length: 79
            Extension: supported_versions (len=2)
                Type: supported_versions (43)
                Length: 2
                Supported Version: TLS 1.3 (0x0304)
            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…
            [JA3S Fullstring: 771,4866,43-51]
            [JA3S: 15af977ce25de452b96affa2addb1036]
    TLSv1.3 Record Layer: Application Data Protocol: http-over-tls
        Opaque Type: Application Data (23)
        Version: TLS 1.2 (0x0303)
        Length: 32
        Encrypted Application Data: a96ddbef76f693dd4f425080416f3bc0545d86bef120a15adf52e047b2043c66
        [Application Data Protocol: http-over-tls]
```

## ServerHello TCP packet 解読


まず tcpはこのサイズ。 1173 bytesというのが後続のパケットに影響します。先に言うと、このtcp segment 1173bytesは後続のパケットと合算されて一つのデータになるみたいです。

```rb
TCP payload (1370 bytes)
TCP segment data (1173 bytes)
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24737/cc377151-62e6-418c-e3a3-9ffd33b4dbb8.png)

TLS record layerは面白いことが起こっています。２つあります。

```rb
TLSv1.3 Record Layer: Handshake Protocol: Server Hello
TLSv1.3 Record Layer: Application Data Protocol: http-over-tls
```

そうか、ひとつのパケットにいくつでも TLS record を詰め込めるのか・・。

当然、まずは Server Helloを見ます。



## TLSv1.3 Record Layer: Handshake Protocol: Server Hello

ここでついにcopyの仕方を覚えた私。

まず  Handshake Type: Server Hello (2)  で中身を宣言。versionは1.2ぽいが、supported_verionsで1.3が指定されている。

`Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) ` が決定される。


```yaml
Transport Layer Security
    TLSv1.3 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Length: 155
        Handshake Protocol: Server Hello
            Handshake Type: Server Hello (2)
            Length: 151
            Version: TLS 1.2 (0x0303)
            Random: 7dcf490bbb38d0f83ad0c979d7dbc1684b6c7efe4fc1dc813514c88dd033ef5f
            Session ID Length: 32
            Session ID: b1c8e600556b5561ceda33e4c9c0b59221e45d11fb5cc03de4c165861b34f642
            Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
            Compression Method: null (0)
            Extensions Length: 79
            Extension: supported_versions (len=2)
                Type: supported_versions (43)
                Length: 2
                Supported Version: TLS 1.3 (0x0304)
            Extension: key_share (len=69)
                Type: key_share (51)
                Length: 69
                Key Share extension
            [JA3S Fullstring: 771,4866,43-51]
            [JA3S: 15af977ce25de452b96affa2addb1036]
```

あれ、これだけ？ そうなのか。



## session_id

Hello retry request で送った、サーバ側のsession idが再登場します。clientから来たsession idとは違うものです。このidでお互いのやり取りを見分けて、他の通信と混ざらないようにします。

```yml
            Session ID: b1c8e600556b5561ceda33e4c9c0b59221e45d11fb5cc03de4c165861b34f642
```

この後サーバからの通信は暗号化されるため中が見えなくなります。その中にもこのsession idが入っているのかも。



## key_share

    Key Share extension の中に暗号化曲線ぽい指定があった。key exchangeってことは・・

```yml
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: 0457a797dc210b0...…
```


## TLSv1.3 Record Layer: Application Data Protocol: http-over-tls

こちらはシンプル。 Opaque Typeが APplication data(23) で、32 bytesのデータがくっついてます。

```yaml
    TLSv1.3 Record Layer: Application Data Protocol: http-over-tls
        Opaque Type: Application Data (23)
        Version: TLS 1.2 (0x0303)
        Length: 32
        Encrypted Application Data: a96ddbef76f693dd4f425080416f3bc0545d86bef120a15adf52e047b2043c66
        [Application Data Protocol: http-over-tls]
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24737/427e7b81-9b0b-579b-c3e8-e7fb27fd7ad3.png)

ってことはもしかして、後続のと合わせて３つのパケットを合体させて初めて、このtls recordとかも見えたんだろうか？







# 147: TCP [PSH, ACK] - [TCP segment of a reassembled PDU]

続いて TLS ではなく TCP の `[PSH, ACK]` が送られています。最初、これが何なのかわからなかった。TCP packetなので、TLS layerはありませんでした。


| #  | src               | dest              | type    | length | info                                                                                                                               |
| -- | ----------------- | ----------------- | ------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| 11 | example.com       | \*\*localhost\*\* | TCP     | 1436   | 443 → 58364 \[PSH, ACK\] Seq=1470 Ack=861 Win=68096 Len=1370 TSval=2936265897 TSecr=107391639 \[TCP segment of a reassembled PDU\] |



> [TCP segment of a reassembled PDU]
これはTCPレベルでパケットを分割しましたよ・・・という意味です。多分。
TCPで指定されるMSS（最大セグメントサイズ）に沿って、分割された一部のパケットですよってことですね。
PDUってなに？と思われる方は、簡単に言うと「パケット」と同じ意味合いだと思うと分かりやすいです。
> https://itmemories.blog.fc2.com/blog-entry-6.html


このパケットが全部で 1436 bytes あって、おそらくMTUのmaxになってるので、これを含めて後続のapplication dataなんだろう。TCP payload, TCP segment data は ともに 1370 bytes.

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24737/1e644434-affa-0d99-380c-d4fffa05cc09.png)

よく考えると、１つのパケットの中に TLS部分が入ってればそれは TLS パケットと、Wiresharkのprotocol部分は表示する。TLS部分がなくて、TCPまであれば、それはTCPなんですね、きっと。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24737/36abe68c-8a31-7da2-0224-525ca5eca824.png)

当たり前なんだけど、要はどこまでカプセル化されたものが入ってるかどうか。wireshark的には、カプセル化された一番小さいものが protocol なのかもしれない。


後続の application dataには、よく見ると `[3 Reassembled TCP Segments (3604 bytes): #146(1173), #147(1370), #148(1061)]` という部分がありました。 ServerHello + このTCP[PSH, ACK] + 続く application data の３つ合わせて 1173+1370+1061= 3604 bytes になります。1370 bytes は、この TCP payloadおよびTCP segment data に一致します。これらを組み合わせたTCP dataは、wiresharkでは続くapplication dataの中に表示がありました。

なんでこれはTCPでこの後はTLSパケットなのかよくわからなかった。
ちなみにIPパケット分割はserver側で行われて、client側でreassenble（再組み立て=くっつけて再構成）されるらしい。



# 13: Application Data, Application Data  

TCP PSH,ACK に後続する Application data の１つめを見ます。#13(1061)の部分なので data は 1061 bytes のはずです。おっとしかし、1436bytesでmax感ありますね。

| #  | src               | dest              | type    | length | info                                                                                                                               |
| -- | ----------------- | ----------------- | ------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| 12 | example.com       | \*\*localhost\*\* | TLSv1.3 | 1436   | Application Data, Application Data                                                                                                 |




まず目を引いたのは TCPとTLS layerの間にある `[3 Reassembled TCP Segments ]` 。TCPセグメントが複数あることが示されています。Frame: 146-148になってますが、これが↑のtableで言う #146-148 に該当します。先行する `[TCP segment of a reassembled PDU]` に関連していることがわかります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24737/9314ab03-60f0-81d0-94d5-243d8491ce79.png)


続いてTLS layerを見てみます。不思議なのは TLS layerが２つあることです。これ、よく見ると１つめの  `TLSv1.3 Record Layer: Application Data Protocol: http-over-tls` はサイズが 3604 bytes と、MTUを大きく超えています。タブに`Reassembled TCP` あるので、wiresharkが先行パケットにまたがったdataをまとめて表示してくれているんじゃないでしょうか。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24737/16fee905-f602-d25a-461c-c0513ed3579c.png)


TLSとしては type が application data(23) であること、http-over-tlsということがわかります。不思議なのは Version = TLS1.2なところ。wireshark的には TLS1.3 と表示されてるんだけど、その根拠が見当たらない。先行するパケットに理由があるのかもしれない。それにしてもここはTLS 1.3じゃないのか、1.3でも、ここは1.2のままでいいのか。わからない

```rb
TLSv1.3 Record Layer: Application Data Protocol: http-over-tls
  Opaque Type: Application Data (23)
  Version: TLS 1.2 (0x0303)
  Length: 3599
  Encrypted Application Data: fa0cd9330425...
  [Application Data Protocol: http-over-tls]   <-- ここは実際のbitなし
```


encrypted application dataは length が示していて、 3599 bytes ありました。暗号化されていて見えませんが、これが ServerHelloに必要なデータのはずです。


２つめの `TLSv1.3 Record Layer: Application Data Protocol: http-over-tls` は予想外に 309 bytes しかなかったです。いやでも、 1061 bytesであるべきものはTCP。TLSじゃないから、それでいいんだった。encrypted application dataは length が示していて、281 bytes.

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24737/8f1a9129-b9ae-d0dd-1893-d466b993365b.png)

うーん。1173+1370+1061= 3604 bytes の最後だから、 1061 bytesのはずだったんだけど・・

よく見ると、TCP layerに TCP segment data が２つあって、ひとつは (1061 bytes)になっています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24737/5cc583b6-473a-5a57-4b36-d24b2dd39add.png)

TCP segment dataの中身は見えないので、ここにあるであろう tcp dataでreassembleするためのデータは揃ったのかな。

で、そのあとに続くTLS ２つは、もしかしたら違うリクエストなりのなにかなのかもしれない。

思い返すと、このパケットには[Application Data , Application Data ] と２つの Application Data が名付けられています。ここまでは１つめの Application Data で、ここから次の Application Data が始まるのかもしれない。


# 14: Application Data



| #  | src               | dest              | type    | length | info                                                                                                                               |
| 149 | example.com       | \*\*localhost\*\* | TLSv1.3 | 117    | Application Data|

やっぱりそうでした。先のpacket 23bytes, このpacketで 51 bytes, 合わせて 74bytes のTCP segmentsが組み立てらています。これは全部で117bytesしかないフレームなので、ここで終わりかな。

> [2 Reassembled TCP Segments (74 bytes): #148(23), #149(51)]

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24737/4fc745c2-99de-46b1-103e-c2c28044127b.png)

TLS record layerは特に変わらず。中身はencryptedでみえません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24737/8b7eed42-3280-3a4e-0d8b-ba7d378ed696.png)


http-over-tlsだから、中にある http protocolが http/1.1 or http/2 がわからない。そうかブラウザで見てるんだからブラウザはhttpを解釈してるんだった。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/24737/01363219-4ac5-6629-ab88-3688aa6f0b41.png)

http/2 を使っていました。ってことはstreamで複数のコンテンツを連続で返したりしてるかもしれない。ここは本当にserverhello sectionだけなんだろうか。証明書のサイズとか見ないとわからなそう。



---

ふむ。さっぱりわからんな。