프록시에서 WRONG_VERSION_NUMBER: HTTP와 HTTPS 확인

오류는 “잘못된 버전”이라고 말하므로 TLS 버전을 바꾸기 시작하고 싶어집니다. 프록시라면 더 앞선 가능성을 확인하십시오. 클라이언트가 일반 HTTP를 기다리던 포트로 TLS 핸드셰이크를 보냈는가?

https://example.com/ 같은 대상과 http://proxy.example:8080 같은 프록시는 흔한 조합입니다. 두 번째 URL을 HTTPS로 바꾸면 클라이언트는 프록시 자체와의 대화를 암호화하라는 지시를 받습니다. HTTPS 웹 사이트를 허용하라는 지시가 아닙니다.

첫 TLS 대화를 찾으십시오

HTTP 프록시에서는 클라이언트가 먼저 CONNECT를 보내고 HTTP 응답을 받을 수 있습니다. 그다음에야 터널 안에서 대상의 TLS를 시작합니다. HTTPS 프록시에서는 먼저 프록시로의 별도 TLS 연결이 옵니다.

HTTP 오류 페이지나 다른 평문을 받은 TLS 파서는 프로토콜 오류를 보고할 수 있습니다. 그 문구는 사이트가 어떤 TLS 버전을 지원하는지, 심지어 사이트에 접속했는지도 확인해 주지 않습니다.

1. 프록시 URL을 스킴까지 포함해 기록하고, 엔드포인트의 문서화된 프로토콜도 기록하십시오.
2. 실패가 CONNECT 응답 이전인지, 대상 TLS 도중인지, 프록시 자체 인증서 검증 중인지 밝히십시오.
3. 오래된 우회책과 비교할 때 실제 클라이언트와 의존성 버전을 확인하십시오. 예전 프록시 구현은 스킴을 다르게 다루기도 했습니다.

여러 수정이 서로 다른 이유로 틀릴 수 있습니다. HTTP 프록시 목록은 그러한 경로로 허용된 공개 요청을 위해 일반 HTTP 엔드포인트 후보를 제공합니다. 평문 HTTP 엔드포인트에는 HTTP 프록시 스킴이 필요하고, 실제로 TLS가 켜진 엔드포인트는 HTTPS와 인증서 검증을 유지해야 합니다. CONNECT를 거부하는 프록시에는 지원되는 서비스나 정책이 필요하며, 라이브러리를 임의로 낮출 일이 아닙니다.

처음 관찰된 실패를 유지하십시오. 인증서 검증을 끈다고 HTTP만 말하는 수신기가 TLS를 말하게 되지는 않으며, 오래된 암호 정책을 고른다고 사이트 핸드셰이크 전에 보낸 HTTP 거부가 설명되지는 않습니다.