OpenSSLの脆弱性（Lucky Thirteen）がOpenVPNに与える影響について

他の誰も返信しないようなので、私から返信します。この件については、この問題が一般に公開される前に開発チーム内で協議されました。この問題に関する情報は、多くのSSLライブラリのアップデートがリリースされるのに合わせて月曜日に公開されたものです。

まず、私は暗号化の専門家ではないため、問題の詳細に関しては限定的な理解であることを前置きさせてください。その上で、事実を過小評価したりいじったりすることなく、なるべく分かりやすく説明したいと思います。

前提として、OpenVPNのセキュリティについてですが、SSL/TLS処理についてはOpenVPNが使用しているSSLライブラリ（v2.3.0以降ではOpenSSLかPolarSSLを指します）に完全に依存しています。しかし！ SSLライブラリが持つ機能のうち、OpenVPNが使用していないものがいくつかあり、OpenVPNはSSLライブラリに今回見つかったセキュリティ上の欠陥の影響をほとんど受けません。さらに、OpenVPNに対する攻撃を困難にするため、OpenVPNはSSL/TLSワイヤプロトコルに直接関連しない追加のレイヤーを追加することができます。

開発者による協議の結果によれば、今回の件でOpenVPNのセキュリティを弱める可能性のある問題は特にないとのことです。私の理解では、この脆弱性に関連した攻撃がOpenVPNに加えられた場合でも、OpenVPNは通常通りそのパケットを廃棄して新しいトンネルネゴシエーションを開始するに過ぎないと考えています。加えて、もし --tls-auth が設定されていれば、追加のHMAC認証にほとんどの場合失敗することになり、その場合はサーバーまたはクライアントはその後の解析処理に送るまでもなくそれらのパケットを破棄してしまいます。

今回発覚した脆弱性はDTLSにも密接に関連したものですが、OpenVPNはこのプロトコルを使用していません。OpenVPNはDTLSが提供している機能（UDPなどの信頼できない/ステートレスな接続上でのTLS機能）と同等の機能を独自のソリューションで実装しているためです。これはまた、OpenVPNがDTLSに関連した問題に影響されにくいことも意味しています。

私が理解している限り、今回の脆弱性の問題はタイミングとパディングに関連したものです。ざっくり言えば、不正なパディングとそれらのパケットの応答時間により、接続を切断できる可能性があり、暗号化されたデータの安全性を脅かすことができる、というものです。

PolarSSLでは、クライアントからのパディングに関わりなくほぼ同じ応答時間を提供する機能を実装したため、タイミング攻撃ベクタの使用がほぼ不可能になったとのことです。OpenSSLがどのような方法で対応したのかは現時点では私は理解していません。ただ、私たちは（OpenVPN側の問題でない限り）OpenSSLの今回の修正によってOpenVPNで問題が発生した [1] ことを理解しており、この件については調査中です。


[1] https://bugs.gentoo.org/show_bug.cgi?id=455810