WRONG_VERSION_NUMBER med en proxy: kontrollera HTTP mot HTTPS

Felet säger “fel version”, så det är frestande att börja byta TLS-versioner. Med en proxy, kontrollera en tidigare möjlighet: skickade klienten en TLS-handskakning till en port som väntade på vanlig HTTP?

Ett mål som https://example.com/ och en proxy som http://proxy.example:8080 är ett vanligt par. Att ändra den andra URL:en till HTTPS säger åt klienten att kryptera sitt samtal med själva proxyn. Det är inte en instruktion att tillåta HTTPS-webbplatser.

Hitta det första TLS-samtalet

Med en HTTP-proxy kan klienten först skicka CONNECT och ta emot ett HTTP-svar. Först därefter börjar den målets TLS inne i tunneln. Med en HTTPS-proxy kommer en separat TLS-anslutning till proxyn först.

En TLS-tolkare som tar emot en HTTP-felsida eller annan vanlig text kan rapportera ett protokollfel. Formuleringen fastställer inte vilka TLS-versioner webbplatsen stöder, eller ens att webbplatsen kontaktades.

1. Anteckna proxyns URL, inklusive dess schema, och slutpunktens dokumenterade protokoll.
2. Ta reda på om felet inträffade före ett CONNECT-svar, under målets TLS eller vid verifieringen av proxyns eget certifikat.
3. Kontrollera de faktiska versionerna av klienten och beroendena när du jämför en gammal omväg. Tidigare proxyimplementeringar behandlade ibland ett schema annorlunda.

Flera rättelser kan vara fel av olika skäl. HTTP-proxylistan erbjuder vanliga HTTP-slutpunktskandidater för offentliga förfrågningar som tillåts via en sådan väg. En vanlig HTTP-slutpunkt behöver HTTP-proxyschemat; en verkligt TLS-aktiverad slutpunkt bör behålla HTTPS och sin certifikatverifiering. En proxy som avvisar CONNECT behöver en stödd tjänst eller policy, inte en godtycklig nedgradering av biblioteket.

Behåll det första observerbara felet. Att stänga av certifikatverifiering kan inte få en lyssnare som bara talar HTTP att tala TLS, och att välja en gammal chifferpolicy kan inte förklara en HTTP-avvisning som skickats före webbplatsens handskakning.