HTTPS와 SSL/TLS: '자물쇠 아이콘' 뒤에 숨겨진 암호화의 원리

들어가며: 카페 Wi-Fi에서 로그인하면 안전한가?

토요일 오후, 강남역 카페에 앉아 노트북을 열었다. Wi-Fi에 연결하고 은행 앱에 로그인한다. 아이디, 비밀번호 입력. "로그인 성공."

그런데 잠깐 — 이 카페 Wi-Fi에는 나 말고도 수십 명이 연결되어 있다. 옆자리의 누군가가 같은 네트워크에서 내 통신 데이터를 엿보고 있다면? 내가 방금 입력한 비밀번호가 그대로 노출되는 건 아닐까?

이것은 가상의 공포가 아니다. 중간자 공격(Man-in-the-Middle Attack, MITM)이라는 이름의 실제 해킹 기법이다.

이 자물쇠 아이콘 하나의 뒤에는 30년에 걸친 암호학의 역사, 수학적 난제, 그리고 수십억 달러 규모의 인프라가 숨겨져 있다. 오늘은 그 모든 것을 풀어본다.

1. SSL에서 TLS까지: 30년의 진화

1994년: Netscape가 연 암호화 시대

HTTPS의 역사는 웹 브라우저의 탄생과 함께한다. 1994년, Netscape Communications의 엔지니어들은 심각한 문제에 직면했다. 인터넷 쇼핑이 시작되고 있었지만, 신용카드 번호를 입력하면 그 데이터가 인터넷을 평문으로 날아갔다. 누구든 중간에서 가로챌 수 있었다.

Netscape는 SSL(Secure Sockets Layer)이라는 프로토콜을 만들었다. SSL 1.0은 내부 검토에서 심각한 보안 결함이 발견되어 공개조차 되지 못했다. SSL 2.0이 1995년에 처음 배포되었고, 곧이어 SSL 3.0(1996년)이 나왔다.

하지만 SSL이라는 이름은 Netscape라는 특정 회사의 소유였다. 인터넷 표준화를 위해 IETF(Internet Engineering Task Force)가 프로토콜을 인수하면서 이름을 TLS(Transport Layer Security)로 바꿨다.

2. 대칭 암호화 vs 비대칭 암호화: 금고와 열쇠의 비유

TLS의 동작 원리를 이해하려면 먼저 두 가지 암호화 방식을 알아야 한다.

대칭 암호화 (Symmetric Encryption)

하나의 열쇠로 잠그고, 같은 열쇠로 푼다.

일상적인 비유로 설명하면: 당신과 친구가 같은 자물쇠 열쇠를 하나씩 가지고 있다. 당신이 상자에 비밀 편지를 넣고 잠그면, 친구가 같은 열쇠로 열 수 있다. 빠르고 단순하다.

대표 알고리즘: AES-128, AES-256, ChaCha20

문제점: 열쇠를 어떻게 상대방에게 안전하게 전달하는가? 인터넷에서 열쇠를 보내는 순간, 그 열쇠도 도청당할 수 있다. 이것이 키 교환(Key Exchange) 문제다.

비대칭 암호화 (Asymmetric Encryption)

공개 열쇠로 잠그고, 비밀 열쇠로만 풀 수 있다.

이번에는 특수한 자물쇠를 상상해 보자. 이 자물쇠에는 열쇠가 두 개다:

• 공개키(Public Key): 누구나 가질 수 있는 열쇠. 이 열쇠로는 잠글 수만 있고, 열 수는 없다.
• 개인키(Private Key): 오직 나만 가진 열쇠. 이 열쇠로만 열 수 있다.

당신이 나에게 비밀 메시지를 보내고 싶다면: 나의 공개키로 메시지를 잠근다. 전 세계 누구도, 심지어 당신도, 이 메시지를 열 수 없다. 오직 나의 개인키만이 풀 수 있다.

대표 알고리즘: RSA, ECDSA, Ed25519

문제점: 비대칭 암호화는 대칭 암호화보다 약 1,000배 느리다. 웹페이지의 모든 데이터를 비대칭 암호화로 전송하면 체감 속도가 끔찍해진다.

TLS의 해법: 두 방식의 결합

TLS는 이 두 가지를 하이브리드로 조합한다.

3. TLS 핸드셰이크: 악수 한 번에 벌어지는 암호학

브라우저에서 https://core.today를 입력하는 순간, 화면에 페이지가 뜨기 전에 보이지 않는 "악수(Handshake)"가 벌어진다.

이 과정에서 브라우저와 서버는 서로의 신원을 확인하고, 암호화 방식을 협상하고, 세션 키를 생성한다.

TLS 1.2 핸드셰이크 (2-RTT)

각 단계에서 어떤 일이 벌어지는지 자세히 보자.

TLS 1.3의 혁신: 1-RTT 핸드셰이크

TLS 1.2는 핸드셰이크에 2 라운드트립(2-RTT)이 필요했다. 서울에서 미국 서버까지 왕복 약 200ms라면, 핸드셰이크에만 400ms가 걸린다.

TLS 1.3은 이것을 1-RTT로 줄였다. 어떻게? ClientHello에서 키 교환 정보까지 한꺼번에 보낸다.

더 놀라운 것은 0-RTT 재개(Resumption)다. 한번 연결했던 서버에 다시 접속할 때, 이전 세션의 키를 재사용해 핸드셰이크 없이 즉시 암호화 데이터를 보낼 수 있다.

암호 스위트: TLS 1.3이 정리한 것

TLS 1.2까지는 수백 개의 암호 스위트 조합이 가능했다. 그중 상당수는 취약했다. TLS 1.3은 과감하게 5개의 암호 스위트만 남겼다.

제거된 것들: RC4, DES, 3DES, CBC 모드, 정적 RSA 키 교환, MD5, SHA-1. 모두 알려진 취약점이 있거나 전방향 비밀성(Forward Secrecy)을 보장하지 못하는 것들이다.

4. 인증서와 신뢰 체계: "이 서버가 진짜 네이버인지 어떻게 아는가?"

암호화만으로는 부족하다. 내 데이터가 암호화되어 전송된다 해도, 수신자가 진짜 네이버 서버인지 확인할 방법이 없다면 의미가 없다.

공격자가 가짜 네이버 서버를 운영하고, 거기로 내 트래픽을 유도하면?

이 문제를 해결하는 것이 디지털 인증서(Digital Certificate)와 인증 기관(Certificate Authority, CA)이다.

인증서의 구조

TLS 인증서(X.509)에는 이런 정보가 들어 있다:

신뢰의 체인 (Chain of Trust)

브라우저가 인증서를 신뢰하는 과정은 체인 구조다.

1. 루트 CA: 자기 자신이 서명한 인증서를 가진 최상위 기관. DigiCert, Comodo, IdenTrust(Let's Encrypt의 상위) 등. 이들의 인증서는 브라우저/OS에 미리 설치되어 있다. (macOS의 키체인, Windows의 인증서 저장소, Chrome의 Root Store)
2. 중간 CA: 루트 CA가 서명한 인증서를 가진 중간 기관. 실제 서버 인증서를 발급하는 역할.
3. 서버 인증서: 중간 CA가 서명한, 특정 도메인에 대한 인증서.

브라우저는 서버 인증서 → 중간 CA 인증서 → 루트 CA 인증서 순서로 서명을 검증한다. 루트 CA가 브라우저에 내장된 것과 일치하면 신뢰 체인이 완성된다.

Let's Encrypt 혁명

2015년 이전, TLS 인증서는 유료였다. 단일 도메인 인증서가 연간 $50~$300. 와일드카드 인증서는 $500 이상. 이 비용이 소규모 웹사이트들이 HTTPS를 도입하지 못하는 주요 장벽이었다.

Let's Encrypt가 이것을 바꿨다.

Let's Encrypt는 ISRG(Internet Security Research Group)가 운영하는 비영리 CA다. ACME(Automatic Certificate Management Environment) 프로토콜을 통해 인증서 발급을 완전 자동화했다. certbot이라는 도구 하나면 커맨드 한 줄로 인증서를 발급받고 갱신할 수 있다.

# Let's Encrypt 인증서 발급 (Certbot)
sudo certbot --nginx -d core.today -d www.core.today

# 자동 갱신 확인
sudo certbot renew --dry-run

Let's Encrypt 이전에는 전 세계 웹사이트의 약 40%만 HTTPS를 사용했다. 2026년 현재, 95% 이상의 웹 트래픽이 HTTPS다. Let's Encrypt가 인터넷 보안의 패러다임을 바꾼 것이다.

인증서 종류: DV, OV, EV

5. 브라우저의 자물쇠 아이콘: 실제로 무엇을 의미하는가

이제 매일 보는 자물쇠 아이콘이 무엇을 보장하는지 정확히 정리하자.

자물쇠가 보장하는 것

자물쇠가 보장하지 않는 것

이것이 중요하다. 많은 사람들이 "자물쇠가 있으면 안전한 사이트"라고 오해한다.

Mixed Content 문제

HTTPS 페이지에서 HTTP 리소스(이미지, 스크립트 등)를 로드하면 Mixed Content 경고가 발생한다. 이는 암호화 체인의 약한 고리가 된다.

<!-- Mixed Content 경고 발생 -->
<img src="http://example.com/image.png" />

<!-- 올바른 방법 -->
<img src="https://example.com/image.png" />

<!-- 프로토콜 상대 경로 (권장하지 않지만 가능) -->
<img src="//example.com/image.png" />

최신 브라우저는 Mixed Content 중 스크립트(Active Mixed Content)를 완전히 차단하고, 이미지(Passive Mixed Content)는 경고를 표시한다.

6. HTTPS 역사상 주요 취약점들

TLS의 역사는 취약점 발견과 수정의 역사이기도 하다. 주요 사건들을 알아두면 보안 설계의 교훈을 얻을 수 있다.

Heartbleed (2014) — 인터넷의 심장이 터지다

사상 최악의 TLS 취약점 중 하나. OpenSSL 라이브러리의 하트비트(Heartbeat) 확장 기능에서 발견되었다.

POODLE (2014) — SSL 3.0의 최후

Padding Oracle On Downgraded Legacy Encryption. SSL 3.0의 CBC 패딩 방식을 악용해 암호화된 쿠키를 한 바이트씩 복호화할 수 있는 취약점이다.

더 심각한 문제는 다운그레이드 공격이었다. TLS 1.2를 지원하는 서버라도, 공격자가 중간에서 핸드셰이크를 조작해 의도적으로 SSL 3.0으로 다운그레이드시킬 수 있었다. 이 공격은 SSL 3.0의 완전한 폐기를 촉발했다.

기타 주요 취약점들

7. HTTP/2와 HTTP/3 (QUIC): HTTPS 위의 성능 혁신

HTTPS가 보안을 해결했다면, HTTP/2와 HTTP/3는 속도를 해결한다. 그리고 이 두 프로토콜은 사실상 HTTPS를 전제로 설계되었다.

HTTP/1.1의 병목

HTTP/1.1에서는 하나의 TCP 연결에서 한 번에 하나의 요청-응답만 처리할 수 있다. 웹페이지에 CSS, JS, 이미지 등 50개의 리소스가 있다면? 50개의 TCP 연결을 열거나, 하나의 연결에서 직렬로 50번 요청해야 한다. 이것이 Head-of-Line(HOL) Blocking 문제다.

HTTP/2: 멀티플렉싱

HTTP/2(2015년)는 하나의 TCP 연결 위에 여러 요청-응답을 동시에 주고받는 멀티플렉싱(Multiplexing)을 도입했다.

HTTP/2의 핵심 기능:

• 멀티플렉싱: 하나의 연결에서 여러 스트림 동시 전송
• 헤더 압축 (HPACK): 반복되는 HTTP 헤더를 압축해 오버헤드 감소
• 서버 푸시: 클라이언트가 요청하기 전에 서버가 미리 리소스를 전송
• 스트림 우선순위: CSS를 이미지보다 먼저 전송하도록 우선순위 지정

HTTP/3과 QUIC: TCP를 넘어서

HTTP/2에도 근본적 한계가 있었다. TCP 자체의 HOL Blocking이다. TCP에서 하나의 패킷이 손실되면, 그 패킷이 재전송될 때까지 같은 연결의 모든 스트림이 멈춘다. 아무리 멀티플렉싱을 해도 TCP 레벨에서 병목이 발생한다.

HTTP/3(2022년)은 TCP를 완전히 버리고 QUIC 프로토콜을 사용한다. QUIC는 Google이 개발한 UDP 기반 전송 프로토콜이다.

QUIC의 핵심 혁신은 TLS 1.3을 전송 계층에 내장한 것이다. TCP + TLS에서는 TCP 핸드셰이크(1-RTT) + TLS 핸드셰이크(1-RTT)로 최소 2-RTT가 필요했다. QUIC는 이를 1-RTT로 통합하고, 재연결 시 0-RTT가 가능하다.

모바일 환경에서 특히 강력하다. Wi-Fi에서 LTE로 전환될 때 TCP 연결은 끊어지지만, QUIC는 Connection ID 기반으로 연결을 유지한다. 지하철에서 유튜브를 보다가 셀 전환이 일어나도 영상이 끊기지 않는 이유다.

8. 클라우드에서의 TLS: AWS 실전 운영

이론을 알았으니 실전으로 가보자. 클라우드 환경에서 HTTPS를 어떻게 구성하고 운영하는가?

AWS Certificate Manager (ACM) — 무료 인증서

AWS는 ACM(AWS Certificate Manager)을 통해 TLS 인증서를 무료로 발급하고 관리한다. Let's Encrypt와 비슷하지만, AWS 서비스와의 통합이 핵심이다.

# AWS CLI로 ACM 인증서 발급
aws acm request-certificate \
  --domain-name core.today \
  --subject-alternative-names "*.core.today" \
  --validation-method DNS \
  --region us-east-1  # CloudFront용은 반드시 us-east-1

TLS 종료(Termination) 아키텍처

프로덕션 환경에서는 TLS 종료 지점을 어디에 둘 것인가가 중요한 설계 결정이다.

왜 ALB에서 TLS를 종료하는가?

1. 성능: TLS 암호화/복호화는 CPU 집약적이다. ALB가 이 부담을 맡으면 애플리케이션 서버는 비즈니스 로직에 집중할 수 있다.
2. 인증서 관리: ACM 인증서를 ALB에 연결하면 자동 갱신이 된다. 개별 서버에 인증서를 배포하고 갱신하는 운영 부담이 사라진다.
3. VPC 내부 보안: ALB 뒤의 통신은 AWS VPC 내부에서 이루어진다. VPC는 격리된 네트워크이므로 평문 통신이라도 외부에서 접근할 수 없다.

CloudFront + ACM 실전 설정

HSTS (HTTP Strict Transport Security)

Strict-Transport-Security 헤더는 브라우저에게 "이 사이트는 항상 HTTPS로만 접속하라"고 알려준다.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

• max-age=63072000: 2년 동안 이 정책을 기억
• includeSubDomains: 모든 서브도메인에도 적용
• preload: HSTS Preload List에 등록 요청 (브라우저에 미리 내장)

HSTS Preload List에 등록되면, 사용자가 처음 방문하기 전부터 브라우저가 HTTPS를 강제한다. 첫 번째 HTTP 요청조차 차단하므로 다운그레이드 공격이 불가능해진다.

9. 실전 보안 점검: 당신의 서버는 안전한가?

지금까지 배운 내용을 바탕으로, 실제 서비스의 TLS 설정을 점검하는 방법을 알아보자.

SSL Labs 테스트

Qualys의 SSL Labs(ssllabs.com/ssltest)는 무료 TLS 진단 도구다. 도메인을 입력하면 A+부터 F까지 등급을 매겨준다.

A+ 등급을 받으려면:

• TLS 1.2 이상만 지원 (TLS 1.0/1.1 비활성화)
• 전방향 비밀성(Forward Secrecy) 지원
• HSTS 헤더 활성화
• 약한 암호 스위트 비활성화 (RC4, 3DES, CBC 모드 등)

커맨드라인 점검

# 서버의 TLS 설정 확인
openssl s_client -connect core.today:443 -tls1_3

# 지원하는 암호 스위트 목록
nmap --script ssl-enum-ciphers -p 443 core.today

# 인증서 만료일 확인
echo | openssl s_client -connect core.today:443 2>/dev/null | \
  openssl x509 -noout -dates

# HSTS 헤더 확인
curl -sI https://core.today | grep -i strict

체크리스트: 프로덕션 HTTPS 설정

10. 미래: 포스트 양자 암호화

한 가지 더 알아둘 것이 있다. 현재 TLS의 키 교환에 사용되는 ECDHE, RSA 같은 알고리즘은 양자 컴퓨터가 실용화되면 깨질 수 있다. 쇼어 알고리즘(Shor's Algorithm)이 큰 수의 소인수 분해와 이산 로그 문제를 다항 시간에 풀 수 있기 때문이다.

이에 대비해 포스트 양자 암호화(Post-Quantum Cryptography, PQC)가 연구되고 있다. 2024년, NIST는 최초의 포스트 양자 암호화 표준을 공식 발표했다:

Chrome은 이미 2024년부터 X25519Kyber768 하이브리드 키 교환을 기본 활성화했다. 기존 X25519(타원곡선)와 ML-KEM(포스트 양자)을 동시에 사용해, 둘 중 하나가 깨져도 안전하도록 설계했다. AWS CloudFront도 2024년부터 하이브리드 포스트 양자 TLS를 지원한다.

마치며: HTTPS는 더 이상 선택이 아니다

2016년만 해도 "HTTPS는 은행이나 쇼핑몰에만 필요한 것"이라는 인식이 있었다. 2026년 현재, 이 말은 완전히 틀렸다.

HTTPS가 필수인 이유를 정리하면:

1. 보안: 중간자 공격, 도청, 데이터 변조로부터 사용자를 보호한다.
2. 신뢰: 브라우저가 HTTP 사이트에 "주의 요함" 경고를 표시한다. 사용자가 이탈한다.
3. SEO: Google이 HTTPS를 검색 순위 신호로 사용한다. HTTP 사이트는 불이익을 받는다.
4. 기능: HTTP/2, HTTP/3, Service Worker, 지오로케이션 API, 카메라/마이크 접근 등 최신 웹 기능은 HTTPS에서만 동작한다.
5. 비용: Let's Encrypt와 AWS ACM 덕분에 인증서 비용은 $0이다.

카페 Wi-Fi에서 로그인하면 안전한가? 답은 "HTTPS라면, 그렇다"이다.

지금 당신의 서비스가 HTTP라면, certbot이든 ACM이든, 오늘 당장 HTTPS로 전환하자. 비용도 없고, 이유도 없다. 2026년에 HTTP를 사용하는 것은 현관문을 열어놓고 자는 것과 같다.

다음 글에서는 이 시리즈의 연장선에서 네트워크 보안의 또 다른 축인 VPC, Security Group, 그리고 제로 트러스트 아키텍처를 다룰 예정이다.