TLS/HTTPS는 어떻게 동작하는가?

Question

IT Interview Practice · Accepted Answer

**HTTPS는 그저 TLS로 암호화된 채널 안에서 실행되는 HTTP다.** TLS(Transport Layer Security)는 세 가지 보장을 준다: **confidentiality**(트래픽이 암호화됨), **integrity**(감지되지 않게 변조될 수 없음), **authentication**(당신이 certificate에 이름 붙은 서버와 정말로 통신하고 있음). 그것은 어떤 HTTP도 보내기 전에 **handshake**로 협상된다:

```text
Client                                   Server
  │──── ClientHello ──────────────────────▶│   (TLS versions, cipher suites, random)
  │◀─── ServerHello + Certificate ─────────│   (chosen cipher + cert with public key)
  │                                         │
  │  verify cert against a trusted CA       │
  │  agree on keys (e.g. ECDHE key exchange)│
  │                                         │
  │──── Finished (encrypted) ──────────────▶│
  │◀─── Finished (encrypted) ───────────────│
  │========= encrypted application data ====│   (now HTTP flows, encrypted)
```

영리한 부분은 두 종류의 암호를 결합하는 것이다. **비대칭(Asymmetric)** 암호(certificate의 공개/개인 키 쌍)는 오직 잠깐 동안 *서버를 인증하고 공유 비밀에 안전하게 합의하는 데* 사용된다. 그 공유 비밀이 이후 데이터 대부분에 대해 빠른 **대칭(symmetric)** 암호화(AES 같은)의 키가 된다 — 비대칭 암호는 모든 바이트에 쓰기엔 너무 느리기 때문이다.

**Authentication**은 certificate 체인에 의존한다: 서버의 certificate는 **Certificate Authority (CA)**에 의해 서명되고, 당신의 OS/브라우저는 신뢰하는 CA 목록을 함께 배포한다. 체인이 유효하고 이름이 일치하면 신뢰가 수립되고; 아니면(만료, 자체 서명, 잘못된 host) 브라우저가 경고를 표시한다. 현대의 **TLS 1.3**은 이 모두를 단일 round trip으로(재개 시 0-RTT) 간소화하고 레거시의 안전하지 않은 cipher를 제거한다.

## 왜 중요한가

TLS는 사실상 모든 웹 트래픽을 뒷받침하므로, 그것을 이해하는 것은 backend, security, 또는 인프라 역할에서 기본 자격이다. 면접관은 그것으로 당신이 **하이브리드 암호 모델** — 신뢰와 공유 키를 수립하는 비대칭, 속도를 위한 대칭 — 을 파악하는지 시험하는데, 이는 보안 시스템 전반에 반복되는 패턴이다. 그것은 또한 대단히 실용적이다: 만료된 certificate, 신뢰되지 않는 체인, protocol/cipher 불일치는 흔한 프로덕션 사고이고, handshake와 certificate 검증이 어떻게 작동하는지 아는 것이 그것들을 빠르게 진단하게 해준다(예: `curl -v` 또는 `openssl s_client`로).

왜 중요한가

관련 질문