現在ではごくごく当たり前に Web サイトが https でアクセスされていると思いますが、クライアントとサーバー間でどのようなやり取りが行われいるかについて、気になったことはないでしょうか？
かく言う私も、「あーこのサーバーは VeriSign の証明書を使ってるだなー」くらいにしか気にしていなくて、
クライアントが Web アプリケーションを使えるようになる前に、どのようなやり取りがされているかなんて意識したことがありませんでした。
今回は、名著「暗号技術入門 秘密の国のアリス」に記載されている、 TLS ハンドシェイクの流れを実際に、パケットキャプチャ ツールの王道「Wireshark」を使って実際のデータを見てみたいと思います。
TLS プロトコルとは
TLS プロトコルは、「TLSレコード プロトコル」「TLSハンドシェイク プロトコル」という 2 つのプロトコルによって構成されており、下層の TLS レコード プロトコルが暗号化の処理を行い、上層の TLS ハンドシェイク プロトコルが暗号化以外のさまざな処理を行います。
TLS ハンドシェイク プロトコルは、さらに 4 つのサブプロトコルに分かれており、その中の 1 つが「ハンドシェイク プロトコル」です。
ハンドシェイク プロトコルとは
ハンドシェイク プロトコルとは、 共有鍵を生成し、証明書を交換するためのプロトコルです。共有鍵を生成するのは、暗号通信を行うためであり、証明書を交換するのは、互いに相手を認証するためです。
ハンドシェイクという言葉は 「握手」という意味ですね、ネットワークを少しでも習ったことがある人は TCP/IP の 3 way ハンドシェイクという言葉でお馴染みだと思います。
TLS の世界では、暗号通信に先立って、サーバーとクライアントが必要な情報交換をするということを「握手」と表現しています。
最初のハンドシェイク プロトコルでのやりとりは、暗号化されていない状況で行われます。
つまり、このプロトコルの途中で流れるすべてのデータは、盗み出される可能性があります。
ですので、公開鍵暗号もしくは Diffie-Hellman 交換鍵をうまく使う必要があります。
ハンドシェイクの流れ
まず、 Wireshark でパケットを見る前に、いかに全体のハンドシェイクの流れを記載します。
「暗号技術入門 秘密の国のアリス」に非常に分かりやすく書かれているので、その流れを引用します。
(1) ClientHello (クライアント→サーバー)
クライアントがサーバーへ「ClientHello」というメッセージを送ります。
クライアント「こんにちは。私が理解できる暗号スイートは、 RSA と 3DES を使ったものか、 DSS と AES を使ったものです。何を使って通信しましょうか。」
このとき、以下の情報がサーバー送られます。
・使用できるバージョン情報
・現在時刻
・クライアント ランダム
・セッション ID
・使用できる暗号スイートの一覧
・使用できる圧縮方法の一覧
(2) ServerHello (クライアント←サーバー)
クライアントからの ClientHello に対して、サーバーは ServerHello というメッセージを返します。
サーバー「こんにちは。それでは RSA と 3DES を使ったもので通信しましょう。」
サーバーは ServerHello メッセージにあわせて、以下の情報を送ります。
・使用するバージョン情報
・現在時刻
・サーバー ランダム
・セッション ID
・使用する暗号スイート
・使用する圧縮方法
サーバーは、クライアントが ClientHello で送ってきた情報を基にして、「使用するバージョン番号」「使用する暗号スイート」「使用する圧縮方法」を決定します。
(3) Certificate (クライアント←サーバー)
サーバーが Certificate メッセージを送ります。
サーバー「はい、これが私の証明書です」
Certificate メッセージにより、クライアントに以下の情報が送られます。
・証明書リスト
証明書リストは、 X.509v3 の証明書の列で、サーバー(送り主)の証明書から始まり、その証明書に署名している認証局の証明書が順番に続きます。
※実はここが今回一番お伝えしたい内容になります。ブラウザーの「鍵マーク」をクリックすると、証明書の情報が表示できますよね、もちろんブラウザーで見られるに越したことはないのですが、ちゃんとパケットの中にも証明書情報が TLS ハンドシェイクの中で流れているんですよ、ということを後程 Wireshark でお見せしたいと思います。
クライアントは、サーバーから送られてきた証明書を検証します。
(4) ServerKeyExchange (クライアント←サーバー)
サーバーが ServerKeyExchange メッセージを送ります。
サーバー「この情報を使って鍵交換をしましょう」
ServerKeyExchange メッセージは、 Certificate メッセージだけでは情報が不足であるとき、クライアントに対して必要な情報を送るためのものです。どのような情報を送るかは、暗号スイートの内容によって異なります。
(5) CertificateRequest (クライアント←サーバー)
サーバーが CertificateRequest メッセージを送ります。
サーバー「ところで、あなたの証明書も見せてほしいです。」
CertificateRequest メッセージは、サーバーがクライアントに対して証明書を要求するためのものです。このメッセージはクライアント認証のためにあります、このメッセージで、クライアントに以下の情報が送られます。
・サーバーが理解できる証明書のタイプ一覧
・サーバーが理解できる認証局の名前一覧
クライアント認証を用いない場合には、 CertificateRequest メッセージは送られません。
(6) ServerHelloDone (クライアント←サーバー)
サーバーが ServerHelloDone メッセージを送ります。
サーバー「以上がごあいさつです」
このメッセージは、 ServerHello メッセージから始まる一連のメッセージの終わりを示します。
(7) Certificate (クライアント→サーバー)
クライアントが Certificate メッセージを送ります。
クライアント「私の証明書はこれです」
サーバーから CertificateRequest メッセージが送られなかった場合には Certificate メッセージは送られません。
(5)でサーバーから CertificateRequest メッセージを送られていた場合、クライアントは、 Certificate メッセージと共に自分の証明書をサーバーに送ります。
サーバーは、クライアントの証明書を読んで検証します。
(8) ClientKeyExchange (クライアント→サーバー)
クライアントが ClientKeyExchange メッセージを送ります。
クライアント「これが暗号化したプレマスターシークレットです」
暗号スイートが RSA を用いる場合には、 ClientKeyExchange メッセージと共に暗号化したプレマスターシークレットが送られます。
暗号スイートが Diffie-Hellman 鍵交換を用いる場合には、 ClientKeyExchange メッセージと共に、 Diffie-Hellman の公開鍵が送られます。
プレマスターシークレットとは、クライアントが作った乱数で、あとからマスターシークレットを作るための種の役割をするものです。
この値は、サーバーの公開鍵で暗号化されてからサーバーへ送られます。
(9) CertificateVerify (クライアント→サーバー)
クライアントが CertificateVerify メッセージを送ります。
クライアント「私は確かにクライアント証明書の本人です」
クライアントが CertificateVerify メッセージを送るのは、サーバーから CertificateRequest メッセージを受け取っていた場合です。このメッセージの目的は、クライアント証明書のプライベート鍵を確かにクライアントが持っていることを、サーバーに通知することです。
この目的のためクライアントは、「マスターシークレット」および「ハンドシェイク プロトコルでやりとりしたメッセージ」のハッシュ値をとり、それにデジタル署名を施したものをサーバーに送ります。
(10) ChangeCipherSpec (クライアント→サーバー)
クライアントが ChangeCipherSpec メッセージを送ります。
クライアント「では、暗号を切り替えます」
実は ChangeCipherSpec メッセージは、ハンドシェイク プロトコルのメッセージではなく、暗号仕様変更のプロトコルのメッセージになります。
この ChangeCipherSpec メッセージが送られる直前までに、暗号スイートに関する情報は、すべてクライアントとサーバー間でやりとりされていますので、このメッセージを合図にして、暗号を切り替えることができます。
これを境にして、 TLS レコード プロトコルは「合意した暗号を使った通信」に入ることになります。
(11) Finished (クライアント→サーバー)
クライアント「以上で、ハンドシェイク プロトコルを終わります。」
暗号はすでに切り替わりましたので、 Finished メッセージは、切り替え後の暗号スイートを使って送られます。
実際に暗号化を行うのは TLS レコード プロトコルです。
サーバーは送られてきた暗号文を復号化して、 Finished メッセージが正しく得られるかどうかを調べます。
これで、ハンドシェイク プロトコルが正常に完了し、正しく暗号スイートが切り替わったどうかを確認できるのです。
(12) ChangeCipherSpec (クライアント←サーバー)
今度は、サーバーが ChangeCipherSpec メッセージを送ります。
サーバー「では、暗号を切り替えます。」
(13) Finished (クライアント←サーバー)
クライアント同様、サーバーも Finished メッセージを送ります。
サーバー「以上で、ハンドシェイク プロトコルを終わります。」
このメッセージは、切り替え後の暗号スイートを使って送られます。
実際に暗号化を行うのは TLS レコード プロトコルになります。
(14) アプリケーション データ プロトコルと TLS レコード プロトコルを用いて、暗号化通信を行うことになります。
やってみる
まず、 Wireshark をクライアント PC にインストールしてください。
URL:https://www.wireshark.org/#download
TLS ハンドシェイクのパケットを取得するのは実に簡単です。
HTTPS サイトにブラウザーアクセスするだけです。
試しに Azure ポータルにアクセスしてみましょう。
その際に Wireshark のパケット取得を開始しておいてください。
アクセスしたら、パケット取得を停止します。これだけです。
TLS ハンドシェイクの中身を見てみよう
1. まず、全部のパケットを 1 行 1 行見るのは大変なので、 Fileter しましょう。
フィルター名：tcp.port == 443
2. 次に、今回は TLS ハンドシェイクの流れを見たいので 、Protocol 列でソートして、 TLS v1.2 を見るようにします。
上記で絞り込むと、下記たった 4 行の中に、上記で説明した TLS ハンドシェイクの一連の流れが詰まっています。
細かく見ていきます
(1) ClientHello (クライアント→サーバー)
赤枠で囲った部分に下記情報(時刻は除く)が記載されているのが分かりますね。
・使用するバージョン情報
・現在時刻
・サーバー ランダム
・セッション ID
・使用する暗号スイート
・使用する圧縮方法
(2) ServerHello (クライアント←サーバー)
上記のとおり、クライアントからの要求に応じて、 TLS 1.2 で通信しましょう、と返しているのがわかりますね。
・使用するバージョン情報
・現在時刻
・サーバー ランダム
・セッション ID
・使用する暗号スイート
・使用する圧縮方法
(3) Certificate (クライアント←サーバー)
下記のとおり、 2 種類の証明書がクライアント側に提示されていることが分かります。
も少し細かく見ていくと、 SHA-2 の 256 bit で暗号化している、とか、 CyberTrust 社が発行している証明書を使っている、などの情報が細かく載っています。
(4) ServerKeyExchange (クライアント←サーバー)
サーバーが ServerKeyExchange メッセージを送っています。
鍵交換をするための情報をクライアント側に送っていますね。
(6) ServerHelloDone (クライアント←サーバー)
サーバーからの一連のメッセージはこれで終了です、というメッセージになります。
(8) ClientKeyExchange (クライアント→サーバー)
クライアントが ClientKeyExchange メッセージを送ります。
暗号スイートが Diffie-Hellman 鍵交換を用いているのが分かりますね。
(10) ChangeCipherSpec (クライアント→サーバー)
クライアントが ChangeCipherSpec メッセージを送ります。
クライアント「では、暗号を切り替えます」
これを境にして、 TLS レコード プロトコルは「合意した暗号を使った通信」に入ることになります。
(11) Finished (クライアント→サーバー)
クライアント「以上で、ハンドシェイク プロトコルを終わります。」
Encrypted Handshake Message と表記されていますが、 Finished と同義です。
(12) ChangeCipherSpec (クライアント←サーバー)
今度は、サーバーが ChangeCipherSpec メッセージを送ります。
サーバー「では、暗号を切り替えます。」
(13) Finished (クライアント←サーバー)
クライアント同様、サーバーも Finished メッセージを送ります。
サーバー「以上で、ハンドシェイク プロトコルを終わります。」
Encrypted Handshake Message と表記されていますが、 Finished と同義です。
まとめ
正直私も今まで全く意識できていなかったのですが、こうやって Wireshark を使うことで、誰もが簡単に、 TLS ハンドシェイクの流れを垣間見ることができます。
今回の内容が少しでもお役に立てれば幸いです。