WRONG_VERSION_NUMBER s proxy: zkontrolujte HTTP proti HTTPS
Diagnostikujte neshodu transportu přes proxy dřív, než kvůli zavádějící chybě SSL snížíte verze TLS nebo změníte nastavení certifikátů.
Chyba říká “špatná verze”, takže svádí začít přepínat verze TLS. U proxy ale prověřte dřívější možnost: neposlal klient TLS handshake na port, který čekal na obyčejný HTTP?
Cíl jako https://example.com/ a proxy jako http://proxy.example:8080 jsou běžná dvojice. Změna druhého URL na HTTPS říká klientovi, aby šifroval svou konverzaci se samotnou proxy. Není to pokyn povolit weby HTTPS.
Najděte první TLS konverzaci
U HTTP proxy může klient nejprve poslat CONNECT a dostat odpověď HTTP. Teprve potom začne TLS cíle uvnitř tunelu. U HTTPS proxy přichází nejprve samostatné TLS spojení s proxy.
TLS parser, který dostane chybovou stránku HTTP nebo jiný obyčejný text, může hlásit chybu protokolu. Formulace neurčuje, které verze TLS web podporuje, ani zda byl web vůbec kontaktován.
- Zaznamenejte URL proxy včetně jejího schématu a dokumentovaný protokol koncového bodu.
- Zjistěte, zda selhání nastalo před odpovědí CONNECT, během TLS cíle, nebo při ověřování vlastního certifikátu proxy.
- Při srovnávání starého obchvatu zkontrolujte skutečné verze klienta a závislostí. Dřívější implementace proxy někdy zacházely se schématem jinak.
Několik oprav může být chybných z různých důvodů. Seznam HTTP proxy nabízí běžné kandidáty na koncové body HTTP pro veřejné požadavky povolené takovou cestou. Obyčejný koncový bod HTTP potřebuje schéma HTTP proxy; skutečně TLS zapnutý koncový bod by měl zachovat HTTPS a ověřování certifikátu. Proxy odmítající CONNECT potřebuje podporovanou službu nebo politiku, ne svévolné snížení knihovny.
Držte se prvního pozorovatelného selhání. Vypnutí ověřování certifikátu nemůže přimět posluchač pouze s HTTP mluvit TLS a volba staré šifrové politiky nemůže vysvětlit odmítnutí HTTP odeslané před handshake s webem.