학습 목표
HTTPS가 HTTP에 기밀성·무결성·서버 인증을 더하는 이유를 설명할 수 있다.
TLS 가 TCP 위에서 핸드셰이크로 키·알고리즘을 맞추고 이후 트래픽을 암호화함을 설명할 수 있다.
인증서와 CA 체인으로 브라우저가 서버 신원을 검증하는 과정을 설명할 수 있다.
curl -v, openssl s_client 출력에서 TLS·인증서 단서를 읽을 수 있다.
문제 상황
- 카페 Wi‑Fi에서
http://로그인 폼을 제출했다- 같은 LAN의 누군가 패킷을 읽거나 수정할 수 있다 — HTTP는 평문
https://api.example.com은 되는데 자체 서명 인증서 서버는 브라우저가 차단한다- 누가 신뢰하는지, 무엇을 검사하는지 모르면 내부망·스테이징 배포가 막힌다
curl -v에TLSv1.3,Server certificate,subject: CN=...이 섞여 나온다- HTTP 헤더와 TLS 협상 중 어디서부터 암호화되는지 경계가 불명확하다
- LB에서 TLS를 종료(termination) 한다고 하는데, 백엔드는
http://다- 암호화 구간이 어디까지인지 그리지 못하면 보안 설계·감사가 어긋난다
HTTP 메시지·쿠키·캐시를 봤다. 웹·API 트래픽의 대부분은 HTTPS — TLS가 무엇을 하는지부터 잡는다.
1. HTTPS가 필요한 이유
공개 네트워크에서는 패킷이 중간 경로를 거친다. HTTP 본문·헤더·쿠키는 그대로 노출될 수 있다.
| 위협 | HTTP (평문) | HTTPS (TLS) |
|---|---|---|
| 도청 | URL·본문·쿠키 읽기 가능 | 대칭키로 암호화된 레코드 |
| 변조 | 응답·JS 삽입 가능 | MAC/AEAD로 무결성 검증 |
| 가장 | 가짜 서버에 연결 가능 | 인증서로 서버 신원 확인 |
- 기밀성(confidentiality) — 제3자가 내용을 읽기 어렵게
- 무결성(integrity) — 전송 중 바뀌면 수신 측이 감지
- 인증(authentication) — 내가 연결한 상대가 주장하는 도메인의 서버인지
HTTPS는 별도 프로토콜이라기보다 HTTP를 TLS 위에서 돌리는 관례다. URL scheme https, 기본 포트 443.
2. 프로토콜 스택에서 TLS 위치
TLS(Transport Layer Security)는 애플리케이션과 전송 계층 사이에서 동작한다. (구 SSL의 후속)
[ HTTP ] 요청/응답 — 애플리케이션 계층
[ TLS ] 핸드셰이크 · 암호화/복호화
[ TCP ] 연결 · 신뢰성
[ IP ] 라우팅- 브라우저·
curl은 TLS 소켓 위에 HTTP 메시지를 올린다 — 앱 코드는 often 평문 HTTP를 쓰고, OS/라이브러리가 TLS 처리 - TLS termination: 로드 밸런서·Ingress가 TLS를 풀고 내부는 HTTP — 암호화 구간과 신뢰 경계를 문서·다이어그램에 명시해야 한다
- HTTP/3(QUIC)은 TLS 1.3을 통합 — 이후 편·심화에서 다룸
3. TLS 핸드셰이크 (개요)
연결 초기에 클라이언트·서버는 암호 스위트, 키 교환, 인증서를 협상한다. 이후 HTTP는 협상된 대칭키로 암호화된다.
| 단계 | 방향 | 내용 (개념) |
|---|---|---|
| ClientHello | C → S | 지원 TLS 버전·암호 스위트·난수 |
| ServerHello | S → C | 선택된 버전·스위트·난수 |
| Certificate | S → C | 서버 인증서 (공개키 포함) |
| 키 교환 | C ↔ S | (ECDHE 등) 세션 키 유도 |
| Finished | C ↔ S | 핸드셰이크까지 MAC — 이후 암호화 |
- TLS 1.3은 왕복을 줄이고 1-RTT(·0-RTT resumption)를 목표로 설계 — 세부는 RFC·Security 시리즈에서
- 핸드셰이크 전 트래픽은 (인증서 제외) 평문에 가깝고, Finished 이후 HTTP가 암호화 레코드로 감싸진다
- 실패 시:
certificate has expired,hostname mismatch,unknown ca등 — 브라우저·curl이 연결 중단
curl -v https://example.com/ 2>&1 | grep -iE 'TLS|SSL|subject:|issuer:|expire'4. 인증서와 PKI
서버는 X.509 인증서로 공개키와 신원(주로 CN/SAN) 을 제시한다. 클라이언트는 CA(인증 기관) 가 서명했는지, 체인이 신뢰 저장소까지 이어지는지 검사한다.
| 구성 | 역할 |
|---|---|
| 서버 인증서 | CN/SAN에 도메인, 공개키, 유효기간 |
| 중간 CA | 루트 CA가 서명 — 브라우저/OS에 중간 저장 |
| 루트 CA | OS·브라우저 신뢰 저장소에 내장 |
| 개인키 | 서버만 보관 — 절대 클라이언트에 전송하지 않음 |
브라우저 검증 (요약)
- 서명 체인이 신뢰 루트까지 유효한가
- 만료·폐기(CRL/OCSP) 상태
- 접속 호스트명이 SAN/CN과 일치하는가 (
*.example.com와일드카드 규칙 주의)
# 인증서 체인·주체 확인
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates- Let's Encrypt 등은 DV 인증서를 자동 발급 — 운영에서 cert-manager·ACME 흔함
- 자체 서명(self-signed) — 개발·내부망용; 프로덕션은 공인 CA 또는 사내 PKI + 클라이언트 신뢰 등록
- 쿠키
Secure플래그는 HTTPS에서만 전송 — HTTP 심화와 연결
5. 실무에서 자주 보는 패턴
| 패턴 | 설명 |
|---|---|
| End-to-end TLS | 클라이언트 ↔ 서버 전 구간 암호화 |
| TLS termination at LB | LB에서 복호화, 내부망 HTTP — 내부망 신뢰 전제 |
| mTLS | 클라이언트도 인증서 제시 — API·서비스 메시 |
| HSTS | Strict-Transport-Security — 브라우저가 HTTP로 downgrade 방지 |
# 협상된 TLS 버전 (OpenSSL 연결)
echo | openssl s_client -connect example.com:443 -tls1_2 2>&1 | grep "Protocol"- Mixed content — HTTPS 페이지에서 HTTP JS/이미지 로드 시 브라우저 차단·경고
- 장애: 인증서 만료, 체인 누락, SNI 미설정(VirtualHost), 시간 skew(NTP)
6. 정리
- HTTPS는 HTTP + TLS — 기밀성·무결성·서버 인증을 공개 네트워크에 가져온다
- TLS는 TCP 위에서 핸드셰이크 후 대칭키로 레코드 암호화
- 인증서·CA 체인으로 서버 신원을 검증 —
openssl·curl -v로 확인 가능 - LB TLS 종료·HSTS·Secure 쿠키는 암호화 구간과 정책을 함께 봐야 한다
다음에 다룰 것
- DNS
- 도메인 → IP, 레코드 타입, 재귀·반복 질의
해당 내용은 Computer Networking: A Top-Down Approach, 8/E (James Kurose, Keith Ross) 의 내용을 기반으로 합니다.