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 peux pas me connecter à pas mal de sites utilisant 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 la même sortie.

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 sais pas si ces informations sont utiles, mais j'ai couru ifconfiget j'ai obtenu les informations suivantes:

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 exécuté 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

Il s'agit d'un FAI japonais et même si je me connecte avec un câble au modem / routeur, je dois ajouter un nom d'utilisateur et un mot de passe, mais avec la connexion "filaire" 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 constaté qu'il s'agissait d'une connexion PPPoE. Après quelques recherches sur Google, j'ai appris que pour créer une connexion PPPoE, je devais créer une connexion DSL et que je pouvais y ajouter un mot de passe et un nom d'utilisateur. J'ai également changé la connexion "filaire" pour ne pas me connecter automatiquement.

J'obtiens le même problème si je me connecte directement au modem.

J'ai essayé de changer le DSL MTU en 500, 1500, 1492 et 1482 mais cela n'a fait aucune différence.

Aussi, pour une raison quelconque, Ubuntu ne prend pas toujours la connexion, je dois parfois redémarrer pour qu'il se connecte.

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 1492. C'est trop élevé et cela provoquera une fragmentation. 1476 est le nombre magique qui fonctionnera avec le plus de sites. Certains sites utilisent différentes implémentations SSL, donc 1480 peut fonctionner, ou même 1488. Pour la compatibilité la PLUS, le MTU du côté WAN de votre périphérique réseau (routeur, modem, etc.) doit être 1476.

Voici quelques choses à essayer:

1. 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'IP). Si cela ne fonctionne pas, essayez de désactiver la prise en charge IPv6 et voyez si cela fait une différence. Pour ce faire, faites un clic droit sur l'icône de mise en réseau près de votre horloge (lorsque vous êtes sur une connexion Ethernet, c'est une paire de flèches, l'une pointant vers le haut, l'autre vers le bas) et en sélectionnant "Modifier les connexions ...". Dans l'onglet "Paramètres IPv4", assurez-vous qu'il est défini sur "Automatique (DHCP)". Si vous souhaitez désactiver IPv6, accédez à son onglet et réglez-le sur "Ignorer".

2. Vérifiez si vous pouvez vous connecter aux sites à l'aide d'autres méthodes. À quoi pingrépond les sites auxquels vous ne pouvez pas vous connecter? Que diriez- traceroutevous d' un (vous devrez peut-être installer traceroute pour l'utiliser, pour info)? Leurs réponses peuvent vous aider à résoudre le problème. S'ils ne peuvent pas accéder aux serveurs de l'URL, cela pourrait être un problème DNS (cependant, 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).

3. Contournez le routeur. Si votre routeur et votre modem sont deux machines différentes, essayez de connecter votre ordinateur directement à votre modem et voyez si cela change quelque chose.

4. Redémarrez votre modem et votre routeur. Parfois, ils sucent juste.

5. Redémarrez votre ordinateur. Parfois, ils sucent juste.

6. Essayez un autre ordinateur. Si vous en avez un, un autre ordinateur fonctionne-t-il là où celui-ci échoue? Sinon, cela pourrait être quelque chose avec votre ordinateur spécifique.

7. Vider le cache de votre ordinateur, les cookies, etc. Parfois, les cookies de mauvaise session, le cache, etc. peuvent interférer avec la connexion à un site (j'ai eu ce problème avec Google il y a quelque temps). Éliminez-les et recommencez à zéro et voyez ce que vous obtenez.

8. Déconnectez toutes les connexions VPN. Le protocole point à point est souvent utilisé pour les VPN (l'interface PPP), et les VPN peuvent interférer avec la connexion aux sites. Assurez-vous que vous n'êtes pas connecté en faisant un clic droit sur l'icône de votre réseau près de votre horloge, en trouvant l'entrée "Connexions VPN" et en vous assurant qu'aucune liste n'est cochée (si vous n'avez pas d'élément de menu "Connexions VPN", alors vous ne ' t en avoir un). S'il y en a une cochée, alors vous y êtes connecté, déconnectez-vous-en.

N'oubliez pas : tout ce que vous faites n'entraînera pas un simple «travail ou échec», tout changement 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 d'homme au milieu. Il usurpait l'ARP de la passerelle, redirigeant ainsi tout le trafic pour passer par cette machine, modifiant les demandes et autres trucs désagréables. La machine fonctionnait sous Windows et s'est révélée infectée par des logiciels malveillants désagréables. 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 trame des réseaux pour lesquels il achemine le trafic n'est pas la même. Pour les connexions DSL utilisant PPPoE / PPPoA, la taille MTU est généralement inférieure aux 1 500 octets côté LAN. De plus, les routeurs entre deux échouent et vous devez activer le serrage TCP MSS sur votre routeur. J'ai toujours eu besoin de définir cela sur la connexion de mon ancien FAI, mais cela résolvait plus que des problèmes liés à SSL. Vérifiez si votre modem / routeur dispose d'une telle option. Considérez cela comme une solution de contournement.
• J'étais dans un réseau exécutant probablement un proxy transparent pour également transmettre 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 de courir curlavec l'option --sslv3. Si cela le résout, alors ça pue.

Trucs généraux à essayer:

• Vérifiez si vous exécutez le dernier firmware sur votre modem / routeur. Sinon, essayez la mise à niveau.

• Capturez le trafic à l'aide de 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.pcap
  

  Si vous obtenez des erreurs de réassemblage ou si le segment précédent est perdu à plusieurs reprises, c'est un signe clair de la perte de paquets causée par une mauvaise taille MTU.
  Cependant, le trafic HTTPS est chiffré et difficile à analyser à partir du trafic réseau par lui-même.

Éditer:

A partir de votre tcpdump la racine de votre problème SSL est clair: TCP Previous segment lost. Le dépannage général du réseau doit s'appliquer ici, mais il peut être en dehors de la portée de votre réseau local et un problème avec votre FAI.

Salut tout le monde, c'est Marcovaleriof d'Italie, récemment, nous avons eu un problème similaire au vôtre: toute notre machine Linux ne pouvait plus se connecter à aucun site Web https alors qu'Android ou Windows Device n'avait aucun problème. Le problème était un désalignement mtu entre notre routeur DSL qui avait une longueur de 1492 mtu et le mtu Linux par défaut qui est 1500. En fait, émettre cette commande en tant que root

ifconfig wlan0 mtu 1492 up

(en anglais cet ensemble La valeur mtu de l'interface nette - wlan0 dans mon cas - jusqu'à 1492 de longueur) a éliminé le problème, merci! J'espère que cela pourrait aider quelqu'un.

Merci pour toute votre aide, le problème est enfin résolu!

J'essayais de limiter le MTU pour voir si cela aiderait et j'ai fini par utiliser pppoeconfpour configurer la connexion PPPoE car il limite le MTU pour moi. J'ai ensuite désactivé la connexion DSL que j'utilisais précédemment.

Pour toute personne rencontrant un problème similaire, vous pouvez essayer cette solution en tapant sudo ppoeconfet en suivant les instructions. Ensuite, vous pouvez vous connecter pon adsl-provideret vous déconnecter avecpoff