鍵ファイルのパスフレーズ。パスを付けていないならば、空のままにしておくこうして[OK]をクリックすれば、暗号化されていた通信の中身が見えるようになります。上図では、先ほど見えなかったGETリクエストと、そのレスポンスボディが見えているのが分かります。Stream]で流れを追うことができるようになります。Stream]を選びます。このように、SSL通信の流れをそのまま見ることができるので大変便利です。ありがちな失敗例ハマり所をいくつか紹介します。暗号化が解けずにそのままEncryptedで出ちゃう秘密鍵をWiresharkに登録しているのに、通信内容が暗号化されたままとなることがあります。Dataが流れているところまでは分かりますが、肝心のデータが暗号化されたままになっています。e127673d4e5fb04ce09ebaed1702a6dd8e2eaeeed12852f4...これは、SSL通信においてメッセージを実際に暗号化している共通鍵が取得できていないためです。その原因は、「SSLキャッシュが効いているから」ということになります。ここで、まずSSL通信のシーケンスを押さえておきましょう。通常は下図のようになっています(この図を描くだけで疲れちゃった)。押さえておくべきポイントは、ClientKeyExchangeです。暗号化は「重い」処理のため、じゃんじゃかトラヒックが流れるメッセージ全体を暗号化するのはとても大変です。SSLではHTTP通信自体は(高速な)共通鍵暗号方式で暗号化し、その共通鍵のやりとりのみに、公開鍵暗号方式での暗号化を適用しています。そのため、この形式をハイブリット方式と呼ぶこともあります。実際に共通鍵をやりとりしている様子は、Wiresharkでも確認できます。PreMasterを見ることができます。これが実際に通信を暗号化している共通鍵の元です(Preと付いていることから分かるように、本当はこのPreMasterからさらに鍵を作っていくのですが、そこは省略します)。このようにSSLでは通信を開始する前に鍵交換をするわけですが、一つ一つのリクエスト全てに対して鍵交換をするのはコスト的によろしくありません。そのため、SSLキャッシュを導入し、いったん作った鍵はしばらく使い回すのが普通です。ここまでの解説で、なぜさっき上手く復号できなかったのかが分かりましたでしょうか。SSLでは、はじめにクライアントで生成した共通鍵(の元)を受け渡しするので、セッションの一番はじめからキャプチャしていないと、暗号化された通信を復号することができません。以下のような手順でキャプチャすると上手く行きません。httpsでWebブラウザで繋いでみて、よし、OKではtcpdumpでキャプチャ開始よし取れた、Wiresharkで中身を......あれ、出ない?もう一度、先ほど復号できなかったパケットキャプチャを見てみます。Exchangeがありません。そのためこの通信だけをキャプチャしても、メッセージのやりとりを復号するための共通鍵が不明のため中身を見ることができないわけです。SSL通信を復号するには、キャッシュに乗ってしまった後ではダメで、「キャッシュに乗る前の一番最初から、通信全体を丸ごと」取得する必要があります。SSLキャッシュは、Apacheならば、ssl.confに以下のように設定されています(もちろん環境により色々違うでしょう。これはCentOSのhttpdのデフォルト値です)。300学習・勉強用のサーバならば、SSLキャッシュは切ってしまった方が良いかもしれません。ApacheでSSLキャッシュを無効にするには、SSLSessionCacheディレクティブに"none"を指定します。none実験環境ならこの方が良いかもしれません。何かのエラー?前述の「キャッシュに乗ってしまった後」からパケットキャプチャした場合、誤解しやすいのがこの事例です。Alertが出るのは、セッションの途中やキャッシュが残っている状態でキャプチャを開始して、前述の共通鍵が入手できず通信の中身が分からないときです。Notifyで通知します。Notifyのパケットです。Notifyとまでは分からず、「Alertプロトコルの何か」であることしか分かりません。Alert」と表示されます。Notifyを投げる」ので、Alertが出るのは正常です。ネーミングが良くない気がしますね。最初から通信全体丸ごとキャプチャしているのに、Diffie-Hellmanってのが出ててEncryptされたまなんですけど話がややこしくなるのでここまで敢えて触れませんでしたが、実はSSLキャッシュが効いていないケースで通信最初から丸ごとキャプチャしていても、通信内容がEncryptされたままで見えないことがあります。Dataの中身はEncryptedされたままでGETリクエストなどを見ることができません。Exchangeすなわち鍵交換のアルゴリズムにあります。Exchangeのパケットを見たものです。ここでは、Diffie-Hellman(DH)という形式で鍵交換をしていることが分かります。SSLのように、公開鍵暗号方式で暗号化した通信路上で共通鍵の交換をおこなう通信では、「過去の通信内容を丸ごとキャプチャして保存している人が、あとで秘密鍵を手に入れた場合、過去の通信内容を簡単に復号できてしまう」という点に気を付ける必要があります。このような事態(というか、今回のHeartbleed問題で現実になりましたね)に備えるには、鍵の生成を、第三者が盗聴したときに計算困難な形で行う手法が用いられます。Diffie-Hellman)鍵交換はこの計算困難なアルゴリズムです。DH鍵交換では、まず「素数p」と「pを法とした原始根g」を両者で共有します。この2つの値pとgは、第三者に知られても構いません。実用上は、gは2か5で決め打ちとし、そこから適当な素数を決めるのが普通です。これが実際に交換する値n,mです。すると、たとえ通信路上でmとnが盗まれても、第三者にはxとyが分からないので、Kを計算することは多項式時間では不可能なため計算困難です。そのためpが十分に大きい値ならば、安全と言えるでしょう。数式を離れて元に戻ります(DH鍵交換は中間者攻撃できるという大きな欠点があるのですが、今回は説明省略)。SSLでは、鍵交換するアルゴリズムは複数あり、それはWebサーバ側やWebブラウザ側で「提示し合って」決めます。今まで見てきた例はInternetExplorerを使いましたが、IEはどうもDHを嫌うようで、RSAが選択されます(たぶん。IE11ではそうでした)。FirefoxはDHを優先して選択するようです(たぶん。この辺ちょっと調査不足)。先ほどのDH鍵交換のパケットキャプチャも、Firefoxでブラウズしたものです。このブログで例示した実験をする際には、暗号通信の中身を全部見たいでしょうからIEを使うと良いでしょう。Webサーバ側でDHを使わないようにするのも一つの手です。/etc/httpd/conf.d/ssl.confで、SSLCipherSuiteディレクティブに以下のように「kRSA」のみを指定すると、DH鍵交換を使わないように強制できます(これはあくまで実験用の設定例ですので、外部公開するWebサーバに使うもんじゃありません。kRSAこうすれば、私の環境ではFirefoxであってもDH鍵交換を使わなくなったため直接通信内容が見えるようになりました。ここで指定しているSSLCipherSuiteの実際の値は、opensslのciphersコマンドで-vオプションに文字列を与えることにより確認することができます。Mac=SHA1....(省略)....参考リンクHTTPSコネクションの最初の数ミリ秒SSLのハンドシェイクを、実際のパケットキャプチャの様子を交えながら懇切丁寧に語ってくださる。不正アクセスを防止するSSL/TLS@ITの記事。Blok)WiresharkでSSL通信を覗いてみるやり方、ハマリ所について動画で語ってくださる。PowerPoint"という所に発表資料のパワポファイルも置いてありますので、動画と合わせて見ましょう。関する罪」の情報公開請求をしました月別アーカイブはてなブログをはじめよう!ozumaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。