StageVPN 앱의 보안 VPN 프로토콜 8문 8답

Q. StageVPN 앱의 VPN 프로토콜은 어떤 프로토콜인가요?

2017년에 공개된 오픈소스 VPN 프로토콜이자 그 구현입니다. 설정 항목을 줄이고 암호 방식을 하나로 고정해, 전문가가 코드 전체를 읽고 검토할 수 있는 크기로 만드는 것이 목표였습니다.

VPN 프로토콜이란 기기와 서버가 서로를 확인하고, 암호화 키를 나누고, 데이터를 포장해 주고받는 규칙입니다. 기존 프로토콜은 다양한 환경에 맞추기 위해 옵션과 협상 단계를 많이 두었습니다. 옵션이 많으면 코드가 커집니다. 설정 실수로 약한 구성이 만들어질 여지도 커집니다. 이 프로토콜은 반대 방향을 택했습니다. 고를 수 있는 것을 줄이고, 줄인 만큼 코드를 짧게 만들었습니다.

코드 규모는 구현과 시점에 따라 달라집니다. 그래서 '약 4,000줄'은 정확한 현재 값이 아니라 '다른 VPN 구현보다 자릿수가 작다'는 뜻으로 읽으면 됩니다. StageVPN 앱은 iPhone·iPad와 Android에서 이 프로토콜의 공식 구현을 사용합니다. Chrome 확장인 StageVPN for Chrome은 이 프로토콜이 아니라 HTTPS 프록시 방식입니다. 두 방식의 차이는 브라우저 VPN과 앱 VPN 비교에서 다룹니다.

Q. VPN 연결은 어떤 순서로 만들어지나요?

연결은 메시지 두 개, 즉 1회 왕복의 핸드셰이크로 만들어집니다. 개시자가 시작 메시지를 보내고 응답자가 응답 메시지를 돌려주면, 양쪽이 같은 세션 키를 계산해 곧바로 데이터를 주고받습니다.

핸드셰이크란 통신을 시작하기 전에 서로를 확인하고 암호화 키를 합의하는 절차입니다. 이 프로토콜의 핸드셰이크는 Noise 프레임워크의 IK 패턴을 따릅니다. IK 패턴에서는 개시자가 응답자의 공개키를 미리 알고 있어야 합니다. StageVPN 앱은 연결할 서버의 공개키를 VPN 구성으로 받기 때문에 이 조건을 만족합니다.

시작 메시지의 타임스탬프는 재전송 공격을 막습니다. 재전송 공격이란 공격자가 정상 메시지를 녹음해 두었다가 나중에 다시 보내는 공격입니다. 서버는 같은 기기가 전에 보낸 타임스탬프보다 오래된 값이 오면 그 메시지를 버립니다.

첫 번째 MAC은 서버의 공개키를 알아야 만들 수 있습니다. 그래서 서버 공개키를 모르는 스캐너가 보낸 패킷에는 서버가 아무 응답도 하지 않습니다. 외부에서 보면 그 포트에 VPN 서버가 있는지조차 알기 어렵습니다. 서버가 과부하 상태일 때는 무거운 계산을 하기 전에 쿠키 응답을 먼저 보냅니다. 출발 주소가 진짜라고 확인된 요청만 처리해, 위조 주소로 서버를 바쁘게 만드는 공격에 대비하는 장치입니다.

Q. 어떤 암호 기법을 쓰나요?

역할마다 암호 기법을 하나씩만 정해 두고 협상 없이 사용합니다. 어떤 기법에 문제가 발견되면 옵션을 더하는 대신 프로토콜 버전을 바꿔 모든 구현이 함께 옮겨 가도록 설계했습니다.

공식 문서에 적힌 핸드셰이크의 정식 이름은 Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s입니다. 이름이 곧 구성표입니다. IK는 핸드셰이크 패턴, psk2는 선택적 사전 공유 키, 25519는 키 교환 곡선, ChaChaPoly는 데이터 암호, BLAKE2s는 해시를 뜻합니다.

협상 단계가 없다는 점이 중요합니다. TLS나 IKEv2처럼 암호 목록을 주고받는 프로토콜에서는 공격자가 약한 암호를 고르도록 유도하는 다운그레이드 공격이 연구되어 왔습니다. 이 프로토콜에는 고를 목록 자체가 없습니다. 따라서 이런 공격이 성립할 지점도 없습니다.

psk2, 즉 사전 공유 키는 선택 기능입니다. 공개키 암호 위에 대칭 키를 한 겹 더 얹어, 장래의 양자 컴퓨터가 Curve25519를 깨더라도 통신 내용을 지키려는 추가 방어입니다. 선택 기능이므로 서비스마다 사용 여부가 다릅니다. StageVPN은 양자 내성 암호화를 제공 기능으로 안내하지 않습니다.

설계의 안전성은 여러 차례 학술적으로 검토되었습니다. Tamarin 증명기를 이용한 기호적 검증, CryptoVerif를 이용한 계산적 증명 등 형식 검증 연구가 공개되어 있습니다. 다만 형식 검증은 프로토콜 설계에 대한 증명입니다. 각 앱의 구현 품질이나 서버 운영까지 보증하지는 않습니다. 그래서 앱을 최신 버전으로 유지하고 운영자의 기록 정책을 확인하는 일은 여전히 필요합니다.

Q. 세션 키는 얼마나 자주 바뀌나요?

세션 키는 약 2분마다 새 핸드셰이크로 교체됩니다. 교체는 기존 키로 통신하는 동안 진행되므로 사용자는 끊김을 느끼지 않습니다.

키를 자주 바꾸는 이유는 전방 보안성 때문입니다. 전방 보안성이란 나중에 기기의 장기 개인키가 노출되더라도 이미 끝난 세션의 통신 내용은 풀 수 없게 하는 성질입니다. 이 프로토콜은 핸드셰이크마다 새 임시 키를 만들고, 다 쓴 키는 메모리에서 지웁니다. 설령 세션 키 하나가 새더라도 영향 범위는 그 키를 쓴 몇 분 분량으로 제한됩니다.

핸드셰이크 시도에도 규칙이 있습니다. 응답이 없으면 5초 간격(REKEY_TIMEOUT)으로 다시 시도합니다. 90초(REKEY_ATTEMPT_TIME) 동안 응답이 없으면 시도를 멈춥니다. 데이터를 받고 10초(KEEPALIVE_TIMEOUT) 안에 보낼 데이터가 없으면 빈 keepalive 패킷을 보내 상대가 응답을 확인할 수 있게 합니다.

이 프로토콜은 보낼 데이터가 없으면 핸드셰이크도 하지 않도록 설계되어 있습니다. 다만 공유기나 통신사 장비(NAT) 뒤에 있는 기기는 연결 정보가 지워지지 않도록 일정 간격으로 빈 패킷을 보내는 설정(PersistentKeepalive)을 쓰는 경우가 많습니다. 공식 안내는 이때 25초 간격을 권합니다. StageVPN 앱의 VPN 구성도 기본값으로 25초를 씁니다(2026년 9월 기준).

Q. OpenVPN, IKEv2/IPsec과 무엇이 다른가요?

StageVPN 앱의 프로토콜은 선택지를 줄이고 코드를 작게 만든 프로토콜입니다. OpenVPN과 IKEv2/IPsec은 다양한 환경에 맞추기 위해 협상과 옵션을 많이 둔 프로토콜입니다.

위 그림은 코드 규모, 전송 방식, 암호 협상 방식의 차이를 보여 줍니다. 아래 표는 그림에 담지 않은 나머지 차이를 정리합니다. 셋 다 현재 널리 쓰이며, 어느 쪽이 무조건 우월하다기보다 설계 철학이 다릅니다.

속도는 프로토콜만으로 정해지지 않습니다. 서버까지의 거리, 현지 회선 품질, 서버 혼잡도, 기기 성능이 함께 영향을 줍니다. 이 프로토콜은 절차가 단순하고 암호 연산이 가벼워 같은 조건에서 빠른 경우가 많습니다. 그렇다고 항상 빠르다고 말할 수는 없습니다. 체감 속도가 낮다면 가까운 위치의 서버로 바꿔 비교해 보는 것이 먼저입니다.

Q. 공개키가 곧 주소가 되는 '암호키 라우팅'이란 무엇인가요?

암호키 라우팅이란 상대의 공개키와 그 상대가 쓸 수 있는 IP 주소 범위(AllowedIPs)를 하나로 묶어 두고, 패킷을 보낼 때와 받을 때 모두 이 묶음으로 판단하는 방식입니다. 보낼 때는 목적지 주소로 어느 공개키로 암호화할지 정하고, 받을 때는 복호화에 성공한 공개키가 그 출발 주소를 쓸 자격이 있는지 확인합니다.

이 구조에는 두 가지 장점이 있습니다. 첫째, 서버는 어떤 터널 IP에서 온 패킷이 그 IP에 묶인 공개키로 복호화된 경우에만 진짜로 인정합니다. 다른 기기가 터널 IP를 흉내 내도 복호화가 되지 않으므로 패킷이 버려집니다. 둘째, 방화벽 규칙과 암호 규칙이 하나로 합쳐집니다. 관리자는 '이 공개키는 이 주소 범위'라는 한 줄만 관리하면 됩니다.

사용자 기기 쪽에서 AllowedIPs를 0.0.0.0/0과 ::/0으로 두면 모든 IPv4·IPv6 통신이 한 서버로 가는 전체 터널이 됩니다. StageVPN 앱이 이 방식을 씁니다. 앱이 서버에서 받는 VPN 구성의 주요 항목은 아래와 같습니다.

MTU란 한 번에 보낼 수 있는 패킷의 최대 크기입니다. 이 프로토콜은 원래 패킷을 암호화해 다시 UDP 패킷에 담기 때문에 헤더만큼 크기가 늘어납니다. 그래서 터널 안 MTU를 회선 MTU보다 작게 잡아야 패킷이 조각나거나 버려지지 않습니다. 접속 기록으로 무엇을 얼마나 보관하는지는 접속 기록 보관 고지에 공개되어 있습니다.

Q. 프로토콜이 튼튼하면 인터넷 사용 전체가 안전한가요?

아닙니다. VPN 프로토콜이 보호하는 구간은 내 기기부터 VPN 서버까지이며, 그 뒤의 안전은 사이트의 HTTPS와 운영자의 기록 정책이 좌우합니다.

그림의 왼쪽 두 구간에서는 공용 Wi-Fi의 다른 사용자, Wi-Fi 운영자, 통신사가 통신 내용과 목적지를 보기 어렵습니다. VPN 서버를 나간 뒤에는 일반 인터넷과 같습니다. 그래서 주소가 https://로 시작하는 사이트인지가 다시 중요해집니다. 프로토콜 바깥의 위험은 따로 대비해야 합니다.

• VPN 서버 이후 구간: HTTPS를 쓰지 않는 사이트는 VPN 서버부터 사이트까지 암호화되지 않습니다.
• 운영자에 대한 신뢰: VPN 서버는 구조상 각 기기의 공개키, 터널 IP, 마지막 접속 주소를 알고 있습니다. 연결의 목적지 IP를 볼 수 있는 위치이기도 합니다. StageVPN은 통신비밀보호법에 따라 접속 기록을 93일 보관한 뒤 자동 삭제하고, 통신 내용은 기록하지 않습니다. 이유는 접속 기록 보관 정책을 공개하는 이유에 설명했습니다.
• 기기 안의 위협: 악성 앱이나 피싱 페이지는 터널 안쪽, 즉 내 기기에서 일어나는 문제입니다. 프로토콜이 막지 못합니다. 구분은 VPN이 막아주는 것과 막지 못하는 것을 참고하세요.
• 연결이 끊긴 순간: 터널이 끊긴 동안의 통신은 일반 경로로 나갈 수 있습니다. 민감한 작업 전에는 앱의 연결 상태를 확인하세요. 공용 네트워크에서의 습관은 공용 와이파이 안전 수칙에 정리했습니다.
• DNS와 IPv6: 다른 VPN 앱이나 기기의 별도 DNS 설정이 경로를 바꾸면 질의가 터널 밖으로 나갈 수 있습니다. 확인 방법은 DNS 누출과 WebRTC 누출 가이드에 있습니다.

처음 연결할 때 iPhone은 VPN 구성 추가를, Android는 VPN 연결 요청을 허용해 달라고 묻습니다. 이를 허용해야 앱이 VPN 터널을 만들 수 있습니다. 기기별 순서는 iPhone·iPad에서 시작하기와 Android에서 시작하기에 있고, 제공 범위는 기능과 제공 범위에서 확인할 수 있습니다.

Q. Wi-Fi에서 LTE로 바뀌어도 연결이 유지되는 이유는 무엇인가요?

이 프로토콜은 기기를 IP 주소가 아니라 공개키로 식별하기 때문입니다. 네트워크가 바뀌어 IP가 달라져도 서버는 정상적으로 복호화된 패킷이 마지막으로 도착한 주소를 기억해 그 주소로 응답합니다.

이 동작을 로밍이라고 부릅니다. 스마트폰은 집 Wi-Fi, 카페 Wi-Fi, 이동 중 LTE·5G 사이를 하루에도 여러 번 오갑니다. 그때마다 VPN이 처음부터 다시 연결된다면 메신저와 스트리밍이 멈추는 순간이 생깁니다. 이 프로토콜은 이 전환을 기본 동작으로 처리합니다. 별도 설정이 필요 없습니다.

이 프로토콜은 UDP만 사용합니다. UDP는 연결 수립 절차가 없는 가벼운 전송 방식입니다. 터널 안에서 오가는 TCP 통신의 재전송 제어와 겹치지 않습니다. TCP 위에 TCP를 다시 얹으면 손실이 생겼을 때 두 층이 동시에 재전송하며 속도가 크게 떨어지는 문제가 알려져 있습니다. 이 프로토콜은 이 문제를 구조적으로 피합니다.

한편 StageVPN은 법령에 따른 접속 기록의 하나로, 기기가 VPN 서버에 접속해 온 IP 주소가 바뀔 때 그 주소를 기록합니다. 로밍이 일어난 사실 자체는 서버에 남는다는 뜻입니다.