Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Некорректная работа сайтов с фрагментированными HTTPS-пакетами #4

Closed
nxrighthere opened this issue May 31, 2017 · 21 comments

Comments

@nxrighthere
Copy link

При попытке открыть https://patreon.zendesk.com в браузере возникает ошибка:

При соединении с patreon.zendesk.com произошла ошибка. SSL получило запись, длина которой превышает максимально допустимую. Код ошибки: SSL_ERROR_RX_RECORD_TOO_LONG

@ValdikSS
Copy link
Owner

У них перед веб-сервером какой-то балансировщик или устройство, которое считает, что раз первый HTTPS-пакет ClientHello не удалось принять одним пакетом, то это HTTP-запрос, и отвечать на него нужно HTTP-ответом.

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

@nxrighthere
Copy link
Author

Понял, спасибо.

@nxrighthere
Copy link
Author

Здесь такая же ерунда https://help.keenetic.net

@ValdikSS
Copy link
Owner

Это тоже zendesk

@ValdikSS
Copy link
Owner

Если вам важнее работоспособность zendesk, а не заблокированных сайтов по HTTPS, то просто отключите HTTPS-фрагментацию (параметр -e)

@nxrighthere
Copy link
Author

Да не, это не критично в принципе. У меня программа просто запущена в качестве фонового процесса весь день. Провайдер на некоторых ресурсах пытается SSL сертификаты подменять, меня это мягко говоря не устраивает.

@ValdikSS
Copy link
Owner

ValdikSS commented Jun 8, 2017

CDN Мегафона тоже некорректно работает с фрагментированными пакетами. Написал и им.

@ValdikSS ValdikSS changed the title На некоторых сайтах возникает ошибка SSL_ERROR_RX_RECORD_TOO_LONG Некорректная работа сайтов с фрагментированными HTTPS-пакетами Jun 8, 2017
@nxrighthere
Copy link
Author

Думаю, ни те ни другие не пофиксят, к сожалению... Проблема редко встречается и они просто не будут над этим заморачиватся.

Может как вариант использовать в программе файл со списком исключений?

@ValdikSS
Copy link
Owner

ValdikSS commented Jun 8, 2017

Техподдержка zendesk бодро отвечала, даже написала скрипт для тестов. Так что они что-то делают.
Можно сделать списки, подумаю над этим.

@ValdikSS
Copy link
Owner

Мегафон CDN:

Эксплуатация CDN анализирует проблему. Обещают дать ответ в конце этой или начале следующей недели. По результатам мы Вас оповестим.

@ValdikSS
Copy link
Owner

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.

@ValdikSS
Copy link
Owner

Мегафон CDN устранил проблему. Написал в Zendesk еще раз.

@ValdikSS
Copy link
Owner

По сообщению @reserved-word, проявляется на https://www.duolingo.com/. У меня не проявляется. Проверьте, у кого есть возможность.

@sergeevabc
Copy link

А можно сделать, чтобы обходные трюки применялись лишь для доменов из чёрного списка, вне зависимости от того, открываются они по HTTP или HTTPS? Именно такого поведения я и ожидал от опции --blacklist, а оказалось, что она распространяется только на HTTP.

@ValdikSS
Copy link
Owner

ValdikSS commented Jun 1, 2018

Никак. Это запланировано в следующих версиях.

@ValdikSS
Copy link
Owner

Похоже, Zendesk исправил ошибку. Все сайты Zendesk у меня теперь работают.

@nxrighthere
Copy link
Author

Действительно работаю. На исправление им понадобилось год с небольшим... Ну, лучше поздно чем никогда.

@HanabishiRecca
Copy link

Словил эту ошибку внезапно на йоте.
изображение
Трабла именно с заблокированными сайтами, прочие https работают нормально. На другом провайдере все ок, так что дело именно в йоте.
Шаманства с флагом -e ничего не дают.

И это конечно больше замечания, нежели репорт.

@megapro17
Copy link

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

А что вы писали? Можете скинуть пример письма?

Никак. Это запланировано в следующих версиях.

image

@ValdikSS
Copy link
Owner

ValdikSS commented Jul 9, 2021

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

А что вы писали? Можете скинуть пример письма?

Вот что писал в 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

ValdikSS added a commit that referenced this issue Dec 24, 2021
Some websites (or more precisely, TLS terminators/balancers) can't
handle segmented TLS ClientHello packet properly, requiring the whole
ClientHello in a single segment, otherwise the connection gets dropped.

However they still operate with a proper TCP stack.
Cheat on them: send the latter segment first (with TCP SEQ "in the future"),
the former segment second (with "current" SEQ), allowing OS TCP
stack to combine it in a single TCP read().

This fixes long-standing number of TCP fragmentation issues:
Fixes #4, #158, #224, #59, #192 and many others.
@ValdikSS
Copy link
Owner

Проблемы с TCP-фрагментацией должны быть решены в версии GoodbyeDPI 0.1.7, опцией --reverse-frag.

TCP fragmentation issues should be solved in GoodbyeDPI 0.1.7, by using --reverse-frag option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants