WRONG_VERSION_NUMBER ar starpniekserveri: pārbaudiet HTTP un HTTPS

Kļūda saka “nepareiza versija”, tāpēc vilina sākt mainīt TLS versijas. Ar starpniekserveri pārbaudiet agrāku iespēju: vai klients nosūtīja TLS rokasspiedienu uz portu, kas gaidīja vienkāršu HTTP?

Galamērķis kā https://example.com/ un starpniekserveris kā http://proxy.example:8080 ir parasts pāris. Otrā URL maiņa uz HTTPS liek klientam šifrēt sarunu ar pašu starpniekserveri. Tas nav norādījums atļaut HTTPS vietnes.

Atrodiet pirmo TLS sarunu

Ar HTTP starpniekserveri klients vispirms var nosūtīt CONNECT un saņemt HTTP atbildi. Tikai pēc tam tas tunelī sāk galamērķa TLS. Ar HTTPS starpniekserveri vispirms nāk atsevišķs TLS savienojums ar starpniekserveri.

TLS analizators, kas saņem HTTP kļūdas lapu vai citu vienkāršu tekstu, var ziņot par protokola kļūdu. Formulējums nenosaka, kuras TLS versijas vietne atbalsta, pat to, vai ar vietni vispār tika sazināts.

1. Pierakstiet starpniekservera URL kopā ar tā shēmu un galapunkta dokumentēto protokolu.
2. Noskaidrojiet, vai kļūme notika pirms CONNECT atbildes, galamērķa TLS laikā vai pārbaudot paša starpniekservera sertifikātu.
3. Salīdzinot vecu apiešanas paņēmienu, pārbaudiet faktiskās klienta un atkarību versijas. Agrākās starpniekservera implementācijas dažkārt shēmu traktēja citādi.

Vairāki labojumi var būt nepareizi dažādu iemeslu dēļ. HTTP starpniekserveru saraksts piedāvā parastus HTTP galapunkta kandidātus publiskiem pieprasījumiem, kas atļauti pa šādu ceļu. Vienkāršam HTTP galapunktam vajag HTTP starpniekservera shēmu; patiešām TLS iespējotam galapunktam jāsaglabā HTTPS un sertifikāta pārbaude. Starpniekserverim, kas noraida CONNECT, vajag atbalstītu pakalpojumu vai politiku, nevis patvaļīgu bibliotēkas pazemināšanu.

Saglabājiet pirmo novērojamo kļūmi. Sertifikāta pārbaudes izslēgšana nevar likt tikai HTTP protošam klausītājam runāt TLS, un vecas šifrēšanas politikas izvēle nevar izskaidrot HTTP noraidījumu, kas nosūtīts pirms vietnes rokasspiediena.