Proven by Intelligence

지금까지 세 편에 걸쳐 TLS 1.2의 구조적 문제, TLS 1.3이 택한 새로운 철학, 그리고 그 철학을 구현하는 ECDHE의 계산 원리까지 살펴봤다. 마지막 편에서는 전체 내용을 한눈에 정리합니다.

한 문장 요약

"TLS 1.2는 '키를 안전하게 전달하는' 기술이었고, TLS 1.3은 '키를 전달하지 않고 함께 만들어내는' 기술입니다."

이 한 문장의 철학 차이가 아래의 모든 구조적 차이를 만들어냅니다. 

Handshake 흐름 비교

가장 눈에 띄는 차이는 Round Trip 수입니다. TLS 1.2는 서버 인증서를 받은 뒤에야 Premaster Secret을 암호화해서 보낼 수 있는 순차적 구조인 반면, TLS 1.3은 ClientHello 단계에서 이미 KeyShare를 함께 실어 보내기 때문에 Handshake가 더 단순하고 빠릅니다. 

[그림 1] TLS 1.2와 TLS 1.3의 Handshake 왕복 횟수 비교

항목별 상세 비교

[표 1] TLS 1.2와 TLS 1.3의 항목별 비교



왜 TLS 1.3이 더 안전한가 ─ 세 가지로 압축하면

① 네트워크로 “훔칠 대상”이 없습니다. TLS 1.2는 암호화된 형태로나마 비밀값(Premaster Secret)이 네트워크를 오갔습니다. TLS 1.3은 공개해도 안전한 KeyShare 값만 오가고, 실제 Shared Secret은 각자의 계산 안에서만 존재합니다.

② 세션마다 키가 새로 만들어지고 즉시 사라집니다. TLS 1.2에서는 서버의 RSA 개인키 단 하나가 모든 과거 세션의 뿌리 역할을 했습니다. TLS 1.3에서는 ECDHE의 비밀 숫자(a, b)가 세션마다 새로 생성되고 세션 종료 후 폐기되므로, 장기 보관되는 인증서 개인키가 나중에 유출되어도 과거 세션은 영향을 받지 않습니다.

③ 인증서가 키 유출의 통로 역할에서 완전히 배제됐습니다. TLS 1.2에서 인증서 개인키는 “서버 신원 증명”과 “키 전달”이라는 두 가지 역할을 겸했기 때문에, 개인키 유출이 곧 키 유출로 직결되었습다. TLS 1.3에서 인증서는 오직 전자서명을 통한 신원 증명에만 쓰이고, 세션키 생성에는 관여하지 않습니다. 그 결과 인증서 개인키가 유출되어도 세션키를 복원할 수단 자체가 없습니다.

부가적인 개선: Cipher Suite 단순화

TLS 1.2는 TLS_RSA_WITH_AES_128_CBC_SHA처럼 키 교환·서명·암호화·MAC 방식을 자유롭게 조합할 수 있었습니다. 조합의 자유도가 높은 만큼, 설정을 잘못하면 RC4, 3DES, CBC 모드, SHA-1 같은 취약한 알고리즘이 섞여 들어갈 여지가 있었습니다.

TLS 1.3은 이런 취약 알고리즘들을 프로토콜 차원에서 아예 제거했습니다. 키 교환은 ECDHE로 통일했고, 암호화는 AES-GCM 같은 AEAD(인증付 암호화) 방식으로 표준화해 안전한 조합 외에는 애초에 선택할 수 없게 만들었습니다. “설정을 잘해야 안전한” 구조에서 “기본값이 곧 안전한” 구조로 바뀐 셈입니다.

마치며 ─ 패러다임의 전환

TLS 1.2에서 TLS 1.3으로의 진화는 단순한 버전업이 아니었다. 보안을 바라보는 관점 자체가 바뀌었습니다.

  ● TLS 1.2: “비밀을 어떻게 안전하게 전달할 것인가”

  ● TLS 1.3: “애초에 전달할 비밀을 만들지 말고, 각자 계산해서 같은 결론에 도달하자”

오늘날 HTTPS, 인터넷 뱅킹, 클라우드 서비스, VPN, 자동차 OTA, IoT 등 대부분의 최신 보안 통신이 TLS 1.3을 기본으로 채택하고 있는 이유가 여기에 있습니다.

단지 조금 더 빠르고 조금 더 단순해서가 아니라, 미래의 키 유출 상황까지 고려한 설계를 기본값으로 제공하기 때문입니다.