Ien ekstra nije rigel kin TLS nei CONNECT brekke
Undersykje HTTP-koptekstframing as in mei de hân skreaune proxyconnector in tunnel iepenet en daliks in TLS-dekodaasjeflater jout.
As CONNECT 200 weromjout en TLS daliks net dekodearje kin, ûndersykje dan de grinsbytes yn 'e connector foardat jo sertifikaten of sifers feroarje.
In generearre autorisaasjewearde kin al mei in nije rigel einigje. It tafoegjen fan noch in rigelein kin de HTTP-kopteksten te betiid ôfslute, wêrtroch in bedoeld Host-fjild of oare platte tekst efter it fersyk efterbliuwt.
In minimaal HTTP/1.1 CONNECT-fersyk brûkt CRLF tusken rigels en in lege rigel oan 'e ein:
b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"Pleatsearje elk autorisaasjefjild foar dy lêste lege rigel, sûnder ynbêde rigelbrek. Yn Python stiet "\n" foar in nije rigel; in rauwe string mei in backslash en de letter n net. Kontrollearje hokker bytes in kodearringshulp produsearret foardat jo se besykje te strippen—âldere helpmiddels koenen rigelbrekken tafoegje.
As CONNECT slagget, hearre dy oerbliuwende bytes by it tunnelprotokol. Fertuttele platte tekst kin in peer berikke dy't TLS ferwachtet. De suksesfolle status kin bytes dy't al yn 'e wachtrige steane nei in ferkeard fersyk net reparearje.
Undersykje ek de ûntfangstgrins. Lês it folsleine proxy-antwurd foardat jo de socket oan TLS jouwe, behannelje foar in part lêzen en bewarje alles wat efter de kopteksten lêzen wurdt. Ien socketlêzing hoecht net ien hiel berjocht te befetsjen.
As jo eigenare fan dizze parser binne, fergelykje dan in redigearre bytewerjefte mei de draadgrammatika; hâld lingten en rigelgrinzen sichtber wylst jo it wachtwurd ferbergje. Foar in applikaasje dy't allinnich in proxyferbining nedich hat, foarkomt in ûnderhâlden connector dat jo dizze framingkoade besitte moatte.