1. SSL과 TLS의 차이점
관례상 여전히 SSL이라는 용어가 혼용되지만, SSL 2.0과 3.0은 암호학적 취약점으로 인해 수십 년 전 공식 폐기되었습니다.
오늘날의 모든 보안 웹 통신은 TLS (Transport Layer Security 1.3, RFC 8446) 표준을 기반으로 하며, HTTP 헤더와 페이로드 전체를 안전하게 암호화합니다.
2. TLS 1.3 핸드셰이크 (1-RTT 고속 연결)
TLS 1.3은 ECDHE 키 교환을 통해 기존 2회의 통신 왕복을 단 1회(1-RTT)로 대폭 단축했습니다:
1. Client Hello: 클라이언트가 지원 암호 스위트와 ECDHE 공개키 파라미터를 선제 전송.
2. Server Hello: 서버가 암호 스위트를 확정하고 서버 공개키, X.509 인증서 및 전자서명 회신.
3. 대칭 세션키 도출: 양측이 독립적으로 동일한 대칭 세션키를 계산.
4. 암호화 통신 개시: 즉각적인 암호화 HTTP 요청 및 응답 시작.
3. X.509 인증서와 CA 신뢰 체인
브라우저는 계층적 전자 서명 검증을 거쳐 서버의 신원을 확인합니다:
- 루트 인증기관 (Root CA): OS 및 브라우저의 트러스트 스토어에 사전 내장된 자체 서명 인증서.
- 중간 인증기관 (Intermediate CA): 루트 CA 비밀키 노출을 방지하기 위해 일상적 인증서 발급을 위임받은 기관.
- 리프 / 서버 인증서 (Leaf Certificate): 도메인명과 서버의 공개키를 공식 결합하는 최종 엔티티 인증서.
4. 인증서 투명성 (Certificate Transparency) 로그
인증기관의 부정 발급을 감시하기 위해 RFC 6962 표준은 모든 공인 인증서를 공개 머클 트리(CT 로그)에 등록하도록 강제합니다.
브라우저는 인증서 내에 유효한 SCT(Signed Certificate Timestamp) 증명이 없는 경우 접속을 즉시 차단합니다.
5. 프로덕션 TLS 보안 강화 체크리스트
1. TLS 1.3 / 1.2 버전만 허용: 구형 TLS 1.0, 1.1 및 취약한 암호 알고리즘을 완벽히 비활성화.
2. HSTS 프리로드 적용:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload 헤더 설정.3. ACME 프로토콜 기반 자동 갱신: Let’s Encrypt 등을 통해 60일 주기로 인증서 발급과 교체를 자동화.