web-dev-qa-db-ja.com

SSLは、PPTPを介したrutracker.orgに対するWindows 10では機能しませんが、L2TPでは機能します

私は、ブラウザが開くことができないという特有の問題を抱えたWindows 10ラップトップを持っています https://rutracker.org/

それはそのようになります（開発者ツールモードの場合）：長い間、ブラウザはリモートに何かを送信したことを認識せず（たとえば、Chromeは「ストール」したと報告します）、リクエストは失敗としてリストされます。明らかな理由。 FirefoxとEdgeも試してみましたが、接続に失敗し、意味のあるデバッグを提供できないという同じ結果が得られました。

CURLもインストールしました。結果は次のとおりです。

curl -k -vvv https://rutracker.org/forum/index.php
* Trying 195.82.146.214...
* TCP_NODELAY set
* Connected to rutracker.org (195.82.146.214) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):

その後、長時間ハングし、SSL_ERROR_SYSCALLのエラーが発生します。対照的に、Linuxではまったく異なって見えます。

curl -k -vvv https://rutracker.org/forum/index.php
* Hostname was NOT found in DNS cache
*   Trying 195.82.146.214...
* Connected to rutracker.org (195.82.146.214) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
*        subject: CN=rutracker.org
*        start date: 2018-07-20 04:13:49 GMT
*        expire date: 2018-10-18 04:13:49 GMT
*        issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*        SSL certificate verify ok.
> GET /forum/index.php HTTP/1.1
> User-Agent: curl/7.38.0
> Host: rutracker.org
> Accept: */*
> 
< HTTP/1.1 200 OK

たぶん、純粋なOpenSSLを使用するブラウザービルドがあり、Windows SSLの実装を完全に回避しますか？ここで問題があるようですから。最近Malwarebytesで確認しましたが、特に何も見つかりませんでした。

[〜＃〜] edit [〜＃〜]：PPTP VPNで接続している場合にのみ発生することを確認しました。 L2TPに切り替えると、突然問題なくWebサイトを開くことができます。ここで何が起きてるの？

windows-10sslpptp
1
alamar

WindowsのTLSライブラリには何の問題もありません（実際、Linuxでのcurlは、OpenSSL/1.1.0iに対してコンパイルした場合と同じように動作します）。新しいハンドシェイク形式を使用して、より少ない、より大きなメッセージを使用しようとします（遅延を減らします）。 curlは、まだ「SSLv3互換」モードの古いライブラリを使用しています。

しかし、それは同じ問題を引き起こす可能性のある多くのことの1つにすぎません。本当の問題は次のとおりです。

  1. VPNサーバーでは、仮想「PPTPクライアント」ネットワークインターフェイスのMTUが比較的低い値（1280バイトなど）に設定されています。これは、VPNのオーバーヘッドとその一部を考慮したものです。
  2. TLSハンドシェイク中に、RutrackerサーバーはこのMTUよりも大きいIPパケットを送信します。
  3. VPNサーバーは、出力インターフェイスよりも大きいためパケットを転送できず、サポートされているMTUを示すICMP「TooLarge」エラーパケットを返します。
  4. Rutracker Webサーバーignores ICMPメッセージは、それに応じてルートキャッシュを調整せず、同じ大きなパケットを送信し続けます。手順2からやり直します。

このICMPベースのMTUネゴシエーションは「パスMTUディスカバリー」と呼ばれ、送信者が受信者のアドバイスを無視する状況は「PMTUブラックホール」と呼ばれます。おそらく、Rutrackerの管理者は、ICMPを完全にブロックすると、サイトが何らかの形で「より安全」になるとどこかで聞いたのでしょう...

VPNサーバーの例から見た場合の外観は次のとおりです（意図的に誤って構成されたOpenVPNを使用）–大きなパケットが何度も拒否されていることに注意してください。

 IP 31.220.xy48872> 195.82.146.214.443：フラグ[S]、seq 2337162999、win 29200、オプション[mss 1358、sackOK、TS val 674971446 ecr 0、nop、wscale 7]、長さ0 
 IP 195.82.146.214.443> 31.220.xy48872：フラグ[S。]、seq 2391406816、ack 2337163000、win 14600、オプション[mss 1460、nop、wscale 8]、長さ0 
 IP 31.220.xy48872> 195.82.146.214.443：フラグ[。]、ack 1、win 229、長さ0 
 IP 31.220.xy48872> 195.82.146.214.443：フラグ[P。]、seq 1： 217、ack 1、win 229、長さ216 
 IP 195.82.146.214.443> 31.220.xy48872：フラグ[。]、ack 217、win 62、長さ0 
 IP195.82.146.214。 443> 31.220.xy48872：フラグ[。]、seq 1：1359、ack 217、win 62、長さ1358 
 IP 31.220.xy> 195.82.146.214：ICMP 31.220.xyに到達できません-フラグを立てる必要があります（mtu 1280）、長さ556 
 IP 195.82.146.214.443> 31.220.xy48872：フラグ[P。]、seq 1359：3242、ack 217、win 62、長さ1883 
 IP 31.220.xy > 195.82.146.214：ICMP 31.220.xyに到達できません-フラグを立てる必要があります（mtu 1280）、長さ556 
 I P 195.82.146.214.443> 31.220.xy48872：フラグ[。]、seq 1：1359、ack 217、win 62、length 1358 
 IP 31.220.xy> 195.82.146.214：ICMP31.220.xy到達不能-フラグを立てる必要がある（mtu 1280）、長さ556 
 IP 195.82.146.214.443> 31.220.xy48872：フラグ[。]、seq 1：1359、ack 217、win 62、長さ1358 
 IP 31.220.xy> 195.82.146.214：ICMP 31.220.xyに到達できません-フラグを立てる必要があります（mtu 1280）、長さ556 
 IP 195.82.146.214.443> 31.220.xy48872：フラグ[。]、seq 1： 1359、ack 217、win 62、長さ1358 
 IP 31.220.xy> 195.82.146.214：ICMP 31.220.xyに到達できません-フラグを立てる必要があります（mtu 1280）、長さ556 
 IP195.82.146.214。 443> 31.220.xy48872：フラグ[。]、seq 1：1359、ack 217、win 62、長さ1358 
 IP 31.220.xy> 195.82.146.214：ICMP 31.220.xyに到達できません-フラグを立てる必要があります（mtu 1280）、長さ556

L2TP VPNは、いくつかの理由で影響を受けません。

  • トンネルにデフォルトの1500MTUを使用し、特大のパケットを透過的にフラグメント化できます。
  • 表示された接続に対してTCP MSSクランプを実行できます。
  • 削減されたMTUをVPNクライアントソフトウェアに報告して、OSがTCP接続要求に適切なMSSを配置することを事前に認識しているようにすることができます。

クライアントとしてのオプションは次のとおりです（OSがサポートするものによって異なります）。

  • PPTP VPNはまったく使用しないでください。（MTUの問題によるものではありません– PPTPは、その点で他のVPNタイプよりも良くも悪くもありません–むしろプロトコルにあるセキュリティの問題のため。MPPE暗号化とMSCHAP認証の両方が非常に弱いです。）
  • クライアントOSでVPNインターフェイスのMTUを下げます（例：1400または1280）。たとえば、Linuxではip link set ppp0 mtu <bytes>。したがって、システムはより低いTCP MSS値をRutrackerサーバーにアドバタイズします。
  • クライアントOSでTCP MTUプローブを有効にします。たとえば、Linuxにはsysctl net.ipv4.tcp_mtu_probing=1。これは、ICMPPMTUDが機能しない場合でも機能します。
  • VPNクライアントのまたはVPNサーバーのファイアウォールを構成してTCP MSSクランプを実行します（これは、道。）
  • Rutrackerの管理者に悪い決断をしたことを納得させてください。
1
user1686