Én ekstra linjeskift kan ødelægge TLS efter CONNECT

Når CONNECT returnerer 200, og TLS straks ikke kan dekode, skal du undersøge grænsebytene i connectoren, før du skifter certifikater eller ciphers.

En genereret autorisationsværdi kan allerede slutte med en ny linje. Tilføjelse af endnu en linjeafslutning kan afslutte HTTP-headerne for tidligt og efterlade et tilsigtet Host-felt eller anden klartekst bag anmodningen.

En minimal HTTP/1.1 CONNECT-anmodning bruger CRLF mellem linjer og en tom linje til sidst:

b"CONNECT example.com:443 HTTP/1.1\r\nHost: example.com:443\r\n\r\n"

Placer ethvert autorisationsfelt før den sidste tomme linje, uden indlejret linjeskift. I Python repræsenterer "\n" en ny linje; en rå streng med en backslash og bogstavet n gør ikke. Kontroller, hvilke bytes en kodningshjælper producerer, før du forsøger at fjerne dem—ældre hjælpere kunne tilføje linjeskift.

Når CONNECT lykkes, tilhører de resterende bytes tunnelprotokollen. Klartekst på afveje kan nå en peer, der forventer TLS. Den vellykkede status kan ikke reparere bytes, der allerede er sat i kø efter en misdannet anmodning.

Undersøg også modtagelsesgrænsen. Læs det komplette proxy-svar, før du overlader socketten til TLS, håndtér delvise læsninger, og bevar alt, der læses ud over headerne. Én socket-læsning behøver ikke indeholde én hel besked.

Hvis du ejer denne parser, sammenlign en redigeret byte-repræsentation med trådgrammatikken; hold længder og linjegrænser synlige, mens du skjuler adgangskoden. Til en applikation, der kun har brug for en proxyforbindelse, undgår en vedligeholdt connector at skulle eje denne framing-kode.