WRONG_VERSION_NUMBER su proxy: patikrinkite HTTP ir HTTPS

Klaida sako “neteisinga versija”, todėl vilioja pradėti keisti TLS versijas. Su proxy pirmiausia patikrinkite ankstesnę galimybę: ar klientas išsiuntė TLS rankos paspaudimą į prievadą, kuris laukė paprasto HTTP?

Paskirties vieta kaip https://example.com/ ir proxy kaip http://proxy.example:8080 yra įprasta pora. Antrojo URL pakeitimas į HTTPS liepia klientui šifruoti savo pokalbį su pačiu proxy. Tai nėra nurodymas leisti HTTPS svetaines.

Raskite pirmąjį TLS pokalbį

Su HTTP proxy klientas pirmiausia gali išsiųsti CONNECT ir gauti HTTP atsakymą. Tik tada jis pradeda paskirties TLS tunelio viduje. Su HTTPS proxy pirmiau ateina atskiras TLS ryšys su proxy.

TLS analizatorius, gaunantis HTTP klaidos puslapį ar kitą paprastą tekstą, gali pranešti protokolo klaidą. Formuluotė nenustato, kurias TLS versijas palaiko svetainė, net to, ar su svetaine buvo susisiekta.

1. Užrašykite proxy URL su jo schema ir dokumentuotą pabaigos taško protokolą.
2. Išsiaiškinkite, ar gedimas įvyko prieš CONNECT atsakymą, paskirties TLS metu, ar tikrinant paties proxy sertifikatą.
3. Palygindami seną apėjimo būdą patikrinkite tikrąsias kliento ir priklausomybių versijas. Ankstesnės proxy implementacijos kartais schema traktuodavo kitaip.

Keli pataisymai gali būti klaidingi dėl skirtingų priežasčių. HTTP proxy sąrašas siūlo įprastus HTTP pabaigos taško kandidatus viešiems užklausoms, leidžiamiems tokiu maršrutu. Paprastam HTTP pabaigos taškui reikia HTTP proxy schemos; tikrai TLS įgalintas pabaigos taškas turėtų išlaikyti HTTPS ir sertifikato tikrinimą. Proxy, atmetantis CONNECT, reikia palaikomos paslaugos ar taisyklės, o ne savavališko bibliotekos sumažinimo.

Išsaugokite pirmą pastebimą gedimą. Sertifikato tikrinimo išjungimas negali priversti tik HTTP kalbančio klausytojo kalbėti TLS, o senos šifravimo taisyklės pasirinkimas negali paaiškinti HTTP atmetimo, išsiųsto prieš svetainės rankos paspaudimą.