WRONG_VERSION_NUMBER uz proxy: provjerite HTTP i HTTPS

Greška kaže “pogrešna verzija”, pa se javlja iskušenje da počnete mijenjati TLS verzije. Uz proxy ipak 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 na HTTPS govori klijentu da šifrira razgovor sa samim proxyjem. To nije uputa da se dopuste HTTPS sajtovi.

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 parser koji primi HTTP stranicu greške ili drugi obični tekst može prijaviti grešku protokola. Formulacija ne utvrđuje koje TLS verzije sajt podržava, niti da je sajt uopće kontaktiran.

1. Zabilježite URL proxyja, uključujući njegovu shemu, i dokumentirani protokol krajnje 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 kada 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 za HTTP krajnje točke za javne zahtjeve dopuštene tim putem. Obična HTTP krajnja točka treba shemu HTTP proxyja; istinski TLS-omogućena krajnja točka treba 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 sajtom.