SSL не работает в Windows 10 против rutracker.org через PPTP, но работает с L2TP

Question

У меня ноутбук с Windows 10 со специфической проблемой, которую ни один браузер не может открыть https://rutracker.org/

Это происходит так (в режиме инструментов разработчика): в течение длительного времени браузер не распознает, что он отправляет что-либо удаленному (например, Chrome сообщает, что он «остановлен»), а затем запрос отображается как неудавшийся без видимой причины. Я также пробовал Firefox и Edge с одинаковыми результатами, потому что они не могут подключиться и не дают какой-либо значимой отладки.

Я даже установил cURL. Результат следующий:

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):

потом долго будет висеть и потом жаловаться на SSL_ERROR_SYSCALL. Напротив, в Linux это выглядит совсем иначе:

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

Может быть, есть сборка браузера, которая будет использовать чистый OpenSSL, полностью избегая реализации Windows SSL? Потому что, кажется, это проблематично. Я недавно проверил с Malwarebytes, который не нашел ничего конкретного.

РЕДАКТИРОВАТЬ: я заметил, что это произойдет только тогда, когда я подключен через PPTP VPN. Когда я перешел на L2TP, я могу без проблем открыть веб-сайт. Что здесь происходит?

Answer 1

В библиотеке TLS Windows нет ничего плохого (и, действительно, curl в Linux ведет себя так же, как при компиляции с OpenSSL/1.1.0i) - она просто использует более новый формат рукопожатия, который пытается использовать меньше больших сообщений (уменьшая задержку), тогда как ваш curl использует старую библиотеку, которая все еще имеет режим "SSLv3-совместимый".

Но это только одна из многих вещей, которые могут вызвать ту же проблему. Настоящая проблема заключается в следующем:

1. На VPN-сервере виртуальный сетевой интерфейс «PPTP-клиенты» имеет свой MTU, установленный на относительно низкое значение (например, 1280 байт) - для учета накладных расходов VPN, а затем и некоторых.
2. Во время квитирования TLS сервер Rutracker отправляет вам IP-пакет, больший, чем этот MTU.
3. Сервер VPN не может переслать пакет из-за того, что он больше, чем выходной интерфейс, и возвращает пакет ошибки ICMP "Слишком большой", указывающий поддерживаемый MTU.
4. Веб-сервер Rutracker игнорирует сообщение ICMP, соответственно не корректирует свой кэш маршрутов и продолжает отправлять вам один и тот же большой пакет. Начните заново с шага 2.

Это согласование MTU на основе ICMP называется "Обнаружение MTU пути", а ситуация, когда отправитель игнорирует рекомендации получателя, известна как "черная дыра PMTU". Возможно, администраторы Rutracker где-то слышали, что полная блокировка ICMP делает сайт как-то "более безопасным" ...

Вот как это выглядит с точки зрения примера VPN-сервера (с использованием преднамеренно неправильно настроенного OpenVPN) - обратите внимание, как большой пакет отклоняется снова и снова:

IP 31.220.x.y.48872 > 195.82.146.214.443: Flags [S], seq 2337162999, win 29200, options [mss 1358,sackOK,TS val 674971446 ecr 0,nop,wscale 7], length 0
IP 195.82.146.214.443 > 31.220.x.y.48872: Flags [S.], seq 2391406816, ack 2337163000, win 14600, options [mss 1460,nop,wscale 8], length 0
IP 31.220.x.y.48872 > 195.82.146.214.443: Flags [.], ack 1, win 229, length 0
IP 31.220.x.y.48872 > 195.82.146.214.443: Flags [P.], seq 1:217, ack 1, win 229, length 216
IP 195.82.146.214.443 > 31.220.x.y.48872: Flags [.], ack 217, win 62, length 0
IP 195.82.146.214.443 > 31.220.x.y.48872: Flags [.], seq 1:1359, ack 217, win 62, length 1358
IP 31.220.x.y > 195.82.146.214: ICMP 31.220.x.y unreachable - need to frag (mtu 1280), length 556
IP 195.82.146.214.443 > 31.220.x.y.48872: Flags [P.], seq 1359:3242, ack 217, win 62, length 1883
IP 31.220.x.y > 195.82.146.214: ICMP 31.220.x.y unreachable - need to frag (mtu 1280), length 556
IP 195.82.146.214.443 > 31.220.x.y.48872: Flags [.], seq 1:1359, ack 217, win 62, length 1358
IP 31.220.x.y > 195.82.146.214: ICMP 31.220.x.y unreachable - need to frag (mtu 1280), length 556
IP 195.82.146.214.443 > 31.220.x.y.48872: Flags [.], seq 1:1359, ack 217, win 62, length 1358
IP 31.220.x.y > 195.82.146.214: ICMP 31.220.x.y unreachable - need to frag (mtu 1280), length 556
IP 195.82.146.214.443 > 31.220.x.y.48872: Flags [.], seq 1:1359, ack 217, win 62, length 1358
IP 31.220.x.y > 195.82.146.214: ICMP 31.220.x.y unreachable - need to frag (mtu 1280), length 556
IP 195.82.146.214.443 > 31.220.x.y.48872: Flags [.], seq 1:1359, ack 217, win 62, length 1358
IP 31.220.x.y > 195.82.146.214: ICMP 31.220.x.y unreachable - need to frag (mtu 1280), length 556

L2TP VPN не затронут по нескольким возможным причинам:

• он может использовать 1500 MTU по умолчанию для туннеля и прозрачно фрагментировать негабаритные пакеты;
• он может выполнять TCP MSS-фиксацию для соединений, которые он видит;
• он может сообщить об уменьшенном MTU вашему программному обеспечению VPN-клиента, чтобы ваша ОС уже знала заранее, чтобы правильно указать MSS в своих запросах на TCP-соединение.

Как клиент, ваши варианты (в зависимости от того, что поддерживает ОС):

• Не используйте PPTP VPN вообще. (Не из-за проблем MTU - PPTP не лучше и не хуже, чем другие типы VPN в этом отношении, а скорее из-за проблем безопасности, которые имеет протокол. И шифрование MPPE, и аутентификация MSCHAP очень слабые.)
• Уменьшите MTU интерфейса VPN (например, до 1400 или 1280) на клиентской ОС. Например, Linux позволяет вам сделать ip link set ppp0 mtu <bytes> . Соответственно, ваша система будет сообщать более низкое значение TCP MSS серверам Rutracker.
• Включите зондирование TCP MTU на клиентской ОС. Например, в Linux sysctl net.ipv4.tcp_mtu_probing=1 . Это работает даже там, где ICMP PMTUD нет.
• Сконфигурируйте брандмауэр VPN-клиента или VPN-сервера для выполнения фиксирования TCP MSS. (Это может быть сделано в любом месте вдоль пути.)
• Попробуйте убедить администраторов Rutracker в том, что они приняли неверное решение.