네트워크

TLS의 인증·기밀성·무결성 경계

TLS는 통신 상대의 신원을 확인하고 전송 중인 데이터를 암호화·보호하지만, 서버 내부의 애플리케이션 취약점까지 막아 주지는 않습니다.

이럴 때 필요해요

HTTPS가 정확히 어디까지를 지켜 주는지 설명하고, 인증서 검증 누락이나 서버 권한 검사(인가) 허점을 구분하기 위해 필요합니다.

어떻게 동작하나요?

공용 와이파이에서 로그인할 때 중간의 공유기가 내 비밀번호를 훔쳐보거나 응답 화면에 악성 스크립트를 몰래 끼워 넣지 못하게 막아 주는 것이 바로 HTTPS의 TLS(Transport Layer Security)입니다. 최신 표준인 TLS 1.3에서는 클라이언트와 서버가 인사를 나누며(ClientHello·ServerHello) 임시 공개키 정보를 교환해 디피-헬만(ECDHE) 방식으로 공유 비밀과 대칭 트래픽 키를 만들어 내고, 서버는 인증서와 전자서명을 제시해 자신이 진짜 해당 도메인 서버임을 증명합니다.

이 핸드셰이크 과정에서 공개키 암호는 '상대방 신원 인증'과 '대칭키 합의'에만 쓰이고, 합의가 끝난 뒤 실제 HTTP 요청과 응답 본문은 빠르고 안전한 대칭키 인증 암호화(AEAD)로 보호됩니다. 즉 모든 HTTP 본문을 서버 인증서의 공개키로 직접 암호화해 보내는 것이 아니며, 매 연결마다 임시 키를 새로 만들기 때문에 나중에 서버의 장기 비밀키가 유출되더라도 과거 통신 내용을 복호화할 수 없는 순방향 비밀성(Forward Secrecy)을 얻습니다.

하지만 TLS가 지켜 주는 경계는 어디까지나 '클라이언트와 서버 사이의 네트워크 전송 구간'입니다. 만약 공격자가 만든 피싱 사이트가 정상 인증서를 발급받아 HTTPS를 띄웠거나, 우리 서버 코드에 XSS 취약점이 있거나, 로그인한 사용자 A가 URL의 ID만 바꿔 사용자 B의 주문 내역을 조회할 수 있는 인가(Authorization) 버그가 있다면 이는 TLS가 막을 수 없는 애플리케이션 계층의 문제입니다.

코드 예제

동작을 설명하는 읽기 전용 예제입니다.

example.txt

클라이언트 → ClientHello + key_share
서버 → ServerHello + 인증 정보 + Finished
클라이언트 → 검증 + Finished
이후 → 합의된 키로 보호된 HTTP 데이터

text · 읽기 전용4줄

TLS 1.3의 기본 서버 인증 및 키 합의 흐름을 요약한 도식입니다. 핸드셰이크 무결성(Finished)을 확인한 뒤에는 합의된 대칭 트래픽 키로 HTTP 데이터를 보호합니다.

자주 헷갈리는 포인트

개발 편의를 위해 인증서 신뢰 체인이나 도메인 이름 검증 옵션을 꺼 버리면 중간자 공격(MITM)에 그대로 노출됩니다.
HTTPS로 전송 구간을 암호화했다는 것과 서버가 사용자의 요청 권한(인가)을 올바르게 검증했다는 것은 전혀 별개의 문제입니다.

내 말로 설명해 보기

HTTPS 연결이 정상적으로 맺어진 상태인데도 URL의 숫자만 바꿔서 다른 사용자의 비공개 프로필을 볼 수 있다면 이는 어느 계층의 무엇이 빠진 문제인가요?

공식 참고 자료

RFC 8446: TLS 1.3 (영문) ↗

← 네트워크

TLS의 인증·기밀성·무결성 경계

이럴 때 필요해요

어떻게 동작하나요?

코드 예제

자주 헷갈리는 포인트

내 말로 설명해 보기

함께 읽으면 좋은 개념

관련 면접 질문 2개

HTTPS는 일반 HTTP 통신에 구체적으로 어떤 보안 속성을 추가해 주나요?

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

공식 참고 자료