TLS는 인증, 키 합의, 키 파생, 레코드 보호를 서로 다른 도구에 맡긴다
TLS를 “공개키로 암호화한다”로 이해하면 실제 구조를 놓칩니다. 공개키 기술은 서버 신원과 키 합의를 보호하고, 합의 뒤 만들어진 트래픽 키가 대칭키 record를 보호합니다.
01
서버 인증
certificate + signature
브라우저는 인증서 체인과 서명을 검증해 상대가 진짜 서버인지 확인합니다.
02
임시 키 합의
ECDHE key exchange
양쪽은 비밀 값을 직접 보내지 않고 같은 shared secret에 도달합니다.
03
트래픽 키 파생
HKDF transcript binding
핸드셰이크 기록을 묶어 client/server write key를 따로 만듭니다.
04
레코드 보호
AEAD symmetric cipher
HTTP 요청과 응답은 빠른 대칭키 암호로 암호화되고 변조 검증됩니다.
기술
TLS에서 하는 일
보호하는 위험
오해하면 안 되는 점
서명
인증서와 핸드셰이크를 서버 개인키로 증명
중간자가 가짜 서버로 끼어드는 공격
데이터 본문을 직접 암호화하지 않음
키 교환
공유 비밀을 합의하고 전방 비밀성 제공
세션 키를 네트워크에 노출하는 문제
인증서가 곧 세션 키는 아님
MAC/AEAD
암호문 변조 여부를 record 단위로 확인
중간자의 비트 수정과 재조립
해시만으로는 비밀 소유를 증명하지 못함
대칭키
합의된 트래픽 키로 대량 데이터 보호
HTTP 본문, 쿠키, 응답 내용 노출
키 합의 없이 미리 공유하면 운영이 어렵다
certificate
신원 검증 실패는 연결 전에 막는다
호스트명, 체인, 만료일, 신뢰 루트가 맞아야 핸드셰이크가 계속됩니다.
downgrade risk
약한 알고리즘 협상은 보안 수준을 낮춘다
TLS 버전과 cipher suite 정책은 서버 설정에서 명시적으로 관리합니다.
record
실제 보호 단위는 TLS record다
핸드셰이크가 끝난 뒤 요청과 응답은 record 단위로 암호화됩니다.