Impossible de se connecter à certains sites HTTPS
Je viens d'emménager dans un nouvel appartement et avec une connexion Internet via un routeur et je constate que je ne parviens pas à me connecter à de nombreux sites utilisant le protocole SSL.
Par exemple, essayez de vous connecter à Paypal:
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 donne le même résultat.
Pour certains sites cela fonctionne:
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/
.
.
.
J'utilise Ubuntu 12.04, avec Windows 7 également installé. Ces sites fonctionnent sous Windows :(
Je ne suis pas sûr que cette information soit utile, mais j'ai lancé ifconfig et obtenu les éléments suivants:
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)
J'ai couru PING:
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
Et sans 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 * * *
sans 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 * * *
Le 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
C'est un FAI japonais et même si je me connecte à un modem/routeur avec un câble, je dois ajouter un nom d'utilisateur et un mot de passe, mais avec la connexion "Wired" d'Ubuntu, je ne pouvais pas les ajouter. Mon colocataire m'a dit de créer une connexion OCN mais je ne sais pas si c'est le nom d'un type de réseau ou simplement de la société japonaise ... mais après avoir regardé son ordinateur, nous avons découvert qu'il s'agissait d'un PPPoE lien. Après quelques recherches sur Google, j'ai appris que pour créer une connexion PPPoE, il me fallait créer une connexion DSL et pouvoir y ajouter un mot de passe et un nom d'utilisateur. J'ai également changé la connexion "Wired" pour ne pas se connecter automatiquement.
Je rencontre le même problème si je me connecte directement au modem.
J'ai essayé de changer le MTU DSL en 500, 1500, 1492 et 1482, mais cela n'a pas changé.
Aussi, pour une raison quelconque, Ubuntu ne détecte pas toujours la connexion, je dois parfois la redémarrer pour la connecter.
C'est une vieille question, mais pour ceux qui arrivent ici via Google, cela aidera. Le problème est que la fragmentation sur SSL est mauvaise et rompt le protocole. Si vous utilisez PPPOE, le MTU normal de votre routeur/modem DSL/câble est de 1492. Cela est trop élevé et entraînera une fragmentation. 1476 est le nombre magique qui fonctionnera avec la plupart des sites. Certains sites utilisent des implémentations SSL différentes, donc 1480 peut fonctionner, voire 1488. Pour une compatibilité optimale, le MTU situé sur le côté WAN de votre périphérique réseau (routeur, modem, etc.) doit être 1476.
Voici quelques choses à essayer:
Vérifiez les paramètres de votre carte réseau. Aucune de vos interfaces eth n'affiche les adresses IPv4. Assurez-vous que IPv4 est activé (vous devrez peut-être rétablir votre connexion avec votre routeur pour renouveler l'adresse IP). Si cela ne fonctionne pas, essayez de désactiver le support IPv6 et voyez si cela fait une différence. Pour ce faire, cliquez avec le bouton droit de la souris sur l'icône de mise en réseau située à côté de votre horloge (sur une connexion Ethernet, il s'agit d'une paire de flèches, l'une dirigée vers le haut, l'autre vers le bas), puis sélectionnez "Modifier les connexions ...". Dans l'onglet "Paramètres IPv4", assurez-vous qu'il est réglé sur "Automatique (DHCP)". Si vous voulez désactiver IPv6, allez dans son onglet et réglez-le sur "Ignorer".
Vérifiez si vous pouvez vous connecter aux sites en utilisant d'autres méthodes. Qu'est-ce que
pingrépond avec les sites auxquels vous ne pouvez pas vous connecter? Que diriez-vous d'untraceroute(vous devrez peut-être installer traceroute pour l'utiliser, pour votre information)? Leurs réponses pourraient vous aider à résoudre le problème. S'ils ne peuvent pas accéder aux serveurs de l'URL, il peut s'agir d'un problème de DNS (toutefois, s'ils peuvent accéder aux serveurs de l'URL, mais sont ensuite supprimés, cela peut simplement signifier que ces commandes sont bloquées).Contournez le routeur. Si votre routeur et votre modem sont deux machines différentes, essayez de connecter votre ordinateur directement à votre modem et de voir si cela change quelque chose.
Redémarrez votre modem et votre routeur. Parfois, ils sont vraiment nuls.
Redémarrez votre ordinateur. Parfois, ils sont juste nuls.
Essayez un autre ordinateur. Si vous en avez un, un autre ordinateur fonctionne-t-il lorsque celui-ci échoue? Sinon, cela pourrait être quelque chose avec votre ordinateur spécifique.
Effacez le cache de votre ordinateur, les cookies, etc. Parfois, de mauvaises sessions comme les cookies, le cache, etc. peuvent interférer avec la connexion à un site (ce problème avec Google datait de quelque temps auparavant). Effacez-les et commencez à nouveau et voyez ce que vous obtenez.
Déconnectez toutes les connexions VPN. Le protocole point à point est souvent utilisé pour les réseaux VPN (interface PPP), qui peuvent interférer avec la connexion aux sites. Assurez-vous de ne pas être connecté en cliquant avec le bouton droit de la souris sur l'icône de votre réseau, sur votre horloge. Recherchez l'entrée "Connexions VPN" et assurez-vous qu'aucune liste n'est cochée (si vous n'avez pas d'élément de menu "Connexions VPN", vous ne le ferez pas. t ont un mis en place). S'il y en a une, alors vous y êtes connecté, déconnectez-vous.
Souvenez-vous: Tout ce que vous faites ne donnera pas simplement un "travail ou échec" ( aucune modification dans la réaction du serveur à votre demande nous dira quelque chose. Donc, si vous faites l’une des choses ci-dessus et recevez un nouveau message, n’oubliez pas de mettre à jour votre question.
J'ai vu ce comportement deux fois dans la pratique pour lequel j'ai trouvé les solutions suivantes.
- Un ordinateur du réseau local tentait avec succès une attaque par interception. C'était une parodie d'ARP sur la passerelle, redirigeant ainsi tout le trafic pour passer par cette machine, modifiant les demandes et autres choses désagréables. La machine fonctionnait sous Windows et s’avérait infectée par un malware malveillant. Dès que cette machine a été déconnectée physiquement du réseau, les symptômes ont disparu.
- Un problème MTU sur votre ou une autre passerelle. Dans IPv4, les passerelles sont responsables de la fragmentation et du réassemblage des paquets IP sur le réseau si la taille de la trame des réseaux pour lesquels le trafic de routage est destiné n'est pas la même. Pour les connexions DSL utilisant PPPoE/PPPoA, la taille du MTU est généralement inférieure à 1 500 octets du côté du réseau local. De plus, les routeurs entre les deux échouent et vous devez activer serrage MSS TCP sur votre routeur. Je avait toujours besoin de définir cela sur la connexion de mon précédent fournisseur de services Internet, mais cela ne résolvait pas que des problèmes liés à SSL. Vérifiez si votre modem/routeur dispose d'une telle option. Considérez ceci comme une solution de contournement.
- J'étais dans un réseau exécutant probablement un proxy transparent pour transmettre également le trafic SSL, mais échouant à TLSv1 pour une raison quelconque. La même demande a fonctionné lors de l'utilisation d'une connexion VPN. effrayant
Essayez d'exécutercurlavec l'option--sslv3. Si cela résout le problème, alors ça pue.
Trucs généraux à essayer:
- Vérifiez si vous utilisez le dernier micrologiciel sur votre modem/routeur. Sinon, essayez de mettre à jour.
Capturez le trafic en utilisant
tcpdumpou Whireshark et faites-le analyser (postez-le ici, par exemple).# 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.pcapSi vous obtenez des erreurs de réassemblage ou , le segment précédent a été perdu plusieurs fois , c'est un signe clair de la perte de paquets provoquée par un mauvais MTU Taille.
Cependant, le trafic HTTPS est crypté et difficile à analyser à partir du trafic réseau.
Modifier:
Depuis votre tcpdump, la racine de votre problème SSL est claire: TCP Previous segment lost. Le dépannage général du réseau devrait s'appliquer ici, mais il se peut que cela dépasse le cadre de votre réseau local et pose un problème avec votre FAI.
Bonjour tout le monde ce IS marcovaleriof d'Italie, nous avons récemment eu un problème similaire au vôtre: toute notre machine Linux ne pouvait plus se connecter à aucun site Web https alors que Android ou appareil Windows n'avait pas de problème . Le problème était un désalignement des mtu entre notre routeur DSL qui avait une longueur de 1492 mtu et le mtu par défaut de Linux qui IS 1500. En fait, cette commande a pour racine
ifconfig wlan0 mtu 1492 up
(en anglais cet ensemble La valeur mtu de l'interface réseau - wlan0 dans mon cas - jusqu'à 1492 longueurs) s'est débarrassée du problème, merci! J'espère que cela pourrait aider quelqu'un.