← 문제로

7. TLS/암호화 핸드셰이크, 대칭/비대칭, 인증서, DTLS

난이도 중
내 답안
모범답안

모범답안 — TLS/암호화 핸드셰이크, 대칭/비대칭, 인증서, DTLS

난이도: 중

핵심 답변

  • 대칭: 같은 키로 암·복호화. 빠름, 대용량에 적합. 단점은 키 공유 문제(어떻게 안전하게 같은 키를 나누나).
  • 비대칭: 공개키/개인키 쌍. 공개키로 암호화 → 개인키로만 복호. 키 공유·서명에 강하지만 느림.
  • TLS는 둘을 결합: 핸드셰이크에서 비대칭(혹은 DH)으로 세션 키를 안전히 합의하고, 이후 실제 데이터는 빠른 대칭 암호화로 보낸다.
  • TLS 핸드셰이크가 주는 셋: 기밀성(암호화) + 무결성(MAC/AEAD) + 인증(인증서로 서버가 진짜임 확인). TLS 1.3은 1-RTT(재접속 0-RTT)로 1.2(2-RTT)보다 빠르다.
  • UDP엔 DTLS: TLS는 TCP의 신뢰·순서를 전제하므로 손실·순서뒤바뀜이 있는 UDP엔 그대로 못 쓴다. DTLS가 이를 UDP용으로 적응시킨 것.

깊이 있는 설명 (왜, 메커니즘)

대칭 vs 비대칭, 왜 같이 쓰나

  • 대칭(AES 등): 연산이 가볍고 빠르다(하드웨어 가속 AES-NI). 그러나 통신 양쪽이 동일한 비밀 키를 가져야 하는데, 그 키를 네트워크로 안전하게 전달하는 게 난제.
  • 비대칭(RSA, ECDSA, (EC)DH): 공개키는 공개해도 되고, 개인키로만 풀거나 서명한다. 키 분배·신원 인증 문제를 해결하지만 수백~수천 배 느려 대용량 데이터엔 부적합.
  • 결합(하이브리드): 느린 비대칭/DH로 세션 키 합의만 하고, 합의된 세션 키로 빠른 대칭 암호화를 해서 실제 페이로드를 처리. 양쪽의 장점만 취한다.

TLS 핸드셰이크가 달성하는 것

  • 인증: 서버가 제출한 인증서를 CA 체인으로 검증 → "내가 접속한 게 진짜 그 서버"임을 확인.
  • 키 합의: 클라/서버가 (EC)DHE로 공유 비밀을 만들어 세션 키 도출. 도청자는 공개값만 봐선 키를 못 구한다.
  • 기밀성·무결성: 이후 데이터는 AEAD(예: AES-GCM, ChaCha20-Poly1305)로 암호화 + 인증 태그 → 도청·변조 방지.

TLS 1.2 vs 1.3 (RTT):

  • 1.2: 핸드셰이크에 2-RTT(ClientHello/ServerHello + 키교환 + Finished). 암호 스위트·옵션이 많아 협상 라운드가 길다.
  • 1.3: 1-RTT. ClientHello에 키 공유(key_share)를 미리 실어 보내 협상을 줄였고, 약한 알고리즘(정적 RSA 키교환, 비-PFS 등)을 제거해 단순·안전해졌다.
  • 0-RTT: 이전에 접속한 서버에 재접속 시 첫 패킷부터 애플리케이션 데이터를 보냄(PSK 기반). 빠르지만 재전송 공격(replay) 위험 — 0-RTT 데이터는 멱등(idempotent)하지 않으면 위험하므로 결제 같은 상태 변경엔 쓰면 안 된다.

인증서와 CA, MITM 차단

  • 문제: 공개키를 받았는데 "이게 진짜 서버 것인지" 어떻게 믿나? 공격자가 자기 공개키를 끼워 넣으면(MITM) 가짜 서버 노릇.
  • 해결: CA가 서버 공개키+도메인에 디지털 서명(인증서 발급). 클라이언트는 OS/브라우저에 내장된 신뢰 루트 CA 목록으로 인증서 체인을 검증:
    1. 인증서 서명이 신뢰 CA(또는 그 체인)로 거슬러 올라가나?
    2. 도메인(CN/SAN)이 접속 대상과 일치하나?
    3. 유효기간·폐기(CRL/OCSP) 확인.
  • MITM이 가짜 키를 끼워도 신뢰 CA의 서명을 위조할 수 없어 검증에 실패 → 차단. (단, 클라가 검증을 끄거나, 악성 CA가 신뢰 목록에 있으면 뚫린다.)

응용/실무 연결 (게임서버에서)

  • 로그인/결제/거래: TCP + TLS가 표준. 인증서 검증을 클라가 반드시 수행해야 하며, **인증서 피닝(pinning)**으로 신뢰 CA 범위를 좁혀 MITM·가짜 CA를 추가 차단하기도 한다.
  • UDP 실시간 트래픽 (질문 4): TLS는 TCP의 신뢰·순서를 전제로 레코드를 처리하므로, 손실/재정렬이 있는 UDP에선 복호화가 깨진다. 그래서:
    • DTLS(Datagram TLS): TLS를 UDP용으로 적응. 레코드마다 명시적 시퀀스 번호를 넣어 순서·재전송 문제를 자체 처리하고, 핸드셰이크에 재전송/타임아웃을 추가. WebRTC·게임에서 사용.
    • 자체 암호화 계층: RUDP 위에 AEAD(예: 패킷마다 nonce + AES-GCM/ChaCha20)를 직접 얹기도 한다. 핸드셰이크는 별도 TLS/DTLS 채널로 키만 합의하고, 데이터는 그 키로 대칭 암호화. (Steam Datagram, 자체 프로토콜 등.)
  • 성능: 핸드셰이크는 비싸므로 **세션 재개(session resumption / PSK)**로 재접속 비용을 줄이고, 대칭 암호화는 AES-NI/ChaCha20로 게임 틱 부하를 최소화한다.

흔한 오답·함정

  • "TLS는 비대칭으로 모든 데이터를 암호화한다" → 비대칭은 키 합의/인증에만, 실제 데이터는 대칭.
  • "인증서가 있으면 데이터가 암호화된다" → 인증서는 **인증(신원)**용. 암호화는 합의된 세션 키로 따로. 둘은 별개 역할(핸드셰이크가 둘 다 묶어줌).
  • "TLS 1.3은 항상 0-RTT" → 0-RTT는 재접속(PSK) 한정의 옵션이고 replay 위험이 있어 신중히 써야 한다. 기본은 1-RTT.
  • "TLS를 UDP에 그냥 켜면 된다" → 못 켠다. DTLS나 자체 계층이 필요.
  • "PFS 없어도 키만 길면 안전" → 서버 개인키가 나중에 유출되면 과거 캡처된 트래픽이 통째로 복호화될 수 있다(정적 RSA 키교환의 약점).

꼬리질문 대비

  • Q. 순방향 비밀성(PFS)이란? (질문 5) A. 세션마다 임시(ephemeral) 키로 키 교환((EC)DHE)을 해서, 서버 장기 개인키가 후에 유출돼도 과거 세션 키를 복원할 수 없게 한다. 각 세션 키가 독립적이라 한 세션이 깨져도 다른 세션은 안전. TLS 1.3은 PFS를 강제(ECDHE만 허용).
  • Q. AEAD가 뭐고 왜 중요? A. 암호화 + 인증을 한 번에(AES-GCM, ChaCha20-Poly1305). 무결성 태그로 변조를 감지. 별도 MAC 조합의 취약점(패딩 오라클 등)을 피한다.
  • Q. 인증서 피닝의 장단점? A. 특정 인증서/공개키만 신뢰해 MITM·악성 CA를 막지만, 인증서 갱신 시 클라 업데이트가 필요해 운영이 까다롭다.
  • Q. QUIC의 암호화는? A. QUIC은 TLS 1.3을 내장(전송 계층에 통합)해 핸드셰이크와 연결 수립을 합쳐 0/1-RTT로 끝낸다. UDP 기반이라 게임에도 잘 맞는다.
← 문제로 돌아가기