WRONG_VERSION_NUMBER պրոքսիով. ստուգեք HTTP-ն ընդդեմ HTTPS-ի

Սխալը ասում է “սխալ տարբերակ”, ուստի գայթակղիչ է սկսել փոխել TLS տարբերակները։ Պրոքսիի դեպքում ստուգեք ավելի վաղ հնարավորություն. արդյո՞ք հաճախորդը TLS ձեռքսեղմում ուղարկեց պորտին, որը սպասում էր սովորական HTTP-ի։

https://example.com/-ի նման նպատակակետը և http://proxy.example:8080-ի նման պրոքսին սովորական զույգ են։ Երկրորդ URL-ը HTTPS դարձնելը հաճախորդին ասում է գաղտնագրել իր զրույցը հենց պրոքսիի հետ։ Դա HTTPS կայքեր թույլատրելու հրահանգ չէ։

Գտեք առաջին TLS զրույցը

HTTP պրոքսիի դեպքում հաճախորդը կարող է նախ ուղարկել CONNECT և ստանալ HTTP պատասխան։ Միայն դրանից հետո է սկսում նպատակակետի TLS-ը թունելի ներսում։ HTTPS պրոքսիի դեպքում նախ գալիս է դեպի պրոքսին առանձին TLS կապակցում։

HTTP սխալի էջ կամ այլ բաց տեքստ ստացող TLS վերլուծիչը կարող է հաղորդել պրոտոկոլի սխալ։ Ձևակերպումը չի հաստատում, թե կայքը որ TLS տարբերակներն է աջակցում, անգամ այն, որ կայքի հետ կապ է հաստատվել։

1. Գրի առեք պրոքսիի URL-ը՝ ներառյալ սխեման, և վերջնակետի փաստաթղթավորված պրոտոկոլը։
2. Պարզեք՝ ձախողումը եղել է CONNECT պատասխանից առաջ, նպատակակետի TLS-ի ընթացքում, թե պրոքսիի սեփական վկայագրի ստուգման պահին։
3. Հին լուծումը համեմատելիս ստուգեք հաճախորդի և կախվածությունների իրական տարբերակները։ Վաղ պրոքսի իրականացումները երբեմն սխեման այլ կերպ էին մեկնաբանում։

Մի քանի ուղղում կարող է սխալ լինել տարբեր պատճառներով։ HTTP պրոքսիների ցանկը առաջարկում է սովորական HTTP վերջնակետի թեկնածուներ այդպիսի ուղիով թույլատրված հանրային հարցումների համար։ Սովորական HTTP վերջնակետին պետք է HTTP պրոքսիի սխեմա. իսկապես TLS-ով աշխատող վերջնակետը պետք է պահպանի HTTPS-ը և վկայագրի ստուգումը։ CONNECT-ը մերժող պրոքսին պետք է աջակցվող ծառայություն կամ քաղաքականություն, այլ ոչ թե գրադարանի կամայական իջեցում։

Պահեք առաջին դիտարկելի ձախողումը։ Վկայագրի ստուգման անջատումը չի կարող ստիպել միայն HTTP խոսող լսողին խոսել TLS, և հին գաղտնագրման քաղաքականության ընտրությունը չի կարող բացատրել կայքի ձեռքսեղմումից առաջ ուղարկված HTTP մերժումը։