VPN과 Tor는 HTTPS를 대신하지 않는다: 각 계층이 끝나는 곳
터널은 자기 쪽 상대에서 끝나고 Tor 회선은 출구 릴레이에서 끝난다. 사이트에 닿는 것은 HTTPS뿐이므로 평문 양식은 읽을 수 있는 채로 남는다.
VPN과 Tor 회선은 둘 다 여정의 일부에서 트래픽을 암호화한다. 둘 다 자기가 고른 상대에서 암호화를 멈춘다. HTTPS는 사이트 자체에 닿는 계층이며, 그 앞에 아무리 터널을 쌓아도 평문 양식 제출이 보호된 제출이 되지는 않는다. 각 계층이 끝나는 지점까지 따라가 보면 그것이 분명해진다.
세 계층, 세 가지 다른 종단점
일반적인 VPN은 VPN 서버에서 터널을 끝낸다. 기기와 그 서버 사이의 모든 것은 터널 안에 있고, 그 뒤의 모든 것은 그렇지 않다. Tor 회선은 다른 상대와 같은 방식으로 동작하며 출구 릴레이에서 네트워크를 떠나 요청을 목적지로 전달한다.
TLS는 사이트에서 끝난다. 검증한 인증서는 호스트 이름을 사이트가 통제하는 키에 묶고, 세션 키는 브라우저와 그 서버 사이에 존재한다. 그 종단점은 VPN 서버와 Tor 출구 모두의 너머에 있다.
따라서 세 계층은 서로 다른 세 개의 신뢰 경계를 가지며, 하나의 요청은 차례로 그 모두를 통과한다. 하나를 강화한다고 다른 것에 대해 말할 수 없고, 마지막 계층만이 목적지가 참여하는 계층이다.
마지막 도약이 드러내는 것
응용 프로그램이 평문 HTTP를 쓰면 출구 너머의 내용은 그 도약을 운영하는 누구나 읽을 수 있다. 앞선 터널은 자기 일을 완벽히 했고 그저 더 이상 존재하지 않을 뿐이다. HTTP 양식에 입력한 자격 증명은 보호가 끝난 바로 그 지점에서 노출된다.
| Layer | Terminates at | Who can read the request there |
|---|---|---|
| VPN tunnel | The VPN server you selected | The operator of that server, and anyone who can compel them |
| Tor circuit | An exit relay chosen by the network | The exit relay operator, for traffic that is not otherwise protected |
| HTTPS | The website's own TLS endpoint | The site itself, and no intermediary on the path |
올바르게 검증된 HTTPS에서는 경로 위의 중개자가 응용 프로그램 내용을 읽거나 조용히 바꿀 수 없다. 그래도 그것은 당신이 언제 어느 주소로 접속했는지를 본다. 패킷 헤더는 라우팅 가능해야 하기 때문이다. 내용의 기밀성과 연결에 관한 메타데이터는 다른 속성이며, TLS가 제공하는 것은 첫 번째뿐이다.
계정 신원은 또 세 번째 문제다. 계정에 로그인하면 어떤 출구 주소를 썼든 그 서비스에 당신이 누구인지 알려진다, 그래서 출구는 계정이 아니라 네트워크 경로를 보호한다. 그 구분은 앞에 몇 개의 계층이 있든 유지된다. 출구를 바꾸어도 로그인된 세션이 드러내는 것은 결코 바뀌지 않는다. 서비스는 첫 패킷이 떠나기 전부터 당신이 누구인지 알고 있었다.
이 배치에서 두 번째 터널을 더한다고 깨지는 것은 없다. 달라지는 것은 어느 관찰자가 첫 도약을 보느냐이고, 마지막 도약이 암호화되었느냐가 아니다.
순서는 관찰자를 바꿀 뿐 종단점은 바꾸지 않는다
VPN과 Tor를 연결하는 것은 네트워크 수준에서 누가 무엇을 보는지 바꾸는 정당한 방법이다. VPN 위에서 Tor를 돌리면 Tor를 쓴다는 사실이 접속 네트워크에서 숨고, Tor 위에서 VPN을 돌리면 VPN 제공자에게서 당신의 주소가 숨는다. 두 순서 모두 공개 문서에 설명되어 있고 둘 다 성능과 장애 동작에서 절충이 있다.
어느 순서도 TLS 종단점을 옮기지 않는다. 두 경우 모두 브라우저는 요청한 호스트 이름의 인증서를 여전히 검증하고, 두 경우 모두 HTTP 주소는 마지막 릴레이 너머에서도 내용을 평문으로 보낸다. 조합은 관찰자 목록을 바꾸지만 목적지의 계층 수를 바꾸지는 않는다.
그래서 연결에 관한 조언은 대개 일반적 안전이 아니라 위협 모델에 관한 것이다. 더 긴 사슬은 같은 것의 더 강한 판본이 아니다, 그리고 응용 프로그램이 고른 프로토콜을 대신하지도 않는다.
curl -sSI https://example.net | head -3
openssl s_client -connect example.net:443 -servername example.net -brief
두 명령 모두 목적지에서 중요한 계층을 보여 준다. 두 번째는 어떤 터널도 끌어들이지 않고 협상된 프로토콜을 출력한다. 어느 것도 당신이 쓴 출구에 대해 아무것도 말하지 않는다.
문제를 찾는 동안 검증을 계속 작동시켜라
인증서 경고는 당신이 곧 만들 연결에 관한 정보다. 호스트 이름 불일치, 시계 문제, 신뢰할 수 없는 사슬, 가로채기 시도일 수 있다. VPN이 연결되어 있다는 이유로 영구 예외를 추가하면 그 경우들을 구별했을 유일한 신호를 없앤다.
Tor Browser의 보안 연결 기능과 경고가 존재하는 이유도 같으며, 페이지를 불러오려고 그것을 끄는 것은 보이는 실패를 보이지 않는 실패로 바꾸는 일이다. 예외 없이 사이트에 닿을 수 없다면 정직한 결론은 연결이 검증 불가능하다는 것이지 터널이 그것을 안전하게 만들었다는 것이 아니다.
암호화도 의도에 대해 아무것도 말하지 않는다. 속이는 사이트로 가는 유효한 HTTPS 연결은 당신의 데이터를 완벽한 기밀성으로 그 사이트에 전달한다. 자물쇠가 있는지만이 아니라 주소와 무엇을 제출하는지 확인하라.
Onion 서비스는 정말로 다른 모델이다. 보통의 공개 출구 없이 Tor 네트워크를 통해 닿으며, 그것은 Tor로 공개 사이트에 접속하는 것과 같지 않다. 같은 방문의 더 강한 판본이 아니라 자기 기대를 가진 별개의 사례로 다루어라.
어떤 구성에서도 살아남는 규칙은 짧다. 브라우저 검증을 그대로 두라. 각 계층은 실제로 끝나는 곳으로 판단하라.