인터넷에서 개인정보를 주고 받을 때, 우리의 네트워크 트래픽은 제3자에 의해 가로채이거나 변조될 위험이 있다. 이를 막기 위해 등장한 것이 SSL(Secure Sockets Layer)과 그 후신인 TLS(Transport Layer Security) 프로토콜이다. 오늘날 웹브라우저, API, 모바일 앱 등 대부분의 애플케이션이 HTTPS를 통해 TLS 기반 암호화 통신을 사용한다.
필자는 이번 글에서 SSL에서 출발해 TLS 1.3에 이르기까지 프로토콜 구조, 동작원리, 주요 기능을 단계별로 살펴보겠다.
SSL과 TSL, 차이
SSL은 넷스케이프(Netscape)가 1990년대 중반에 개발한 프로토콜로 1.0은 공개되지 않았고, 2.0, 3.0이 사용되었다.
TLS는 IETF가 SSL 3.0을 기반으로 표준화한 프로토콜로 1.0, 1.1, 1.2, 1.3 버전이 있다.
SSL 3.0 이후 새 버전은 모두 TLS로 명명되며, 호환성과 보안성 강화를 위해 계속 개선중이다.
프로토콜 구조 개관
TLS는 크게 두 가지 레이어로 구성된다.
1. 헨드셰이크 레이어(Handshake Layer)
- 클라이언트와 서버가 서로를 인증하고, 암호화 매개변수를 협상하는 단계
- 주로 공개키와 암호화 디지털 인중서를 사용
2. 레코드 레이어(Record Layer)
- 실제 애플리케이션 데이터를 암호화, 무결성 검증하여 안전하게 전송
- 대칭키 암호화(AES) + MAC/HMAC(SHA-256) 또는 AEAD(AES-GCM)를 사용
헨드셰이크가 끝나면 고성는 대칭키 암호화 통신이 시작되고, 레코드 레이어가 이를 관리한다.
TLS 핸드셰이크 과정 (TLS 1.2기준)
1. ClientHello
- 지원 가능한 TLS 버전, 암호 스위트(cipher suite), 랜덤 난수 전송
2. ServerHello
- 선택된 TLS 버전, 암호 스위트, 서버 랜덤 난수 전송
3. 서버 인증서 교환 (Cerrificate)
- 서버 공개키 인증서 전송 -> 클라이언트는 CA 서명, 유효기간, 도메인 일치 여부 검증
4. 키 교환(ServerKeyExchange & ClientKeyExchange)
- RSA: 클라이언트가 서버 공개키로 사전 키(Per-master secret) 암호화
- DHE/ECDHE: 양측이 디피-헬만 기반의 키 교환수행
5. 인증 및 Finished 매시지 교환
- changeCipherSpec: 이후 전송되는 메시지는 대칭키로 암호화
- Finished: 해시 기반으로 검증값 전송 -> 양측이 동일한 세션 키 사용 여부 확인
이 과정을 통해 Master Secre이 생성되고, 이를 기반으로 실제 통신용 대칭키가 파생된다.
TLS 1.3의 주요 개선 사항
TLS 1.3에서는 보안 강화와 지연(latency) 최소화를 위해 다음과 같은 부분이 개선되었다.
핸드셰이크 라운드 수 단축
- RTT(Round-Trip Time)만에 키 교환 완료
- 재접속(0-RTT)기능 지원으로 이전 세션 키를 재사용해 지연 추가 없이 데이터 전송 가능
취약한 암호 스위트 제거
- RSA 키 교환, SHA-1 기반 MAC등 오래된 알고리즘 제거
- AEAD 암호 모드(AES-GCM, ChaCha20-Poly1305)만 혀용
메시지 암호화 범위 확대
- 핸드셰이크 일부 메시지 (ServerHello)도 암호화 가능
이러한 기능 개선으로 이전 버전 대비 성능과 보안성이 대폭 향상되었다.
SRIHS infoSec 119th