TCP 3-way handshakeの復習 - CubicLouve
上記を踏まえた上でSSL/TLSのシーケンスをtcpdumpとwiresharkで追ってみました。
まだ理解しきれていない部分があるので直すかも。
clientのコードはこちらから。
clientのコードは下記ページのものを使っています。
流れ
1. クライアントからSYN(TCPと一緒)
22:41:54.444298 IP 192.168.100.101.51013 > nrt04s05-in-f18.1e100.net.https: Flags [S], seq 1497432669, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 946049109 ecr 0,sackOK,eol], length 0
2. サーバーから SYN + ACK(TCPと一緒)
22:41:54.609915 IP nrt04s05-in-f18.1e100.net.https > 192.168.100.101.51013: Flags [S.], seq 1784227309, ack 1497432670, win 42540, options [mss 1360,sackOK,TS val 3615605143 ecr 946049109,nop,wscale 7], length 0
3. クライアントから ACK(TCPと一緒)
22:41:54.609979 IP 192.168.100.101.51013 > nrt04s05-in-f18.1e100.net.https: Flags [.], ack 1, win 8256, options [nop,nop,TS val 946049273 ecr 3615605143], length 0
4. クライアントがClient Helloメッセージを送る
クライアントがサポート可能な暗号化/圧縮アルゴリズムを通知する
wiresharkでみてみると、CipherSpecsが送られている。
ここではフラグがPUSHになっている。(すぐに返せってことなのかな)
22:41:54.611008 IP 192.168.100.101.51013 > nrt04s05-in-f18.1e100.net.https: Flags [P.], seq 1:131, ack 1, win 8256, options [nop,nop,TS val 946049274 ecr 3615605143], length 130
5. サーバーがACKを返し、さらにServer Helloを返す
使用する暗号アルゴリズムをServerHelloメッセージに格納しておくる。
今回はCipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)を使っていた。
この時点で証明書送ってそうだけどな。。。。
22:41:54.769011 IP nrt04s05-in-f18.1e100.net.https > 192.168.100.101.51013: Flags [.], seq 1:1349, ack 131, win 341, options [nop,nop,TS val 3615605273 ecr 946049274], length 1348 22:41:54.769090 IP nrt04s05-in-f18.1e100.net.https > 192.168.100.101.51013: Flags [.], seq 1349:2697, ack 131, win 341, options [nop,nop,TS val 3615605273 ecr 946049274], length 1348
6. サーバーがCertificateを送る
サーバの証明書をCertificateメッセージに格納して送る。
22:41:54.769249 IP nrt04s05-in-f18.1e100.net.https > 192.168.100.101.51013: Flags [P.], seq 2697:3172, ack 131, win 341, options [nop,nop,TS val 3615605273 ecr 946049274], length 475
7. クライアントがClient Key Exchange, Change Cipher Spec, Encrypted Handshake Messageを送る
クライアントが生成した、プリマスターシークレットをサーバーの公開鍵で暗号化して送信する。
22:41:54.804024 IP 192.168.100.101.51013 > nrt04s05-in-f18.1e100.net.https: Flags [P.], seq 131:445, ack 3172, win 8192, options [nop,nop,TS val 946049465 ecr 3615605273], length 314
8. サーバーがChange Cipher Spec, Encrypted Handshake Messageを送る
新しい暗号化仕様の利用開始を通知。
22:41:54.904878 IP nrt04s05-in-f18.1e100.net.https > 192.168.100.101.51013: Flags [P.], seq 3172:3219, ack 445, win 350, options [nop,nop,TS val 3615605439 ecr 946049465], length 47
9. 通信開始
ここからやっと通信開始
ここまでをSSL_connectがやっている。
SSL_connect - initiate the TLS/SSL handshake with an TLS/SSL server
参考文献
WiresharkでSSL通信の中身を覗いてみる - ろば電子が詰まっている
SSL/TLS の暗号アルゴリズムの決定メカニズムをパケットレベルで追いかけてみる - /dev/null blog
「不正アクセスを防止するSSL/TLS」最新記事一覧 - ITmedia Keywords
OpenSSLライブラリを使ってプログラミング(1) - 再帰の反復
