Jedan dodatni novi red može pokvariti TLS nakon CONNECT
Provjerite uokvirivanje HTTP zaglavlja kada ručno napisan proxy konektor otvori tunel i odmah proizvede grešku TLS dekodiranja.
Kada CONNECT vrati 200 i TLS odmah ne uspije dekodirati, provjerite granične bajtove u konektoru prije nego promijenite certifikate ili šifre.
Generirana vrijednost autorizacije može već završavati novim redom. Dodavanje još jednog kraja reda može prerano završiti HTTP zaglavlja i ostaviti željeno polje Host ili drugi otvoreni tekst iza zahtjeva.
Minimalni HTTP/1.1 CONNECT zahtjev koristi CRLF između redova i prazan red na kraju:
b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"Stavite bilo koje polje autorizacije prije tog završnog praznog reda, bez ugrađenog prijeloma reda. U Pythonu "\n" predstavlja novi red; sirovi string s backslashom i slovom n ne. Provjerite koje bajtove proizvodi pomoćnik za kodiranje prije nego ih pokušate ukloniti—stariji pomoćnici mogli su dodati prijelome redova.
Nakon uspješnog CONNECT ti preostali bajtovi pripadaju tunelskom protokolu. Zalutali otvoreni tekst može doći do partnera koji očekuje TLS. Uspješan status ne može popraviti bajtove koji su već u redu nakon neispravnog zahtjeva.
Provjerite i granicu primanja. Pročitajte kompletan proxy odgovor prije nego predate socket TLS-u, rukujte djelimičnim čitanjima i sačuvajte sve što je pročitano iza zaglavlja. Jedno čitanje socketa ne mora sadržavati jednu cijelu poruku.
Ako posjedujete ovaj parser, uporedite redigovanu reprezentaciju bajtova s gramatikom žice; držite dužine i granice redova vidljivima dok skrivate lozinku. Za aplikaciju kojoj treba samo proxy veza, održavani konektor izbjegava potrebu da posjedujete ovaj kod za uokvirivanje.