Én ekstra linjeskift kan ødelegge TLS etter CONNECT
Undersøk HTTP-headerinnrammingen når en håndskrevet proxykobling åpner en tunnel og straks gir en TLS-dekodingsfeil.
Når CONNECT returnerer 200 og TLS straks ikke kan dekode, undersøk grensebytene i koblingen før du bytter sertifikater eller chiffere.
En generert autorisasjonsverdi kan allerede slutte med en ny linje. Å legge til nok en linjeslutt kan avslutte HTTP-headerne for tidlig og etterlate et tiltenkt Host-felt eller annen klartekst bak forespørselen.
En minimal HTTP/1.1 CONNECT-forespørsel bruker CRLF mellom linjer og en tom linje til slutt:
b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"Plasser ethvert autorisasjonsfelt før den siste tomme linjen, uten innebygd linjeskift. I Python representerer "\n" en ny linje; en rå streng med en backslash og bokstaven n gjør det ikke. Sjekk hvilke byte en kodingshjelper produserer før du prøver å fjerne dem—eldre hjelpere kunne legge til linjeskift.
Når CONNECT lykkes, tilhører de resterende bytene tunnelprotokollen. Klartekst på avveie kan nå en part som forventer TLS. Den vellykkede statusen kan ikke reparere byte som allerede er satt i kø etter en feilformet forespørsel.
Undersøk også mottaksgrensen. Les hele proxyresponsen før du overlater socketen til TLS, håndter delvise lesinger og bevar alt som leses utenfor headerne. Én socketlesing trenger ikke inneholde én hel melding.
Hvis du eier denne parseren, sammenlign en redigert byte-representasjon med ledningsgrammatikken; hold lengder og linjegrenser synlige mens du skjuler passordet. For en applikasjon som bare trenger en proxyforbindelse, unngår en vedlikeholdt kobling å måtte eie denne innrammingskoden.