Մեկ ավելորդ նոր տողը կարող է կոտրել TLS-ը CONNECT-ից հետո

Երբ CONNECT-ը վերադարձնում է 200, և TLS-ը անմիջապես չի վերծանում, ստուգեք միակցիչի սահմանային բայթերը՝ նախքան վկայագրեր կամ գաղտնագրեր փոխելը։

Գեներացված լիազորման արժեքը կարող է արդեն ավարտվել նոր տողով։ Եվս մեկ տողի վերջ ավելացնելը կարող է HTTP վերնագրերը վաղ ավարտել՝ նախատեսված Host դաշտը կամ այլ բաց տեքստ թողնելով հարցումից հետո։

Նվազագույն HTTP/1.1 CONNECT հարցումը օգտագործում է CRLF տողերի միջև և դատարկ տող վերջում․

b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"

Տեղադրեք ցանկացած լիազորման դաշտ այդ վերջին դատարկ տողից առաջ՝ առանց ներկառուցված տողադարձի։ Python-ում "\n" ներկայացնում է նոր տող. հակադարձ շեղ և n տառ պարունակող չմշակված տողը՝ ոչ։ Ստուգեք, թե ինչ բայթեր է արտադրում կոդավորման օգնականը, նախքան դրանք հեռացնելը փորձելը—հին օգնականները կարող էին տողադարձեր ավելացնել։

CONNECT-ի հաջողությունից հետո այդ մնացած բայթերը պատկանում են թունելի արձանագրությանը։ Մոլորված բաց տեքստը կարող է հասնել TLS սպասող գործընկերոջը։ Հաջող կարգավիճակը չի կարող վերականգնել սխալ ձևավորված հարցումից հետո արդեն հերթագրված բայթերը։

Ստուգեք նաև ընդունման սահմանը։ Կարդացեք պրոքսի ամբողջական պատասխանը՝ նախքան սոկետը TLS-ին հանձնելը, կարգավորեք մասնակի ընթերցումները և պահպանեք այն ամենը, ինչ կարդացվել է վերնագրերից հետո։ Մեկ սոկետի ընթերցումը պարտադիր չէ, որ պարունակի մեկ ամբողջ հաղորդագրություն։

Եթե այս պարսերիչը ձերն է, համեմատեք խմբագրված բայթային ներկայացումը լարային քերականության հետ. ցուցադրեք երկարություններն ու տողերի սահմանները՝ թաքցնելով գաղտնաբառը։ Հավելվածի համար, որին պետք է միայն պրոքսի միացում, պահպանվող միակցիչը խուսափում է այս ձևավորման կոդին տիրապետելու անհրաժեշտությունից։