Некорректная работа сайтов с фрагментированными HTTPS-пакетами
nxrighthere opened this issue · 21 comments
При попытке открыть https://patreon.zendesk.com в браузере возникает ошибка:
При соединении с patreon.zendesk.com произошла ошибка. SSL получило запись, длина которой превышает максимально допустимую. Код ошибки: SSL_ERROR_RX_RECORD_TOO_LONG
У них перед веб-сервером какой-то балансировщик или устройство, которое считает, что раз первый HTTPS-пакет ClientHello не удалось принять одним пакетом, то это HTTP-запрос, и отвечать на него нужно HTTP-ответом.
Их сервер не может обрабатывать корректные с точки зрения стандартов запросы. Напишу им, но не обещаю, что они что-либо исправят.
Понял, спасибо.
Здесь такая же ерунда https://help.keenetic.net
Это тоже zendesk
Если вам важнее работоспособность zendesk, а не заблокированных сайтов по HTTPS, то просто отключите HTTPS-фрагментацию (параметр -e)
Да не, это не критично в принципе. У меня программа просто запущена в качестве фонового процесса весь день. Провайдер на некоторых ресурсах пытается SSL сертификаты подменять, меня это мягко говоря не устраивает.
CDN Мегафона тоже некорректно работает с фрагментированными пакетами. Написал и им.
Думаю, ни те ни другие не пофиксят, к сожалению... Проблема редко встречается и они просто не будут над этим заморачиватся.
Может как вариант использовать в программе файл со списком исключений?
Техподдержка zendesk бодро отвечала, даже написала скрипт для тестов. Так что они что-то делают.
Можно сделать списки, подумаю над этим.
Мегафон CDN:
Эксплуатация CDN анализирует проблему. Обещают дать ответ в конце этой или начале следующей недели. По результатам мы Вас оповестим.
Zendesk:
We were able to reproduce the problem, identify the cause, and we've worked with one of our network vendors to create a patch for the bug in their system.The update has not yet been applied to the problematic systems, but we anticipate that once applied it should resolve your issue. Unfortunately a date for the update is not yet scheduled, but should be soon.
Мегафон CDN устранил проблему. Написал в Zendesk еще раз.
По сообщению @reserved-word, проявляется на https://www.duolingo.com/. У меня не проявляется. Проверьте, у кого есть возможность.
А можно сделать, чтобы обходные трюки применялись лишь для доменов из чёрного списка, вне зависимости от того, открываются они по HTTP или HTTPS? Именно такого поведения я и ожидал от опции --blacklist, а оказалось, что она распространяется только на HTTP.
Никак. Это запланировано в следующих версиях.
Похоже, Zendesk исправил ошибку. Все сайты Zendesk у меня теперь работают.
Действительно работаю. На исправление им понадобилось год с небольшим... Ну, лучше поздно чем никогда.
Словил эту ошибку внезапно на йоте.
Трабла именно с заблокированными сайтами, прочие https работают нормально. На другом провайдере все ок, так что дело именно в йоте.
Шаманства с флагом -e ничего не дают.
И это конечно больше замечания, нежели репорт.
Их сервер не может обрабатывать корректные с точки зрения стандартов запросы. Напишу им, но не обещаю, что они что-либо исправят.
А что вы писали? Можете скинуть пример письма?
Никак. Это запланировано в следующих версиях.
Их сервер не может обрабатывать корректные с точки зрения стандартов запросы. Напишу им, но не обещаю, что они что-либо исправят.
А что вы писали? Можете скинуть пример письма?
Вот что писал в Fastly:
Hello, recently (apparently after update on Fastly side) services hosted on Fastly started to return incorrect certificate upon establishing TLS (HTTPS) connection if the fist TLS packet (ClientHello) is fragmented on TCP level (not send in a single TCP packet).
This disrupts the service for networks with low MTU value, embedded devices, and other not-very-common network connections.
Example of affected service: https://about.gitlab.com
People also reported such issues on other websites which use Fastly, namely Reddit, Stackoverflow and others, but right now I can only reproduce it on Gitlab.
PCAP file of traffic dump between the laptop and about.gitlab.com is in attachment. In this dump, the ClientHello packet is sent as 2-byte packet and 515-byte packet, instead of a single 517-byte packet.
Also see ticket #338276 — I've been told this is another report of this issue.
Attachment(s)
gitlab-fastly-tls-fragmentation-issue.pcapng
Проблемы с TCP-фрагментацией должны быть решены в версии GoodbyeDPI 0.1.7, опцией --reverse-frag.
TCP fragmentation issues should be solved in GoodbyeDPI 0.1.7, by using --reverse-frag option.