[Network] TLS/SSL HandShake

jiny·2026년 2월 21일
computer sciencenetwork

Computer Science

목록 보기
13/16

1. TLS/SSL이란?

✨ 기본 개념

TLS(Transport Layer Security)와 SSL(Secure Sockets Layer)은 웹 브라우저와 서버 간의 인터넷 통신을 암호화하여 정보를 안전하게 주고받을 수 있게 해주는 보안 프로토콜이다.

  • 역사적 배경: SSL은 1990년대 넷스케이프에 의해 처음 개발되었으나 보안 취약점이 발견되어 폐기되었다. 이를 개선하여 표준화한 것이 TLS이다.
  • 현재 상황: 오늘날 우리가 사용하는 대부분의 보안 통신은 TLS 1.2 또는 1.3 버전이다. 하지만 관습적으로 여전히 'SSL'이라는 용어를 혼용하여 사용한다.

✨ 목적

TLS/SSL은 단순히 암호화만 하는 것이 아니라, 안전한 통신을 위한 세 가지 핵심 요소를 보장한다.

요소설명구현 방식
기밀성 (Confidentially)인가되지 않은 제3자가 데이터를 읽을 수 없도록 보호한다.대칭키 암호화 (AES 등)
무결성 (Integrity)전송 중 데이터가 위조되거나 변조되지 않았음을 보장한다.MAC(Message Authentication Code) 또는 해시 함수
인증 (Authentication)통신하는 상대방(서버)이 실제 본인이 맞는지 확인한다.CA(공인 인증 기관) 발행 디지털 인증서

2. 사전 지식: 암호화 방식

✨ 대칭키 암호화

암호화할 때와 복호화할 때 동일한 하나의 키를 사용하는 방식이다.

  • 특징
    • 장점: 계산 속도가 매우 빨라 대용량 데이터를 처리하기에 적합하다.
    • 단점: 키가 유출되면 보안이 완전히 무너지며, 통신 대상이 많아질수록 관리해야 할 키의 개수가 기하급수적으로 늘어난다.
  • 주요 알고리즘
    • AES (Advanced Encryption Standard): 현재 가장 널리 쓰이는 표준이다. 키 길이에 따라 AES-128, 192, 256으로 나뉘며 숫자가 클수록 보안성이 높다.
    • 기타: DES, 3DES, ChaCha20 등
  • 활용: 데이터베이스 암호화, 파일 및 디스크 암호화(BitLocker 등), VPN 터널 내 데이터 보호

✨ 공개키(비대칭키) 암호화

공개키(Public Key)와 개인키(Private Key)라는 한 쌍의 키를 사용하는 방식이다.

  • 특징
    • 장점: 키를 직접 전달할 필요가 없어 키 유출 위험이 적고 확장성이 뛰어나다.
    • 단점: 대칭키 방식보다 100~1000배 정도 느리고 CPU 부하가 크다.
  • 주요 알고리즘
    • RSA: 가장 대표적인 알고리즘이지만, 보안을 위해 키 길이가 길어져야 한다는 단점이 있다.
    • ECC (Elliptic Curve Cryptography): RSA보다 짧은 키로도 동일한 보안 수준을 제공하며 속도가 빨라 현대 TLS에서 선호된다.
    • DSA/ECDSA: 주로 전자서명(인증) 용도로 사용된다.
  • 활용: 디지털 인증서, 전자서명, 초기 키 교환

✨ TLS의 하이브리드 방식

TLS는 두 방식의 단점을 보완하고 장점만을 취하기 위해 하이브리드 구조를 채택했다.

  • HandShake (공개키 활용): 서버의 공개키를 사용하여 클라이언트가 생성한 난수(대칭키의 재료)를 암호화해 보낸다. 이 과정 덕분에 해커가 중간에 가로채더라도 서버의 개인키 없이는 내용을 알 수 없다.
  • 실제 통신 (대칭키 활용): 일단 안전하게 대칭키(세션 키)가 공유되면, 이후의 모든 데이터는 이 키를 사용해 대칭키 방식으로 암호화한다. 덕분에 고화질 영상이나 대용량 파일도 빠르게 주고받을 수 있다.

3. TLS HandShake 상세 과정

✨ Phase 1: 협상 (Hello)

  1. Client Hello: 클라이언트가 서버에 인사를 건네며 자신의 정보를 보낸다.
    • 포함 정보: TLS 버전, 지원하는 암호 방식(Cipher Suite), 클라이언트 난수(Client Random)
  2. Server Hello: 서버가 클라이언트의 제안 중 하나를 선택해 응답한다.
    • 포함 정보: 선택한 TLS 버전 및 암호 방식, 서버 난수(Server Random)

✨ Phase 2: 인증 및 키 교환

  1. Certificate: 서버가 자신의 신원을 증명하는 CA 인증서를 보낸다. 이 안에는 서버의 공개키가 들어있다.
  2. Server Hello Done: 서버가 보낼 정보를 모두 보냈음을 알린다.
  3. Client Key Exchange: 클라이언트는 인증서를 검증한 뒤, 새로운 난수(Pre-Master Secret)를 생성하여 서버의 공개키로 암호화해 보낸다.
    • 이제 클라이언트와 서버는 Client Random, Server Random, Pre-Master Secret 3가지를 모두 가지게 되며, 이를 조합해 실제 통신에 쓸 대칭키(Master Secret)를 만든다.

✨ Phase 3: 암호화 적용 및 확인

  1. Change Cipher Spec: "이제부터 우리가 합의한 대칭키로 암호화해서 보낼게!"라고 선언하는 단계이다. (8번도 동일)
  2. Finished: 핸드셰이크 과정의 모든 메시지를 해싱하여 암호화한 뒤 보낸다. 서로 이 값을 복호화해 확인하며 과정에 오류나 변조가 없었는지 최종 점검한다. (9번도 동일)

✨ Phase 4: 데이터 전송

핸드셰이크가 성공적으로 끝나면, 생성된 대칭키를 이용해 실제 HTTP 데이터를 암호화하여 주고받는다.

4. 단계별 상세 설명

✨ Step 1: Client Hello (제안 및 탐색)

  • 설명: 클라이언트가 서버에 연결을 시도하며 자신의 보안 역량을 제시한다.
  • 포함 정보
    • TLS 버전: 클라이언트가 지원하는 TLS 버전 (예: TLS 1.2, 1.3)
    • Random 데이터: 나중에 세션 키 생성에 사용될 랜덤 값
    • Cipher Suite 목록: 지원하는 암호화 알고리즘 목록
      • 예: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    • 압축 방식: 지원하는 압축 알고리즘
    • 확장 기능: SNI(Server Name Indication) 등

      ⭐ SNI(Server Name Indication): 하나의 IP에 여러 도메인이 있을 때, 어떤 도메인에 접속하려는지 서버에 알려주어 올바른 인증서를 보낼 수 있게 한다.

✨ Step 2: Server Hello (협상 완료)

  • 설명: 서버는 클라이언트의 제안 중 가장 보안 수준이 높으면서 서로 지원 가능한 방식을 선택하여 응답한다.
  • 포함 정보
    • 선택된 TLS 버전
    • Random 데이터: 서버가 생성한 랜덤 값
    • 선택된 Cipher Suite: 사용할 암호화 알고리즘
    • 세션 ID: 연결이 끊겼을 때 핸드셰이크 과정을 생략하고 빠르게 재연결하기 위한 식별자
    • 선택된 압축 방식

✨ Step 3: Certificate (인증서 전송)

  • 설명: 서버가 자신의 신원을 증명하는 인증서를 보낸다.
  • 인증서 구조
    서버 인증서 {
  - 서버 도메인 정보 (예: www.example.com)
  - 서버의 공개키
  - 발급 기관(CA) 정보
  - 유효 기간
  - CA의 디지털 서명
}
  • 인증서 체인 (Certificate Chain): 서버 인증서만 보내는 것이 아니라, 이를 보증하는 중간 CA 인증서와 루트 CA 정보를 함께 보내 신뢰의 사슬을 형성한다.
  • OCSP/CRL 확인: 클라이언트는 인증서가 유효 기간 내에 있더라도, 혹시 도난 등의 이유로 폐기(Revocation)되지 않았는지 실시간으로 확인한다.
  • CA(Certificate Authority)
    • 공인된 인증 기관 (예: Let's Encrypt, DigiCert)
    • 브라우저에 이미 CA의 공개키가 내장되어 있다.
    • CA의 서명으로 인증서의 진위를 확인한다.

✨ Step 4: Server Hello Done (준비 완료)

  • 설명: 서버가 인증서 전송을 완료했음을 알린다.
  • 선택사항: 서버가 클라이언트 인증서도 요구할 수 있다. (양방향 인증)

✨ Step 5: Client Key Exchange (비밀 재료 전달)

  • 설명: 가장 중요한 보안 단계로, 클라이언트가 대칭키를 생성할 재료를 안전하게 전송한다.
  • 과정
    1. 클라이언트가 Pre-Master Secret(난수) 생성

      ⭐ Pre-Master Secret: 클라이언트가 생성한 48비트의 무작위 숫자로, 서버의 공개키로 암호화되어 전송된다.

    2. 서버의 공개키로 암호화
    3. 암호화된 Pre-Master Secret을 서버에 전송
  • 대칭키 생성 (Master Secret 유도)
    Master Secret = 함수(
  Client Random,
  Server Random,
  Pre-Master Secret
)
Session Key = Master Secret에서 파생
    ➡️ 클라이언트와 서버 모두 같은 재료를 가지고 있으므로 동일한 대칭키를 생성할 수 있다.

✨ Step 6: Change Cipher Spec (클라이언트)

  • 설명: 클라이언트가 "이제부터 암호화 통신을 시작합니다"라고 알린다.

✨ Step 7: Finished (클라이언트)

  • 설명: 클라이언트가 검증 메시지를 보낸다.
  • 내용
    • 지금까지 주고받은 모든 HandShake 메시지를 해싱한다.
    • 생성한 대칭키로 암호화하여 전송한다.

✨ Step 8: Change Cipher Spec (서버)

  • 설명: 서버도 "암호화 통신 시작"을 알린다.

✨ Step 9: Finished (서버)

  • 설명: 서버도 검증 메시지를 보낸다.
  • 검증
    • 서버도 모든 HandShake 메시지를 해싱한다.
    • 클라이언트가 보낸 값과 비교한다.
    • 일치하면 대칭키로 암호화한 Finished 메시지를 전송한다.

5. 보안 메커니즘

✨ 중간자 공격(MITM) 방지

중간자 공격이란, 해커가 클라이언트와 서버 사이에서 통신을 가로채고 조작하는 것을 말한다.
TLS는 이를 세 가지 방어선으로 막아낸다.

  1. 인증서 체인(Chain of Trust) 검증
    • 서버가 보낸 인증서가 신뢰할 수 있는 CA(인증 기관)에 의해 서명되었는지 확인한다.
    • 브라우저는 '루트 CA'의 공개키를 이미 가지고 있으며, 이를 통해 루트 CA → 중간 CA → 서버 인증서로 이어지는 신뢰의 사슬을 검증한다.
  2. Handshake 무결성 확인 (Finished 메시지)
    • 핸드셰이크 과정에서 오간 모든 메시지를 해싱하여 대칭키로 암호화해 서로 교환한다.
    • 만약 중간에 해커가 암호 알고리즘을 약한 것으로 바꾸는 등의 조작을 했다면, 해시값이 일치하지 않아 즉시 연결이 차단된다.
  3. 재생 공격(Replay Attack) 방지
    • 클라이언트와 서버가 매번 생성하는 Random 데이터는 일종의 '일회용 번호(Nonce)' 역할을 한다.
    • 해커가 이전에 성공했던 통신 패킷을 그대로 복사해서 다시 보내더라도, 랜덤 값이 매번 다르기 때문에 서버는 이를 무효한 요청으로 간주한다.

✨ 완전 순방향 비밀성 (PFS: Perfect Forward Secrecy)

가장 강력한 보안 기능 중 하나로, "오늘 서버의 개인키가 털려도, 어제 주고받은 대화는 안전하다"는 원칙이다.

  • 기존 방식 (RSA 키 교환): 서버의 개인키가 유출되면, 해커가 과거에 캡처해둔 모든 통신 데이터를 복호화할 수 있는 치명적인 약점이 있다.
  • PFS 방식 (DHE/ECDHE)
    • 고정된 개인키를 사용하는 대신, 매 세션마다 임시 키(Ephemeral Key)를 생성하여 대칭키를 만든다.
    • 통신이 끝나면 이 암시 키는 즉시 파기되므로, 나중에 서버의 마스터 개인키가 유출되더라도 과거의 통신 내용을 복구할 방법이 없다.
    • 현대 TLS(1.3 등)에서는 이 PFS 방식을 필수적으로 사용한다.

✨ 데이터 무결성 및 인증 (MAC/HMAC)

데이터가 전송 중에 1비트라도 바뀌지 않았음을 보장하는 장치이다.

  • HMAC (Hash-based Message Authentication Code)
    • 송신자는 데이터와 대칭키를 조합해 해시값(MAC)을 만들어 데이터 뒤에 붙인다.
    • 수신자는 받은 데이터와 자신의 대칭키로 직접 해시를 계산해보고, 받은 MAC과 일치하는지 확인한다.
    • 이를 통해 데이터 변조 여부와 보낸 사람이 본인이 맞는지를 동시에 확인한다.

✨ 보안 메커니즘 요약

✨ 최신 보안 강화 기술

기술설명효과
HSTS브라우저에게 "이 사이트는 무조건 HTTPS로만 접속해"라고 강제하는 설정HTTP 강제 전환 공격 방지
OCSP Stapling서버가 미리 인증서 유효성 확인서를 받아 클라이언트에게 전달인증서 확인 속도 향상 및 프라이버시 보호
TLS 1.3취약한 암호화 방식(DES, MD5 등)을 완전히 제거보안 구멍 원천 차단

6. 인증서 검증 과정

브라우저는 서버가 보낸 인증서가 진짜인지 확인하기 위해 '신뢰의 사슬(Chain of Trust)'을 거슬러 올라가며 검증을 수행한다.

✨ 인증서 체인 검증 (Chain of Trust)

대부분의 서버 인증서는 루트 CA가 직접 발급하지 않고, 보안을 위해 중간 CA(Intermediate CA)를 거쳐 발급된다.

  • 서버 인증서 수신: 서버가 자신의 인증서와 중간 CA 인증서를 함께 보낸다.
  • 중간 CA 검증: 서버 인증서에 찍힌 서명이 중간 CA의 것인지 확인한다.
  • 루트 CA 검증: 중간 CA 인증서에 찍힌 서명이 루트 CA의 것인지 확인한다.
  • 최종 신뢰 확인: 브라우저(또는 OS)의 신뢰할 수 있는 루트 인증서 저장소(Trust Store)에 해당 루트 CA가 등록되어 있는지 확인한다.

✨ 단계별 상세 검증 로직

  1. 디지털 서명 복호화 및 비교
    • 과정: 브라우저는 상위 CA의 공개키를 사용하여 인증서에 포함된 '디지털 서명'을 복호화한다.
    • 검증: 복호화해서 나온 해시값과, 브라우저가 직접 인증서 내용을 해싱한 값이 일치하는지 비교한다.
    • 의미: 1비트라도 수정되었다면 해시값이 달라지므로 데이터 변조 여부를 완벽히 알 수 있다.
  1. 인증서 메타데이터 검증
    • 도메인(Subject Alt Name): 인증서에 찍힌 도메인(예: *.naver.com)과 사용자가 주소창에 입력한 주소가 일치하는지 확인한다.
    • 유효 기간(Validity): 현재 시간이 인증서의 '시작일'과 '만료일' 사이에 있는지 확인한다.
  1. 실시간 폐기 여부 확인 (Revocation Check)
    인증서가 유효 기간 내에 있더라도, 키 유출 등의 사유로 취소되었을 수 있다.
    • CRL (Certificate Revocation List): CA가 배포하는 '취소된 인증서 목록' 파일을 다운로드하여 대조한다. (목록이 커지면 느려짐)
    • OCSP (Online Certificate Status Protocol): CA 서버에 "이 인증서 아직 괜찮나요?"라고 실시간으로 물어본다.
    • OCSP Stapling: 서버가 미리 CA로부터 "이 인증서는 안전함"이라는 증명서를 받아두었다가 클라이언트에게 전달하여 속도를 높인다.

✨ 인증서 종류에 따른 신뢰 수준

종류검증 대상특징
DV (Domain Validation)도메인 소유권가장 빠르고 저렴함 (Let's Encrypt 등)
OV (Organization Validation)도메인 + 실존 기업기업의 실재성을 확인하여 신뢰도 높음
EV (Extended Validation)매우 엄격한 기업 심사과거 주소창에 회사 이름이 직접 표시되던 가장 높은 등급

✨ 검증 실패 시 발생하는 일

하나라도 검증에 실패하면 브라우저는 "연결이 비공개로 설정되어 있지 않습니다"라는 무시무시한 경고창을 띄워 사용자를 보호한다.
이는 중간자 공격(MITM)이나 피싱 사이트일 가능성이 높기 때문이다.

7. 실제 예시

✨ 웹사이트 접속 실례: 네이버(Naver) 접속 시

우리가 주소창에 https://www.naver.com을 입력하고 페이지가 뜨기까지의 찰나(약 0.5초~1초)에 일어나는 일이다.

  • TCP 연결: 먼저 서버와 3-Way Handshake를 통해 기본적인 통신 통로를 연다.
  • TLS Handshake 수행
    • 브라우저가 네이버 서버의 인증서를 받아 '진짜 네이버'인지 확인한다.
    • 서로 암호화 알고리즘을 맞추고, 데이터를 암호화할 대칭키(세션 키)를 생성한다.
  • 암호화 데이터 전송: 이제 생성된 대칭키로 HTML, 이미지, 개인정보 등을 암호화하여 주고받는다.
  • 사용자 확인: 주소창에 자물쇠 아이콘🔒이 표시되며, 사용자는 안전한 연결임을 인지한다.

✨ 성능 최적화 기술

HTTPS는 암호화 과정 때문에 HTTP보다 느리다는 편견이 있었지만, 최신 기술들은 이를 거의 극복했다.

  1. TLS 1.3: 1-RTT 핸드셰이크
    • 기존(TLS 1.2): 암호화 통신을 시작하기 위해 클라이언트와 서버가 2번씩 왔다갔다(2-RTT) 해야 했다.
    • 개선(TLS 1.3): 첫 번째 메시지에 암호화에 필요한 정보를 미리 담아 보내 단 1번의 왕복(1-RTT)으로 과정을 끝낸다.
  1. 세션 재사용 (Session Resumption)
    • Session ID: 서버가 이전에 접속했던 클라이언트의 정보를 기억해 두었다가, 재접속 시 핸드셰이크 과정을 대폭 생략한다.
    • Session Ticket: 서버 대신 클라이언트가 암호화된 티켓을 가지고 있다가 재접속 시 서버에 보여주는 방식이다. (서버의 메모리 부담을 줄여준다.)
  1. 0-RTT (Zero Round Trip Time)
    • 개념: 이전에 접속했던 사이트라면, 핸드셰이크가 끝나기도 전에 첫 번째 요청 메시지와 함께 암호화된 데이터를 바로 보내버리는 기술이다.
    • 장점: 체감 속도가 비약적으로 빨라진다.
    • 주의(Trade-off): 해커가 해당 패킷을 가로채 똑같이 다시 보내는 재생 공격(Replay Attack)에 취약할 수 있어, 결제 같은 민감한 작업에는 사용하지 않는다.

✨ TLS 1.2 vs. 1.3 성능 비교

항목TLS 1.2TLS 1.3
핸드셰이크 속도2-RTT (느림)1-RTT (빠름)
재연결 속도1-RTT0-RTT (즉시)
보안성오래된 암호 방식 지원 (취약)최신 암호 방식만 지원 (강력)
성능 최적화기본 수준최적화 설계 (CPU 부하 감소)

✨ 기타 최적화 기법

  • HSTS (HTTP Strict Transport Security): 브라우저가 처음부터 HTTPS로만 접속하도록 강제하여, HTTP에서 HTTPS로 리다이렉트되는 시간(약 0.1초~0.2초)을 절약한다.
  • OCSP Stapling: 인증서 유효성 확인을 서버가 대신 처리하여 클라이언트의 대기 시간을 줄인다.

✨ 성능 최적화 흐름도

profile
jiny
이전 포스트

[Network] HTTP & HTTPS

다음 포스트

[Network] 로드 밸런싱 (Load Balancing)

0개의 댓글