Ошибка ERR_SSL_PROTOCOL_ERROR на определённых прокси

Поддержка
  • @m4zuper все

  • Как решить проблему? Премиум поддержка молчит. Вся работа встала. Неужели я один такой?

  • @arcos said in Ошибка ERR_SSL_PROTOCOL_ERROR на определённых прокси:

    Как решить проблему? Премиум поддержка молчит. Вся работа встала. Неужели я один такой?

    Я выше тебе написал, если открывать сайт с plain http, то прокси провайдер отдаст тебе прямо в браузер ошибку.

    http://lumtest.com/myip.json

  • @sergerdn конкретно этот запрос - работает (если ставить http)
    если https - не работает. В то же время в браузере - прокси работают в обоих случаях

  • @arcos said in Ошибка ERR_SSL_PROTOCOL_ERROR на определённых прокси:

    @sergerdn конкретно этот запрос - работает (если ставить http)
    если https - не работает. В то же время в браузере - прокси работают в обоих случаях

    Кто-то снимает твой https трафик 😄. В обычном Chrome mitm сертификат применяется, а в BAS - нет.

    Проверить просто - открой в Chrome сайт с https и посмотри его сертификат.

  • @sergerdn что значит "снимает"? это прокси из топ-20 по миру.
    вставил в антидетект браузер (всё работает):
    296efc0d-88cd-497e-8cf5-6dbd34f56457-image.png

    в бас:
    eebb1ae1-b8fd-479b-b3c2-9d4e5ceba19a-image.png

  • @arcos said in Ошибка ERR_SSL_PROTOCOL_ERROR на определённых прокси:

    @sergerdn что значит "снимает"? это прокси из топ-20 по миру.

    Браузер так мне "помог", в оригинале было сниффает. И речь шла не про прокси-провайдера, а про твою локальную машину.

    Что показывает в самом BAS в сертификате?

  • @sergerdn так а при чём тут локальная машина, если это происходит только под определённым прокси. если поставить любую другую прокси - то ни единой ошибки нет:
    40cfb43b-3e37-4e08-af45-38a154660778-image.png

  • @arcos said in Ошибка ERR_SSL_PROTOCOL_ERROR на определённых прокси:

    @sergerdn так а при чём тут локальная машина, если это происходит только под определённым прокси. если поставить любую другую прокси - то ни единой ошибки нет:

    У тебя возможные варианты:

    1. Прокси провайдер выдает ошибку. Это возможно, если неправильный логин, пароль, ресурс забанен прокси-провайдером, etc. Так как соединение https, то ты видишь ошибку, net::ERR_SSL_PROTOCOL_ERROR, а не ту, что выдает прокси-провайдер.
    2. Кто-то при соединении через плохой прокси вмешивается в трафик.

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

    P.S.
    Пиши в личку телегу, ставь anydesk. Помогу отдебажить причину ошибки.

  • @sergerdn в пароле кстати есть символы ";". но я пробовал через авторизацию по айпи (т.е. без логина/пароля), и ситуация не поменялась

  • Не нашли решение?

  • Я то же заинтересован в том что бы найти решение. У меня баг воспроизводится на WIndows Server 21H2 + BAS 27.1.1. При этом с той же самой Windows коробки Chromium + Playwright или ProxyChick отлично работают с тем же прокси листом от SOAX. У меня есть возможность посмотреть логи в SOAX и тд и с самими resi device, при работе с которыми BAS выдавал ошибку, проблем не наблюдается.

    По поводу снифинга, IMHO это должно иначе выглядеть, стоковый Chrome без рутового сертификата от MITM выдаст ошибку.

    Кто-нибудь, кто шарит в BAS может со мной созвониться и вместе покопать? Для меня test.xml это филькина грамота. Может быть есть какой-то DEBUG logging в BAS что бы уидеть детали ошибки, почему конкретно не удается установить TLS сессию.
    Возможно еще кто-нибудь знает, BAS сам не пытается интерсептить сессию, он патченный Chromium использует или нет, есть какая-то специфика того, как он работает с трафиком proxy протоколами?

  • @greggyNapalm

    Не используй слишком длинные пароли или юзернейм к прокси. У BAS ограничения на длину и того и другого.

  • Повторил тест с очень короткой строчкой - не повлияло. Так же вижу net::ERR_SSL_PROTOCOL_ERROR

  • У меня была идея о том, что могут быть проблемы с ipv6 addr target ресурса. Но она не подтвердилась. Я направил тарафик на свой хост у которого только ipv4 addr и ошибка присутствует.
    Теперь я думаю о том, что возможно внутри BAS есть таймаут на установление TLS сессии и когда длительность выходит за рамки он возвращает ошибку.

  • @greggyNapalm said in Ошибка ERR_SSL_PROTOCOL_ERROR на определённых прокси:

    Так же вижу net::ERR_SSL_PROTOCOL_ERROR

    Это ошибка на стороне прокси 99%.

    Попробуй эту же прокси в командной строке запросить curl на сайт без https и посмотри ответ, я думаю, он будет что-то вроде "ой, выходной ноды с такими параметрам нет".

  • Я писал выше, что я тот же proxylist прогнал через тулу https://github.com/greggyNapalm/proxychick несколько раз(я ее для тестов и написал, там стандартная библиотека Golang используется). Она имеет более детализированный вывод ошибок по TLS в том числе. Можно понять где дело в timeout на shandshake, где валидация сертификата не прошла и тд. Так вот, нет ошибок в ней.

    Так же на Python + playwright написал простенький скрипт, который последовательно запрашивает тот же URL через Chrome используя те же proxy - то же нет проблем.

    Сервер один и тот же, proxylist один и тот же. Проблемы только при работе через BAS.

  • @greggyNapalm said in Ошибка ERR_SSL_PROTOCOL_ERROR на определённых прокси:

    Я писал выше

    Я предложил тебе сделать не то, что ты делал.

    Конкретно SOAX, если ему не нравится что-то, то он отвечает plain text с ошибкой, а в браузере ты получаешь ошибку net::ERR_SSL_PROTOCOL_ERROR, как следствие.

    Так как браузер ожидает начало рукопожатия, а получает в ответ plain text.

    Также, конкретно я репортил баг, связанные с SOAX и BAS, дело было в длине логина и пароля. Якобы это было fixed. В браузере это выглядело ровно также, как и у тебя с такой же ошибкой.

    Отдебажить все это можно любым сниффером трафика и увидеть что отвечает SOAX, Wireshark лучше всех в этом плане.

  • Мне удалось собрать cap file с взаимодействием с ifcinfig.co через TLS с успешным исходном и неудачным. В неудачном клиент(BAS) отвечает серверу ошибкой о том что версия протокола не верна, но в ответе сервера валидный ServerHello ответ, plaint text я не вижу. Сейчас буду разбираться в деталях, чем ServerHello от успешного handshake отличается от неуспешного.

  • Экспортнул из Wireshark оба TLS сообщения в виде текста и сделал diff

    Screenshot 2024-04-27 at 12.17.44.png