No se puede conectar a ciertos sitios HTTPS


12

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.


¿Estos sitios solo no se abren curlo tampoco se abren con otros navegadores?
adempewolff

No están abriendo en absoluto, sólo estaba tratando de localizar el origen del problema es ...
mind.blank

@ mind.blank: ¿qué te proporciona el navegador cuando intentas conectarte? Si no obtiene nada de la ventana principal, intente instalar Firebug (si usa Firefox; si usa Chrome, tiene las herramientas de desarrollo integradas), ábralo y active la consola y las pestañas de red y vea si hay cualquier error, luego repórtelos aquí.
Shauna

¿Estaba usando el enrutador antes o es nuevo? Además, ¿no has hecho nada tonto y has actualizado tus paquetes SSL o algo de una instalación predeterminada? Estoy accediendo a todos esos sitios bien (bueno, al menos a través de mi proxy, China bloquea aleatoriamente el protocolo SSL), así que supongo que el problema radica en el enrutador o en un paquete actualizado / instalado.
adempewolff

@Shauna Estoy usando Chrome y está diciendo Error 7 (net::ERR_TIMED_OUT): The operation timed out. FireFox sigue intentando cargar, pero nunca lo hace (la página no cambia). La consola y la red no me dan nada ...
mind.blank

Respuestas:


11

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.


1
No veo cómo la fragmentación romperá SSL. Los paquetes fragmentados serán reensamblados por enrutadores en IPv4. SSL ocurre sobre TCP, en un nivel en el que no debería notar esto. Creo que esto tiene que ver con los valores de MTU, pero no creo que su explicación califique. Creo que tiene que ver con configuraciones de MTU que no están sincronizadas en ambos extremos, lo que resulta en un reensamblaje incorrecto de paquetes fragmentados. El número mágico puede funcionar en su caso, pero no para otros.
gertvdijk

El bit DF (Dont Fragment) siempre se establece en el tráfico SSL por diseño: la fragmentación es un agujero de seguridad. Un paquete SSL fragmentado se descartará el 99.9% del tiempo. Una MTU demasiado baja en tráfico PPoE causará fragmentación.
Regretoverflow

Esto me sucedió con el sitio web de PayPal. Traté de llegar a un acuerdo con MTU 1476 y no funcionó, pero con 1480 funcionó. ¡Gracias!
juguetón

Pasé 6 am-2pm tratando de resolver esto hasta que encontré su respuesta. ¡Muy apreciado!
WayBehind

1
vaca santa! Esto me permitió sudo yum install docker-enginedespués de agregar el repositorio yum.dockerproject.org en un recuadro CentOS 7: sudo ip link set mtu 1476 dev enp6s0bajar la MTU de su valor predeterminado de 1500 a 1476. Estuve rascándome la cabeza por un día tratando de descubrir por qué estaba accesible yum.dockerproject.org a través de https desde otros nodos en la misma red.
jwd630

3

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.


1) Lo siento, no estoy seguro de cómo hacer ambas cosas. cyberciti.biz/faq/setting-up-an-network-interfaces-file - no estoy seguro de qué direcciones IP agregar. 2) He agregado ambos en la pregunta original. 3) Veré si tengo esa opción mañana (el módem, etc. está en la habitación del compañero de cuarto). 4) Igual que el anterior, aunque he reiniciado el enrutador al menos. 5) Probado algunas veces. 6) No tengo otra compilación con ubuntu, sin embargo, estas conexiones funcionan cuando cambio a Windows. 7) Intenté eso.
mind.blank

@ mind.blank No necesita hacer nada por el estilo en el enlace. Simplemente haga clic derecho en el icono de red junto al reloj y seleccione "Editar conexiones ...". Haga clic en la conexión y seleccione "Editar" y seleccione la pestaña "Configuración de IPv4" y asegúrese de que esté configurado en "Automático (DHCP)". A continuación, vaya a la pestaña "Configuración de IPv6" y asegúrese de que "Exigir el direccionamiento IPv6 para que esta conexión completa" es la ONU marcada. Guarda y vuelve a conectar. Si desea desactivar IPv6, vuelva a la pestaña Configuración de IPv6 y cambie "Automático" a "Ignorar".
Shauna

En Conexiones de red> DSL> Editar, la configuración de IPv4 está en "Automático (PPPoE)" y no hay una pestaña de IPv6 ...
mind.blank

2

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.


He intentado ejecutar curl con --sslv3y todavía no funciona. ¿También intenté capturar el volcado pero parece que no funciona? tcpdump: WARNING: eth0: no IPv4 address assigned 0 packets captured 6 packets received by filter 0 packets dropped by kernel- No estoy seguro de cómo asignar el IPv4 ... Mañana tendré que probar el resto ya que se está haciendo tarde y mi cerebro no funciona bien. Gracias por su ayuda a todos hasta ahora!
mind.blank

@ mind.blank Para usted, es la ppp0interfaz en lugar de eth0lo que me hace pensar: ¿Por qué necesita PPP para una conexión cuando usa un enrutador?
gertvdijk

La conexión normal "por cable" no recogió nada. Ahora he agregado el tcpdump al final de mi pregunta con más detalles sobre por qué estoy usando PPPoE. Además, si necesita más información del vertedero, dígame.
mind.blank

@ mind.blank El volcado es muy útil, pero no apunta a una solución justa. Ver mi respuesta actualizada.
gertvdijk

0

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.


-2

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.