SSL/TLS 작동 원리: TLS 핸드셰이크 설명

HTTPS 웹사이트를 방문할 때마다 브라우저와 서버는 TLS 핸드셰이크를 수행합니다 — 서버를 인증하고 암호화 매개변수에 합의하며 공유 비밀 키를 도출하는 빠른 교환입니다. 이 과정은 페이지 콘텐츠가 로드되기 전에 1-2회의 네트워크 왕복(50-200ms)으로 완료됩니다.

TLS 1.3 핸드셰이크 (현재 표준)

TLS 1.3은 단일 왕복(1-RTT)으로 핸드셰이크를 완료합니다:

1단계 — Client Hello 브라우저가 전송: 지원하는 TLS 버전, 지원하는 암호 스위트, 난수, 키 공유 매개변수(Diffie-Hellman 키 교환용).

2단계 — Server Hello + Certificate + Finished 서버가 응답: 선택된 암호 스위트, 인증서(서버 신원 증명), 키 공유, “Finished” 메시지. TLS 1.3에서는 인증서가 암호화되어 수동 관찰자가 어떤 사이트에 연결하는지 볼 수 없습니다.

3단계 — Client Finished 브라우저가 신뢰할 수 있는 CA 목록을 기준으로 인증서를 검증하고, Diffie-Hellman 교환으로 공유 세션 키를 계산한 후 “Finished” 메시지를 전송합니다. 이제 암호화된 애플리케이션 데이터가 흐를 수 있습니다.

총 1회 왕복. 이전에 연결한 적 있는 재개 연결은 0-RTT를 사용할 수 있습니다 — 첫 번째 메시지와 함께 암호화된 데이터를 전송합니다.

TLS 1.2 핸드셰이크 (여전히 널리 사용)

TLS 1.2는 2회 왕복이 필요합니다:

1. Client Hello → 지원 버전, 암호, 난수
2. Server Hello → 선택된 암호, 인증서, 서버 키 교환
3. Client Key Exchange → 프리마스터 시크릿(서버의 공개키로 암호화 또는 Diffie-Hellman 통해)
4. Change Cipher Spec + Finished (양측)

TLS 1.2는 더 많은 암호 스위트를 지원하며 — 일부 취약한 것도 포함됩니다. TLS 1.3보다 적절한 설정이 더 중요합니다.

암호화된 연결 내부에서 일어나는 일

핸드셰이크 후 모든 데이터는 협상된 세션 키를 사용하여 대칭 암호(일반적으로 AES-256-GCM 또는 ChaCha20-Poly1305)로 암호화됩니다:

• 기밀성 — 데이터가 암호화됨; 양쪽 끝점만 읽을 수 있음
• 무결성 — 각 메시지에 MAC(메시지 인증 코드)가 포함; 변조가 감지됨
• 인증 — 서버의 인증서가 신원을 증명(선택적으로 클라이언트도)

모든 HTTP 요청과 응답 — 헤더, 본문, 쿠키, URL — 이 암호화된 채널을 통해 전달됩니다.

순방향 비밀성

최신 TLS는 임시 Diffie-Hellman 키 교환을 사용하여 모든 연결이 고유한 세션 키를 생성합니다. 서버의 개인키가 나중에 침해되더라도 과거의 대화를 복호화할 수 없습니다.

TLS 1.3은 순방향 비밀성을 필수로 만들었습니다. TLS 1.2는 이를 지원하지만 RSA 키 교환(순방향 비밀성을 제공하지 않음)도 허용합니다. 이것이 TLS 1.3이 선호되는 이유입니다.

인증서의 역할

TLS 핸드셰이크는 서버에 유효한 SSL/TLS 인증서가 있어야 합니다. 인증서는 다음을 제공합니다:

1. 서버의 공개키 — 키 교환 중 사용
2. 도메인 이름 — 브라우저가 URL과 일치하는지 확인
3. CA 서명 — 신뢰할 수 있는 인증 기관이 이 인증서를 보증함을 증명
4. 유효기간 — 브라우저가 만료된 인증서를 거부

유효한 인증서가 없으면 핸드셰이크가 실패하고 브라우저가 보안 경고를 표시합니다. 무료 인증서 발급 →

성능

최신 하드웨어에서 암호화의 CPU 비용은 무시할 수 있습니다 — AES-NI 명령어가 하드웨어에서 처리합니다. 주요 비용은 추가 왕복이며, TLS 1.3이 이를 최소화합니다.

네트워크에서 볼 수 있는 것

HTTPS 없이 (HTTP)

네트워크의 관찰자가 모든 것을 봅니다:

GET /login HTTP/1.1
Host: example.com
Cookie: session=abc123

username=admin&password=secret123

사용자 이름, 비밀번호, 쿠키, 페이지 콘텐츠 — 모두 평문으로.

HTTPS 사용 시 (TLS)

동일한 관찰자가 보는 것:

[TLS handshake — server certificate visible in TLS 1.2, encrypted in TLS 1.3]
[Encrypted application data — indistinguishable from random bytes]
[Encrypted application data]
[Encrypted application data]

목적지 IP 주소와 SNI 호스트명(TLS 1.2에서 — TLS 1.3에서는 ECH로 암호화)만 볼 수 있습니다. URL 경로, 헤더, 본문, 쿠키는 볼 수 없습니다.

인증서의 위치

TLS 핸드셰이크는 서버에 유효한 SSL/TLS 인증서가 있어야 합니다:

1. 서버의 공개키 — 키 교환 중 사용
2. 도메인 이름 — 브라우저가 URL과 일치하는지 확인
3. CA 서명 — 신뢰할 수 있는 인증 기관이 이 인증서를 보증함을 증명
4. 유효기간 — 브라우저가 만료된 인증서를 거부

유효한 인증서가 없으면 핸드셰이크가 실패하고 브라우저가 보안 경고를 표시합니다. 무료 인증서 발급 →

2026년의 일반적인 TLS 암호 스위트

TLS 1.3 (5개 암호 스위트만 — 모두 안전)

TLS_AES_256_GCM_SHA384       ← Most common
TLS_AES_128_GCM_SHA256       ← Widely used
TLS_CHACHA20_POLY1305_SHA256 ← Best for mobile/ARM
TLS_AES_128_CCM_SHA256       ← IoT/embedded
TLS_AES_128_CCM_8_SHA256     ← IoT/embedded (short tag)

TLS 1.2 (AEAD 스위트만 사용)

ECDHE-ECDSA-AES256-GCM-SHA384  ← Best with ECC cert
ECDHE-RSA-AES256-GCM-SHA384    ← Best with RSA cert
ECDHE-ECDSA-CHACHA20-POLY1305  ← Mobile-optimized

TLS 1.2에서 비AEAD 스위트(CBC 모드)는 피하세요 — BEAST 및 Lucky13과 같은 공격에 취약합니다.

자주 묻는 질문

HTTPS가 웹사이트를 느리게 만드나요?

TLS 핸드셰이크가 첫 번째 연결에 1회 왕복(TLS 1.3) 또는 2회(TLS 1.2)를 추가합니다. 세션 재개는 재방문 시 이를 제거합니다. HTTPS는 HTTP/2(멀티플렉싱, 헤더 압축)를 활성화하므로 HTTPS 사이트가 전반적으로 더 빠른 경우가 많습니다.

암호 스위트란 무엇인가요?

암호 스위트는 키 교환, 암호화, 메시지 인증에 사용되는 알고리즘의 조합입니다. 예: TLS_AES_256_GCM_SHA384는 AES-256-GCM 암호화와 SHA-384 메시지 무결성을 사용하는 TLS를 의미합니다. TLS 1.3에는 5개의 암호 스위트만 있으며 모두 안전합니다. TLS 1.2에는 37개가 있으며 일부는 취약합니다.

누군가 나중에 HTTPS 트래픽을 복호화할 수 있나요?

순방향 비밀성(임시 키 교환)이 있으면 불가능합니다. 각 세션은 Diffie-Hellman 교환에서 도출된 고유한 키를 사용합니다. 서버의 장기 개인키가 침해되어도 과거 세션 키를 복구할 수 없습니다. TLS 1.3은 이를 강제합니다; TLS 1.2는 올바르게 설정하면 지원합니다.

GetHTTPS는 이것과 어떤 관계인가요?

GetHTTPS는 TLS 핸드셰이크를 가능하게 하는 인증서를 생성합니다. 인증서에는 서버가 키 교환 중 사용하는 공개키가 포함되어 있습니다. GetHTTPS는 Web Crypto API를 사용하여 브라우저에서 이 키 쌍을 생성하고 Let’s Encrypt의 ACME API에 직접 연결하여 서명을 받습니다. GetHTTPS 작동 방식 →