추가된 줄바꿈 하나가 CONNECT 이후 TLS를 깨뜨릴 수 있다

CONNECT가 200을 반환했는데 TLS가 즉시 디코드하지 못한다면, 인증서나 암호를 바꾸기 전에 커넥터의 경계 바이트를 확인하라.

생성된 인증 값이 이미 줄바꿈으로 끝나 있을 수 있다. 줄바꿈을 하나 더 붙이면 HTTP 헤더가 일찍 끝나, 의도한 Host 필드나 다른 평문이 요청 뒤에 남을 수 있다.

최소 HTTP/1.1 CONNECT 요청은 줄 사이에 CRLF를, 끝에는 빈 줄을 사용한다:

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

인증 필드는 마지막 빈 줄 앞에 두고, 내부에 줄바꿈을 넣지 않는다. Python에서 "\n"는 줄바꿈을 나타내지만, 백슬래시와 문자 n을 담은 원시 문자열은 그렇지 않다. 제거하기 전에 인코딩 도우미가 어떤 바이트를 만드는지 확인하라—오래된 도우미는 줄바꿈을 추가할 수 있었다.

CONNECT가 성공하면 남은 바이트는 터널 프로토콜에 속한다. 길을 잃은 평문이 TLS를 기대하는 피어에 도달할 수 있다. 성공 상태는 잘못된 요청 뒤에 이미 대기 중인 바이트를 복구할 수 없다.

수신 경계도 점검하라. 소켓을 TLS에 넘기기 전에 프록시 응답 전체를 읽고, 부분 읽기를 처리하며 헤더 너머로 읽은 것도 보존하라. 소켓 읽기 한 번이 메시지 하나를 온전히 담을 필요는 없다.

이 파서를 직접 관리한다면, 가린 바이트 표현을 와이어 문법과 비교하라. 비밀번호를 숨기면서도 길이와 줄 경계는 보이게 유지하라. 프록시 연결만 필요한 애플리케이션이라면, 유지 관리되는 커넥터를 쓰면 이 프레이밍 코드를 직접 소유하지 않아도 된다.