Jedan dodatni novi red može slomiti 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, pregledajte 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 retka 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 redaka i prazan redak 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 retka, bez ugrađenog prijeloma retka. U Pythonu "\n" predstavlja novi red; sirovi niz 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 redaka.
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 cijeli proxy odgovor prije nego predate socket TLS-u, rukujte djelomičnim čitanjima i sačuvajte sve što je pročitano iza zaglavlja. Jedno čitanje socketa ne mora sadržavati cijelu poruku.
Ako posjedujete ovaj parser, usporedite redigirani prikaz bajtova s gramatikom žice; držite duljine i granice redaka vidljivima dok skrivate lozinku. Za aplikaciju kojoj treba samo proxy veza, održavani konektor izbjegava potrebu da posjedujete ovaj kod za uokvirivanje.