盗聴されたデータは、SSLで暗号化されていればそのままでは解読されることはありませんが、暗号化する際に使用した鍵が入手できた時のためにそのまま保存されている可能性はあります。
NSA・米国国家安全保障局による盗聴疑惑が話題になりましたが、国家機関であれば暗号化された全インターネットデータも保存することが可能です。
実際に、暗号化鍵が露呈される事件も起こっています。2014年にも、有名なOpenSSLに重大な脆弱性(Heartbleed)が見つかっています。(HeartbleedについてはOpenSSL Heartbleed(心臓出血)脆弱性へのDigiCertの対応をご参照ください。)
このような事態が起こった場合、バグフィックスを行ったうえで新しい秘密鍵を設定すれば、それ以降の通信データの安全性は確保できますが、過去データについては救済の方法がありません。
国家機関のようなところが「いつかは暗号化鍵を入手できる」と考え、暗号化通信データを保存していたとしたら、重要情報や個人情報がそこから読み取られてしまう可能性もあります。
更に、暗号化鍵が外部に漏れるケースはソフトウェアバグ以外にもたくさんあります。
SSL通信で従来から主流となっている鍵交換は以下の図のような方法で行われています。
これは公開鍵で暗号化したデータを復号できるのは秘密鍵だけという原理によっています。
この仕組みではすべての通信内容が傍受されており、秘密鍵が露呈した場合、その内容は解読されてしまいます。
サーバーの秘密鍵に頼っている場合、その鍵が読まれてしまえば、データの機密は保持できません。
Forward Secrecyとは、サーバーの秘密鍵が暴露された場合でも、過去に暗号化によって通信されたデータの安全性を守ろうとする考え方で、実用化されているのはDHE(ディフィー・ヘルマン鍵共有)と、ECDHE(楕円曲線ディフィー・ヘルマン鍵共有)です。
この方法では、データの暗号化の際、サーバーの秘密鍵・公開鍵を利用するのではなくクライアントとサーバーそれぞれに秘密鍵を持たせるようにします。
公開されている二つのデータとクライアントとサーバーそれぞれの秘密鍵から作成したデータをもとに、相手の秘密鍵を知ることなく暗号化した通信が可能です。
第三者がこの方式で暗号化されたデータの復号を行うためにはクライアントとサーバー両方の秘密鍵を知る必要があるため、仮に一方の秘密鍵が露呈したとしてもデータの安全性は守られます。
しかもDHEとECDHEでは秘密鍵は固定ではなく随時変更されるので、事実上、第三者による解読は不可能とされています。
暗号化だけでは通信相手を検証することができず中間者攻撃が可能になってしまいますので、SSLでは、証明書と組み合わせた以下どれかの方式を使います。
これらの技術を使う場合、従来の共通鍵方式に比べサーバーへの負荷は高まりますが、ECDHE-RSAでは通常のRSAと比べて負荷は15%程度増、ECDHE-ECDSAではむしろforward secrecyなしのRSAより高速化しうるといわれています。(ウィキペディア:Forward secrecy参照)
現時点(2017年10月1日)で、Apache2.4x、Nginx 1.0.6+ でForward Secrecyが利用できます。
ApacheとNginxでのForward Secrecy設定方法を参照してください。
IISでのForward Secrecyは、hass alexander Setup your IIS for SSL Perfect Forward Secrecy and TLS 1.2 で提供されているパワーシェルスクリプトで可能とされています。
IE 6 / XP、IE 8 / XP以外のほとんどのブラウザがForward Secrecyに対応しています。