VPN 터널이 끝난 뒤에도 HTTPS가 중요한 이유

녹색 VPN 표시, 프라이버시 느낌, 그다음 브라우저가 은행 사이트에서 인증서 경고를 띄운다. 그 경고에서 터널 덕분에 나아지는 것은 없다. VPN은 기기에서 자기 서버까지의 경로를 보호하고, HTTPS는 브라우저에서 웹사이트의 TLS 종단까지의 요청을 보호한다. 둘은 여정의 서로 다른 구간을 덮으며, 하나가 다른 하나를 대신하지 않는다.

양 끝이 다른 두 개의 터널

VPN 터널은 VPN 서버에서 끝난다. 그 지점을 지나면 트래픽은 평범한 인터넷을 통해 목적지로 계속 간다. VPN 사업자는 내용을 읽을 수 없어도 연결 메타데이터는 본다.

HTTPS는 브라우저에서 시작해 웹사이트의 TLS 종단에서 끝난다. 패킷이 서버에 어떻게 도착했는지는 상관하지 않고, VPN의 존재에 의존하지도 않는다.

그래서 두 보호는 경쟁하는 대신 서로를 보완한다. VPN은 요청을 로컬 네트워크와 ISP로부터 자기 출구까지 숨긴다. HTTPS는 그 출구 이후의 모든 관찰자로부터, VPN 제공자 자신까지 포함해 숨긴다. 어느 것도 다른 쪽의 빈틈을 덮지 않는다. 이를 이해한 사람은 어느 쪽이면 충분한지 묻기를 멈춘다.

평범한 HTTP 양식은 출구를 지나도 평범하다

HTTP로 양식을 받는 오래된 사이트는 VPN 서버 너머에서 보호되지 않는다. 터널은 양식을 출구까지 운반하고, 나머지 경로는 그것을 평문으로 운반한다.

민감한 것에는 진짜 HTTPS 버전이나 다른 공식 채널을 써야 한다.

연결 표시는 애플리케이션의 전송 방식을 바꾸지 않는다. 브라우저의 HTTPS 전용 모드는 우발적 후퇴를 막는 데 도움이 되지만, TLS를 한 번도 제공하지 않은 사이트를 고칠 수는 없다.

인증서 경고는 VPN으로 고쳐지지 않는다

잘못된 호스트 이름, 만료된 인증서, 기울어진 기기 시계, 가로채기 모두 검증 실패를 일으킬 수 있다. VPN은 그중 어느 것도 무해하게 만들지 않는다.

무엇보다 먼저 정확한 주소와 시스템 시계를 확인한다.

네트워크 로그인 페이지가 관련되면 플랫폼의 일반 캡티브 포털 흐름을 쓴다. 호텔 네트워크가 요청했다고 해서 무관한 계정 사이트에 영구 예외를 주지 않는다.

관리되는 기기에서는 검사용 인증서가 설치되어 있는지 묻는다. 그것은 평소의 신뢰 체계를 바꾸며, 어깨를 으쓱하는 대신 구체적인 설명을 들을 자격이 있다. 인증서의 목적과 소유자가 누구인지 묻는다.

암호화는 추적을 멈추지 않는다

세션은 쿠키, 로그인, 양식 데이터를 의도한 그대로 사이트로 운반한다. 추적자도 암호화된 연결에 올라탈 수 있고, 대부분 그렇게 한다.

VPN은 경로와 겉으로 보이는 출구 주소를 바꾼다. 계정을 통해 제공하는 신원을 바꾸지 않으며, 사이트 사이에서 따라다니는 쿠키를 지우지도 않는다.

이미 쓰고 있는 브라우저 보호를 그대로 두자. VPN은 거기에 더하는 것이지 대체가 아니다.

표시가 아니라 주소를 확인하라

주소 표시줄의 호스트 이름과 사이트가 제시하는 인증서를 확인한다. 자물쇠는 연결이 어느 종단까지 암호화되었다는 것만 뜻하며, 그 종단이 의도한 종단이라는 뜻은 아니다.

두 명령이 인증서와 리디렉션 사슬을 보여준다:

curl -sSI https://bank.example/ | head -5
openssl s_client -connect bank.example:443 -servername bank.example < /dev/null 2>/dev/null | openssl x509 -noout -subject -dates

인증서가 다른 호스트를 가리키면 멈춘다. 시계가 틀렸다면 다시 시도하기 전에 고친다. 리디렉션이 평문 HTTP로 보낸다면 검증을 끄는 이유가 아니라 사이트의 실패로 본다. 브라우저 경고가 있는 이유는 그 대안이 어느 종단이 비밀번호를 받았는지 추측하는 것이기 때문이다.