VPN 공개 키를 공유해도 될까? 세 가지를 확인하세요

VPN 공개 키는 동료나 공급자, 포럼에 건네도 터널은 그대로 유지됩니다. 반면 개인 키는, 지원 담당자에게조차, 그 키가 증명하는 신원을 함께 넘기지 않고서는 건넬 수 없습니다. 판단이 이렇게 깔끔하게 유지되는 경우는 드뭅니다. 사람들이 쌍의 어느 절반을 보고 있는지 혼동하고, 일부 배포에서는 공개 값을 이름처럼 다루기 때문입니다. 세 가지 확인이 이를 정리합니다. 어느 절반을 가졌는지, 배포가 그 값을 무엇에 묶는지, 교체에 얼마가 드는지입니다.

확인 하나: 쌍의 어느 절반이 클립보드에 있는가

비대칭 키는 쌍으로 존재합니다, 그리고 유도 방향이 핵심입니다. WireGuard에서 개인 키는 32개의 무작위 바이트이고 공개 키는 그로부터 계산됩니다. 반대 방향으로는 갈 수 없습니다.wg genkey는 개인 값을 쓰고,wg pubkey는 공개 값을 유도하며, 동료에게 보내는 메시지에 들어갈 것은 후자뿐입니다.

wg genkey | tee private.key | wg pubkey > public.key
chmod 600 private.key
openssl x509 -noout -pubkey -in server.crt

인증서 세계도 더 많은 부품으로 같은 분할을 씁니다. 서버 인증서는 공개 키와 이름을 담고, CA를 절대 떠나지 않는 CA 개인 키로 서명됩니다. 그 서버를 검증하는 클라이언트에게 필요한 것은 공개된 CA 인증서이며, CA의 개인 서명 키는 전혀 쓰지 않습니다.

어느 값을 쥐고 있는지 확실하지 않다면 파일 이름이 아니라 표식을 찾으세요. 다음으로 시작하는 PEM 블록,-----BEGIN PRIVATE KEY-----, 또는 더 오래된BEGIN RSA PRIVATE KEY 형식이 비밀 절반입니다. 그 표식 없이 붙여넣을 수 있는 값은 다음 두 확인을 전제로 공유 후보입니다.

확인 둘: 배포가 그 공개 값을 무엇에 묶는가

암호학적 안전성과 익명성은 다른 속성입니다. WireGuard 동료의 공개 키는 배포 내부에서 안정적인 식별자입니다. 서버 설정에 나열되고, 핸드셰이크에서 이름으로 쓰이며, 로그를 읽는 관리자는 그 동료가 접속할 때마다 같은 문자열을 봅니다. 설정에 관한 질문 옆에 키를 게시하면, 그 문자열을 게시물의 다른 모든 것과 연결한 셈입니다.

인증서는 설계상 신원을 노출합니다. subject와 subject alternative name은 읽을 수 있고, 공적으로 신뢰되는 TLS 인증서의 경우 인증서 자체가 검색 가능한 Certificate Transparency 로그에 게시됩니다. 그중 어느 것도 개인 키를 드러내지 않지만, 모두가 관계를 드러냅니다.

여기서 배포가 갈리고, 그것이 답을 결정합니다. 실험실 서버의 일회용 테스트 동료와 기업의 사이트 간 엔드포인트를 식별하는 키는 바이트가 똑같아 보여도 다른 대상입니다.

확인 셋: 무엇을, 얼마나 빨리 폐기할 수 있는가

세 번째 확인은 두 절반을 완전히 분리합니다. 공개된 공개 키는 원하는 일정에 따라 교체할 수 있습니다. 공개된 개인 키는 되돌릴 수 없습니다. 내 사본을 지워도 이미 가져간 사본에는 닿지 않고, 그것을 신뢰한 모든 동료는 이제 외부인이 가진 무언가를 신뢰합니다.

폐기는 암호학적 조치가 아니라 설정 조치입니다. WireGuard는 폐기 목록을 제공하지 않으므로 동료를 제거합니다.

wg set wg0 peer <peer-public-key> remove
# then delete the [Peer] block from the config so it does not return on restart

OpenVPN 인증서 기반 배포는 인증서를 폐기하고, 서버가 실제로 crl-verify 를 통해 확인하는 CRL을 게시합니다. 그 지시문이 없으면 폐기 목록은 장식일 뿐입니다. 어느 경우든 순서는 같습니다. 교체품을 발급하고, 지원되는 경로로 배포한 뒤, 옛 신원을 은퇴시킵니다.

세 가지 확인을 하나로 뭉갤 때 생기는 실수

실제 유출의 대부분은 누군가 개인 키를 공개하기로 결심한 경우가 아닙니다. 프로필 전체를 포럼에 붙여넣은 경우입니다..conf 파일에 PrivateKey 줄이 있는 WireGuard 구성, .ovpn 번들, 또는 키 입력란이 우연히 찍힌 클라이언트 창 스크린숏입니다. 공개 값 자체는 아마 문제가 없었고, 문제가 있는 부분과 함께 여행했을 뿐입니다.

지원 워크플로가 두 번째 원천입니다. 정당한 검증 절차 중 개인 키가 필요한 것은 없습니다. 상대방은 필요한 것을 공개 절반에서 유도하기 때문입니다. 양식이나 사람이 개인 값을 요구하면, 올바른 답은 공개 값과 그것을 만드는 로컬 명령입니다.

로그와 스크린숏도 같은 범주입니다. 진단 출력에는 키 자료, 세션 식별자, 내부 주소가 담길 수 있고, 질문 하나에 답을 얻으려고 그 전부를 게시하는 것은 작은 편의를 더 큰 노출과 맞바꾸는 일입니다.

개인 값이 유출된 뒤에는 신원을 은퇴시키세요

개인 값이 실제로 나갔다면 그 신원은 은퇴한 것으로 취급하세요. 새 쌍을 만들고, 동료가 기대하는 위치에 공개 절반을 설치하고, 옛 동료를 제거하거나 옛 인증서를 폐기하고, 게시했던 장소를 확인하세요. 통제하지 못하는 사본은 지울 수 없으므로, 제거는 과거가 아니라 미래에 관한 일입니다.

그다음 배포를 기록하세요. 어느 키가 어느 기기에 속하는지, 누가 사본을 갖는지, 교체품은 어떻게 전달되는지, 은퇴한 동료는 누가 제거하는지. 사람들이 잊는 부분이 바로 이것이고, 유출이 얼마나 오래 유용하게 남는지를 이것이 결정합니다.