3. TLS handshake — HTTPS 암호화 연결

TCP 연결이 끝났으면, HTTPS라면 여기서 암호화 채널을 만들어요.
"우리 어떤 방식으로 암호화할지 협의하고, 서버가 진짜인지 검증하자"는 과정이에요.

 

TCP handshake가 "연결 확인"이라면, TLS handshake는 "신원 확인 + 암호화 키 교환"이에요.

 

각 단계 설명:

ClientHello — 클라이언트가 "나는 TLS 1.3 쓸 수 있고, 이런 암호화 방식들 지원해"라고 먼저 제안해요.

지원하는 cipher suite 목록을 쭉 보내요.

 

ServerHello + 인증서 — 서버가 "그 중에 이 방식 쓰자"고 결정하고, 자신의 신원을 증명하는 인증서(공개키 포함)를 보내요.

 

인증서 검증 — 브라우저가 "이 인증서 진짜야?"를 확인해요. CA(인증기관, ex. Let's Encrypt)가 서명한 게 맞는지,

유효기간이 지나지 않았는지, 도메인이 일치하는지 체크해요. 여기서 실패하면 브라우저가 경고를 띄워요.

 

키 교환 — 비대칭키(공개키/개인키)로 실제로 데이터를 암호화할 대칭키를 안전하게 합의해요.

비대칭키는 느리기 때문에, 연결 수립 시에만 쓰고 이후 실제 데이터는 빠른 대칭키로 주고받아요.

 

Finished — 양쪽이 "나 이제 암호화 준비 됐어"를 확인하면 이후 모든 통신은 암호화돼요.

 

 

참고로, TLS 1.2까지는 handshake에 왕복이 2번 필요했는데, TLS 1.3부터는 1번으로 줄었어요.

한 번 연결한 서버라면 0-RTT로 handshake 없이 바로 데이터를 보낼 수도 있어요.

초기 로딩 속도에 직접적인 영향을 줘요.

또 브라우저 주소창의 자물쇠 아이콘이 바로 이 인증서 검증이 통과됐다는 표시예요.

 

 

TLS 키 교환에서 대칭키와 비대칭키는 각각 어떤 역할인가요?

 

대칭키 vs 비대칭키

먼저 둘의 차이부터 잡고 가요.

 

왜 둘 다 쓰냐면:

대칭키만 쓰면 — 빠르지만, 처음에 키를 어떻게 안전하게 공유하냐는 문제가 생겨요. 인터넷으로 "우리 이 키 쓰자"고 보내면 중간에 누가 탈취할 수 있어요.

비대칭키만 쓰면 — 공개키는 누구나 알아도 되고 개인키는 서버만 갖고 있으니까 키 공유 문제가 없어요. 근데 암호화/복호화 연산이 대칭키보다 수백 배 느려요. 대용량 데이터를 주고받는 데 쓰기엔 너무 비효율적이에요.

그래서 TLS는 이렇게 해요:

1. 비대칭키로 "우리 이 대칭키 쓰자"를 안전하게 전달
         ↓
2. 이후 실제 HTTP 데이터는 빠른 대칭키로 주고받기

비대칭키는 딱 처음 키 교환할 때만 쓰고, 그 이후엔 합의된 대칭키로만 통신해요.

 

TLS 1.3부터는 키 교환 방식이 바뀌어서 서버의 개인키가 탈취되더라도 과거 통신 내용을 복호화할 수 없어요. 이걸 Forward Secrecy(전방 비밀성) 라고 해요. 매 세션마다 임시 키를 새로 만들어서 쓰고 버리기 때문이에요.