Un solo newline in più può rompere TLS dopo CONNECT
Ispeziona l'incorniciatura delle intestazioni HTTP quando un connettore proxy scritto a mano apre un tunnel e produce subito un errore di decodifica TLS.
Quando CONNECT restituisce 200 e TLS non riesce subito a decodificare, ispeziona i byte di confine nel connettore prima di cambiare certificati o cifrari.
Un valore di autorizzazione generato può già terminare con un newline. Aggiungere un altro fine riga può chiudere le intestazioni HTTP in anticipo, lasciando un campo Host previsto o altro testo in chiaro dietro la richiesta.
Una richiesta HTTP/1.1 CONNECT minima usa CRLF tra le righe e una riga vuota alla fine:
b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"Metti qualsiasi campo di autorizzazione prima di quell'ultima riga vuota, senza interruzioni di riga incorporate. In Python, "\n" rappresenta un newline; una stringa grezza contenente una barra rovesciata e la lettera n no. Controlla quali byte produce un helper di codifica prima di provare a rimuoverli—gli helper più vecchi potevano aggiungere interruzioni di riga.
Una volta che CONNECT riesce, quei byte rimanenti appartengono al protocollo del tunnel. Un testo in chiaro disperso può raggiungere un peer che si aspetta TLS. Lo stato di successo non può riparare i byte già accodati dopo una richiesta malformata.
Ispeziona anche il confine di ricezione. Leggi la risposta completa del proxy prima di consegnare il socket a TLS, gestisci le letture parziali e conserva tutto ciò che viene letto oltre le intestazioni. Una singola lettura del socket non deve contenere un intero messaggio.
Se questo parser è tuo, confronta una rappresentazione dei byte oscurata con la grammatica del filo; mantieni visibili lunghezze e confini di riga nascondendo la password. Per un'applicazione che necessita solo di una connessione proxy, un connettore mantenuto evita di dover possedere questo codice di incorniciatura.