[WebRTC] WebSocket TLS Handshake 완벽 정리 (1/2)

WebRTC 기반 실시간 통신을 다루면서, 가장 먼저 마주하게 되는 보안 프로토콜 – TLS Handshake 과정에 대해 설명합니다.
WebSocket이든 WebRTC든, HTTPS 기반이라면 무조건 거쳐 가는 이 과정!
(사실 한번에 이해되지 않아서 두고두고 보려고 작성하는 글.. 😊)

 

 

 

🧩 1. TLS Handshake란?

TLS(Transport Layer Security)는 네트워크 통신의 기밀성과 무결성을 보장하는 보안 프로토콜입니다.
특히 WebSocket에서 wss:// 스킴을 사용할 때, 그리고 WebRTC에서 시그널링 서버와 HTTPS 통신할 때 반드시 필요하죠.

TLS Handshake는 다음과 같은 단계로 진행됩니다.

---

📡 [1단계] Client Hello (from Client)

TLS 통신의 시작은 클라이언트가 서버에게 보내는 Hello 인사로부터 시작됩니다.

client hello

📥 클라이언트가 보내는 정보:

• TLS Version: 클라이언트가 지원하는 TLS 버전 (예: TLS 1.2, TLS 1.3)
• Cipher Suites: 클라이언트가 지원하는 암호화 방식 목록
  (대칭키 암호화 + 공개키 암호화 + 해시 함수 조합)
• Client Random: 클라이언트가 생성한 난수 (후에 키 생성에 사용됨)
• Session ID:
  기존의 TLS 세션 재사용 여부를 나타내는 ID
  → 재사용하면 Resume Handshake, 아니면 Full Handshake 수행
• SNI (Server Name Indication):
  하나의 IP에 여러 도메인이 존재할 경우, 어떤 도메인에 접속할 것인지를 명시
  → 가상 호스팅 환경에서 서버가 올바른 인증서를 선택하게 해줍니다.

---

📡 [2단계] Server Hello (from Server)

서버가 클라이언트의 인사에 응답하는 단계입니다.

2~4단계 Server Hello, Certificate, Server Key Exchange, Server Hello Done

📤 서버가 보내는 정보:

• TLS Version: 서버가 선택한 TLS 버전
• Selected Cipher Suite: 서버가 선택한 암호화 방식 (클라이언트 목록 중 택1)
• Server Random: 서버가 생성한 난수
• Session ID: 세션 재사용 가능 여부에 따라 새로 생성하거나 기존 세션 유지

---

🛡️ [3단계] Server Certificate (from Server)

서버는 자신을 증명하기 위해 디지털 인증서를 클라이언트에게 보냅니다.

• 인증서에는 서버의 공개키, 인증서 발급기관(CA)의 정보, 유효 기간 등이 포함되어 있습니다.
• 클라이언트는 이 인증서를 바탕으로 서버의 신뢰성 및 무결성을 검증합니다.
  → 유효한 경우 다음 단계로 진행, 아니면 TLS 실패! ❌

---

🖐️ [4단계] Server Hello Done

서버 측에서 Hello 메시지 전송이 끝났음을 알리는 신호입니다.
이제부터 클라이언트가 본격적인 암호화 협상 작업에 들어갑니다.

---

🔑 [5단계] Client Key Exchange (from Client)

클라이언트는 Pre-Master Secret (초기 대칭키 재료)을 생성한 뒤,
서버의 공개키로 암호화하여 서버에게 전달합니다.

- 서버의 공개키는 'Server hello' 부분의 Transport Layer Security/Handshake Protocol: Server Key Exchange/EC Diffie-Hellman Server Params/Pubkey: *****  해당 값일 듯 싶다.

서버만이 자신의 **개인키(Private Key)**로 이 값을 복호화할 수 있습니다.

---

🔧 [6단계] Key Generation (Both)

서버와 클라이언트는 서로의 Random 값 + Pre-Master Secret을 조합하여
세션 키(Session Key)를 생성합니다.

이 세션 키는 이후 모든 데이터를 대칭키 방식으로 암호화/복호화하는 데 사용됩니다.

---

🔁 [7단계] Change Cipher Spec

클라이언트와 서버가 각각 "이제부터 암호화된 데이터로 주고받자!" 라고 선언하는 메시지를 보냅니다.
실제로 암호화가 적용되기 시작하는 시점이에요.

---

✅ [8단계] Finished

양측 모두 지금까지의 TLS Handshake 내용이 정상적으로 처리되었는지 검증하고
성공했다면 암호화 통신이 시작됩니다.

---

💬 [9단계] Application Data

이제부터는 실제 데이터(WebSocket 메시지, WebRTC 시그널링 등)가
TLS로 암호화된 채 전송됩니다.
모든 데이터는 앞서 생성된 세션 키를 이용해 암호화되며, 외부 노출이 불가능해집니다.

---

📌 마무리 요약

단계설명

Client Hello	클라이언트가 초기 정보 전송
Server Hello	서버가 선택한 암호화 방식 응답
Server Certificate	서버 인증서 제공 및 검증
Server Hello Done	서버 측 초기 작업 종료
Client Key Exchange	Pre-Master Secret 전달
Key Generation	대칭키 생성
Change Cipher Spec	암호화 시작 알림
Finished	핸드쉐이크 완료
Application Data	암호화된 실제 통신 시작

---

🧠 마치며

WebRTC나 WebSocket을 사용할 때 종종 wss:// 또는 https://로 통신을 시작하는 이유,
그리고 그 뒤에 숨어있는 복잡한 TLS Handshake 과정을 이해하면
보안과 성능에 대한 감각이 훨씬 날카로워질 수 있습니다.

다음 글에서는 이 TLS Handshake 이후의 WebSocket Upgrade 과정과
WebRTC의 ICE + DTLS + SRTP 연결 흐름도 다뤄보겠습니다! 🚀

 

 

 

다음글 : https://thinkandthing.tistory.com/116

 

 

 

 

참조 : https://babbab2.tistory.com/7?category=1058182