WRONG_VERSION_NUMBER med proxy: sjekk HTTP mot HTTPS

Feilen sier “feil versjon”, så det frister å begynne å bytte TLS-versjoner. Med en proxy bør du sjekke en tidligere mulighet: sendte klienten et TLS-håndtrykk til en port som ventet på vanlig HTTP?

En destinasjon som https://example.com/ og en proxy som http://proxy.example:8080 er et vanlig par. Å endre den andre URL-en til HTTPS forteller klienten at den skal kryptere samtalen sin med selve proxyen. Det er ikke en instruks om å tillate HTTPS-nettsteder.

Finn den første TLS-samtalen

Med en HTTP-proxy kan klienten først sende CONNECT og motta et HTTP-svar. Først etterpå starter den destinasjonens TLS inne i tunnelen. Med en HTTPS-proxy kommer en egen TLS-tilkobling til proxyen først.

En TLS-parser som mottar en HTTP-feilside eller annen vanlig tekst, kan rapportere en protokollfeil. Formuleringen fastslår ikke hvilke TLS-versjoner nettstedet støtter, eller om nettstedet i det hele tatt ble kontaktet.

1. Noter proxyens URL, inkludert skjemaet, og endepunktets dokumenterte protokoll.
2. Finn ut om feilen skjedde før et CONNECT-svar, under destinasjonens TLS eller under verifiseringen av proxyens eget sertifikat.
3. Sjekk de faktiske versjonene av klienten og avhengighetene når du sammenligner en gammel omvei. Tidligere proxyimplementasjoner behandlet noen ganger et skjema annerledes.

Flere rettelser kan være feil av ulike grunner. HTTP-proxylisten tilbyr vanlige HTTP-endepunktkandidater for offentlige forespørsler som tillates gjennom en slik rute. Et vanlig HTTP-endepunkt trenger HTTP-proxyskjemaet; et reelt TLS-aktivert endepunkt bør beholde HTTPS og sertifikatverifiseringen. En proxy som avviser CONNECT, trenger en støttet tjeneste eller policy, ikke en vilkårlig nedgradering av biblioteket.

Behold den første observerbare feilen. Å slå av sertifikatverifisering kan ikke få en mottaker som bare snakker HTTP til å snakke TLS, og valg av en gammel chifferpolicy kan ikke forklare en HTTP-avvisning sendt før nettstedets håndtrykk.