En extra ny rad kan bryta TLS efter CONNECT
Granska HTTP-huvudramningen när en handskriven proxyanslutning öppnar en tunnel och omedelbart ger ett TLS-avkodningsfel.
När CONNECT returnerar 200 och TLS omedelbart inte kan avkoda, granska gränsbyten i anslutningen innan du byter certifikat eller chiffer.
Ett genererat auktoriseringsvärde kan redan sluta med en ny rad. Att lägga till ännu ett radslut kan avsluta HTTP-huvudena för tidigt och lämna ett avsett Host-fält eller annan klartext bakom begäran.
En minimal HTTP/1.1 CONNECT-begäran använder CRLF mellan rader och en tom rad i slutet:
b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"Placera alla auktoriseringsfält före den sista tomma raden, utan inbäddad radbrytning. I Python representerar "\n" en ny rad; en rå sträng med ett bakstreck och bokstaven n gör det inte. Kontrollera vilka byte en kodningshjälp producerar innan du försöker ta bort dem—äldre hjälpmedel kunde lägga till radbrytningar.
När CONNECT lyckas tillhör de återstående byten tunnelprotokollet. Klartext på avvägar kan nå en part som väntar på TLS. Den lyckade statusen kan inte reparera byte som redan står i kö efter en felaktig begäran.
Granska även mottagningsgränsen. Läs hela proxy-svaret innan du lämnar socketen till TLS, hantera partiella läsningar och bevara allt som läses bortom huvudena. En socket-läsning behöver inte innehålla ett helt meddelande.
Om du äger den här parsern, jämför en redigerad byte-representation med trådgrammatiken; håll längder och radgränser synliga medan du döljer lösenordet. För ett program som bara behöver en proxyanslutning undviker en underhållen anslutning att behöva äga den här ramningskoden.