터널이 암호화하는 것과 읽히는 채로 남기는 것

터널은 켜져 있고 한 탭에는 초록 자물쇠가 보이는데, 다른 탭의 평범한 HTTP 페이지는 여전히 연결이 안전하지 않다고 경고합니다. 이 조합이 사람들을 혼란스럽게 하는 이유는 두 보호가 서로 다른 거리를 덮기 때문입니다. VPN은 자기 끝점 사이의 트래픽을 보호하고, 출구 너머에서는 트래픽이 다시 평범해집니다. HTTPS는 하나의 연결을 웹사이트까지 보호합니다. 이 두 사실을 나란히 놓으면 VPN이 실제로 무엇을 감추는지에 관한 대부분의 질문이 설명됩니다.

터널이 실제로 덮는 범위

클라이언트와 VPN 피어 사이에서 관찰자는 읽을 수 있는 요청이 아니라 암호화된 바이트를 봅니다. 이것은 터널이 지나는 구간을 덮으며, 보통 당신이 통제하지 않는 부분입니다. VPN 출구와 웹사이트 사이의 연결까지 이어지지는 않는데, 터널이 출구에서 끝났기 때문입니다. 바이트는 터널이 끝나는 순간부터 다시 읽을 수 있게 됩니다. 이것은 잘못된 설정이 아닙니다.

출구는 복호화하고 전달하는 기계이며, VPN은 바로 그런 용도입니다. 전달하는 모든 것은 받은 그 형태로 출구에 보이므로, 평범한 HTTP 요청은 출구부터 평문으로 남습니다.

이것을 결함이 아니라 성질로 읽으십시오. 암호화는 하나의 경로에 한정되고, 경로는 서비스가 시작되는 곳에서 끝납니다.

키, nonce, 무결성을 쉬운 말로

진행 중인 트래픽은 대칭 암호로 보호되며, 양쪽 끝은 핸드셰이크 동안 키 재료를 도출하거나 얻습니다. RFC 5116이 일반적으로 설명하는 인증 암호화는 하나의 구성으로 기밀성과 무결성을 제공합니다. 수신자는 변조된 바이트를 단지 읽지 못하는 것이 아니라 거부하며, 사람들이 암호화를 뒤섞기라고 생각할 때 잊는 부분이 바로 이것입니다.

키는 그 교환에서 나오며, 로그인 때 입력한 비밀번호에서 나오지 않습니다. 비밀번호는 신원을 인증하고, 그다음 프로토콜이 세션 재료를 수립합니다. 임시 키 교환이 전방 비밀성을 제공하므로, 기록된 세션은 나중에 장기 키가 유출되어도 읽을 수 없는 상태로 남습니다.

명세서의 큰 숫자는 그 질문들 중 어느 것에도 답하지 않으며, 무관한 알고리즘의 숫자를 비교하는 것은 순위가 아닙니다. 대신 키 교환이 무엇을 제공하는지 물으십시오.

터널이 끝나는 곳

터널을 종료하는 끝점은 전달하는 내용을 읽을 수 있습니다. 이것은 기업 게이트웨이, 상용 공급자, 자체 호스팅 서버 모두에 똑같이 해당합니다. 설계이며 결함이 아닙니다. 강한 암호로도 침해된 끝점이 도착하는 평문을 읽는 것을 막을 수는 없습니다. 보호가 멈추는 곳이 바로 끝점이기 때문입니다.

HTTPS는 그 지점 너머로 계속됩니다. 그래서 VPN 없이도 적대적인 네트워크에서 사이트가 안전할 수 있습니다. 두 보호는 첫 구간에서 겹치고, 출구 이후에는 하나만 계속됩니다.

연결을 살리려고 인증서 검증을 약화하는 것이 터널의 시험이 아닌 이유도 같습니다. 그것은 다른 보호를 끄고 시작보다 적은 상태로 남깁니다.

익명성이 다른 제품인 이유

주소, 시간, 양은 터널 밖에서 계속 관찰할 수 있습니다. 관찰자는 트래픽이 VPN 끝점으로 흐르는 것, 대략 얼마나, 언제인지를 볼 수 있습니다. 내용을 읽을 수 없어도 패턴은 여전히 정보를 담습니다.

공급자도 당신의 네트워크와 다른 곳에 있으므로, 이는 관찰자의 교체이지 관찰의 제거가 아닙니다. 쿠키, 로그인, 계정 식별자는 이전과 똑같이 작동합니다. 터널이 그것들을 바꾸겠다고 약속한 적이 없기 때문입니다.

그것이 요구 사항이라면 로깅 정책과 관할권으로 공급자를 고르고, 그다음 정책 자체를 읽으십시오. 마케팅 페이지는 누구나 검증할 수 있는 방식으로 그 질문에 답하는 경우가 드뭅니다.

터널과 사이트를 따로 확인하십시오

먼저 터널을 검증해 어떤 보호를 시험하는지 아십시오. 그다음 사이트 자체의 전송을 검증하고, 하나가 다른 하나를 의미한다고 가정하지 말고 두 결과를 비교하십시오. 평문 HTTP를 나르는 터널과 HTTPS를 제공하는 사이트는 둘 다 설정된 그대로 동작합니다.

시험이 허용된 호스트를 대상으로 점검을 실행하고, 요약이 아니라 출력을 읽으십시오.

wg show
ip -brief addr show tun0
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com

터널이 켜져 있고 사이트가 HTTPS라면 첫 구간에 두 개의 보호가 있고 둘째 구간에 하나가 있습니다. 사이트가 평문 HTTP라면 둘째 구간은 그 안에 있는 누구에게나 읽히며, 요청을 전달한 출구도 포함됩니다. 둘 중 무엇이 빠졌는지 아는 것이 진단의 전부이며, 새 클라이언트가 아니라 두 개의 명령이 필요합니다.