No se puede conectar a ciertos sitios HTTPS

Me acabo de mudar a un nuevo apartamento y con conexión a Internet a través de un enrutador y descubro que no puedo conectarme a varios sitios que usan SSL.

Por ejemplo, intentando conectarse a 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 da el mismo resultado.

Para algunos sitios funciona:

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/
  .
  .
  .

Estoy usando Ubuntu 12.04, con Windows 7 instalado también. Estos sitios funcionan en Windows :(

No estoy seguro si esta información ayuda, pero ejecuté ifconfigy obtuve lo siguiente:

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)

He corrido 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

Y sin 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

TRACEROUTO:

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  * * *

sin 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  * * *

El 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

Este es un ISP japonés y, aunque me conecto con un cable al módem / enrutador, necesito agregar un nombre de usuario y una contraseña, pero con la conexión "cableada" de Ubuntu no pude agregarlos. Mi compañera de casa me dijo que creara una conexión OCN, pero no estoy seguro de si ese es el nombre de un tipo de red o solo de la compañía japonesa ... pero después de mirar su computadora, encontramos que era una conexión PPPoE. Después de buscar en Google, aprendí que para crear una conexión PPPoE necesitaría crear una conexión DSL y que podría agregarle una contraseña y un nombre de usuario. También cambié la conexión "cableada" para que no se conecte automáticamente.

Me sale el mismo problema si me conecto directamente al módem.

Intenté cambiar la MTU DSL a 500, 1500, 1492 y 1482, pero no hizo la diferencia.

Además, por alguna razón, Ubuntu no siempre recoge la conexión, a veces tengo que reiniciar para que se conecte.

Esta es una vieja pregunta, pero para aquellos que llegan aquí a través de Google, esto ayudará. El problema es que la fragmentación en SSL es mala y rompe el protocolo. Si está utilizando PPPOE, la MTU normal en su enrutador / DSL / Cable módem es 1492. Eso es demasiado alto y causará fragmentación. 1476 es el número mágico que funcionará con la mayoría de los sitios. Algunos sitios utilizan diferentes implementaciones SSL, por lo que 1480 puede funcionar, o incluso 1488. Para la MAYOR compatibilidad, la MTU en el lado WAN de su dispositivo de red (enrutador, módem, etc.) debe ser 1476.

Aquí hay un par de cosas para probar:

1. Verifique la configuración de su tarjeta de red. Ninguna de sus interfaces eth muestra direcciones IPv4. Asegúrese de tener IPv4 activado (es posible que deba restablecer su conexión con su enrutador para renovar la IP). Si eso no funciona, intente desactivar el soporte de IPv6 y vea si eso hace la diferencia. Para ello, haga clic con el botón derecho en el icono de red que se encuentra junto a su reloj (cuando esté en una conexión Ethernet, es un par de flechas, una apuntando hacia arriba y la otra hacia abajo) y seleccionando "Editar conexiones ...". En la pestaña "Configuración de IPv4", asegúrese de que esté configurado en "Automático (DHCP)". Si desea desactivar IPv6, vaya a su pestaña y configúrelo en "Ignorar".

2. Verifique si puede conectarse a los sitios utilizando otros métodos. ¿Con qué pingresponde los sitios a los que no puede conectarse? ¿Qué tal un traceroute(puede que tenga que instalar traceroute para usarlo, para su información)? Sus respuestas pueden ayudarlo a solucionar el problema. Si no pueden acceder a los servidores de la URL, entonces podría ser un problema de DNS (sin embargo, si pueden acceder a los servidores de la URL, pero luego se descartan, podría significar que esos comandos están bloqueados).

3. Omitir el enrutador. Si su enrutador y su módem son dos máquinas diferentes, intente conectar su computadora directamente a su módem y ver si eso cambia algo.

4. Reinicie su módem y enrutador. A veces, simplemente apestan.

5. Reinicia tu computadora. A veces, simplemente apestan.

6. Prueba con una computadora diferente. Si tiene una, ¿funciona otra computadora donde esta falla? Si no, entonces podría ser algo con su computadora específica.

7. Borre el caché, las cookies, etc. de su computadora A veces, las cookies de sesión incorrecta, el caché, etc. pueden interferir con la conexión a un sitio (tuve un problema con Google hace un tiempo). Límpielos y comience de nuevo y vea lo que obtiene.

8. Desconecte las conexiones VPN. El protocolo punto a punto a menudo se usa para VPN (la interfaz PPP), y las VPN pueden interferir con la conexión a los sitios. Asegúrate de no estar conectado haciendo clic derecho en el ícono de tu red junto a tu reloj, buscando la entrada "Conexiones VPN" y asegurándote de que no esté marcada ninguna lista (si no tienes un elemento de menú "Conexiones VPN", entonces no t tiene una configuración). Si hay alguna marcada, entonces estás conectado a ella, desconéctate de ella.

Recuerde: no todo lo que haga resultará en un simple "trabajo o falla", cualquier cambio en la reacción del servidor a su solicitud nos dirá algo. Por lo tanto, si hace algo de lo anterior y recibe un nuevo mensaje, no olvide actualizar su pregunta.

He visto este comportamiento dos veces en la práctica para lo cual he encontrado las siguientes soluciones.

• Alguna computadora en la red local intentaba con éxito un ataque de hombre en el medio. Estaba falsificando ARP la puerta de enlace, redirigiendo así todo el tráfico para pasar a través de esta máquina, modificando solicitudes y otras cosas desagradables. La máquina estaba ejecutando Windows y se descubrió que estaba infectada con algún malware desagradable. Tan pronto como esta máquina se desconectó físicamente de la red, los síntomas desaparecieron.
• Un problema de MTU en su u otra puerta de enlace. En las puertas de enlace IPv4 son responsables de fragmentar y volver a ensamblar los paquetes IP en la red si el tamaño de trama de las redes para las que está enrutando el tráfico no es el mismo. Para conexiones DSL que utilizan PPPoE / PPPoA, el tamaño de la MTU suele ser menor que los 1500 bytes en el lado LAN. También los enrutadores intermedios fallan y debe habilitar TCP MSS Clamping en su enrutador. Siempre tuve que configurar esto en la conexión de mi ISP anterior, pero estaba resolviendo más que solo problemas relacionados con SSL. Compruebe si su módem / enrutador tiene esa opción. Considere que esto es una solución alternativa.
• Estaba en una red que probablemente ejecutaba un proxy transparente para pasar también el tráfico SSL, pero fallaba en TLSv1 por alguna razón. La misma solicitud funcionó cuando se usa una conexión VPN. Miedo
  Intenta correr curlcon la opción --sslv3. Si eso lo resuelve, entonces apesta.

Cosas generales para probar:

• Compruebe si está ejecutando el último firmware en su módem / enrutador. Si no, intente actualizar.

• Capture el tráfico con tcpdumpWhireshark y analícelo (publíquelo aquí, por ejemplo).

    # 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 obtiene errores de reensamblado o el segmento anterior se pierde repetidamente, esta es una señal clara de la pérdida de paquetes causada por un tamaño de MTU incorrecto.
  Sin embargo, el tráfico HTTPS está encriptado y es difícil de analizar desde el tráfico de red por sí mismo.

Editar:

Desde su tcpdump la raíz de su problema SSL es clara: TCP Previous segment lost. La solución de problemas de red general debe aplicarse aquí, pero puede estar fuera del alcance de su red local y un problema con su ISP.

Hola a todos, este ES marcovaleriof de Italia, recientemente tuvimos un problema similar al suyo: toda nuestra máquina Linux ya no podía conectarse a ningún sitio web https, mientras que el dispositivo Android o Windows no tuvo ningún problema. El problema fue una desalineación de mtu entre nuestro enrutador DSL que tenía una longitud de 1492 mtu y el mtu predeterminado de Linux que es 1500. De hecho, emitimos este comando como root

ifconfig wlan0 mtu 1492 up

(en inglés este conjunto El valor mtu de la interfaz de red - wlan0 en mi caso - a 1492 de longitud) se ha librado del problema, ¡gracias! Espero que esto pueda ayudar a alguien.

Gracias por toda su ayuda, el problema finalmente se solucionó.

Estaba tratando de limitar la MTU para ver si ayudaría y terminé usando la pppoeconfconfiguración de la conexión PPPoE, ya que limita la MTU para mí. Luego deshabilité la conexión DSL que utilicé anteriormente.

Para cualquier persona que experimente un problema similar, puede probar esta solución escribiendo sudo ppoeconfy siguiendo las instrucciones. Entonces puedes conectarte pon adsl-providery desconectarte conpoff