☰

SSL funktioniert unter Windows 10 nicht gegen rutracker.org über PPTP, funktioniert aber mit L2TP

tag-icon • tag-icon windows-10 ssl pptp
SSL funktioniert unter Windows 10 nicht gegen rutracker.org über PPTP, funktioniert aber mit L2TP

Ich habe einen Windows 10-Laptop mit einem eigenartigen Problem, dass kein Browser geöffnet werden kannhttps://rutracker.org/

Es läuft so ab (im Entwicklertool-Modus): Der Browser bestätigt lange Zeit nicht, dass er etwas an die Remote-Verbindung sendet (z. B. meldet Chrome, dass es „abgestürzt“ ist), und dann wird die Anfrage ohne ersichtlichen Grund als fehlgeschlagen aufgeführt. Ich habe es auch mit Firefox und Edge versucht, mit den gleichen Ergebnissen, da sie keine Verbindung herstellen und keine sinnvolle Fehlerbehebung bereitstellen.

Ich habe sogar cURL installiert. Das Ergebnis ist folgendes:

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):

dann bleibt es lange hängen und beschwert sich dann über SSL_ERROR_SYSCALL. Unter Linux sieht es dagegen ganz anders aus:

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

Vielleicht gibt es einen Browser-Build, der reines OpenSSL verwendet und die Windows-SSL-Implementierung vollständig vermeidet? Denn es scheint, dass hier das Problem liegt. Ich habe kürzlich bei Malwarebytes nachgefragt und nichts Besonderes gefunden.

BEARBEITEN: Ich habe festgestellt, dass dies nur passiert, wenn ich über PPTP VPN verbunden bin. Wenn ich auf L2TP umschalte, kann ich die Website plötzlich problemlos öffnen. Was ist hier los?

Antwort1

An der TLS-Bibliothek von Windows ist nichts auszusetzen (und tatsächlich verhält sich curl unter Linux genauso, wenn es mit OpenSSL/1.1.0i kompiliert wird) – es verwendet einfach ein neueres Handshake-Format, das versucht, weniger und größere Nachrichten zu verwenden (und so die Latenz zu verringern), während Ihr curl eine alte Bibliothek verwendet, die noch immer den „SSLv3-kompatiblen“ Modus hat.

Aber das ist nur eines von vielen Dingen, die das gleiche Problem auslösen können. Das eigentliche Problem ist:

  1. Auf dem VPN-Server ist die MTU der virtuellen Netzwerkschnittstelle des „PPTP-Clients“ auf einen relativ niedrigen Wert eingestellt (z. B. 1280 Byte), um den VPN-Overhead und noch mehr zu berücksichtigen.
  2. Während des TLS-Handshakes sendet Ihnen der Rutracker-Server ein IP-Paket, das größer als diese MTU ist.
  3. Der VPN-Server kann das Paket nicht weiterleiten, da es größer als die Ausgabeschnittstelle ist, und gibt ein ICMP-Fehlerpaket „Zu groß“ zurück, das die unterstützte MTU angibt.
  4. Der Rutracker-Webserverignoriertdie ICMP-Nachricht, passt seinen Routen-Cache nicht entsprechend an und sendet Ihnen weiterhin dasselbe große Paket. Beginnen Sie erneut bei Schritt 2.

Diese ICMP-basierte MTU-Aushandlung wird als „Path MTU Discovery“ bezeichnet, und die Situation, in der der Absender den Rat des Empfängers ignoriert, wird als „PMTU Blackhole“ bezeichnet. Vielleicht haben die Administratoren von Rutracker irgendwo gehört, dass die vollständige Blockierung von ICMP die Site irgendwie „sicherer“ macht …

So sieht es aus der Sicht eines Beispiel-VPN-Servers aus (unter Verwendung eines absichtlich falsch konfigurierten OpenVPN) – beachten Sie, wie das große Paket immer wieder abgelehnt wird:

IP 31.220.xy48872 > 195.82.146.214.443: Flags [S], Sequenz 2337162999, Win 29200, Optionen [mss 1358,sackOK,TS val 674971446 ecr 0,nop,wscale 7], Länge 0
IP 195.82.146.214.443 > 31.220.xy48872: Flags [S.], Sequenz 2391406816, Ack 2337163000, Win 14600, Optionen [mss 1460,nop,wscale 8], Länge 0
IP 31.220.xy48872 > 195.82.146.214.443: Flags [.], ack 1, win 229, Länge 0
IP 31.220.xy48872 > 195.82.146.214.443: Flags [P.], Sequenz 1:217, Bestätigung 1, Gewinn 229, Länge 216
IP 195.82.146.214.443 > 31.220.xy48872: Flags [.], ack 217, win 62, Länge 0
IP 195.82.146.214.443 > 31.220.xy48872: Flags [.], Sequenz 1:1359, Bestätigung 217, Gewinn 62, Länge 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy nicht erreichbar – muss fragmentiert werden (MTU 1280), Länge 556
IP 195.82.146.214.443 > 31.220.xy48872: Flags [P.], Sequenz 1359:3242, Ack 217, Win 62, Länge 1883
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy nicht erreichbar – muss fragmentiert werden (MTU 1280), Länge 556
IP 195.82.146.214.443 > 31.220.xy48872: Flags [.], Sequenz 1:1359, Bestätigung 217, Gewinn 62, Länge 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy nicht erreichbar – muss fragmentiert werden (MTU 1280), Länge 556
IP 195.82.146.214.443 > 31.220.xy48872: Flags [.], Sequenz 1:1359, Bestätigung 217, Gewinn 62, Länge 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy nicht erreichbar – muss fragmentiert werden (MTU 1280), Länge 556
IP 195.82.146.214.443 > 31.220.xy48872: Flags [.], Sequenz 1:1359, Bestätigung 217, Gewinn 62, Länge 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy nicht erreichbar – muss fragmentiert werden (MTU 1280), Länge 556
IP 195.82.146.214.443 > 31.220.xy48872: Flags [.], Sequenz 1:1359, Bestätigung 217, Gewinn 62, Länge 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy nicht erreichbar – muss fragmentiert werden (MTU 1280), Länge 556

Das L2TP-VPN ist aus mehreren möglichen Gründen nicht betroffen:

  • Es könnte eine Standard-MTU von 1500 für den Tunnel verwenden und die übergroßen Pakete transparent fragmentieren.
  • es könnte TCP-MSS-Clamping für die Verbindungen durchführen, die es sieht;
  • Es könnte die reduzierte MTU an Ihre VPN-Clientsoftware melden, sodass Ihr Betriebssystem bereits im Voraus weiß, dass es die richtige MSS in seine TCP-Verbindungsanforderungen einfügen muss.

Als Client haben Sie folgende Optionen (je nachdem, was das Betriebssystem unterstützt):

  • Verwenden Sie PPTP-VPNs überhaupt nicht. (Nicht wegen MTU-Problemen – PPTP ist in dieser Hinsicht weder besser noch schlechter als andere VPN-Typen – sondern wegen der Sicherheitsprobleme, die das Protokoll hat. Sowohl die MPPE-Verschlüsselung als auch die MSCHAP-Authentifizierung sind sehr schwach.)
  • Verringern Sie die MTU der VPN-Schnittstelle (z. B. auf 1400 oder 1280) auf dem Client-Betriebssystem. Linux ermöglicht Ihnen dies beispielsweise ip link set ppp0 mtu <bytes>. Ihr System wird den Rutracker-Servern dementsprechend einen niedrigeren TCP-MSS-Wert mitteilen.
  • Aktivieren Sie die TCP-MTU-Prüfung auf dem Client-Betriebssystem. Linux verfügt beispielsweise über sysctl net.ipv4.tcp_mtu_probing=1. Dies funktioniert auch dort, wo ICMP PMTUD dies nicht tut.
  • Konfigurieren Sie den VPN-Clientoderdie Firewall des VPN-Servers, um TCP MSS Clamping durchzuführen. (Dies kann überall entlang des Pfads erfolgen.)
  • Versuchen Sie, die Rutracker-Administratoren davon zu überzeugen, dass sie eine schlechte Entscheidung getroffen haben.

verwandte Informationen