TLS 1.3 연결 수립 과정에서 서버 인증과 대칭키 합의는 어떻게 이루어지나요?

이렇게 답해 보세요 (핵심 답변)

TLS 1.3에서는 클라이언트와 서버가 ClientHello·ServerHello로 지원 암호 매개변수와 임시 키 공유(key_share) 정보를 교환해 디피-헬만(ECDHE) 방식으로 공유 비밀과 트래픽 대칭키를 유도합니다. 이때 서버는 인증서와 전자서명을 보내 자신이 해당 도메인의 주인임을 증명하고, 양쪽이 Finished 메시지로 핸드셰이크 무결성을 확인한 뒤 인증된 암호화(AEAD)로 HTTP 데이터를 보호합니다. 세션 재개와 0-RTT는 별도 흐름이며 재전송 공격 제약을 고려해야 합니다.

함께 설명하면 좋은 이유 (꼬리질문 대비)

1. 공개키 암호 연산은 인증과 키 합의 단계에서만 쓰이고, 실제 대용량 HTTP 데이터는 핸드셰이크에서 유도한 대칭 세션 키로 암호화해 성능과 순방향 비밀성(Forward Secrecy)을 함께 챙깁니다.
2. 이전에 접속했던 서버와 세션을 재개하는 0-RTT 모드를 쓰면 첫 왕복부터 데이터를 보낼 수 있지만, 공격자가 그 패킷을 그대로 재전송(Replay)할 위험이 있어 멱등하지 않은 요청에는 주의해야 합니다.

면접에서 자주 하는 실수

현대 TLS 1.3을 설명하면서 '클라이언트가 대칭키를 만들어 서버의 RSA 공개키로 암호화해 보낸다'거나 '모든 HTTP 본문을 공개키로 직접 암호화한다'고 설명하면 안 됩니다.