IPsecにおけるLogjamの影響

Tweet

編集長の佐藤（@akihirosato1975）です。

OpenSSHに続いて、今度はIPsecにおけるLogjamの影響について調べてみました。これも今のところ日本語の情報がないに等しいので。

…ただ先にお断りしておくと、OpenSSHの時ほどすっきりした結論になりません。とりあえず今代表的なオープンソースのIPsec実装であるlibreswan/openswanについてはおそらく設定変更だけで影響を回避できるだろうと思われることははっきりしましたが（詳細は後述）、なんせIPsecにはCiscoのVPN製品に代表される商用アプライアンスや、クライアント側についてもWindows/Mac OS XなどOS側にビルトインされている実装など多数のソフトが存在していて、それぞれがデフォルトでどの鍵交換方式・ビット長を使っているか、またそれを変更可能かといった点は把握しきれません。なので最終的にはお使いの環境を提供しているベンダにお問い合わせされることをおすすめします。

なお今回の情報元は、基本的に「The weak DH and LogJam attack impact on IKE / IPsec (and the *swans)」になります。
以下は同記事を斜め読みしてまとめているだけなので、内容については確認していないことをあらかじめお断りしておきます。

サーバ側

IKEv1

IKEv1における、デフォルトの鍵交換のビット長はFreeS/WANの場合で1024bit、openswanは1536bit、libreswanは2048bit（いずれも最新版の場合）。ただlibreswanがデフォルトで2048bit化したのは2014年7月なので、ちょっと古い実装だとデフォルトが1536bitになっている。
とはいえFreeS/WANのサイトを見てもわかるように、FreeS/WANは2004年を最後にリリースを停止しているので、そもそもFreeS/WANを使い続けるのは現実的ではない。openswan/libreswanであれば、デフォルトでLogjamの影響は受けないと考えられる。

IKEv2

openswanでは2008年に、デフォルトのビット長を2048bit化している。libreswanも最新版ではデフォルトが2048bit。従ってこちらもデフォルトではLogjamの影響は受けないと考えられる。

クライアント側

libreswanをクライアントとして使う場合、IKEv1では1024bit、IKEv2では1536bitが最低のビット長になる。
同じくopenswanではIKEv1時が1536bit、IKEv2時が2048bit。ただしopenswanはINVALID_KEメッセージを適切に処理しないため、サーバ側が最低2048bit設定の場合、接続を拒否される可能性がある。

従ってLogjamの影響を避ける場合は、libreswanかつIKEv1を使う場合に限り最低ビット長を引き上げる必要がある（/etc/ipsec.confのikeオプションで指定する）。