Një rresht i ri shtesë mund të thyejë TLS pas CONNECT

Kur CONNECT kthen 200 dhe TLS nuk arrin të dekodojë menjëherë, inspektoni bajtët kufitarë në lidhës përpara se të ndryshoni certifikatat ose shifrat.

Një vlerë autorizimi e gjeneruar mund të përfundojë tashmë me një rresht të ri. Shtimi i një tjetër fundi rreshti mund t'i përfundojë kokave HTTP shumë herët, duke lënë një fushë Host të synuar ose tekst tjetër të thjeshtë pas kërkesës.

Një kërkesë minimale HTTP/1.1 CONNECT përdor CRLF ndërmjet rreshtave dhe një rresht bosh në fund:

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

Vendosni çdo fushë autorizimi përpara atij rreshti bosh të fundit, pa ndërprerje rreshti të integruar. Në Python, "\n" përfaqëson një rresht të ri; një varg i papërpunuar që përmban një backslash dhe shkronjën n jo. Kontrolloni çfarë bajtësh prodhon një ndihmës kodimi përpara se t'i hiqni—ndihmësat më të vjetër mund të shtonin ndërprerje rreshtash.

Pasi CONNECT të ketë sukses, ato bajtë të mbetur i përkasin protokollit të tunelit. Teksti i thjeshtë i humbur mund të arrijë një partner që pret TLS. Statusi i suksesshëm nuk mund të rregullojë bajtë që janë tashmë në radhë pas një kërkese të keqformuar.

Inspektoni edhe kufirin e marrjes. Lexoni përgjigjen e plotë të proxy përpara se t'ia dorëzoni socket-in TLS, trajtoni leximet e pjesshme dhe ruani çdo gjë që lexohet përtej kokave. Një lexim i vetëm socket nuk duhet të përmbajë një mesazh të plotë.

Nëse ky parser është i juaji, krahasoni një paraqitje të redaktuar të bajtëve me gramatikën e telit; mbani gjatësitë dhe kufijtë e rreshtave të dukshëm duke fshehur fjalëkalimin. Për një aplikacion që ka nevojë vetëm për një lidhje proxy, një lidhës i mirëmbajtur shmang nevojën për të zotëruar këtë kod kornizimi.