SSL/TLS 핸드셰이크와 레코드 프로토콜

핵심 정리

SSL/TLS는 웹 통신을 암호화하여 안전한 웹 서핑을 가능하게 하는 보안 프로토콜이다. SSL은 서버 인증, 클라이언트 인증, 암호화 세션 기능을 제공한다. TLS는 SSL을 기반으로 발전한 인터넷 표준이다. 그래서 두 이름은 같은 계열의 보안 프로토콜로 묶어 이해하면 된다.

SSL/TLS는 여러 하위 프로토콜로 짜여 있고, 그중 핸드셰이크 프로토콜과 레코드 프로토콜이 골격을 이룬다. SSL/TLS 핸드셰이크 프로토콜은 서버와 클라이언트를 인증하고 암호 및 MAC 알고리즘과 암호키를 협상한다. SSL/TLS의 Record 프로토콜은 대칭키 암호화와 메시지 무결성 검사를 담당한다. 응용 데이터를 실제로 보내는 일은 TLS 핸드셰이크가 아니라 레코드 프로토콜의 역할이다.

이 구조가 주는 효과는 기밀성, 무결성, 인증으로 요약된다. SSL은 인증, 기밀성, 무결성 서비스를 제공한다. 핸드셰이크의 목적에는 세션키 생성 및 교환이 포함된다. 그 결과 SSL 암호화 기능을 사용하면 주고받는 데이터가 인터넷상에서 도청되는 위험을 줄일 수 있다.

다만 SSL/TLS가 보호하는 범위는 상위 계층에 한정된다. HTTPS는 HTTP 내용을 암호화하지만 포트 번호는 TCP/IP 구조상 암호화되지 않고 노출된다. 같은 이유로 IP 헤더의 TTL 필드도 TLS가 보호하는 HTTP 계층 정보가 아니어서 암호화되지 않는다.

자세히

핸드셰이크의 협상과 인증

핸드셰이크 과정은 정해진 순서에 따라 메시지를 주고받으며 진행된다. 전체 흐름은 ClientHello로 보안 능력을 수립한 뒤 서버 응답과 인증서 요청, 클라이언트 인증서와 키 교환, 암호 조합 변경 순으로 진행된다. SSL 핸드셰이크에서는 서버 Certificate, 클라이언트 Client_Key_Exchange, Change_Cipher_Spec 순으로 메시지가 교환된다.

핸드셰이크는 세션의 보안 특성과 암호 알고리즘을 협상하는 데 쓰인다. 협상과 인증은 핸드셰이크의 몫이지만, 세션을 살려 두는 기능은 그 몫이 아니다. 세션을 활성 상태로 유지하는 것은 TLS 핸드셰이크의 목적이 아니다. TLS의 Heartbeat 프로토콜은 매번 재협상하지 않고 연결을 테스트하며 세션을 활성 상태로 유지하는 데 쓰인다.

익명 DH 키 교환은 인증서 없이 DH 파라미터를 교환하는 SSL/TLS 키 교환 기법이다. 인증서를 쓰지 않는다는 점에서 인증서 교환이 중심인 방식과 구분된다.

ClientHello의 구성

ClientHello 메시지에는 클라이언트 난수가 포함되며 이후 대칭키 생성에 쓰인다. ClientHello 메시지에는 클라이언트가 지원하는 암호 스위트 목록이 담겨 서버에 제안된다.

ClientHello에는 이전 세션을 재개할 때 쓰는 세션 ID가 포함된다. 반면 인증서는 ClientHello가 아니라 서버가 보내는 응답 메시지에 담긴다. 요약하면 ClientHello는 클라이언트가 제안하는 메시지이고, 서버 쪽 정보는 응답에서 나온다는 구분으로 정리하면 된다.

HTTPS와 보호 범위

SSL을 지원하는 웹사이트의 URL은 https://로 시작한다. HTTPS에서는 HTTP 전체가 TLS로 보호되어 요청 문서의 URL이 암호화된다. HTTPS를 구성하는 프로토콜은 TCP와 SSL(TLS)이다.

TCP 헤더의 플래그 비트는 전송 계층 정보로 HTTPS가 암호화하지 않는다. 이를 정리하면 TLS가 감싸는 범위는 HTTP 계층 이상이고, 그 아래 TCP·IP 헤더는 평문으로 남는다.

레코드 프로토콜의 처리 단계

레코드 프로토콜은 상위 계층 메시지를 전달하며 메시지를 단편화하거나 선택적으로 압축한다. 단편화는 응용 계층 데이터를 고정 길이 조각으로 나누는 처리 단계다. 압축은 단편화된 데이터에 선택적으로 적용되는 처리 단계다. MAC은 압축 후 데이터에 추가되어 무결성을 보장하는 처리 단계다.

이 단계들을 거쳐 SSL 레코드 프로토콜은 단편화, 압축, MAC 첨부, 암호화를 수행하여 기밀성과 메시지 무결성을 제공한다. 여기서 압축은 선택 처리 단계이므로 항상 거치는 단계와 구분해야 한다.

취약점

하트블리드는 TLS 하트비트 확장을 구현한 OpenSSL에서 요청 메시지의 실제 길이를 확인하지 않아 생긴 취약점이다. Heartbleed는 OpenSSL의 메모리 노출 취약점이다.