WRONG_VERSION_NUMBER з проксі: праверце HTTP і HTTPS

Памылка кажа “няправільная версія”, таму хочацца пачаць перабіраць версіі TLS. З проксі праверце больш раннюю магчымасць: ці адправіў кліент рукапоціск TLS на порт, які чакаў звычайны HTTP?

Прызначэнне накшталт https://example.com/ і проксі накшталт http://proxy.example:8080 — звычайная пара. Змена другога URL на HTTPS кажа кліенту шыфраваць размову з самім проксі. Гэта не ўказанне дазваляць HTTPS-сайты.

Знайдзіце першую размову TLS

Для проксі HTTP кліент спачатку можа адправіць CONNECT і атрымаць адказ HTTP. Толькі пасля гэтага ён пачынае TLS прызначэння ўнутры тунеля. Для проксі HTTPS спачатку ідзе асобнае злучэнне TLS з проксі.

Аналізатар TLS, які атрымлівае старонку памылкі HTTP або іншы звычайны тэкст, можа паведаміць пра памылку пратакола. Фармулёўка не ўстанаўлівае, якія версіі TLS падтрымлівае сайт, і нават ці быў кантакт з сайтам.

1. Запішыце URL проксі разам са схемай і дакументаваны пратакол канцавога пункта.
2. Высветліце, ці здарыўся збой да адказу CONNECT, падчас TLS прызначэння ці падчас праверкі ўласнага сертыфіката проксі.
3. Праверце фактычныя версіі кліента і залежнасцей, калі параўноўваеце старое абыходнае рашэнне. Ранейшыя рэалізацыі проксі часам трактавалі схему інакш.

Некалькі выпраўленняў могуць быць няправільнымі з розных прычын. Спіс проксі HTTP прапануе звычайныя кандыдаты канцавых пунктаў HTTP для публічных запытаў, дазволеных праз такі маршрут. Звычайнаму канцавому пункту HTTP патрэбна схема проксі HTTP; сапраўды TLS-уключаны канцавы пункт павінен захаваць HTTPS і праверку сертыфіката. Проксі, які адхіляе CONNECT, патрабуе падтрыманай паслугі або палітыкі, а не адвольнага зніжэння бібліятэкі.

Трымайцеся першага назіранага збою. Адключэнне праверкі сертыфіката не прымусіць слухача толькі з HTTP гаварыць TLS, а выбар старой палітыкі шыфраў не можа патлумачыць адмову HTTP, адпраўленую да рукапоціску сайта.