사용자 지정 VPN 인증서는 추가 암호화 계층이 아니다

VPN 엔드포인트에 사용자 지정 인증서를 설치하면 보호가 더해진 것처럼 느껴진다. 인증서와 암호화가 어디서나 함께 등장하기 때문이다. 실제로 바뀌는 것은 두 가지다. 엔드포인트가 제시하는 신원과, 그 상대가 신뢰하려는 발급자다. 어느 쪽도 데이터를 두 번째로 감싸지 않는다. 정말로 필요한 것이 두 번째 보호 채널이라면, 자체 엔드포인트를 가진 두 번째 채널이 필요하고 인증서 한 장 더가 필요한 것은 아니다.

TLS 1.3 핸드쉐이크의 세 가지 별개 작업

RFC 8446 이 셋을 분리하고 있으며, 그 분리가 곷 답이다. Certificate 메시지는 엔드포인트의 인증서 체인을 나른다. CertificateVerify는 대응하는 개인 키의 보유를 증명하고 핸드쉐이크 기록에 묶는다. 레코드 계층은 협상된 트래픽 키로 트래픽을 보호한다.

인증서를 바꾸면 앞의 두 항목이 바뀌다. 레코드 보호가 두 번 돌지 않고, 발급자가 사설이 되었다고 해서 더 강해지지도 않는다.

사설 CA가 실제로 사는 것

사설 CA는 통제된 신원 체계를 산다. 누구에게 발급할지, 상대가 어느 발급자를 받아들일지를 직접 정하고, 스스로 정한 일정에 따라 폐기할 수 있다. 양쪽 끝을 직접 운영한다면 이것은 정말로 유용하다.

그러나 의무도 함께 들여온다. 신뢰는 의도적으로 배포해야 하고, 상대 검증은 켜 둔 채로 유지해야 하며, 자게 증명의 수명 주기는 누군가가 소유해야 한다. 사설 CA는 이 세 가지 중 어느 것도 우회하는 지름길이 아니다.

두 번째 채널이 정답인 경우

어느 애플리케이션이 자기 서비스로 검증된 HTTPS를 열면서 그 패킷이 VPN으로도 흐른다고 하자. 그 설계에는 엔드포인트가 다를 수 있는 경계가 둘 있고, 두 번째 보호 채널은 바로 그런 모습이다.

이 구분은 게이트웨이에서 중요하다. 애플리케이션의 TLS 세션이 애플리케이션이 아니라 VPN 게이트웨이에서 끝난다면, 터널 너머에도 보호가 있다고 생각한 것은 사실이 아니다. 그 속성을 주장하기 전에 어느 채널를 누가 끝내는지 적어 두어라.

설치가 무엇을 바꾸는지 물어라

인증서 설치 요청은 세 가지 다른 뜻일 수 있다. 클라이언트 자체의 신원을 바꾸는 것일 수도, 애플리케이션별 신뢰 앵커를 바꾸는 것일 수도, 또는 기기 안의 모든 것에 대한 플랫폼 전체 신뢰 를 바꾸는 것일 수도 있다. 이들은 동등하지 않으며, 무관한 소프트웨어에 영향을 주는 것은 마지막 하나뿐이다.

셋 중 어느 것이 의도인지 묻고, 이어서 그것이 무엇을 달성해야 하는지 물어라. 답이 더 많은 암호화라면 그 제안은 잘못된 메커니즘을 거넛있다.

경계를 적어라

각 채널마다 엔드포인트, 양쪽이 검증하는 신원, 중간 운영자가 볼 수 있는 것을 기록하라. 그다음 실패 동작을 기록하라. 검증이 실패할 때 무슨 일이 일어나는지, 채널이 거부될 때 무슨 일이 일어나는지.

한 장에 두 줄이면 인증서 교체로는 정리되지 않는 논쟁이 대개 정리된다.

세 가지 질문으로 결정하라

문제는 엔드포인트가 누구라고 주장하는가인지, 아니면 데이터에 무슨 일이 생기는가인지? 보호가 VPN 게이트웨이 너머 특정 애플리케이션까지 이어져야 하는가? 그리고 두 번째 채널을 끝낼 두 엔드포인트를 이름으로 댓 수 있는가?

첫 질문이 진짜라면 신원과 신뢰를 고쳐라. 두 번째나 세 번째라면 두 번째 채널을 설계하고 인증서는 있어야 할 자리에 두어라.