알고리즘 이름 옆의 큰 숫자를 보고 그것이 실제로 무엇을 재는지 물어보라. 그 숫자는 어느 연결이 보호되는지, 어떤 프로토콜이 보호를 제공하는지, 클라이언트가 어떤 설정을 지원하는지 알려주지 않는다. 주장을 그중 하나에도 연결하지 못하는 페이지는 문서가 아니라 광고다. 아래 점검은 받은 요약이 무엇이든 적용할 읽기 순서이며, 특정 연결에 연결할 수 없는 첫 번째 주장이 멈춰야 할 지점이다.

주장이 어느 연결을 다루는지 확인하라

한 제품 페이지가 한 문단에서 터널 암호화, 계정 포털로 가는 HTTPS, 저장 데이터 암호화를 함께 다룰 수 있다. 이들은 서로 다른 경로와 서로 다른 저장 시스템이므로 하나의 속성이 다른 것에 대해 말해 주는 것이 없다. 경쟁사와 비교하기 전에 문장이 이 셋 중 무엇을 말하는지 정하라. 같은 단어인 암호화가 세 맥락 모두에 나타나고 매번 다른 뜻을 가진다.

터널 자체에 대해서는 문서화된 프로토콜과 문서화된 지원 보안 설정 집합을 찾아라. 이 세 가지 표기는 서로 바꿔 쓸 수 없다: 기본 집합은 사용자가 고르지 않아도 따라오고, 선택 모드는 프로필이 선택할 때만 적용되며, 협상된 결과는 연결 시 두 당사자가 합의한 것이다. 이것들을 흐리는 공급자는 보이는 것보다 적게 말한 것이다.

프로토콜과 그것이 허용하는 집합을 확인하라

비교 그래픽이 아니라 클라이언트 프로필에서 시작하라. 프로필이 프로토콜의 이름을 밝히고, 흔한 두 경우가 보여 주듯 프로토콜이 어떤 집합이 애초에 가능한지 결정한다.

PropertyIKEv2/IPsec profileWireGuard profile
Cipher suiteProposal list of encryption, integrity, PRF and DH groupFixed ChaCha20-Poly1305 with Curve25519
NegotiationThe gateway narrows the proposal at connect timeNo suite negotiation at all
Peer authenticationCertificates or a preshared secretA public key per peer

IKEv2 제안 목록은 게이트웨이가 고르는 메뉴이므로, 클라이언트 설정이 동일한 두 게이트웨이에서 받는 집합이 다를 수 있다. WireGuard에는 그런 메뉴가 없어 그 주장은 검증하기 쉽고 설명하기 좁아진다. 어느 쪽 구성도 그 자체로 더 강하지 않으며, 요점은 문서가 어느 쪽을 뜻하는지 말해야 한다는 것이다.

암호 이름만으로는 인증이 빠지고, 키 설정, 메타데이터 노출, 보존 기간도 빠진다. 현대 구성은 암호화와 무결성을 한 집합으로 묶고 오래된 구성은 그것을 분리하므로, 알고리즘 이름 하나를 인용하면 실제로 어떤 속성을 얻는지 가려질 수 있다. 페이지가 밝히지 않으면 협상 정책을 서면으로 요구하라.

상대방 인증과 업데이트 상태를 확인하라

마케팅 문구가 건너뛰어도 상대방 인증은 주장의 일부다. 검증되지 않은 수신자에게 하는 강한 암호화는 누구도 의도한 결과가 아니며, 누가 응답했는지 말할 수 없는 터널은 보이는 것보다 적게 보호한다. 클라이언트가 서버를 어떻게 검증하는지 보라: 인증서 체인, 고정된 키, 사전 공유 비밀이다. 이들은 실패 방식이 다른 서로 다른 신뢰 모델이다.

패치되지 않은 클라이언트의 문서화된 암호는 실행하지 않을 수도 있는 버전을 설명하기에, 그다음 구현과 그 업데이트 상태를 확인하라. 프로토콜 저자가 공개한 한계도 같은 이유로 읽을 가치가 있다. 한 해 동안 업데이트되지 않은 클라이언트는 눈앞의 페이지와 다른 주장을 하고 있다.

터널이 어디서 끝나는지 확인하라

클라이언트에서 서버로 가는 터널은 VPN 서버에서 끝난다. 그 뒤 서비스로 가는 HTTPS 같은 응용 프로그램 암호화는 경로 더 앞쪽의 트래픽을 보호할 수 있으며, 서버 이후에는 그것이 남은 유일한 보호일 수 있다. 운영자의 종단점 설명을 읽고 주장이 이 계층 중 어디를 가리키는지 정하라.

기록 정책과 계정 추적은 암호화 완전히 바깥에 있다. 운영자는 암호화된 내용을 나르면서 시간, 주소, 양을 관찰할 수 있으므로, 페이로드 기밀성에 관한 주장은 무엇이 기록되는지에 아무 답도 하지 않는다. 보존은 자체 증거를 가진 별도 질문으로 다루라.

문서가 말하지 않는 것을 기록하라

속성이 빠져 있으면 소프트웨어의 이름이나 평판에서 추론하지 말고 빠져 있다고 기록하라. 감사는 실제로 검토한 속성과 구성 요소만 다루며, 문서의 공백은 그 자체로 하나의 발견이다. 어느 페이지가 그것을 만들었는지 아직 기억할 때 공백을 적어 두라.

통제하는 기계에서는 클라이언트 상태 페이지나 게이트웨이의 보안 연결 목록을 사용해 실행 중인 세션에서 집합을 다시 읽고, 그 값을 클라이언트 버전 옆에 기록하라. 그 기록은 업데이트가 협상된 결과를 바꿀 때 공급자의 주장을 나중에 비교할 수 있게 만든다. 클라이언트와 문서가 어긋나면 협상된 결과를 믿고, 조용히 맞추지 말고 불일치를 보고하라.

관련 글