WRONG_VERSION_NUMBER uz proxy: provjerite HTTP i HTTPS

Greška kaže “pogrešna verzija”, pa je primamljivo početi mijenjati TLS verzije. Uz proxy provjerite raniju mogućnost: je li klijent poslao TLS rukovanje na port koji je čekao obični HTTP?

Odredište poput https://example.com/ i proxy poput http://proxy.example:8080 običan su par. Promjena drugog URL-a u HTTPS govori klijentu da šifrira razgovor sa samim proxyjem. To nije uputa da se dopuste HTTPS stranice.

Pronađite prvi TLS razgovor

Kod HTTP proxyja klijent najprije može poslati CONNECT i primiti HTTP odgovor. Tek tada započinje TLS odredišta unutar tunela. Kod HTTPS proxyja prvo dolazi zasebna TLS veza prema proxyju.

TLS raščlanjivač koji primi HTTP stranicu greške ili drugi obični tekst može prijaviti grešku protokola. Formulacija ne utvrđuje koje TLS verzije stranica podržava, niti da je stranica uopće kontaktirana.

1. Zabilježite URL proxyja, uključujući njegovu shemu, i dokumentirani protokol završne točke.
2. Utvrdite je li do kvara došlo prije CONNECT odgovora, tijekom TLS-a odredišta ili tijekom provjere vlastitog certifikata proxyja.
3. Provjerite stvarne verzije klijenta i ovisnosti kad uspoređujete staro zaobilazno rješenje. Ranije implementacije proxyja ponekad su drugačije tretirale shemu.

Nekoliko ispravaka može biti pogrešno iz različitih razloga. Popis HTTP proxyja nudi obične kandidate završne točke HTTP za javne zahtjeve dopuštene tim putem. Obična HTTP završna točka treba shemu HTTP proxyja; istinski TLS-omogućena završna točka trebala bi zadržati HTTPS i provjeru certifikata. Proxy koji odbija CONNECT treba podržanu uslugu ili pravilo, a ne proizvoljno snižavanje biblioteke.

Zadržite prvi uočljivi kvar. Isključivanje provjere certifikata ne može natjerati poslužitelj koji govori samo HTTP da govori TLS, a odabir stare šifarske politike ne može objasniti HTTP odbijanje poslano prije rukovanja sa stranicom.