TLS (HTTPS, 인증서, CA)

통신을 암호화하고 상대가 진짜인지 확인하는 계층. HTTP 위에 얹으면 HTTPS다.

왜 두 종류의 자물쇠를 섞나

대칭키 — 같은 키로 암호화·복호화. 빠르다
- 문제: 그 키를 어떻게 안전하게 나눠 갖나

비대칭키 공개키로 잠그고 개인키로만 열 수 있다. 키 배포 문제가 없다

- 문제: 느리다 (수백~수천 배)

해법: 비대칭키로 '대칭키를 나눠 갖는 과정' 만 보호하고,

실제 데이터는 빠른 대칭키로 주고받는다

세 가지를 동시에 보장한다

기밀성 — 암호화 — 훔쳐봐도 못 읽는다
무결성 — MAC · AEAD — 중간에 바꾸면 들킨다
인증 — 인증서 — 상대가 진짜 그 서버인가

셋 중 인증이 가장 어렵다 — 암호화만 하면 중간자와 안전하게 통신할 뿐이다.

인증서와 신뢰 사슬

루트 CA (브라우저·OS 에 미리 내장돼 있다)
   │ 서명
중간 CA
   │ 서명
example.com 인증서 (공개키 + 도메인 + 유효기간)

검증: 사슬을 위로 따라가 신뢰하는 루트에 닿는가
      + 도메인이 맞는가 + 유효기간 안인가 + 폐기되지 않았는가

openssl s_client -connect example.com:443 -servername example.com
openssl x509 -in cert.pem -noout -text -dates

"인증서 오류"의 대부분은 만료·도메인 불일치·중간 인증서 누락 셋 중 하나다. 특히 마지막은 브라우저에서는 되고 서버 간 호출에서만 실패해 헷갈린다.

핸드셰이크가 짧아졌다

TLS 1.2 — 2-RTT — 알고리즘 협상 → 키 교환
TLS 1.3 — 1-RTT — 클라이언트가 키 공유를 미리 추측해 보낸다
- 0-RTT — 재방문이면 이전 세션 정보로 첫 패킷에 데이터를 실어 보낸다
TLS 1.3 은 안전하지 않은 옛 알고리즘(RC4 · SHA-1 · 정적 RSA 키 교환)을 아예 제거했다

0-RTT의 대가

첫 패킷에는 재전송 방지 장치가 없다

공격자가 그 패킷을 복사해 다시 보낼 수 있다 (리플레이 공격)
그래서 0-RTT 는 '멱등한 요청' 에만 허용한다
- GET 은 되고 결제 POST 는 안 된다

전방 비밀성

지금 트래픽을 저장해 뒀다가 나중에 서버 개인키를 훔치면 다 풀 수 있을까?

정적 RSA 키 교환 — → 풀린다
ECDHE (임시 키) — → 세션마다 임시 키를 새로 만들어 못 푼다 (Perfect Forward Secrecy)

TLS 1.3 은 ECDHE 만 남겼다

면접 함정

❌ "HTTPS는 비대칭키로 데이터를 암호화한다" → 데이터는 대칭키다. 비대칭은 키 교환·인증에만 쓴다.
❌ "인증서가 있으면 안전하다" → 도메인 소유만 증명한다. 피싱 사이트도 인증서를 받을 수 있다.

핸드셰이크를 직접 본다

openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null
# Protocol  : TLSv1.3
# Cipher    : TLS_AES_128_GCM_SHA256
# Verify return code: 0 (ok)         ← 0 이 아니면 검증 실패

# 인증서 사슬이 온전한지
openssl s_client -connect example.com:443 -showcerts </dev/null | grep 's:\|i:'

SNI — 한 IP에 여러 사이트

암호화를 시작하려면 어느 인증서를 쓸지 정해야 한다 그런데 어느 사이트인지는 암호화된 HTTP 헤더 안에 있다 → 닭과 달걀

SNI: 클라이언트가 핸드셰이크 첫 메시지에 '평문으로' 도메인을 적어 보낸다

서버가 맞는 인증서를 고른다
대신 어느 사이트에 접속하는지가 노출된다 (ECH 로 이를 암호화하려는 표준이 진행 중)

-servername 옵션을 빼면 기본 인증서가 나와 검증이 실패하는 것처럼 보인다 — 진단할 때 흔히 헷갈리는 지점이다.

만료 감시

echo | openssl s_client -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -enddate
# notAfter=Nov 10 12:00:00 2026 GMT

인증서 만료로 인한 장애는 예고된 사고다 — 자동 갱신과 만료 알림을 반드시 건다.