OpenSSL s_client: 프록시 403은 목적지 TLS보다 먼저 발생한다
OpenSSL 프록시를 통한 CONNECT의 403을 터널 단계의 실패로 해석하고, 시작조차 되지 않은 핸드셰이크로 목적지 인증서를 진단하지 마십시오.
만약 openssl s_client 이 프록시 CONNECT 요청에 대한 응답으로 HTTP 403을 받으면, 그 거부에서부터 출발하십시오. 요청한 터널은 수립되지 않았습니다.
-proxy 옵션을 주면 s_client는 먼저 HTTP 프록시에 -connect 로 지정한 목적지로 연결해 달라고 요청합니다. 성공한 CONNECT 응답만이 이 교환을 목적지 TLS 핸드셰이크용 터널로 전환합니다.
이 순서를 알면 그렇지 않으면 당혹스러운 출력이 설명됩니다: 프록시 오류 뒤에 TLS 관련 제목이 이어지거나, 피어 인증서가 없거나, 안심되는 듯한 검증 줄이 나오는 경우입니다. 그 필드들은 목적지 인증서가 수신되고 검증되었다는 것을 입증하지 않습니다. 작업은 더 이른 단계에서 멈춘 것입니다.
프록시 응답과 요청한 목적지 호스트 및 포트를 기록하십시오. 403은 프록시의 접근 결정으로 주의를 돌리고, 407은 프록시 인증을 요구합니다. 둘 다 목적지 인증서 검증을 끄는 것으로 해결되지 않습니다.
교환을 검사할 수 있는 상황이라면 s_client의 -debug 출력이 거부를 드러내는 데 도움이 될 수 있습니다. 프록시 자격 증명은 공유되는 추적 기록에 남기지 마십시오. 성공한 터널이라도 그 뒤에는 자체적인 TLS와 인증서 평가가 필요하지만, 그 단계에 실제로 도달하기 전에는 진단할 목적지 인증서 체인이 없습니다.