web-dev-qa-db-ja.com

VPNサービスがTLSを使用しないのはなぜですか？

企業環境では、セキュリティ検査官はフィルターとファイアウォールを使用して、セキュリティ目的でVPN接続をブロックします。

VPNトラフィックは区別可能であり、それがopenVPNが中国のグレートファイアウォール上で機能しない理由でもあります。では、VPNチャネルがTLSを使用しないのはなぜですか。ほとんどのトラフィッククロスフィルターは、フィルターが許可する必要があるHTTPSであるため、VPNサーバーに属するトラフィックを予測することは不可能になります。

tlsvpn
10
defalt

理解すべきことがいくつかあります。

1つ目は、ほとんどのVPNツールは本来、安全ではなく、NATされている可能性があるか、ファイアウォールで保護されているが、VPNに積極的に敵対しないネットワークを介してプライベート接続を提供するように設計されていたことです。

2つ目は、従来のTLSがTCPのラッパーであることです。 TCPは、「ヘッドオブラインブロッキング」の影響を受けるため、VPNには適していません。1つのパケットが失われると、正常に再送信されるまで、その背後にあるすべてのデータがブロックされます。これにより、 VPNをTCPで実行する場合の大きな問題、TCP高速再送信があるため、今ではそれほど問題ではありませんが、それでも理想的とは言えません。

3つ目は、ディープパケットインスペクションはかなり新しいことです。正規のTLSトラフィックを無害に通過させるが、ポート443で他のトラフィックを通過させないネットワークも例外ではありません。

OpenvpnにはTCPオプションがありますが、これは基本的にUDPで実行するように設計されています。鍵交換にTLSを使用しますが、その目的のために明示的に設計されたシステムを使用して実際のネットワークパケットを暗号化します。

https://openvpn.net/index.php/open-source/documentation/security-overview.html

誰かもDTLS（TLS over UDP）について何か言うべきです

DTLSはかなり新しいプロトコルです。 VPNソリューションを上に構築できなかった、またはできなかった理由はわかりませんが、VPNソフトウェアベンダーは特にソフトウェアを再設計する気になっていないと思います。

いずれにしても、質問で説明されているシナリオには役立ちません。

19
Peter Green

ショートバージョン：

  • VPNプロトコルは、TLSが提供しないカプセル化を提供する必要があります
  • もちろん、VPNをTLSでトンネリングして同じ効果を得ることができます。

ロングバージョン：

Virtual Private Networkという名前は、あなたの質問に対する答えを示唆しています。真のVPNプロトコルはネットワークをエミュレートします。これは、複数のトラフィックタイプとポートを1つのチャネルで同時にルーティングする機能を意味します。そのため、IPSecなどのVPNプロトコルでは、TCPカプセル化されたパケットESP他のカプセル化されたパケットTCPパケット（参照 SSHとIPsecの違いは何ですか？ ）

デフォルトでは、TLSはこの機能を提供しません。 TLSはバイトを受け取り、それらを暗号化し、それを復号化できる受信者に転送します。それでおしまい;それ以外のすべてのことは、アプリケーションで行う必要があります。 HTTPSでは、WebサーバーとクライアントがTLSチャネルを介してHTTPデータバイトを交換します。 IMAPSでは、メールサーバーとクライアントがTLSチャネルを介してIMAPデータバイトを交換します。

TLSを介した一般的な「ネットワーク」接続を実現するには、両端でカプセル化とカプセル化解除を実行できるクライアントとサーバーが必要です。あなたはそれを無料で手に入れません。

これは、TLSを介して実行するVPNを使用できないと言っているのではありません。それを行う多くの製品があります。チェックポイントのようなメインラインベンダーでさえ、IPSecとTLSベースのVPNの両方をサポートしています。場合によっては、TLSは単にIPSecデータグラムをカプセル化しているため、実際の "N"はIPSecを経由しますが、TLSはインターネット経由でそれを取得します。

通信のパターンに基づいてVPNにTLS接続が使用されている場合、高度な攻撃者が推測できる場合があることに注意してください。運用セキュリティには、ビットを暗号化する以上のものがあります！

18
gowenfawr

多くのVPNプロトコル do はTLSを使用します。特に、ほとんどすべての最新のクライアントサーバーVPN（たとえば、ラップトップをリモートで企業ネットワークに接続するために使用される）は、プライマリまたはフォールバックトランスポートとしてTLSをサポートしています。

私はTLS/SSLベースのVPNの有名なオープンソースクライアント openconnect の寄稿者です。 GlobalProtect VPNプロトコル（TLS + ESP）をほぼ完全に自分でリバースエンジニアリングしました。かなり明確なパターンと設計のトレードオフに気づくのに十分なVPNプロトコルを詳細に調査しました。

VPN認証とトランスポートのためのTLSの利点：

  • 堅牢性。 TLSベースのVPNトラフィックは、パケットの構造と暗号化されたコンテンツの点で「通常の」HTTPSトラフィックと区別できません。ただし、パケットのタイミングとサイズ、接続の継続時間は、「通常の」ブラウザトラフィック以外のものを伝送していることを示しています。 HTTPSの普遍性は、TLSベースのVPNがほとんどすべてのファイアウォールとミドルボックスを通過できることを意味します。トラフィック分析を行う本当に決定された検閲者、またはDNSまたはIPによってVPNエンドポイントをブラックリストに登録する場合のみ、それをブロックできます。
  • 強力なセキュリティ保証：最新のTLSv1.2（まもなく1.3）は、安全な通信のための非常に適切に設計され、慎重に分析され、徐々に成熟したプロトコルです。多くのライブラリは、誤用をかなり難しくする方法でそれをラップします。 TLSベースのVPNを使用している場合、ゲートウェイへの接続には最新の暗号（たとえば、古代1DESではない）とゲートウェイのx509公開鍵証明書の検証が使用され、中間者攻撃を制限することが期待できます。 TLSの実装を台無しにしてセキュリティを大幅に破壊することは可能ですが、比較的高品質のライブラリの標準化により、トリッキーなビットのほとんどを行います。 「カスタム」プロトコルに基づく安全でないVPNを作成する方がはるかに簡単です。

VPNのTLSの欠点 transport と比較した場合 [〜＃〜] esp [〜＃〜] （IPSECベースのVPNの通常のトランスポート層）：

  • TLSは通常、TCP上で実行されます。これは、基になるネットワーク条件が混雑または損失しているトンネルトランスポートとしては不十分です。 特にTCP-over-TCPの場合 。
  • さいわい、 [〜＃〜] dtls [〜＃〜] （ "datagram TLS"）はこれを軽減できます。 AnyConnect/openconnect VPNプロトコルや、WebRTCなどのリアルタイム通信プロトコルで最もよく使用されています。
  • 最近のほとんどのオペレーティングシステムでは、IPSECおよびESPのカーネルサポートが最適化されています。これにより、ESP reallyefficient and over-overhead for the gateways and firewalls and end-client systems、when正しく実装された場合、TLSは通常ユーザースペースに実装されます。基になるTCPストリームの複雑さと組み合わせると、効率が低下します。
  • （同様に効率的なカーネル内の[〜＃〜] d [〜＃〜] TLSの実装は可能ですが、私は主流のオペレーティングシステムでは何も知りません。）

…VPNの認証/設定にTLSを使用する限り？私は基本的に、標準化されたプロトコルが欠如していることを除いて、そこには実際の欠点はありません。

TLSは [〜＃〜] isakmp [〜＃〜] （IPSECの認証/鍵交換コンポーネント）よりも柔軟で、広く実装されており、デバッグが容易です。 GlobalProtectを含むいくつかの最新の企業VPNプロトコルは認証と鍵交換にTLSを使用しますが、次にデータ転送にESPを使用します（ただし、必要に応じてTLSにフォールバックできます）。私の経験では、これはかなり効果的で効率的な組み合わせです。

6
Dan Lenski