Es kann keine Verbindung zu bestimmten HTTPS-Sites hergestellt werden

Ich bin gerade in eine neue Wohnung umgezogen und habe eine Internetverbindung über einen Router. Ich habe festgestellt, dass ich keine Verbindung zu einigen Sites herstellen kann, die SSL verwenden.

Versuchen Sie beispielsweise, eine Verbindung zu PayPal herzustellen:

curl -v https://paypal.com
* About to connect() to paypal.com port 443 (#0)
*   Trying 66.211.169.3... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to paypal.com:443 
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to paypal.com:443 

curl -v -ssl https://paypal.com gibt die gleiche Ausgabe.

Für einige Sites funktioniert es:

curl -v https://www.google.com
* About to connect() to www.google.com port 443 (#0)
*   Trying 74.125.235.112... connected
* 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 ECDHE-RSA-RC4-SHA
* Server certificate:
*    subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=www.google.com
*    start date: 2011-10-26 00:00:00 GMT
*    expire date: 2013-09-30 23:59:59 GMT
*    common name: www.google.com (matched)
*    issuer: C=ZA; O=Thawte Consulting (Pty) Ltd.; CN=Thawte SGC CA
*    SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: www.google.com
> Accept: */*
> 
< HTTP/1.1 302 Found
< Location: https://www.google.co.jp/
  .
  .
  .

Ich verwende Ubuntu 12.04, wobei auch Windows 7 installiert ist. Diese Seiten funktionieren unter Windows :(

Ich bin mir nicht sicher, ob diese Informationen helfen, aber ich bin gelaufen ifconfigund habe Folgendes erhalten:

eth0      Link encap:Ethernet  HWaddr 1c:c1:de:bc:e2:4f  
          inet6 addr: 2408:c3:7fff:991:686b:8d18:81b3:8dd1/64 Scope:Global
          inet6 addr: 2408:c3:7fff:991:1ec1:deff:febc:e24f/64 Scope:Global
          inet6 addr: fe80::1ec1:deff:febc:e24f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:87075 errors:0 dropped:0 overruns:0 frame:0
          TX packets:54522 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:78167937 (78.1 MB)  TX bytes:10016891 (10.0 MB)
          Interrupt:46 Base address:0x4000 

eth1      Link encap:Ethernet  HWaddr ac:81:12:0d:93:80  
          inet6 addr: fe80::ae81:12ff:fe0d:9380/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:498
          TX packets:0 errors:26 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:17 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:630 errors:0 dropped:0 overruns:0 frame:0
          TX packets:630 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:39592 (39.5 KB)  TX bytes:39592 (39.5 KB)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:180.57.228.200  P-t-P:118.23.8.175  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:39631 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22391 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:43462054 (43.4 MB)  TX bytes:2834628 (2.8 MB)

Ich habe PING ausgeführt:

ping www.paypal.com
PING e6166.b.akamaiedge.net (184.31.66.234) 56(84) bytes of data.
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=1 ttl=54 time=15.3 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=2 ttl=54 time=15.0 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=3 ttl=54 time=15.2 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=4 ttl=54 time=17.2 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=5 ttl=54 time=16.6 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=6 ttl=54 time=16.7 ms
64 bytes from a184-31-66-234.deploy.akamaitechnologies.com (184.31.66.234): icmp_req=7 ttl=54 time=14.8 ms
^C
--- e6166.b.akamaiedge.net ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6009ms
rtt min/avg/max/mdev = 14.878/15.890/17.214/0.901 ms

Und ohne www:

ping paypal.com
PING paypal.com (66.211.169.66) 56(84) bytes of data.
^C
--- paypal.com ping statistics ---
303 packets transmitted, 0 received, 100% packet loss, time 302265ms

TRACEROUTE:

traceroute www.paypal.com
traceroute to www.paypal.com (184.31.66.234), 30 hops max, 60 byte packets
 1  118.23.8.175 (118.23.8.175)  8.424 ms  8.404 ms  8.540 ms
 2  118.23.10.121 (118.23.10.121)  8.212 ms  8.189 ms  8.162 ms
 3  122.1.164.213 (122.1.164.213)  9.405 ms  11.359 ms  13.469 ms
 4  60.37.55.165 (60.37.55.165)  8.049 ms  8.072 ms  8.040 ms
 5  118.23.168.89 (118.23.168.89)  8.574 ms  8.549 ms  8.558 ms
 6  210.163.230.238 (210.163.230.238)  8.667 ms  7.605 ms  7.545 ms
 7  xe-4-0-0.a21.osakjp01.jp.ra.gin.ntt.net (61.213.169.218)  18.255 ms  18.232 ms xe-3-0-0.a21.osakjp01.jp.ra.gin.ntt.net (61.213.162.206)  19.042 ms
 8  * * *
 9  * * *
   .
   .
   .
29  * * *
30  * * *

ohne www:

traceroute paypal.com
traceroute to paypal.com (66.211.169.66), 30 hops max, 60 byte packets
 1  118.23.8.175 (118.23.8.175)  5.607 ms  5.674 ms  5.875 ms
 2  118.23.10.121 (118.23.10.121)  5.468 ms  5.453 ms  5.576 ms
 3  122.1.164.213 (122.1.164.213)  7.595 ms  10.062 ms  11.660 ms
 4  60.37.55.165 (60.37.55.165)  5.684 ms  5.660 ms  5.635 ms
 5  60.37.27.90 (60.37.27.90)  5.960 ms  5.924 ms  5.898 ms
 6  ae-11.r20.tokyjp01.jp.bb.gin.ntt.net (129.250.12.197)  86.468 ms  30.960 ms  30.899 ms
 7  as-1.r20.sttlwa01.us.bb.gin.ntt.net (129.250.4.189)  161.185 ms  144.343 ms  132.410 ms
 8  ae-1.r05.sttlwa01.us.bb.gin.ntt.net (129.250.5.47)  139.008 ms  127.377 ms  139.050 ms
 9  xe-0.sprint.sttlwa01.us.bb.gin.ntt.net (129.250.9.190)  116.006 ms  104.306 ms  115.954 ms
10  144.232.1.153 (144.232.1.153)  141.046 ms  129.870 ms  140.991 ms
11  sl-crs2-sj-0-5-2-0.sprintlink.net (144.232.18.204)  131.271 ms  131.248 ms  142.544 ms
12  sl-st31-sj-0-15-0-0.sprintlink.net (144.232.8.151)  129.543 ms  141.575 ms  141.066 ms
13  * * *
14  * * *
    .
    .
    .
29  * * *
30  * * *

Der tcpdump:

1   0.000000    114.178.88.59   66.211.169.66   TCP 76  37374 > https [SYN] Seq=0 Win=14520 Len=0 MSS=1452 SACK_PERM=1 TSval=68855 TSecr=0 WS=64
2   0.136291    66.211.169.66   114.178.88.59   TCP 80  https > 37374 [SYN, ACK] Seq=0 Ack=1 Win=4356 Len=0 MSS=1460 WS=1 TSval=3608913175 TSecr=68855 SACK_PERM=1
3   0.136322    114.178.88.59   66.211.169.66   TCP 68  37374 > https [ACK] Seq=1 Ack=1 Win=14528 Len=0 TSval=68889 TSecr=3608913175
4   0.137409    114.178.88.59   66.211.169.66   SSL 309 Client Hello
5   0.274446    66.211.169.66   114.178.88.59   SSL 95  [TCP Previous segment lost] Continuation Data
6   0.274469    114.178.88.59   66.211.169.66   TCP 80  [TCP Dup ACK 4#1] 37374 > https [ACK] Seq=242 Ack=1 Win=14528 Len=0 TSval=68923 TSecr=3608913175 SLE=2881 SRE=2908
7   7.117833    91.189.89.76    114.178.88.59   TLSv1   142 Application Data, Application Data
8   7.118823    114.178.88.59   91.189.89.76    TLSv1   216 Application Data, Application Data, Application Data, Application Data
9   7.393725    91.189.89.76    114.178.88.59   TCP 68  https > 41264 [ACK] Seq=75 Ack=149 Win=146 Len=0 TSval=875420654 TSecr=70634
10  60.301444   66.211.169.66   114.178.88.59   TCP 56  https > 37374 [RST, ACK] Seq=2908 Ack=242 Win=4597 Len=0

Dies ist ein japanischer ISP, und obwohl ich mit einem Kabel eine Verbindung zum Modem / Router herstelle, muss ich einen Benutzernamen und ein Passwort hinzufügen, aber mit Ubuntus "Wired" -Verbindung konnte ich diese nicht hinzufügen. Meine Mitbewohnerin sagte mir, ich solle eine OCN-Verbindung herstellen, aber ich bin mir nicht sicher, ob das ein Name für eine Art Netzwerk oder nur für die japanische Firma ist. Als wir ihren Computer betrachteten, stellten wir fest, dass es sich um eine PPPoE-Verbindung handelt. Nach einigem googeln habe ich erfahren, dass ich zum Herstellen einer PPPoE-Verbindung eine DSL-Verbindung herstellen muss und dass ich ein Passwort und einen Benutzernamen hinzufügen kann. Ich habe auch die "Wired" -Verbindung so geändert, dass sie nicht automatisch hergestellt wird.

Ich bekomme das gleiche Problem, wenn ich mich direkt mit dem Modem verbinde.

Ich habe versucht, die DSL-MTU auf 500, 1500, 1492 und 1482 zu ändern, aber es hat keinen Unterschied gemacht.

Auch aus irgendeinem Grund nimmt Ubuntu die Verbindung nicht immer auf, ich muss manchmal neu starten, damit es eine Verbindung herstellt.

Dies ist eine alte Frage, aber für diejenigen, die über Google hierher kommen, wird dies helfen. Das Problem ist, dass die Fragmentierung bei SSL fehlerhaft ist und das Protokoll bricht. Wenn Sie PPPOE verwenden, ist die normale MTU in Ihrem Router / DSL / Kabelmodem 1492. Dies ist zu hoch und führt zu einer Fragmentierung. 1476 ist die magische Zahl, die auf den meisten Websites funktioniert. Einige Standorte verwenden andere SSL-Implementierungen, sodass 1480 möglicherweise funktioniert oder sogar 1488. Für die MOST-Kompatibilität sollte die MTU auf der WAN-Seite Ihres Netzwerkgeräts (Router, Modem usw.) 1476 sein.

Hier sind ein paar Dinge, die Sie ausprobieren sollten:

1. Überprüfen Sie die Einstellungen Ihrer Netzwerkkarte. Keine Ihrer eth-Schnittstellen zeigt IPv4-Adressen an. Stellen Sie sicher, dass IPv4 aktiviert ist (möglicherweise müssen Sie die Verbindung zu Ihrem Router wiederherstellen, um die IP zu erneuern). Wenn dies nicht funktioniert, deaktivieren Sie die IPv6-Unterstützung und prüfen Sie, ob dies einen Unterschied macht. Klicken Sie dazu mit der rechten Maustaste auf das Netzwerksymbol neben Ihrer Uhr (bei einer Ethernet-Verbindung sind es zwei Pfeile, von denen einer nach oben und der andere nach unten zeigt) und wählen Sie "Verbindungen bearbeiten ...". Stellen Sie auf der Registerkarte "IPv4-Einstellungen" sicher, dass "Automatisch (DHCP)" eingestellt ist. Wenn Sie IPv6 deaktivieren möchten, wechseln Sie zu seiner Registerkarte und stellen Sie "Ignorieren" ein.

2. Überprüfen Sie, ob Sie mit anderen Methoden eine Verbindung zu den Sites herstellen können. Womit pingreagieren Sie auf Websites, zu denen Sie keine Verbindung herstellen können? Wie wäre es mit einem traceroute(möglicherweise müssen Sie Traceroute installieren, um es zu verwenden, FYI)? Ihre Antworten helfen Ihnen möglicherweise bei der Behebung des Problems. Wenn sie nicht auf die Server der URL zugreifen können, liegt möglicherweise ein DNS-Problem vor (wenn sie jedoch auf die Server der URL zugreifen können, diese jedoch gelöscht werden, bedeutet dies möglicherweise nur, dass diese Befehle blockiert sind).

3. Umgehen Sie den Router. Wenn Ihr Router und Ihr Modem zwei verschiedene Computer sind, schließen Sie Ihren Computer direkt an Ihr Modem an und prüfen Sie, ob sich dadurch etwas ändert.

4. Starten Sie Ihr Modem und Ihren Router neu. Manchmal saugen sie einfach.

5. Starte deinen Computer neu. Manchmal saugen sie einfach.

6. Probieren Sie einen anderen Computer aus. Wenn Sie einen haben, funktioniert ein anderer Computer, bei dem dieser ausfällt? Wenn nicht, könnte es etwas mit Ihrem spezifischen Computer sein.

7. Leeren Sie den Cache Ihres Computers, Cookies usw. Manchmal können Cookies, Cache usw. für fehlerhafte Sitzungen die Verbindung zu einer Website beeinträchtigen (ich hatte dieses Problem vor einiger Zeit bei Google). Räumen Sie sie auf und fangen Sie neu an und sehen Sie, was Sie bekommen.

8. Trennen Sie alle VPN-Verbindungen. Das Punkt-zu-Punkt-Protokoll wird häufig für VPN (die PPP-Schnittstelle) verwendet, und VPNs können die Verbindung zu Standorten stören. Stellen Sie sicher, dass Sie keine Verbindung hergestellt haben, indem Sie mit der rechten Maustaste auf Ihr Netzwerksymbol klicken, den Eintrag "VPN-Verbindungen" suchen und sicherstellen, dass keine Liste aktiviert ist. t haben eine Einstellung). Wenn ein Häkchen vorhanden ist, ist die Verbindung hergestellt. Trennen Sie die Verbindung.

Denken Sie daran: Nicht alles, was Sie tun, führt zu einem einfachen "Work or Fail". Jede Änderung der Reaktion des Servers auf Ihre Anfrage wird uns etwas mitteilen. Vergessen Sie also nicht, Ihre Frage zu aktualisieren, wenn Sie eine der oben genannten Aktionen ausführen und eine neue Nachricht erhalten.

Ich habe dieses Verhalten zweimal in der Praxis gesehen, für die ich die folgenden Lösungen gefunden habe.

• Ein Computer im lokalen Netzwerk versuchte erfolgreich einen Man-in-the-Middle-Angriff. Es war ARP-Spoofing des Gateways, wodurch der gesamte Datenverkehr umgeleitet wurde, um diesen Computer zu durchlaufen und Anforderungen und andere unangenehme Dinge zu ändern. Auf dem Computer wurde Windows ausgeführt und es wurde festgestellt, dass er mit böser Malware infiziert war. Sobald dieser Computer physisch vom Netzwerk getrennt wurde, verschwanden die Symptome.
• Ein MTU-Problem auf Ihrem oder einem anderen Gateway. In IPv4-Gateways werden IP-Pakete im Netzwerk fragmentiert und neu zusammengestellt, wenn die Frame-Größe des Netzwerks, für das der Routing-Verkehr ausgeführt wird, nicht identisch ist. Bei DSL-Verbindungen mit PPPoE / PPPoA ist die MTU-Größe normalerweise kleiner als die 1500 Byte auf der LAN-Seite. Auch Router dazwischen fallen aus und Sie müssen TCP MSS Clamping auf Ihrem Router aktivieren . Ich musste dies immer für die Verbindung meines vorherigen ISP festlegen, aber es löste nicht nur SSL-bezogene Probleme. Prüfen Sie, ob Ihr Modem / Router eine solche Option hat. Betrachten Sie dies als Problemumgehung.
• Ich war in einem Netzwerk, in dem wahrscheinlich ein transparenter Proxy ausgeführt wurde, um auch SSL-Datenverkehr weiterzuleiten, der jedoch aus irgendeinem Grund bei TLSv1 fehlschlug. Dieselbe Anfrage funktionierte bei Verwendung einer VPN-Verbindung. beängstigend
  Versuchen Sie curlmit der Option ausgeführt --sslv3. Wenn das das Problem löst, stinkt es.

Allgemeine Dinge zum Ausprobieren:

• Überprüfen Sie, ob auf Ihrem Modem / Router die neueste Firmware installiert ist. Wenn nicht, versuchen Sie ein Upgrade.

• Erfassen Sie den Verkehr mit tcpdumpoder Whireshark und lassen Sie ihn analysieren (zum Beispiel hier posten).

    # 1. start the dump
  $ sudo tcpdump -w httpstrafficdump.pcap -i eth0 -s 0 port 443
    # 2. open a new terminal window and do your HTTPS request there (curl/browser)
    # 3. end tcpdump (Ctrl+C)
    # 4. open the file in wireshark
  $ wireshark httpstrafficdump.pcap
  

  Wenn beim erneuten Zusammenbau Fehler auftreten oder das vorherige Segment wiederholt verloren geht , ist dies ein deutliches Zeichen für den Paketverlust, der durch eine falsche MTU-Größe verursacht wird.
  HTTPS-Verkehr ist jedoch verschlüsselt und kann nur schwer anhand des Netzwerkverkehrs selbst analysiert werden.

Bearbeiten:

Von Ihrem tcpdump die Wurzel Ihrer SSL Problem ist klar: TCP Previous segment lost. Hier sollte die allgemeine Problembehandlung für das Netzwerk gelten, möglicherweise liegt sie jedoch außerhalb des Bereichs Ihres lokalen Netzwerks und es liegt ein Problem mit Ihrem Internetdienstanbieter vor.

Hallo allerseits, das ist Marcovaleriof aus Italien. Vor kurzem hatten wir ein ähnliches Problem wie Sie: Alle unsere Linux-Rechner konnten keine Verbindung mehr zu einer https-Website herstellen, während Android- oder Windows-Geräte keine Probleme hatten. Das Problem war eine MTU-Abweichung zwischen unserem DSL-Router mit einer MTU-Länge von 1492 und dem standardmäßigen Linux-MTU-Wert von 1500. Tatsächlich wurde dieser Befehl als Root ausgegeben

ifconfig wlan0 mtu 1492 up

(in englischer Sprache dieses Set Der MTU-Wert der Netzschnittstelle - wlan0 in meinem Fall - auf 1492 Länge) hat das Problem beseitigt, danke! Hoffe das könnte jemandem helfen.

Vielen Dank für all Ihre Hilfe, das Problem ist endlich behoben!

Ich habe versucht, die MTU einzuschränken, um zu sehen, ob dies hilfreich ist, und habe letztendlich verwendet pppoeconf, um die PPPoE-Verbindung einzurichten, da dies die MTU für mich einschränkt. Ich habe dann die DSL-Verbindung deaktiviert, die ich zuvor verwendet habe.

Wenn Sie ein ähnliches Problem haben, können Sie diese Lösung ausprobieren, indem Sie sudo ppoeconfdie Anweisungen eingeben und befolgen. Dann können Sie mit verbinden pon adsl-providerund mit trennenpoff