One Extra Newline Can Break TLS After CONNECT

When CONNECT returns 200 and TLS immediately fails to decode, inspect the boundary bytes in the connector before changing certificates or ciphers.

A generated authorization value may already end in a newline. Appending another line ending can finish the HTTP headers early, leaving an intended Host field or other plaintext behind the request.

A minimal HTTP/1.1 CONNECT request uses CRLF between lines and an empty line at the end:

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

Put any authorization field before that final empty line, with no embedded line break. In Python, "\n" represents a newline; a raw string containing a backslash and the letter n does not. Check which bytes an encoding helper produces before trying to strip them—older helpers could add line breaks.

Once CONNECT succeeds, those remaining bytes belong to the tunneled protocol. Stray plaintext can reach a peer expecting TLS. The successful status cannot repair bytes already queued after a malformed request.

Inspect the receive boundary too. Read the complete proxy response before handing the socket to TLS, handling partial reads and preserving anything read beyond the headers. One socket read need not contain one whole message.

If you own this parser, compare a redacted byte representation with the wire grammar; keep lengths and line boundaries visible while hiding the password. For an application that only needs a proxy connection, a maintained connector avoids having to own this framing code.