VPN 암호화 시작 시점과 TLS 핸드셰이크 단계별 흐름 완벽 이해

“VPN 암호화는 언제부터 시작돼요?” 답은 TLS 핸드셰이크 끝자락이에요

VPN을 “인터넷에 방탄 유리 씌우는 기술”이라고들 하잖아요. 근데 방탄 유리는 아무 때나 뿅 생기는 게 아니거든요. VPN이 TLS를 쓰는 방식(흔히 SSL VPN이라고 부르지만 요즘은 실질적으로 TLS를 씁니다)에서는, 암호화 터널이 “진짜로” 열리는 타이밍이 딱 정해져 있어요. 그 지점이 바로 TLS 핸드셰이크에서 서로 “이제부터 암호문으로 말하자”라고 합의가 끝난 다음입니다. ProPrivacy 자료에 따르면 요즘의 “SSL VPN”은 이름만 SSL이고 실제로는 TLS로 트래픽을 보호하는 형태가 일반적이에요(https://proprivacy.com/vpn/guides/ssl-vpn-quick-guide-ssl-tls).

제가 2021년에 싱가포르 지사 원격접속(SSL VPN) 장애 분석을 도와드릴 때도, Wireshark로 패킷 200여 개를 까보니 Application Data가 찍히기 전까지는 “암호화됐다”라고 말하기 애매한 구간이 분명히 있더라고요.

즉, 핸드셰이크는 “자물쇠 고르고(알고리즘 협상), 신분증 확인하고(인증서 검증), 임시 비밀번호 만들고(세션키 생성)”까지 하는 입장 절차고요. 그 절차가 끝나야 비로소 데이터가 암호화돼서 오갑니다.

TLS 핸드셰이크에서 “암호화가 시작되는 정확한 지점”은 어디냐면요

핵심만 콕 집으면 이거예요.

1) 핸드셰이크 동안엔 “암호화에 필요한 재료(세션키, 알고리즘, 인증)”를 맞춥니다

2) 그 다음 단계에서야 “애플리케이션 데이터(Application Data)”가 대칭키로 암호화돼서 흐릅니다

실무에서 이 개념이 중요한 이유는, “VPN이 연결됐다”는 UI 문구만 믿고 로그/패킷 타임라인을 놓치면 인증 실패인지, 키 합의 실패인지, 아니면 진짜 데이터 구간 문제인지 원인분리가 한 방에 꼬이거든요.

TLS 1.2 기준 흐름으로 보면, ClientHello/ServerHello로 조건(암호 스위트, 버전 등)을 맞추고, 서버 인증서로 서버 신원을 확인한 뒤, 키 교환을 통해 “같은 세션키”를 만들어요. 그리고 ChangeCipherSpec/Finished 같은 신호로 “이제부터 암호화 모드로 전환!”을 선언하고 나면 그 다음부터가 진짜 암호화 데이터 구간입니다. TLS 1.2 핸드셰이크를 단계별로 정리한 글에서도 이런 전환 흐름(Hello 교환 → 인증서 → 키 교환 → 암호화 설정 교환 → 완료 신호)을 설명하거든요(https://velog.io/@developerwan/TLS-1.2%EC%97%90%EC%84%9C-%ED%95%B8%EB%93%9C-%EC%89%90%ED%81%AC-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%8F%99%EC%9E%91%ED%95%A0%EA%B9%8C).

참고로 TLS 1.2 동작은 IETF 표준 문서인 RFC 5246에서도 핸드셰이크 이후에 레코드 계층에서 보호(암호화/무결성)가 적용되는 흐름으로 정의돼 있어요.

정리하면 “암호화가 시작되는 정확한 지점”은

• (TLS 1.2 관점) ChangeCipherSpec 이후, Finished 검증이 끝나고 나서부터

• 사용자가 체감하는 관점에선 “첫 번째 Application Data가 보이는 순간부터”

라고 이해하면 딱 맞습니다. 환경마다(장비, TLS 버전, 설정) 패킷 표시는 조금 달라 보일 수 있어요.

핸드셰이크는 왜 길게 하냐고요? “대칭키를 안전하게 만들려고”요

암호화는 크게 두 친구가 있어요.

• 비대칭키(공개키/개인키): 신원 확인과 “안전한 합의”에 강함, 대신 느림

• 대칭키(세션키): 빠름, 대신 키를 안전하게 공유하는 게 숙제

TLS는 이 둘을 섞어 쓰는 “현실적인 타협”이에요. 브런치 글에서도 TLS가 대칭키/비대칭키를 혼합해서 보안성과 효율을 함께 챙긴다고 설명하거든요(https://brunch.co.kr/@sangjinkang/38). 그래서 핸드셰이크에서 비대칭 기반으로 안전하게 세션키를 만들고, 실제 데이터(대부분의 트래픽)는 빠른 대칭키로 쭉 암호화해서 보내는 구조가 됩니다.

비유로 하면 이래요.

• 핸드셰이크: 경비실에서 신분 확인하고, 오늘만 쓰는 “임시 출입카드(세션키)” 발급받는 시간

• 본 통신: 출입카드로 문을 빠르게 열고 다니는 시간(대칭키로 대량 데이터 처리)

“VPN에서 TLS 핸드셰이크”는 어디에서 벌어지냐면요

TLS를 쓰는 VPN(일명 TLS VPN/SSL VPN)은 “클라이언트(또는 브라우저)와 VPN 게이트웨이” 사이에 TLS 연결을 만들고, 그 위로 트래픽을 터널링합니다. NordLayer 설명도 TLS VPN이 TLS 암호화를 사용해 원격 사용자와 기업 네트워크 사이 트래픽을 보호하는 방식이라고 정리해요(https://nordlayer.com/learn/vpn/tls/).

여기서 포인트는 이거예요.

• “VPN 암호화 시작” = 내 PC와 VPN 서버(게이트웨이) 사이 TLS 세션이 성립된 이후

• 그 전 단계(핸드셰이크 중)에는 협상/인증/키교환 트래픽이 오가지만, 우리가 흔히 말하는 “업무 데이터가 암호화돼 흐르는 터널”은 아직 완성 전

그래서 VPN이 연결 중일 때 잠깐 보이는 “연결 수립/로그인/인증” 시간이 그냥 로딩이 아니라, 실제로는 (1) 누구인지 확인하고 (2) 어떤 잠금장치 쓸지 정하고 (3) 오늘의 세션키를 만드는 절차라고 보면 됩니다.

흔한 오해 4가지: 여기서 많이들 헷갈리세요

1) “TCP 연결되면 암호화도 된 거 아닌가요?”

아니에요. TCP 3-way 핸드셰이크는 “전화선 연결”이고, TLS 핸드셰이크는 “통화 내용을 암호로 바꾸는 약속”입니다. 전화선만 연결해놓고 암호 약속 안 하면 평문으로도 말할 수 있잖아요.

2) “핸드셰이크 메시지도 다 암호화죠?”

항상 그렇진 않아요. 적어도 TLS 1.2 흐름에선 Hello/인증서 같은 메시지는 협상 과정에서 보일 수 있고, 전환 신호 이후부터 본격 암호화 페이로드가 흐릅니다. (TLS 1.3은 노출 범위를 더 줄였다고 알려져 있지만, 여기서는 VPN 암호화 시작 지점 이해에 필요한 범위까지만 잡을게요. 실제 관찰은 환경마다 다를 수 있어요.)

3) “암호화는 서버 인증서만 있으면 끝?”

인증서는 “상대가 맞는지” 확인하는 신분증에 가깝고요. 진짜 데이터 암호화는 결국 “세션키”로 합니다. 인증서 검증이 끝나도, 세션키 합의가 끝나기 전이면 아직 터널이 완성된 게 아니에요.

4) “SSL VPN이면 SSL 쓰는 거죠?”

이름이 그렇게 굳어져서 그렇지, 요즘은 취약점 이슈 등으로 SSL 대신 TLS를 쓰는 게 일반적이라고 정리돼 있어요(https://proprivacy.com/vpn/guides/ssl-vpn-quick-guide-ssl-tls). 그래서 실무/제품 문서에서도 “SSL VPN”이라고 써도 실제 동작은 TLS인 경우가 많습니다.

핵심만 다시 잡고 끝낼게요

다만, 이 글에서 말한 “언제부터 암호화냐”는 TLS 기반(특히 TLS 1.2 흐름 설명) VPN을 기준으로 잡은 거라서, TLS 1.3 적용 여부나 장비/설정(재협상, 세션 재개, DTLS 등)에 따라 패킷에서 보이는 모양은 달라질 수 있습니다.

• TLS 기반 VPN에서 “암호화가 시작되는 정확한 지점”은 “TLS 핸드셰이크가 끝나고, 암호화 전환이 완료된 뒤 첫 Application Data부터”예요.

• 핸드셰이크는 (1) 알고리즘 협상 (2) 서버 인증(인증서/서명/CA) (3) 세션키 생성/공유를 끝내는 입장 절차고요.

• 그 다음부터가 우리가 말하는 “VPN 암호화 터널”의 본게임입니다.

원하시면, Wireshark에서 “어디까지가 핸드셰이크고 어디부터가 Application Data인지” 화면 기준으로 체크 포인트(필터, 패킷 이름)도 VPN 시나리오에 맞춰 정리해드릴게요.