Éin ekstra linjeskift kan øydeleggje TLS etter CONNECT
Undersøk HTTP-hovudramma når ein handskriven proxykopling opnar ein tunnel og straks gir ein TLS-dekodingsfeil.
Når CONNECT returnerer 200 og TLS straks ikkje kan dekode, undersøk grensebyta i koplinga før du byter sertifikat eller chiffer.
Ein generert autorisasjonsverdi kan allereie slutte med ei ny linje. Å leggje til endå ein linjeslutt kan avslutte HTTP-hovuda for tidleg og etterlate eit tiltenkt Host-felt eller annan klartekst bak førespurnaden.
Ein minimal HTTP/1.1 CONNECT-førespurnad brukar CRLF mellom linjer og ei tom linje til slutt:
b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"Plasser eit kva som helst autorisasjonsfelt før den siste tomme linja, utan innebygd linjeskift. I Python representerer "\n" ei ny linje; ein rå streng med ein backslash og bokstaven n gjer det ikkje. Sjekk kva byte ein kodingshjelpar produserer før du prøver å fjerne dei—eldre hjelparar kunne leggje til linjeskift.
Når CONNECT lukkast, høyrer dei resterande byta til tunnelprotokollen. Klartekst på avvegar kan nå ein part som ventar på TLS. Den vellukka statusen kan ikkje reparere byte som allereie står i kø etter ein feilforma førespurnad.
Undersøk også mottaksgrensa. Les heile proxyresponsen før du overlèt sokkelen til TLS, handsam delvise lesingar og ta vare på alt som blir lese utanfor hovuda. Éi socketlesing treng ikkje innehalde éi heil melding.
Viss du eig denne parsaren, samanlikn ein redigert byte-representasjon med leidningsgrammatikken; hald lengder og linjegrenser synlege medan du skjuler passordet. For ein applikasjon som berre treng ei proxykopling, unngår ein vedlikehalden kopling å måtte eige denne rammekoden.