HTTPS에서의 TLS Handshake 진행 과정

zayn_noh·2026년 5월 28일
TLSTLS handshakehttpspublic keysymmetric key

웹(Web) 개념 정립

목록 보기
1/1
post-thumbnail

1. HTTPS의 등장 배경

기존 HTTP(Hypertext Transfer Protocol)의 경우,
클라이언트(웹 브라우저)와 서버가 통신하며 데이터를 주고 받을 때 어떠한 보호장치도 없이
평문(plain text)을 그대로 전송하였다.

이러한 방식은 네트워크 중간에서 데이터가 탈취된다면 어떠한 암호화도 되어있지 않기에
요청과 응답 내용에 해당하는 정보가 바로 노출될 위험성이 존재하였다.

이러한 문제점을 해결하고자 기존 HTTP 통신에 TLS 암호화 프로토콜을 적용한
HTTPS(Hypertext Transfer Protocol Secure)가 등장하였다.

HTTPS는 클라이언트와 서버 사이의 데이터를 암호화하여,
네트워크 중간에서 탈취되더라도 내용을 쉽게 알 수 없도록 보호한다.

또한 전송되는 데이터의 변조를 방지하고, 인증서를 통해 서버의 신뢰성을 확인할 수 있게 한다.

TLS(Transport Layer Security)
TLS는 뜻을 살펴보면 전송 계층 보안이다.

이러한 이름이 붙은 이유는 전송 계층 위에서 오가는 데이터를 안전하게 보호하기 위한 프로토콜이기 때문이다.

HTTP : HTTP 메시지 생성
TLS : HTTP 메시지를 암호화
TCP : 암호화된 데이터를 전달
IP : 목적지(destination)까지 라우팅

정확히 말하자면,
TLS는 전송 계층의 연결을 사용하는 어플리케이션 데이터를 보호하는 계층이라 할 수 있다.

2. TLS Handshake의 목적

TLS Handshake는 HTTPS 통신을 시작하기 전, 클라이언트와 서버가 안전한 통신을 준비하는 과정이다.

주요 목적은

  • 서버의 신원을 확인하고

  • 사용할 암호화 방식을 협상하며

  • 데이터 암호화에 사용할 세션키(대칭키(Symmetric key))를 생성한다.

이때 세션키의 세션은 로그인 세션 과정 등에서 사용하는 세션이 아닌,
일반적인 의미의 세션을 뜻한다.
즉 TLS를 통한 암호화 통신을 진행하는 기간, 상태를 의미한다.

3. TLS Handshake 진행

0. 웹 서버의 인증서가 만들어지는 과정

서버가 HTTPS를 사용하려면 먼저 인증서를 발급받아야 한다. 이때 다음과 같은 과정을 거친다.

  1. 서버 관리자는 공개키(Ks+), 비밀키(Ks-)를 생성한다.

  2. 이후 공개키와 도메인 정보를 담은 CSR을 만든다.
    이때 해당 CSR은 서버의 Ks-로 서명되어있다.
    CSR = Ks-(message) // message = Ks+, 서버 공개키, 도메인 정보 등이 적혀있다.

  3. CA에 CSR(Ks-(message))을 제출한다.

  4. CA는 해당 CSR의 신청자가 실제 도메인 소유자인지 검증한다.
    (특정 파일을 업로드해봐라, 어떤 부분 수정해봐라 etc.)

이때 CSR은 Ks-로 서명되어 있기에, CA는 Ks+로 내용을 볼 수 있다.

  1. 검증이 끝났다면 CA가 디지털 인증서를 발급한다.
    Kca-(인증서 내용) : CA의 비밀키(Kca-)로 서명되어있다.

  2. 서버 관리자는 해당 인증서 Kca-(인증서 내용)를 웹 서버에 설치한다.


1. 서버 신원 확인 절차

사용자가 웹 브라우저를 통해 velog.io에 접속한다 가정하면
해당 접속 서버가 진짜 서버인지, 벨로그를 사칭한 가짜 서버인지 확인해야한다.

이를 위해 서버는 CA(Certificate authority), 인증기관이 발급한 인증서를 브라우저에게 보여준다.
해당 인증서에는 다음과 같은 내용들을 포함한다.

Kca-(인증서 내용)

  • 도메인 이름
  • 서버 공개키
  • 인증서 유효 기간
  • 인증서 발급 CA 정보
  • CA의 디지털 서명

클라이언트는 받은 인증서를 CA의 공개키(Kca+)로 내부 내용을 확인한다.
Kca+(Kca-(인증서 내용)) = 인증서 내용

  • 신뢰할 수 있는 CA가 발급했는가
  • 인증서가 위조되지는 않았는가
  • 유효 기간이 남아있는가
  • 접속한 도메인과 인증서의 도메인이 일치하는가

해당 과정이 끝나면 브라우저는 "이 서버는 신뢰할 수 있다"고 판단한다.


2. 대칭키 생성 절차

서버가 신뢰할 수 있음을 확인하였기에,
클라이언트와 서버는 이후 통신과정에서 송신할 데이터를 암호화하는 세션키(공개키)를 만들어야한다.

  1. 대칭키 생성 : Kc
    클라이언트는 서버와 빠르고 안전하게 통신하기 위해 대칭키를 만든다.

  2. 서버의 공개키 Ks+로 대칭키를 암호화하여 전송한다. : Ks+(Kc)

해당 절차는 과거 초기 방식으로, 현대 TLS에서는 다음과 같은 과정을 거친다.

클라이언트와 서버가 키 교환 정보를 주고받는다.
네트워크에는 공개되어도 되는 값만 오간다.
각자 자신의 비밀값과 상대의 공개값을 이용해 같은 공유 비밀값을 계산한다.
그 공유 비밀값으로 세션키를 만든다.

자세히는 다루지 않겠지만 정리하자면
본인들의 공개키, 비밀키를 사용하여 각각 계산을 해서 동일한 비밀키를 만드는 것이다.

  1. 서버는 암호화된 대칭키를 받아 본인의 비밀키로 대칭키를 확인한다.
    Ks-(Ks+(Kc)) = Kc

이후 안전하게 공유된 세션키(대칭키)를 통해 네트워크에서 데이터를 송수신한다. Kc(data)

왜 클라이언트와 서버간 통신에서 대칭키를 활용할까?

비대칭키 암호화는 안전하지만 계산 비용이 크다.
반면 대칭키 암호화는 비대칭키에 비해 덜 안전하지만, 빠른 속도를 가진다.

결과적으로 비대칭키(공개키, 비밀키)를 사용하여 안전하게 대칭키를 공유하고
공유된 대칭키로 빠른 통신을 가능하게 하는 것이다.

대칭키-공개키 암호화 관련, 과거 정리 링크

profile
zayn_noh
개발 및 IT기술에 대해 정리하고 기록합니다.

0개의 댓글