Why not "Why not WireGuard?"
Why not "Why not WireGuard?"
マイケル・トレマー氏による「Why not WireGuard」というタイトルの記事が、VPNの議論の中で共有されることがあります。残念ながら、その記事にはいくつかの誤解や古い情報が含まれており、それに対処する必要があります。
彼の主張をセクションごとに見ていきましょう。
Will WireGuard replace my (IPsec) site-to-site VPN? - WireGuardは、私の(IPsec)サイト間VPNを置き換えることができますか?
- Tremerが書いています。
- 大手ベンダーがWireGuardを採用する可能性はありません。彼らは、大きな必要性がない限り、このような列車に飛び乗ることはありません。
このように言うとき、Tremer氏は、ほとんどの場合、集中型のハブ＆スポークアーキテクチャを使用している商用VPNハードウェア/ソフトウェアベンダーの話をしています。
ほとんどの IPsec VPN ベンダーが WireGuard にアップグレードする可能性は低いのは事実ですが、私たちが聞いたユーザーは、既存の VPN 集中装置を新しいプロトコルで動作させようとしていることはほとんどありません。むしろ、ボトルネックとなっているVPN集中装置を、より軽量で制限の少ないものに置き換えたいと考えているようです。WireGuardは、VPNハードウェアをシンプルなソフトウェアソリューションで置き換えるため、従来のハードウェアベンダーからのサポートは必要ありません。
WireGuardは、ラップトップからデータセンターへのロードウォーリアーを交換してくれるのでしょうか？
- Tremer氏は次のように述べています。
- 今のところ、WireGuardには、このユースケースに適した機能を実装するために必要な膨大なバックログがあります。例えば、トンネルのサーバ側でダイナミックIPアドレスを使用することはできません。
記事では、WireGuardには「膨大な機能のバックログ」が不足していると主張していますが、不足している機能として動的IPアドレスだけが挙げられています。この「膨大なバックログ」は、WireGuardの以前のバージョンの情報が古くなっている可能性があります。
記事のこのセクションでは、「ロードウォーリアー」ユーザー（一般的にダイナミックIPアドレスを持つ）がWireGuardでサポートされていないことについて言及しているため、最初は混乱します。標準の WireGuard は、少なくとも一方のエンド (通常は中央の VPN 集中装置) が静的 IP アドレスを持っている限り、問題なく動作します。
このセクションの残りの部分は、接続の両端が動的な IP アドレスを持つことによって引き起こされる問題について議論しているように見えます (例えば、ホーム接続が動的 DNS を使用しているオフィスネットワークに接続することができるようにするため)。確かに、プレーンなWireGuardはこの設定をサポートしていません。しかし、これを正常に動作させる様々なスクリプトや高レベルのツール（当社のものを含む）があります。
- 2020-04-28を更新しました。
- 両端がダイナミックIPアドレスであってもWireGuardは正常に動作するとの回答が数人からありました。
これは、最初からそうではありません。 サーバーのDNS名を指すようにWireGuardクライアントを設定することができ、そのDNS名はダイナミックDNSを使用して定期的に更新することができます。 ただし、標準のWireGuardソフトウェアは、起動時に一度だけDNS名を解決するため、サーバーが新しいアドレスにホップした場合は、各クライアントのWireGuardインスタンスを再起動してからDNS名を再検索する必要があります。 WireGuardとIPsecの両方でこのプロセスを自動化するためのさまざまなツールやスクリプトが存在します。 Tailscaleもこの問題を解決していますが、方法は異なります。
では使いやすいのか？
- トレマーが書いています。
- IPsec は本当に使いにくいのか？ベンダーが宿題をきちんとこなし、使いやすいインターフェイスを提供しているかどうかは、明らかに違います。
このセクションでは、トレマー氏は、IPsec の使用はそれほど難しくないと主張し、自分のパブリック IP アドレス、相手のパブリック IP、各サイドで利用可能にしたいサブネット、そして事前に共有された鍵を指定するだけでよいと指摘しています。その後、VPNは "そこにあるすべてのベンダーと互換性がある "としています。
これは意外な主張です。まず第一に、IPsec を設定するために必要な情報はこれだけではありません。重要なことに、IPsec を正しく使用するためには、許可したい暗号スイートを正確に指定する必要があります。これは暗号の専門家でない人には答えの出ない質問です。デフォルトは事実上安全ではなく、クロスプラットフォームでもありません。
暗号スイートの選択は、どのIPsecベンダーと互換性があるかに影響します。あるベンダのデフォルト設定が別のベンダのハードウェアやソフトウェアで動作することはほとんどありません。
第二に、トンネルの両端にパブリックIPアドレスを指定する必要があることを示唆しています。前のセクションで、彼は WireGuard がまさにそれを必要とし、したがって動的な IP では動作しないと誤って主張していたことを考えると、これは不思議なことです。実際には、IPsec と WireGuard の両方とも、よく定義された IP 上の片方の端だけで問題なく動作するので、どちらの場合も、最大でも 1 つのパブリック IP アドレスを設定するだけで済みます。
最後に、彼は両末端で事前共有鍵（PSK）を使用することを提案しています。PSKは最も脆弱な認証方法の1つである（パスワードもPSKの1つである）。特に、一方のノードから盗まれた鍵は、どちらか一方のノードになりすまして、両方のノードからトラフィックを偽造することが可能になります。IPsec と WireGuard は両方とも公開鍵認証を許可しており、これはかなり強力ですが、必須としているのは WireGuard だけです。IPsec の「柔軟性」のセキュリティ上の危険性については、以下で説明します。
- これまでに、OpenBSD マシンへの IPsec トンネルを作成しようとした誰もが、おそらくその話をすることができるでしょう。
ここでの著者は、OpenBSD 上での IPsec の設定が複雑であることを示唆しているようです。私たちのチームは、個人的には OpenBSD 上の IPsec に精通しているわけではありませんが、私たちは、OpenBSD 上の WireGuard の設定が、他のプラットフォームと同様に簡単であることを知っています。
プロトコルの複雑さについて
- 心配なことに、Tremer氏は次のように述べています。
- エンドユーザーはプロトコルの複雑さを心配する必要はありません。もしそれが問題であれば、SIPやH.323、FTPなど、NATにうまく対応できず、何十年も前からあるプロトコルは絶対に排除していたでしょう。
プロトコルの複雑さは許容できるものもあります(決して望ましいものではありませんが)。しかし、セキュリティにおいては、それは致命的なものです。N Ferguson と B. Schneier による 2003 年の論文から。
- 私たちの考えでは、IPsec は安全性を確保するには複雑すぎる。設計は明らかに異なるオプションで多くの異なる状況をサポートしようとしています。結果として得られるシステムは、現在の方法論で分析したり、適切に実装したりすることができる複雑さのレベルをはるかに超えていると強く感じています。したがって、どのIPsecシステムも、高いレベルのセキュリティを提供するという目標を達成することはできません。
その論文は16年以上前のもので、IPsecは複雑さが増しただけです。分析することはほぼ不可能なままです。2020年には、より良いオプションが利用できるようになった今、IPsecの過剰な複雑さがIPsecを陳腐化の危機に瀕していることは十分に理解されています。これらの問題は、IPsecが標準化されてから数十年の間に、IPsecではなくTLSへと強くシフトしてきた理由の一部です。
- Tremer氏も言う。
- ユーザー名/パスワードまたはEAP付きSIMカードを使用したユーザー認証。WireGuardにはそれがありません。
この記述は、コアとなる WireGuard にも当てはまる。ただし、WireGuard はデータプレーンであり、その上に構築された鍵交換メカニズムと一緒に使用することを意図しており、さまざまな状況で使用できる鍵交換メカニズムがいくつかあります。
Tailscale は、そのような鍵交換メカニズムの 1 つを提供します (Oauth2、OIDC、または SAML を使用して、好みの ID プロバイダに接続します)。IPsec の非常に複雑なキーネゴシエーションプロトコルと比較すると、WireGuard のセキュリティを分析して監査し、その上で別のキー交換メカニズムを監査するのがはるかに簡単です。
On Ignoring Real-World Problems - 現実の問題を無視することについて
次に、Tremer氏は、WireGuardの「意見のある」暗号設計を批判しています。
- 使用している暗号をある日から次の日に変更する場合、すべてのラップトップ、電話などで同時にWireGuardソフトウェアをアップグレードする必要があります。
この記述は単に誤りです。いつか、WireGuard は第二の暗号スイートをサポートするようにアップグレードする必要があるでしょう。その場合、ユーザーは他の VPN と同じように、一方の暗号スイートまたは他方の暗号スイート、またはその両方を許可するように、ピアバイピアで設定することができるようになります。
ほとんどのVPN(およびTLS)は、何千もの異なるアルゴリズムの組み合わせを提供しており、そのほとんどは安全ではないか、遅いか、またはその両方を選択することができます。対照的に、仮想的なWireGuardプロトコルv2では、古いものと新しいものの2つのスイートだけを提供することができます。暗号の専門家でなくても設定できることを除けば、何も変わったことはありません。
Cryptography! - 暗号！
Tremer氏は、より多くの暗号化アルゴリズムがIPsecをWireGuardと同様に優れたものにするという主張を続けています。
- ここでは、実質的に同じ暗号化方式がすべてのVPNで利用可能であるという結論になります。したがって、暗号化やデータの完全性に関しては、WireGuardは他のVPNよりも安全性が高いわけでも低いわけでもありません。
表面的には、この主張は真実です: WireGuard で使用されている (唯一の) 暗号化スイートとほぼ同じ IPsec 用の暗号化スイートを組み立てることができます。
しかし、これはいくつかの重要な詳細を省いています。まず第一に、正しい IPsec 暗号スイートを選択して設定する方法を学ばなければなりません。そして第二に、一度その暗号スイートを使用しようとすると、それが事実上すべての VPN ハードウェアやソフトウェアと互換性がないことに気づくでしょう。
皮肉なことに、IPsec 標準は事実上すべての暗号スイートを許可していますが、それらの暗号スイートを強制するものではありません。2つのノードが完全にIPsecに準拠していても、お互いに完全に話ができない場合があります。
WireGuard では、暗号スイートが 1 つしかないので、暗号学の学位を持っていなくても選択することができます。いつの日か、2 つ目の暗号スイートが利用できるようになるでしょう。IPsec とは異なり、2 つの WireGuard 対応ソフトウェアパッケージがお互いに通信できるかどうかを確認するのは簡単です。
Is WireGuard faster than other VPN solutions? - WireGuardは他のVPNソリューションよりも高速ですか?
このセクションで Tremer は、CPU がどのように進化してきたかによって、AES 暗号化はおそらく ChaCha20 よりも高速になるだろうと、いくつかの手垢のついた主張をしている（ベンチマークはない）。テストする特定のプラットフォームと言語を特定しないと、この主張が技術的に正しいかどうかは不明である。
しかし、重要なのは、ほとんどすべてのユースケースでは、IPsec と WireGuard の両方が完全に問題ないということです。使用する対称暗号化 (AES や ChaCha20 など) は、非常に高速な (10 Gbit/sec 以上の) ネットワークを除いては、全く関係ありません。
(一つの例外は、レガシーな VPN コンセントレータのハードウェアで、比較的遅いプロセッサ上に構築されている傾向があり、一度に多くの IPsec ユーザを使用した場合には動作が重くなることがあります。しかし、これは実際には IPsec 自体のせいではありません)。
モバイルプロセッサは、暗号化を行う場合、もちろんデスクトップやサーバープロセッサよりも多少遅くなりますが、通常ははるかに遅いネットワーク上にあります。モバイルでは、対称暗号化は時間の1%程度で、遅いネットワークでは99%の時間がかかると予想してください。
非IPsecおよびWireGuard以外のVPNプラットフォームの中には、TCPを介してトラフィックを転送するものがあります。(ほとんどの「SSL VPN」と「BeyondCorp プロキシ」はこのカテゴリに属します。) TCP 上で VPN トラフィックを転送することは風変わりで、VoIP、ビデオ通話、リモートデスクトップなどのリアルタイムトラフィックで速度低下や遅延を引き起こす可能性があります。しかし、IPsec も WireGuard もこの問題はありません。
もう一つ気をつけなければならないのは、ポイント・ツー・マルチポイントとハブ・アンド・スポークのVPNアーキテクチャです。一般的に、ハブアンドスポークのアーキテクチャでは、余分なホップのために高いレイテンシが発生します。IPsec はもともとポイント・ツー・マルチポイント・アーキテクチャをサポートすることを意図していましたが、いくつかの大きな設計上の欠陥のため、実際にはほとんど試みられていません。
WireGuardは、正しく構成されている場合、ポイントツーマルチポイントモードで安全に動作し、待ち時間を短縮することができます。たとえば、WireGuard対応のラップトップは、1つのデータセンターに接続して他のデータセンターにトンネルを通すのではなく、3つのデータセンターに直接オープン接続することができます。
Issues integrating into Linux - Linuxへの統合の問題
Tremer氏の記事のこの部分は陳腐化しています。彼の記事が書かれて以来、WireGuardはLinuxカーネルに受け入れられ、作者はWireGuardの安定版バージョン1.0をリリースしました。
What does the real world look like? - 現実の世界はどうなっているのでしょうか？
結論から言うと、トレマーは言う。
- 残念なことに、顧客からVPNの設定を手伝ってほしいと頼まれるたびに、彼らが取得している認証情報は古い暗号を使用しています。3DESとMD5の組み合わせは、AES-256とSHA1の組み合わせと同様に一般的な候補です。後者の方が良いとはいえ、私が今でも使いたいと思うものではありません。
Tremer はもちろん、彼自身の顧客の話をしている。それらの顧客は、おそらく何年も前に、時代遅れでますます安全でない暗号スイートを必要とするように設定されたレガシー IPsec VPN サーバと通信するための新しいソフトウェアを設定しようとしているようです。もしそれが必要なことならば、選択肢はありません。レガシーシステムと通信するために利用可能な最高の IPsec ソフトウェアを使用するのです。
長期的な選択肢としては、そもそもなぜレガシーなVPNコンセントレータを必要としているのかを再考することです。WireGuardはオープンソースであり、純粋なソフトウェア仮想マシンで動作し（ハードウェアのロックインやボトルネックを回避）、非常に高速で非常に安全であることが知られている単一の暗号スイートのみをサポートし、その上にレイヤリングしたいどのような鍵交換メカニズムでも動作します。これは、安全な VPN 接続の未来として、ますます広く受け入れられています。