HTTPS 프록시는 TLS 연결이 두 개이지 하나가 아니다
프록시 홉과 웹사이트는 별개의 TLS 관계이며 신뢰도 별개입니다. 인증서 설정을 바꾸기 전에 어느 끝점이 실패했는지 읽어 보십시오.
HTTPS 프록시라는 표지는 클라이언트와 프록시 사이의 전송만을 설명하며 그 이상은 말하지 않습니다. 그 뒤의 웹사이트가 같은 연결로 암호화된다고도, 프록시가 페이지를 읽을 수 있다고도 말하지 않습니다. 두 연결을 분리하면 인증서 오류는 더 이상 불가사의하지 않고 VPN과의 비교도 구체적으로 변합니다.
두 쌍의 끝점, 두 번의 검증
일반 터널 모드에는 두 개의 TLS 관계가 있습니다. 첫 번째는 클라이언트에서 프록시로 이어지며 프록시를 인증합니다. 두 번째는 클라이언트에서 터널 안의 웹사이트로 이어지며 웹사이트를 인증합니다. 둘은 독립적으로 실패하고 독립적으로 구성됩니다.
둘은 별개의 신뢰 결정, 별개의 인증서 체인, 별개의 실패 메시지를 가집니다. 조직 CA를 쓰는 프록시와 공개 체인을 쓰는 공개 웹사이트가 정당하게 다른 검증 구성을 필요로 할 수 있으며, 그것은 잘못된 구성이 아닙니다.
실제로 그렇기 때문에 같은 소켓을 우연히 공유하는 두 연결로 다루십시오.
CONNECT가 실제로 터널링하는 것
클라이언트는 호스트와 포트를 지정한 CONNECT 요청을 보내고, 프록시는 그 대상으로 TCP 연결을 엽니다. 프록시가 응답한 뒤 이어지는 바이트는 해석 없이 중계되므로 웹사이트의 TLS 핸드셰이크가 프록시를 그대로 통과합니다. 그래서 프록시는 목적지 이름과 연결 메타데이터를 알지만, 그 배치에서 복호화된 페이지를 받지는 않습니다.
그 구분이 터널 모드의 보안 논거 전부이며, 동시에 그 한계입니다.
프록시 홉에 TLS가 없는 HTTP 프록시도 CONNECT를 통해 HTTPS 웹사이트를 운반합니다. 클라이언트와 프록시 사이의 교환은 평문이지만 웹사이트 연결은 그렇지 않으며, 전체를 HTTPS 프록시라고 부르면 그 차이가 가려집니다.
어느 인증서가 실패했는가
검증이 실패하면 어떤 신뢰 설정을 바꾸기 전에 오류에 명시된 끝점을 읽으십시오. 두 실패는 터미널에서 비슷해 보이지만 전혀 다른 수정을 가리키므로, 첫 질문은 항상 어느 연결이 거부했는가입니다.
curl이 옵션을 분리한 것은 바로 이 때문입니다. 프록시의 CA 파일은 프록시 검증을 구성하고, CA 파일은 서버 검증을 구성하며, 적용되는 신뢰 저장소의 동작도 curl이 어떻게 빌드되었는지에 달려 있습니다.
curl -v --proxy https://proxy.example.net:443 \
--proxy-cacert org-ca.pem --cacert public-ca.pem https://www.example.com/검사를 억제하는 것은 수리가 아닙니다. 두 끝점 어느 쪽에 대해서도 아무것도 증명하지 않습니다.
검사는 다른 배치입니다
TLS 검사는 터널링이 아닙니다. 검사하는 중간자는 웹사이트를 향한 신뢰 관계를 종료하고 자신의 인증서를 클라이언트에 제시하므로, 클라이언트는 사이트가 아니라 중간자를 검증합니다. 승인된 설계 아래에서는 정당할 수 있지만, 바이트 단위 중계와는 본질적으로 다른 주장입니다. 모든 프록시가 검사한다고 가정하지 말고, 암호화된 프록시 홉이 그것을 배제한다고도 가정하지 마십시오.
신뢰 저장소의 조직 CA는 어떤 배치에 있는지에 대한 단서일 뿐 증거가 아닙니다. 인증서 체인에서 추론하는 대신 설계를 물으십시오.
그 두 배치는 누가 페이지를 읽을 수 있는가라는 질문에 서로 다른 답을 냅니다.
같은 네 줄로 프록시와 VPN을 비교하십시오
두 배포를 같은 방식으로 설명할 때만 비교가 유용해집니다.
| Line | What to state |
|---|---|
| Protected segments | Which hops are encrypted, and between which endpoints |
| Verified identities | What each end proves, and against which trust anchor |
| Trusted intermediaries | Who can read or alter traffic by design |
| Traffic included | Which processes and destinations the policy actually covers |
하나의 요청에 맞춰 구성된 프록시는 그 요청만 담당합니다. 기기의 모든 프로세스를 통과시키지 않으며, 예시 명령도 정확히 그만큼 좁습니다. VPN의 범위는 라우팅과 애플리케이션 정책에 달려 있으며, 이것도 가정이 아니라 확인이 필요합니다. 설치되었다는 이유만으로 어느 쪽도 모든 것을 포괄하지 않습니다.
각 선택지에 대해 네 줄을 적으면 논쟁은 대개 스스로 해결됩니다. 유용한 비교는 어느 표지가 더 암호화되어 들리는가가 아닙니다. 어떤 구간이 보호되고, 그 끝에서 누가 검증되며, 어떤 중간자를 신뢰하고, 정책이 실제로 어떤 트래픽을 포함하는가입니다.