セキュリティ初心者も暗号化通信の中身をみてみよう｜セキュリティごった煮ブログ

さて、本日ですが「セキュリティ初心者も暗号化通信の中身をみてみよう」と題しまして、暗号化通信の内容をいろんな角度から覗いてみたいと思います。
「暗号化通信って暗号化されているから中身見てもわかんないでしょ？」という会話のとき「ですよねー。見えたら暗号の意味ないですもんねー」ではなく「実は暗号化通信でもわかる情報もありますよ。例えば～」なーんて、技術的なことはワカランっていうアナタもサラって言えるようになっちゃいますよー( *´艸｀)
あ、今回は通信の細かなやり取りの技術的な説明はほとんどなく「おー水の中に魚が見えるねー。きれいだねー」的なゆるい雰囲気でご紹介していきたいと思います。

ではでは早速本題です。
今回は皆様ご存知のヤフートップページである https://yahoo.co.jp へアクセスしたときの暗号化通信を下記の3つの方法で見比べてみました。

• 送信元端末の「Wireshark」でアクセスしたパケットをキャプチャして中身をチェック。
• 同通信をプロキシの手前でtcpdumpというパケットキャプチャソフトでキャプチャして「Wireshark」で中身をチェック。
• 同通信を「ネットエージェント製復号プロキシ Counter SSL Proxy 」で復号して PacketBlackHole で中身をチェック。

同じ通信を3つの方法で同時にキャプチャしちゃいます。
キャプチャの仕方で見え方も変わるのでしょうか。

ではまず
（ア）Wireshark で送信元端末のパケットをチェーック！

ボクの端末のアドレスは172.16.3.126です。
それからボク専用のWEBプロキシアドレスが172.16.180.199になります。
ちなみに、Yahooトップページへのアクセスをブラウザの開発者ツールで見てみると要求数130と表示されています。また、WiresharkのNo.を見るとざっくりですが3,500件くらいのパケットのやり取りがありました。たった一つのサイトを表示するだけでも、たくさんの情報のやり取りがあるんですね。
こりゃパケット見る仕事の人は大変ですなー。

では、中身を見ていきましょう。

①では、宛先のホスト名である「www.yahoo.co.jp」があります。
①を展開した内容が②になります。
暗号化通信ですので②の表示では443のサーバポートでアクセスしていますが、プロキシを介していますので実際に①のポートを見ると送信元ポートは53657、宛先ポートは8080でやり取りをしていたんですね。送信元ポートは動的に割り当てられているようです。

んで①以降ではクライアントとWEBサーバ側で暗号鍵の交換をしてますね。
"Client Key Exchange"が読めます。（No.66）
さあ、次は実際のコンテンツデータを見ていきましょう。
ところどころにある"Application Data"を見てきますね。

んー、ブラウザの開発者ツールで見ていくと、③のあたりの"Application Data"には画像データが含まれているはずなんですが、④で中身を見てみても画像ファイルまでは特定できないですね。
相変わらずホスト名のwww.yahoo.co.jpだけが確認できます。
以降、同様にいくつかの"Application Data"の中身を確認していきましたが、やはりデータの中身はわかりませんでした。

でも⑤で示しているように、ページ内で他のサーバへ接続しに行くときにはHTTPで接続しているんで接続先の情報もわかりそうですね。「~yimg.jp」ちょっと調べてみるとyahooサイトの画像ファイルが保管されているホストのようです。

送信元端末で取得したパケットからわかったことはこちらです。

1. アクセス日時
2. 送信元IPアドレスとポート
3. 宛先IPアドレスとポート（社内にプロキシやルータがある場合はこれらのアドレスになります）
4. 宛先ホスト名
5. ページを読み込むときに接続するホスト名

では次は
（イ）tcpdump × Wireshark でプロキシ手前のパケットをチェーック！

先に答えを言ってしまうとタイムスタンプや取得通信に違いがあるものの、送信元端末と同じような情報の確認ができました。

アプリケーションデータについてももちろん中身はわかりませんが、送信元端末で取得したパケットと同様にホスト名については確認できました。（⑥⑦⑧⑨）
わかる情報も送信元端末で取得する情報と変わりはなく

1. アクセス日時
2. 送信元IPアドレスとポート
3. 宛先IPアドレスとポート（社内にプロキシやルータがある場合はこれらのアドレスになります）
4. 宛先ホスト名
5. ページを読み込むときに接続するホスト名

ですね。

では最後に
（ウ）Counter SSL Proxy × PacketBlackHole で復号したパケットをチェーック！

まず PacketBlackHole を使うので、せっかくなんで検索条件を使って通信を検索しちゃいます。
時間を指定して、URLを指定して検索開始と・・・。
おーURLで検索できちゃうよー！こりゃ便利。（⑩）
もちろん、当該通信がヒットして抽出されてきました。ここまでWiresharkとにらめっこだったのでラクチンで助かりました。（⑪）

もちろん復号されていますので、ヘッダー情報からアプリケーションデータ（画像ファイル等）、ストリーム情報までばっちり確認できました。ついでに記録されたデータから通信の再現表示ボタンをクリックすると・・・。

わー画像データもばっちり復元されるんですねー。（注意：本画像はリンクのクリックではなく、記録したデータをもとに再現しています）

という事でキャプチャ方法別に結果を比較してみました。

	送信元端末で Wireshark	プロキシ手前で tcpdump × Wireshark	復号 Counter SSL Proxy × PacketBlackHole
日時	〇	〇	〇
送信元IPアドレス	〇	〇	〇
宛先IPアドレス	〇	〇	〇
宛先ホスト名	〇	〇	〇
接続先ホスト名	〇	〇	〇
宛先URL	×	×	〇
リンク先URL	×	×	〇
アプリケーションデータ （画像ファイルとか）	×	×	〇

（結果は2018年5月現在のものですので、WEBサイトの仕様変更により結果が異なる場合もございます）

ポイントとしては

• 復号しなくてもパケットがあれば宛先のホスト名はわかりますよー。
  でもURLはわからないです！
• ただ、見れる見れないということよりもWiresharkで特定通信を探したり内容を確認する作業自体がとても大変ですので業務で行うには覚悟が必要ですよー。（汗

という事で次回は別の暗号化通信を比較してみたいと思います！