ubuntuでFirefoxのTLS通信をキャプチャする。

ブラウザにFirefoxを使っている場合、TLS通信をキャプチャできる方法があるので書いてみます。試した環境は以下です。

OS:ubuntu 18.04 LTS
ブラウザ:Firefox Quantum
キャプチャツール:Wireshark(Version 2.6.3)

まず、TLSの通信で使う鍵をファイルに書き出すように環境変数を設定します。設定する環境変数は「SSLKEYLOGFILE」です。コンソール画面を立ち上げて、以下のようにします。

$ export SSLKEYLOGFILE=/home/user/sslkey.log
$ env | grep SSLKEYLOGFILE
SSLKEYLOGFILE=/home/user/sslkey.log

※「/home/user/sslkey.log」は任意の場所、ファイル名で構いません。

Firefoxをコンソールからコマンドで立ち上げます。

$ which firefox
/usr/bin/firefox
$ /usr/bin/firefox

Firefoxが立ち上がり、コンソールは待ち状態になります。別ウィンドウでコンソールを開いて、SSLKEYLOGFILE が書き出されていることを確認します。

$ ls -l /home/user/sslkey.log

[広告]

ここまででキャプチャする準備が整いました。ここからはWiresharkの設定をします。Wiresharkを起動して、上部の「編集」メニューから「設定..」を選択します。設定画面が表示されるので左ウィンドウから「Protocols」を選び、そのなかの「SSL」を選択します。

(Pre)-Master-Secret log filename に SSLKEYLOGFILE の場所を指定します。これでキャプチャを開始するとTLS通信の中身が解析できるようになります。

注意点です。
マウス操作でFirefoxを立ち上げてもSSLKEYLOGFILEで指定したファイルには書き込まれません。コンソールで環境変数を設定した上で、コマンドでFirefoxを立ち上げてください。

なお、Firefoxをマウスを使って閉じるとコンソール画面では「接続が相手からリセットされました」となりますが、気にしなくても良いでしょう。

QUICでのHTTP通信の高速化

HTTPの高速化に関わる仕組み」でHTTP/2までの高速化についてまとめてみたのですが、QUICについても書いておこうと思います。QUIC(Quick Udp Internet Connectionsのこと、クイックと読みます)はGoogleが開発したプロトコルでHTTP通信をUDP上で行うものです。UDPはTCPと違い通信の信頼性を保証しないためTCPが持つ機能の一部(再送制御など)をQUICが担います。また暗号化に関わる機能もQUICは持っています。

そもそもGoogleがTCPではなくUDP上でHTTP通信をやろうと思った理由の1つに、TCP/TLSの接続時のオーバーヘッドを抑えることで更なる高速化が期待できると考えたからだと思います。TCPの接続時のコネクション確立には3ウェイハンドシェイクで3回のやりとり、TLSでのネゴシエーションでは7回のやりとりが行われたあとにデータ送信が始まります。

これがQUICの場合だとクライアントとサーバー間を1往復するだけでデータ送信が開始できます。接続のやりとりが1往復のみなので「1-RTT」と呼ばれています(RTTはラウンドトリップタイム、往復時間という意味です)。

2回目以降のデータ送信については②で得たトークンを使い、いきなりデータをサーバーに送ります。接続時のやりとりがないため「0-RTT」と呼ばれています。

なお、③、④のデータは暗号化されています。

UDPを使うもう一つのメリットは、ヘッドオブラインブロッキング(※)がTCPに比べ緩和されることではないでしょうか。HTTP/2でも非同期通信ができますので前のリクエストを待たずに後続のリクエストを送ることができるわけですが、パケットをロストした場合においてはTCPは再送制御が働き、後続のリクエストに「待ち」が発生します。QUICはこの再送制御を独自で実装しているためTCPに比べ効率的な方法で(もしくは「待ち」が発生しない方法で)ヘッドオブラインブロッキングを取り除いているのではないかと思います。

(※)ヘッドオブラインブロッキング・・・前のリクエストが処理されるまで次のリクエストが待たされてしまう(ブロックされてしまう)ことをいいます。

他にもQUICの利点はあるのかもしれませんが、ここでは接続時のオーバヘッドとヘッドオブラインブロッキングについて書いてみました。なお、QUICは今後TLS1.3と同等の機能を持つ(TLS1.3の仕様を取り込み同様の機能を持つ)ことになるようです。

■2019年2月24日 「HTTP/3」について追記
2015年6月にGoogleがIETFにQUICのドラフトを提出し、2016年末にIETFの中でワーキンググループが設置され標準化の検討が始まりました。

上に書いていたことは、Googleが開発を行ったときにQUICをWeb利用のものとして考えていたものです。IETFの標準化の中ではWeb利用に限らないトランスポート層のプロトコルとしてQUICを位置づけています。IETFではQUICを利用するHTTPを「HTTP over QUIC」と呼んでいたのですが、2018年の11月に「HTTP/3」という名称で呼ぶことにかえました。

GoogleもIETFの標準化作業がまとまればそれを踏襲する意思を示しています。IETFでは2019年7月にQUICの標準化仕様の公開を予定しているようです。

■2022年7月14日 「HTTP/3」について追記
2022年6月にIETFはHTTP/3を正式に勧告しました。これにより今後は脱TCPの流れになっていくかもしれません。なお、2022年6月時点でHTTP/3に対応しているWEBサイトは全体の25%程度とのことです。