HTTPS, DoH, ECH, VPN은 서로 다른 것을 숨긴다
각 메커니즘은 경로에서 서로 다른 관찰자를 제거하며, 어느 것도 모두 제거하지 않는다. 다른 터널을 더하기 전에 무엇이 보호되는지 비교하라.
이미 HTTPS, DoH, ECH를 쓰는 브라우저에 VPN을 더한다고 세 가지 보호가 하나로 쌓이지는 않으며, 누가 무엇을 관찰할 수 있는 위치에 있는지가 달라질 뿐이다. 각 메커니즘은 서로 다른 교환에서 서로 다른 당사자를 제거하며, 각각은 무언가를 남긴다. 유용한 질문은 어느 것이 가장 강한가가 아니라 어떤 관찰자를 없애려는가이며, 그 답이 터널이 애초에 도움이 되는지를 결정한다. 남은 관찰자를 비교하는 편이 기능 목록보다 유용하다.
네 가지 메커니즘, 네 명의 관찰자
네 가지 관계와 각각이 밖에 두려는 당사자에서 시작하라. 아래 표는 내가 검토에서 쓰는 것으로, 대화가 기술 대신 관찰자의 이름을 대게 만들기 때문이다.
| 메커니즘 | 보호하는 관계 | 제거하지 않는 관찰자 |
|---|---|---|
| HTTPS | 애플리케이션과 지목된 종단점 사이의 TLS 연결 | 접속망은 여전히 목적지 주소를 본다 |
| DoH | 선택한 HTTPS 확인자와의 DNS 교환 | 그 확인자는 모든 질의를 본다 |
| ECH | 지원되고 수용될 때의 ClientHello 민감 필드 | 목적지 주소, 그리고 덮이지 않으면 DNS |
| VPN | VPN 피어까지 운반되는 가려진 패킷 | VPN 사업자는 목적지를 본다 |
표의 가치는 말하지 않기로 한 것에 있다. 메커니즘의 순위를 매기지 않고, 네 가지를 모두 써도 네 관찰자가 모두 사라진다고 주장하지 않는다. 자기 경계에서 이미 TLS를 끝내는 클라우드 웹 애플리케이션은 그 교환에 대해 접속망으로부터 보호되며, 어떤 터널도 그 특정 속성을 개선하지 않는다. 터널이 바꿀 수 있는 것은 바깥 패킷을 어느 망이 보는지, 그리고 지금 경로 위에 어느 사업자가 있는지다.
HTTPS가 실제로 숨기는 것
HTTPS는 클라이언트와 인증서가 지목한 종단점 사이의 애플리케이션 교환을 보호한다. 목적지 주소를 숨기지 않고, 연결이 있었다는 사실도 숨기지 않으며, ECH가 개입하지 않으면 이름도 숨기지 않는다. 인증서 검증은 보호의 일부이지 그 주변의 형식이 아니다.
VPN이 그 TLS를 끝낼 필요는 없으며, 전달하는 출구를 애플리케이션의 인증된 종단점으로 취급해서는 안 된다. 설계가 출구에서 복호화한다면 그것은 다른 신뢰 선언을 가진 다른 구조다.
DoH와 ECH가 옮기는 것과 남기는 것
DoH는 DNS 교환을 HTTPS 확인자로 옮기므로, 지역망의 확인자 대신 그 확인자가 당신의 질의를 본다. 이는 실질적이고 제한된 변화로, 선택한 확인자가 질의를 이후 접속하는 주소와 연관지을 수 있는 당사자가 되며, 바로 그것이 RFC 8484가 논의하는 연관성이다. 암호화된 전송은 응답하는 쪽이 질의를 모르게 만들지 않는다.
ECH는 ClientHello의 민감한 부분을 보호하여 경로 위의 수동적 관찰자가 의도한 서버 이름을 읽을 수 없게 한다. 지원하는 배포와 서버 및 망의 수용에 의존하며 다른 경로는 그대로 두는데, 목적지 주소는 계속 보이고 DNS가 이름을 드러낼 수도 있다.
ECH가 하지 않는 또 하나는 스스로를 증명하는 일이다. TLS 1.3을 쓰는 연결은 ECH가 수용되었다는 증거가 아니며, 지원하지 않는 서버에 ECH를 제시하는 브라우저는 조용히 물러난다. 프로토콜 버전에서 추론하지 말고 연결의 실제 상태를 확인하라.
이 비교 전체의 형태는 각 메커니즘이 자기 계층에서 검증되며, 어느 것도 다른 것의 성공으로 검증되지 않는다는 것이다.
VPN이 옮기는 것과 더하는 것
웹 트래픽이 VPN으로 들어가면 접속망은 개별 애플리케이션 연결 대신 VPN 피어와의 바깥 교환을 보고, VPN 사업자는 그 뒤 경로에서 위치를 차지한다. 이는 신뢰 경계의 이동이지 제거가 아니다. 사업자는 내용이 종단 간 암호화된 채로 남아 있어도 당신이 어느 목적지에 닿는지 본다. 그것이 개선인지는 이 두 당사자 중 누구를 더 신뢰하지 않는지에 전적으로 달려 있다.
그러는 동안 애플리케이션의 HTTPS와 의도한 확인자 보호는 그대로 두어라. 터널은 인증서 검증을 대신하지 않으며, 트래픽이 터널을 지난다고 확인자의 보호를 끄는 것은 통제를 대체 없이 없애는 일이다.
요구에서 고르기
실제 요구를 적어야 하며, 그것이 설계를 결정한다. 사설 자원에 대한 입장, 관리되는 출구 지점, 접속망의 특정 위협, 기기 인가는 서로 다른 네 가지 필요이며 네 가지 다른 답을 가지므로, 공용 클라우드 애플리케이션만 쓰는 기업도 인가와 데이터 처리는 정해야 한다. 추가 계층은 적절할 수 있지만 서로 바꿀 수 있는 것은 아니다. 더 복잡한 연결은 익명성의 척도가 아니며 그 자체로 보안 논거도 아니다.
ECH 명세인 RFC 9849는 이 메커니즘이 무엇을 덮고 덮지 않는지 알기 위해 읽을 가치가 있으며, 손대지 않는 경로에 대해 정직하다. 각 메커니즘이 제거하는 관찰자로 비교하고, 그 관찰자를 적은 뒤, 추가 계층이 그것을 다루는지 결정하라. 그 관찰자가 이미 위협 모델 밖에 있었다면 터널은 이득 없는 비용이다.