continuing from 2023-11-24

TLS の振る舞いについてまだよくわかっていない。もしかしたら ServerHello や ClientHello から追っていく必要があるのかもしれない。CLIENT_RANDOM として SSLKEYLOGFILE に書き込まれるのは client random と master secret であるから、これらの情報を使えば ClientHello と ServerHello が終わった後の処理ができると考えてもよいのだろうか？（AEAD の場合は最初の application data とか initialization vector が他に必要そうだけど）
とりあえず、今のところは rustls で TLS packets の encrypted payload から cleantext を得るためにはどのような手順を踏めばよいのかを調べる必要があり、そのためには TLS 1.2 における復号の手法をまず知る必要がありそう。
GCM は AEAD の一種であるから、

eng-b@zeektls で出てきた pre-master secret のことは RFC 5246 において premaster secret と表記されている。
The Transport Layer Security (TLS) Protocol Version 1.2 (RFC 5246) で続きを行う。

정인지(鄭麟趾)が「ハングルは賢い人なら半日で、バカでも一週間で読めるようになる」と言ったらしく、세종（世宗）さんによる発言ではないらしい。

https://twitter.com/public_yusuke/status/1729130669094445314
Quest 3 被ってベッドの中で Immersed 開いて作業をしていたが、普通にヘッドセットが重すぎて耐えられなかったので結局 MBP を体の前に開いて作業している。

The Transport Layer Security (TLS) Protocol Version 1.2 (RFC 5246)@key-calculation から、解読のためには server_random をキャプチャしたパケットなどから得ておく必要があることがわかった。eBPF プログラムの中で、TLS 1.2 のパケットが到達した際には例外なく sergver_random を保持しておくような実装を追加してあげる必要がありそう。とりあえず解読関数には GCM なら前のパケットの平文を与えてあげる必要があるだろうし、
最初のパケットなら master_secret から導出できる key_block で IV も揃うので、まずはそのパケットから decrypt するための関数を書いてみたい。
今後 server_secret を得たくなったら、同一の TLS セッションをうまく見分けて保持しておく必要がある（ServerHello から得たものを今後のパケットと紐づけ可能である必要がある）。これは TCP レベルで突合すればうまくいくんだろうか？