☰

SSL no funciona en Windows 10 contra rutracker.org a través de PPTP, pero funciona con L2TP

tag-icon • tag-icon windows-10 ssl pptp
SSL no funciona en Windows 10 contra rutracker.org a través de PPTP, pero funciona con L2TP

Tengo una computadora portátil con Windows 10 con un problema peculiar que ningún navegador puede abrirhttps://rutracker.org/

Es así (en el modo de herramientas de desarrollador): durante mucho tiempo el navegador no reconoce que envía nada al control remoto (por ejemplo, Chrome informa que está "bloqueado"), y luego la solicitud aparece como fallida sin motivo aparente. También probé Firefox y Edge con los mismos resultados, ya que no logran conectarse y no brindan ninguna depuración significativa.

Incluso he instalado cURL. El resultado es el siguiente:

curl -k -vvv https://rutracker.org/forum/index.php
* Trying 195.82.146.214...
* TCP_NODELAY set
* Connected to rutracker.org (195.82.146.214) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):

luego se bloqueará durante mucho tiempo y luego se quejará de SSL_ERROR_SYSCALL. Por el contrario, en Linux se ve totalmente diferente:

curl -k -vvv https://rutracker.org/forum/index.php
* Hostname was NOT found in DNS cache
*   Trying 195.82.146.214...
* Connected to rutracker.org (195.82.146.214) port 443 (#0)
* 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 TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
*        subject: CN=rutracker.org
*        start date: 2018-07-20 04:13:49 GMT
*        expire date: 2018-10-18 04:13:49 GMT
*        issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*        SSL certificate verify ok.
> GET /forum/index.php HTTP/1.1
> User-Agent: curl/7.38.0
> Host: rutracker.org
> Accept: */*
> 
< HTTP/1.1 200 OK

¿Quizás haya una compilación de navegador que utilice OpenSSL puro y evite por completo la implementación de SSL de Windows? Porque parece que aquí es lo problemático. Recientemente consulté con Malwarebytes y no encontré nada en particular.

EDITAR: He observado que esto sólo sucederá cuando esté conectado mediante PPTP VPN. Cuando me cambié a L2TP, de repente puedo abrir el sitio web sin problemas. ¿Que está sucediendo aquí?

Respuesta1

No hay nada malo con la biblioteca TLS de Windows (y de hecho, curl en Linux se comporta de la misma manera cuando se compila con OpenSSL/1.1.0i): simplemente usa un formato de protocolo de enlace más nuevo que intenta usar menos mensajes más grandes (reduciendo la latencia), mientras que su curl usa una biblioteca antigua que todavía tiene el modo "compatible con SSLv3".

Pero esa es sólo una de las muchas cosas que podrían desencadenar el mismo problema. El verdadero problema es:

  1. En el servidor VPN, la interfaz de red virtual de "clientes PPTP" tiene su MTU configurada en un valor relativamente bajo (por ejemplo, 1280 bytes), para tener en cuenta la sobrecarga de VPN y algo más.
  2. Durante el protocolo de enlace TLS, el servidor Rutracker le envía un paquete IP más grande que esta MTU.
  3. El servidor VPN no puede reenviar el paquete debido a que es más grande que la interfaz de salida y devuelve un paquete de error ICMP "demasiado grande" que indica la MTU admitida.
  4. El servidor web Rutrackerignorael mensaje ICMP, no ajusta su caché de ruta en consecuencia y sigue enviándole el mismo paquete grande. Comience de nuevo desde el paso 2.

Esta negociación de MTU basada en ICMP se denomina "descubrimiento de MTU de ruta", y la situación en la que el remitente ignora el consejo del receptor se conoce como "agujero negro de PMTU". Quizás los administradores de Rutracker escucharon en alguna parte que bloquear completamente ICMP hace que el sitio de alguna manera sea "más seguro"...

Así es como se ve desde el punto de vista de un servidor VPN de ejemplo (usando un OpenVPN deliberadamente mal configurado): observe cómo el paquete grande se rechaza una y otra vez:

IP 31.220.xy48872 > 195.82.146.214.443: Banderas [S], secuencia 2337162999, win 29200, opciones [mss 1358,sackOK,TS val 674971446 ecr 0,nop,wscale 7], longitud 0
IP 195.82.146.214.443 > 31.220.xy48872: Banderas [S.], secuencia 2391406816, reconocimiento 2337163000, ganancia 14600, opciones [mss 1460,nop,wscale 8], longitud 0
IP 31.220.xy48872 > 195.82.146.214.443: Banderas [.], reconocimiento 1, victoria 229, longitud 0
IP 31.220.xy48872 > 195.82.146.214.443: Banderas [P.], secuencia 1:217, reconocimiento 1, victoria 229, longitud 216
IP 195.82.146.214.443 > 31.220.xy48872: Banderas [.], reconocimiento 217, victoria 62, longitud 0
IP 195.82.146.214.443 > 31.220.xy48872: Banderas [.], secuencia 1:1359, reconocimiento 217, ganancia 62, longitud 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy inalcanzable: es necesario fragmentar (mtu 1280), longitud 556
IP 195.82.146.214.443 > 31.220.xy48872: Banderas [P.], secuencia 1359:3242, reconocimiento 217, victoria 62, longitud 1883
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy inalcanzable: es necesario fragmentar (mtu 1280), longitud 556
IP 195.82.146.214.443 > 31.220.xy48872: Banderas [.], secuencia 1:1359, reconocimiento 217, ganancia 62, longitud 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy inalcanzable: es necesario fragmentar (mtu 1280), longitud 556
IP 195.82.146.214.443 > 31.220.xy48872: Banderas [.], secuencia 1:1359, reconocimiento 217, ganancia 62, longitud 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy inalcanzable: es necesario fragmentar (mtu 1280), longitud 556
IP 195.82.146.214.443 > 31.220.xy48872: Banderas [.], secuencia 1:1359, reconocimiento 217, ganancia 62, longitud 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy inalcanzable: es necesario fragmentar (mtu 1280), longitud 556
IP 195.82.146.214.443 > 31.220.xy48872: Banderas [.], secuencia 1:1359, reconocimiento 217, ganancia 62, longitud 1358
IP 31.220.xy > 195.82.146.214: ICMP 31.220.xy inalcanzable: es necesario fragmentar (mtu 1280), longitud 556

La VPN L2TP no se verá afectada por varias razones posibles:

  • podría usar una MTU predeterminada de 1500 para el túnel y fragmentar de forma transparente los paquetes de gran tamaño;
  • podría realizar sujeción TCP MSS en las conexiones que ve;
  • podría informar la MTU reducida a su software de cliente VPN para que su sistema operativo ya sepa de antemano cómo colocar el MSS correcto en sus solicitudes de conexión TCP.

Como cliente, sus opciones son (dependiendo de lo que admita el sistema operativo):

  • No utilice VPN PPTP en absoluto. (No se debe a problemas de MTU; PPTP no es mejor ni peor que otros tipos de VPN en ese sentido, sino más bien a problemas de seguridad que tiene el protocolo. Tanto el cifrado MPPE como la autenticación MSCHAP son muy débiles).
  • Reduzca la MTU de la interfaz VPN (por ejemplo, a 1400 o 1280) en el sistema operativo del cliente. Por ejemplo, Linux te permite hacer ip link set ppp0 mtu <bytes>. En consecuencia, su sistema anunciará un valor TCP MSS más bajo a los servidores Rutracker.
  • Habilite el sondeo TCP MTU en el sistema operativo del cliente. Por ejemplo, Linux tiene sysctl net.ipv4.tcp_mtu_probing=1. Esto funciona incluso donde ICMP PMTUD no lo hace.
  • Configurar el cliente VPNoel firewall del servidor VPN para realizar la sujeción de TCP MSS. (Esto se puede hacer en cualquier lugar del camino).
  • Intenta convencer a los administradores de Rutracker de que han tomado una mala decisión.

información relacionada