WRONG_VERSION_NUMBER z proxy: sprawdź HTTP i HTTPS

Błąd mówi “zła wersja”, więc kusi, by zacząć przełączać wersje TLS. Przy proxy sprawdź wcześniejszą możliwość: czy klient wysłał uścisk dłoni TLS do portu, który czekał na zwykły HTTP?

Miejsce docelowe takie jak https://example.com/ i proxy takie jak http://proxy.example:8080 to zwykła para. Zmiana drugiego adresu URL na HTTPS mówi klientowi, aby szyfrował swoją rozmowę z samym proxy. To nie jest polecenie zezwalania na witryny HTTPS.

Zlokalizuj pierwszą rozmowę TLS

Przy proxy HTTP klient może najpierw wysłać CONNECT i otrzymać odpowiedź HTTP. Dopiero potem rozpoczyna TLS miejsca docelowego wewnątrz tunelu. Przy proxy HTTPS najpierw pojawia się osobne połączenie TLS z proxy.

Parser TLS, który otrzyma stronę błędu HTTP lub inny zwykły tekst, może zgłosić błąd protokołu. Sformułowanie nie ustala, które wersje TLS obsługuje witryna, ani nawet czy witryna została połączona.

1. Zapisz adres URL proxy wraz z jego schematem oraz udokumentowany protokół punktu końcowego.
2. Ustal, czy awaria nastąpiła przed odpowiedzią CONNECT, podczas TLS miejsca docelowego, czy podczas weryfikacji certyfikatu samego proxy.
3. Porównując stare obejście, sprawdź rzeczywiste wersje klienta i zależności. Wcześniejsze implementacje proxy czasem traktowały schemat inaczej.

Kilka poprawek może być błędnych z różnych powodów. Lista proxy HTTP oferuje zwykłych kandydatów punktów końcowych HTTP dla publicznych żądań dozwolonych taką trasą. Zwykły punkt końcowy HTTP potrzebuje schematu proxy HTTP; punkt końcowy naprawdę obsługujący TLS powinien zachować HTTPS i weryfikację certyfikatu. Proxy odrzucające CONNECT potrzebuje obsługiwanej usługi lub polityki, a nie dowolnego obniżenia biblioteki.

Zachowaj pierwszą zaobserwowaną awarię. Wyłączenie weryfikacji certyfikatów nie sprawi, że odbiornik mówiący tylko HTTP zacznie mówić TLS, a wybór starej polityki szyfrów nie wyjaśni odrzucenia HTTP wysłanego przed uściskiem dłoni witryny.