AES-256이 VPN 암호화 스위트를 설명하지 못하는 이유
스위트는 네 가지 역할을 맡는다. 대량 암호화, 무결성, 키 설정, 상대방 인증이다. 암호 이름은 그중 하나만, 한 계층에서 덮는다.
VPN이 어떤 암호화를 쓰는지 물으면 답은 보통 한 단어로 돌아온다. AES-256, 혹은 ChaCha20, 어쩌면 WireGuard다. 그 답은 한 계층의 한 부품을 지목할 뿐이고, 연결을 실제로 지키는 것은 네 가지 서로 다른 역할을 맡는 알고리즘의 집합이다. 부품과 구성을 혼동하는 것이 이런 대화에서 가장 흔한 실수이며, 결판나지 않는 비교를 낳는다.
하나의 연결 안에 있는 네 가지 일
대량 암호화는 데이터 채널을 위해 평문을 암호문으로 바꾸고, 그 키는 전송되지 않고 유도된다. 무결성 보호는 변조를 탐지하는데, 하나의 구성이 둘을 함께 하더라도 이는 별개의 일이다. 키 설정은 공유 트래픽 재료를 만들고, 상대방 인증은 반대편이 누구인지 정한다. 이 중 하나라도 빠지면 나머지가 아무리 강해도 연결은 안전하지 않다.
어떤 설계는 두 역할을 하나로 합친다. AES-GCM과 ChaCha20-Poly1305는 인증 암호 구성이라 기밀성과 무결성이 함께 온다. AES-CBC는 그렇지 않아 자체 키를 가진 별도의 메시지 인증 코드가 필요하다. 그래서 제안을 독립된 숫자의 자루로 읽으면 쌍으로 설계된 것들을 잘못 읽는다.
역할은 계층도 다르다. 그래서 같은 단어가 두 제품에서 다른 뜻일 수 있다. ESP 안의 블록 암호와 TLS 안의 블록 암호는 요구가 다른 서로 다른 협상에서 같은 기본 요소다. 그래서 모드와 계층을 빼고 기본 요소만 인용하면 아무것도 인용하지 않는 것보다 나쁠 수 있다.
암호 이름이 거의 아무것도 말하지 않는 이유
AES-256이라는 표현을 잠시 진지하게 받아들여 보자. 그것은 블록 암호와 키 길이를 가리킨다. 동작 모드, 무결성 제공 여부, 키가 어떻게 설정되고 상대가 어떻게 인증되었는지는 말하지 않는다. 두 제품이 모두 AES-256을 광고하면서 나머지 모든 점에서 다를 수 있다. 인증 없는 모드와 짝지은 것도, 현대적 키 교환을 갖춘 AEAD 모드를 쓰는 것도 있다.
TLS 1.3은 이 분리를 표준으로 끌어들였다. 옛 용어를 배운 사람에게 유용한 교정이다. 그 암호 스위트는 AEAD와 해시만 이름 붙이고, 키 교환 그룹과 서명 알고리즘은 별도 매개변수로 협상된다. 그래서 TLS 1.3 스위트 이름은 TLS 1.2 스위트 이름과 같은 조건에서 비교할 수 없다. 둘 다 설정 파일의 같은 필드에 나타나더라도 그렇다. 두 문자열을 곧바로 비교하는 감사자는 프로토콜이 뒷받침하지 않는 결론에 이른다. 협상된 그룹과 서명 매개변수도 읽어야 비교가 완전해진다.
WireGuard는 반대 길을 택해 협상을 거의 완전히 없앤다. 프로토콜이 고정된 알고리즘 집합을 정하므로 두 구현은 함께 동작하거나 아니거나 둘 중 하나다. 이는 정당한 설계 선택이며, WireGuard가 어떤 스위트를 협상하는가라는 질문에 비교할 만한 답이 없다는 뜻이기도 하다. 감사한다면, 명세를 한 번 읽고 그 주변의 키 처리를 감사하라. 협상이 아니라.
용어를 정하는 것은 계층이다
IPsec 배포는 두 번 협상한다. 제어 채널을 위한 IKE 제안과 데이터를 위한 ESP 변환이며, 둘은 정당하게 다를 수 있다. 앞의 것을 읽고 뒤의 것을 설명한다고 가정하는 것은 감사 중 혼란의 흔한 원인이다. 설정 파일이 둘 다 언급하고 흥미로운 쪽은 뒤의 것이기 때문이다.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
한 라이브러리에서 쓸 수 있는 이름이 다른 데이터 경로에 자동으로 구현되지는 않는다. 그래서 우리 제품이 AES-256을 지원한다는 주장은 들리는 것보다 약하고, 그래서 상호운용 문제는 보통 양쪽에서 모든 옛 알고리즘을 켜는 대신 유지되는 교집합을 찾아 해결된다.
TLS 1.3 명세는 이 분리의 가장 분명한 공개 사례다. 스위트를 쌍으로 정의하고 나머지를 자체 협상으로 옮긴다. 그 형태가 익숙해지면 IPsec 제안과 WireGuard의 하나의 고정 집합은 같은 발상의 변형으로 읽힌다.
협상된 결과를 읽고 멈춰라
설정된 제안은 두 상대가 무엇을 골랐는지의 증거가 아니다. 살아 있는 세션이 답을 지니며, 주요 구현은 패킷을 잡지 않고도 그것을 보고할 수 있다.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show출력에서는 제시된 목록이 아니라 선택된 알고리즘을 읽어라. 답이 정책이 의도한 것보다 약하면 수정은 어느 한쪽의 제안 설정에 있고, 현대 구현에서 불일치는 보통 조용한 하향이 아니라 협상 실패로 나타난다.
그다음 스위트가 덮지 않는 것을 기억하라. 경로, 앱 권한, 기록, 보존은 각자의 검토가 있는 별개의 결정이며, 호환되는 암호 구성은 그것들에 대해 아무것도 말하지 않는다. 암호 논의는 할 만하지만, 대부분이 실제로 묻는 질문보다 좁은 질문에 답한다.
용어를 정확히 유지하면 논증은 짧아진다. 스위트는 계층 위의 역할 집합이고, 암호는 하나의 부품이며, 협상된 결과만이 실제로 가진 연결을 설명한다. 비교에서 나머지는 모두 장식이다.