Unu kroma linifino povas rompi TLS post CONNECT
Inspektu la kadrigon de HTTP-kapoj kiam permane skribita proksea konektilo malfermas tunelon kaj tuj produktas TLS-malkodan eraron.
Kiam CONNECT redonas 200 kaj TLS tuj malsukcesas malkodi, inspektu la limajn bajtojn en la konektilo antaŭ ol ŝanĝi atestilojn aŭ ĉifrojn.
Generita rajtiga valoro jam povas finiĝi per linifino. Aldoni alian linifinon povas fini la HTTP-kapojn tro frue, lasante celatan kampon Host aŭ alian klartekston malantaŭ la peto.
Minimuma HTTP/1.1 CONNECT-peto uzas CRLF inter linioj kaj malplenan linion ĉe la fino:
b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"Metu ajnan rajtigan kampon antaŭ tiu fina malplena linio, sen enkonstruita linifino. En Python "\n" reprezentas linifinon; kruda ĉeno enhavanta retroklavon kaj la literon n ne. Kontrolu, kiujn bajtojn kodiga helpilo produktas antaŭ ol provi forigi ilin—pli malnovaj helpiloj povis aldoni linifinojn.
Post sukcesa CONNECT, tiuj restantaj bajtoj apartenas al la tunela protokolo. Vaganta klarteksto povas atingi partneron atendantan TLS. La sukcesa statuso ne povas ripari bajtojn jam envicigitajn post misformita peto.
Inspektu ankaŭ la ricevan limon. Legu la kompletan proksean respondon antaŭ ol transdoni la ingon al TLS, traktu partajn legadojn kaj konservu ĉion legitan preter la kapoj. Unu inga legado ne devas enhavi unu tutan mesaĝon.
Se vi posedas ĉi tiun analizilon, komparu redaktitan bajtan prezenton kun la drata gramatiko; tenu longojn kaj liniobordojn videblaj dum vi kaŝas la pasvorton. Por aplikaĵo, kiu bezonas nur proksean konekton, prizorgata konektilo evitas la bezonon posedi ĉi tiun kadrigan kodon.