[HTTPS] SSL/TLS Handshake란?

NetWork 2024. 4. 4. 02:34

들어가며

인터넷 보안은 개인, 기업, 나아가 국가적 차원에서 정보 보호와 사이버 범죄 예방에 필수적인 요소입니다. 관련 법안도 존재합니다. 개인정보를 취급하는 모든 웹사이트는 2016년 3월 22일 이후로 ⌜정보통신망법⌟ 제 28조 1항 제4호에 따라 의무적으로 HTTPS 서버를 구축해야 하며, 위반 시 3천만원 이하의 과태료가 부과됩니다.

HTTPS 서버를 구축한다는 것은 SSL/TLS 인증서를 사용한다는 의미입니다. SSL/TLS는 HTTPS 통신의 핵심으로, 웹 서버와 클라이언트 간의 안전한 데이터 전송을 보장하기 위해 개발된 보안 프로토콜입니다. 또한 웹 사이트의 신뢰성을 유지하기 위한 방법이기도 합니다.

참고로 SSL이면 SSL이고 TLS면 TLS지, SSL/TLS는 도대체 무엇인지 궁금하신 분도 계실텐데요, SSL은 1990년대 초 Netscape사에 의해 개발되었고, SSL 3.0을 기반으로한 TLS 1.0이 IETF(Internet Engineering Task Force)에 의해 개발되어 현재 업계 표준은 보안이 강화된 TLS입니다만, 여전히 SSL이라는 용어가 사용되고 있으며, 기술적으로는 TLS가 정확한 표현이지만 SSL/TLS라는 용어를 통해 과거와 현재의 프로토콜을 모두 아울러 표현하기도 합니다. 휴! 😌 저는 역사적인 의미가 내포된 'SSL/TLS'라는 용어로 설명하겠습니다.

이 글에서는 HTTP/2 이하 버전을 기준으로 SSL/TLS Handshake의 과정을 설명합니다. HTTP/2 이하 버전을 기준으로 삼은 이유는 HTTP/3는 UDP 기반의 QUIC 프로토콜 위에서 동작하므로 TCP를 기반으로 하는 HTTP/2 이하 버전과 연결 구축 메커니즘이 상이하기 때문입니다.

HTTPS 통신을 하기 위해서는 figure 0-1과 같이 TCP 3-way Handshake 이후 SSL/TLS Handshake를 거쳐야 합니다. SSL/TLS Handshake의 목적은 1️⃣ 서버 신원 확인, 2️⃣ Cipher Suite 결정, 3️⃣ 대칭키 교환입니다. 간단히 말해 '암호화 통신을 위한 준비 과정'이라고 할 수 있습니다.

대칭 키 교환 프로세스를 이해하기 위해서는 암호화 메커니즘의 기본 개념과 서버의 인증서 발급 과정을 알고 있어야 합니다. 따라서 본문에서는 '암호화' → '서버 인증서 발급' → 'SSL/TLS Handshake' 순서로 설명합니다. 참고로 Cipher Suite는 '암호화를 위한 알고리즘 정보의 모음' 정도로 생각해주시면 될 것 같습니다. 상세한 설명은 차차 나옵니다! 🤓

figure 0-1. 클라이언트-서버 간 주고받는 패킷으로 살펴보는 HTTPS 통신 흐름 (TCP 3-way Handshake, SSL/TLS Handshake)

👀 figure 0-2를 주의깊게 봐주세요

figure 0-2는 HTTPS 통신 과정 전체를 그린 그림으로, TCP 3-way Handshake 과정은 생략되어있습니다. 아래 목차와 본문의 숫자 원형기호 ①-⑨는 figure 0-2를 따릅니다. 따라서 본문을 보시다가 전체적인 흐름을 확인하고 싶을 때마다 figure 0-2로 올라오시면 됩니다.

①-③번은 서버가 CA(Certificate Authority)에게 인증서를 발급받는 과정입니다. CA는 디지털 인증서를 발행하고 관리하는 인증 기관입니다. CA가 발급한 인증서는 웹 사이트의 신원을 인증하는 데 사용되며, HTTPS와 같은 보안 연결을 가능하게 합니다. 이후 ④-⑧번과 같이 SSL/TLS Handshake를 거쳐 ⑨번과 같이 암호화된 데이터를 주고받습니다.

figure 0-2. HTTPS 통신 과정 상세(TCP 3-way Handshake 과정 생략)

서론이 참 길었네요. 목차는 아래와 같습니다.

1. SSL/TLS Handshake를 알아보기 전에..

1-1. 암호화 🔒

암호화에는 크게 대칭키 암호화(Symmetric Key Algorithm), 비대칭키 암호화(Asymmetric Key Algorithm) 방식이 있습니다. 대칭키 방식은 암호화와 복호화에 동일한 키를 사용하는 방식이고, 비대칭키 암호화는 공개키(Public Key)-개인키(Private Key)로 이루어진 한 쌍의 키로 암호화, 복호화를 하는 방식입니다. 공개키로 암호화하면 개인키로 복호화하고, 개인키로 암호화를 하면 공개키로 복호화할 수 있습니다. 개인키는 공개되면 안 되므로 비밀키(Secret Key)라고도 합니다.

	대칭키 암호화(Symmetric Key Algorithm)	비대칭키 암호화(Asymmetric Key Algorithm)
사용되는 키	대칭키	비대칭키 (공개키-개인키 한 쌍) * 개인키는 비밀키라고도 함
암호화·복호화 방식	대칭키로 암호화, 동일한 대칭키로 복호화	공개키로 암호화하면 개인키로 복호화, 개인키로 암호화하면 공개키로 복호화

SSL/TLS Handshake에서는 Cipher Suite를 통해 HTTPS 통신과정 전반에 사용될 암호화 알고리즘을 클라이언트와 서버간에 협상합니다. Cipher Suite의 구성은 figure 1-1과 같이 '프로토콜', '인증서 검증 알고리즘', '키 교환 알고리즘', '블록 암호화 알고리즘', '블록 암호 운용 방식', '메세지 인증 코드(Hash 알고리즘)'로 이루어져 있습니다. 암호화에 대해서 더 자세히 이야기하면 주제에서 너무 멀어질 것 같으니 이하 암호화 알고리즘의 종류, 암호화 알고리즘의 수학적 원리 등 자세한 이야기는 [Cipher Suite] 안전한 데이터 전송을 위한 SSL/TLS 기술 집약체, [비대칭키 알고리즘] DH, RSA로 살펴보는 수학적 자물쇠 원리와 그 취약점 보완에서 다루겠습니다. 여기서는 대칭키 암호화와 비대칭키 암호화의 개념, 그리고 Cipher Suite의 구성만 기억해주시면 됩니다!

1-2. 서버 인증서 발급(feat. PKI) 📑

※ 서버 인증서 발급은 설명의 편의를 위해 ①-③ 순번을 붙였을 뿐, SSL/TLS Handshake를 하기 전마다 수행하는 과정이 아닙니다. 인증서 발급은 SSL/TLS Handshake 이전에 이미 완료되어 있어야 하는 전제조건입니다.

서버의 인증서 발급 과정에 대해서 설명하기 전에 PKI에 대해서 짚고 넘어가겠습니다. PKI는 Public Key Infrastructure의 약자로, 디지털 인증서를 사용하여 클라이언트, 서버의 신원을 검증하고 안전한 전자 거래를 가능하게 하는 시스템입니다. 이 시스템은 디지털 인증서 발급, 관리, 저장, 분배 및 폐기의 기능을 포함합니다. 다음은 PKI의 핵심 구성 요소입니다.

∙ CA(Certificate Authority)
: 사용자의 신원 확인 후 디지털 인증서를 발급하고 관리하는 기관
∙ RA(Registration Authority)
: 신원 확인과 인증서 발급 요청에 대한 승인 담당
∙ 인증서 저장소
: 발급된 인증서와 폐기된 인증서 목록(CRL - Certificate Revocation List) 보관
∙ 비대칭 키 쌍
: 공개키는 인증서에 포함되어 공개적으로 배포되고, 개인키는 비밀리에 안전하게 보관
∙ 인증서 관리 체계
: 인증서의 생명 주기를 관리하는 프로세스 및 정책. 인증서의 발급, 갱신, 폐기 등을 포함
∙ PKI 클라이언트 소프트웨어
: 사용자의 디지털 인증서와 개인키를 활용해 데이터 암호화, 디지털 서명, 인증서 검증 등 작업 수행

그럼 서버의 인증서 발급 과정을 살펴보시죠!

① 서버의 비대칭키 생성 및 CSR 제출

서버는 공개키-개인키로 이루어진 비대칭키 1쌍을 생성한 후 CA에게 해당 공개키와 서버 식별 정보가 포함된 인증서 서명 요청서(CSR, Certificate Signing Request)를 제출합니다. 서버는 개인키를 안전하게 보관해야 합니다.

② CA의 디지털 서명 및 인증서 생성

CSR을 받은 CA는 도메인의 소유권 검증(DV, Domain Validation) 또는 조직의 실체 검증(OV, Organization Validation) 또는 엄격한 확장 검증(EV, Extended Validation) 방식으로 서버를 검증합니다. DV, OV, EV 순서대로 보안 수준이 높아지며, 이후 인증서의 발급 유형을 나타내게 됩니다.

서버 검증이 완료되면 CA는 figure 1-3과 같이 CSR에 대한 Hash값을 계산해서 Finger Print(지문)를 만들고, Finger Print를 CA 자신의 개인키로 암호화해서 Signature(디지털 서명)를 생성합니다. 이 Signature는 인증서의 무결성과 인증서 발급자의 신뢰성을 보장하는 역할을 합니다. CA는 'CA 신원 정보', '인증서 유효 기간', '서버 정보', '서버 공개키', '암호화 알고리즘', 'Finger Print', 'Signature' 등이 내제된 인증서를 생성합니다. 국제적으로 통용되는 SSL/TLS 인증서의 규격은 보통 X.509 표준을 따릅니다.

③ CA가 서버에게 인증서 발급 인증서 체인: 공개키 변조 방지

CA는 인증서를 발급해서 서버에게 전달합니다. 사실은 인증서 하나가 아니라 인증서 체인을 전달합니다. 예를 들어, figure 1-4에 나타난 바와 같이 네이버 서버가 가지고 있는 인증서 체인은 네이버가 DigiCert CA1에게 받은 'Leaf 인증서', DigiCert CA1이 DigiCert Global Root CA에게 받은 'Intermediate 인증서', DigiCert Global Root CA 가 Self-Sign한 'Root 인증서'로 구성되어 있습니다.

여기서 Intermediate 인증서는 1개 이지만 경우에 따라 n개일 수 있습니다. 이렇게 인증서 체인은 연쇄적으로 상위 인증 기관에게 인증을 받은 구조로, CA나 서버의 공개키가 해커에 의해 변조될 위험을 방지하기 위해서 사용됩니다. 인증서 체인 내의 모든 인증서가 유효하다면, 이를 근거로 서버를 신뢰할 수 있을 것입니다. 이것이 인증서 체인의 의의입니다.

figure 1-4. 네이버 서버의 인증서 체인(Certificate Chain) 구성

인증서 생성 과정을 일반화해보면 figure 1-5와 같이 서버는 자신의 상위 CA에게 CSR을 제출하여 해당 CA가 자신의 개인키로 서명한 인증서를 받고, 서버의 인증서를 발급한 CA는 자신의 상위 CA에게 CSR을 제출하여 인증서를 받고, 그 상위 CA는 또 자신의 상위 CA에게 CSR을 제출하여 인증서를 받습니다. 이 과정이 n번 반복되며, 인증서 체인의 꼭대기에는 Root 인증서가 있습니다. Root 인증서는 Root CA가 자신의 개인키로 Self-Sign하여 만든 인증서입니다. 이렇게 서버 인증서인 'End-Entity 인증서(Leaf 인증서)', 'Intermediate 인증서' n개, 'Root 인증서'로 구성된 인증서 체인이 서버에게 전달됩니다.

2. SSL/TLS Handshake 🤝🏻

Client Hello(Client) → Server Hello, Certificate(Server) → (Server Key Exchange(Server)) → Client Key Exchange(Client) → Key Generation(Client, Server) → Cipher Spec Exchange(Client, Server) → Finished(Client, Server)

※ figure 0-2에서 키교환 알고리즘에 대한 설명은 RSA가 기준이기 때문에 아래에서 ( )를 통해 DH 계열의 방식을 추가 설명합니다.

④ 브라우저가 웹 서버에게 접속 요청

SSL/TLS Handshake의 시작으로 브라우저가 서버에게 접속 요청을 하면서 [Client Hello] 패킷에 '사용 가능한 Cipher Suites 목록', 'TLS 버전', 'Random Byte', 'Session ID', 'SNI(Server Name Indication)' 등을 전달합니다. Cipher Suite는 1-1. 암호화에서 설명한 바와 같이 '암호화를 위한 알고리즘 정보의 모음'입니다. 클라이언트는 사용 가능한 Cipher Suite들의 리스트를 서버에게 보내 그 중 하나를 서버가 선택하게 합니다. 암호화와 관련된 또 다른 정보에는 대칭키 생성에 사용될 Random Byte가 있습니다.

Session ID는 SSL/TLS Handshake의 식별값입니다. 최초의 Client Hello의 Session ID값은 0이며, 이후 Server Hello를 통해 서버가 할당한 Session ID를 보내주면 클라이언트는 로컬에 해당 ID를 저장해두고 이후 Handshake에서 사용합니다. 최초의 Handshake 이후에는 Session ID의 유효성이 확인되면 네트워킹의 효율성 향상을 위해 서버의 인증서 확인, Cipher Suites 결정, 대칭키 교환 작업을 생략합니다.

SNI는 IPv4 주소의 고갈 문제로 가상 호스팅(Virtual Hosting)을 사용한 이래, 하나의 IP 주소에 여러 도메인 이름이 매핑되어 있는 상황이므로 클라이언트가 접속하려는 구체적인 도메인 이름을 서버에 명시적으로 알려줌으로써 해당 서버의 정확한 인증서를 제공받기 위한 값입니다.

⑤ 서버의 Cipher Suite 결정, 인증서 전달, (키 파라미터 전달 - DH)

서버는 [Server Hello] 패킷에 선택한 'Chiper Suite', 'TLS 버전', 'Random Byte', 'Session ID' 등을 담아 보내고, [Certificate] 패킷을 통해 CA에게 발급받은 인증서(인증서 체인)를 전달합니다. ( 키 교환 알고리즘이 DH, DHE, ECDHE와 같이 DH 계열이면 서버는 [Server Key Exchange] 패킷을 통해 '키 파라미터'를 클라이언트에게 전달합니다. 지금은 키 파라미터에 대해서 '대칭키 생성 재료' 정도로 생각하시면 될 것 같습니다. 키 교환 알고리즘이 RSA이면 이미 인증서에 대칭키 암호화에 사용될 서버 공개키가 포함되어 있기 때문에 Server Key Exchange는 생략됩니다. )

⑥ 브라우저의 인증서 검증 '인증서의 Signature를 복호화한 값'과 'CSR을 Hash한 값'에 대한 동등성 비교

클라이언트는 서버가 보낸 인증서를 검증합니다. 더 정확히는 figure 2-2와 같이 서버 인증서인 'Leaf 인증서', 'Intermediate 인증서', 'Root 인증서'로 구성된 인증서 체인 전체를 검증합니다. 일단, 인증서 하나를 검증하는 방식은 figure 2-1과 같이 인증서를 발급한 CA의 공개키로 '인증서의 Signature를 복호화한 값'과 인증서의 'CSR을 해시한 값'의 일치 여부를 판단하는 것입니다. 애초에 인증서 생성 시 CSR을 해시한 Finger Print를 암호화한 것이 Signature이기 때문입니다. 인증서 검증 알고리즘은 Cipher Suite에 따라 정해졌으며, 보통 RSA를 사용합니다. CSR 해시를 위한 알고리즘도 Cipher Suite에 메세지 인증 코드로 지정되어 있습니다.

인증서 체인을 검증하는 방법을 figure 2-2를 통해 조금 더 자세히 살펴보겠습니다. Leaf(Owner)인증서가 가지고 있는 Signature는 첫 번째 Intermediate CA(Issuer)에 의해 생성된 것으로, 해당 Signature를 복호화하기 위해서는 Issuer의 공개키가 필요합니다. Issuer의 공개키는 Owner 인증서에 있는 Issuer의 DN(Distinguised Name)을 참조하여 가져옵니다. DN은 'Distinguised Name'이라는 명칭에서 알 수 있듯이 CA에 대한 고유 식별값입니다. figure 0-2에서 인증서에 붙어있는 연두색, 노란색, 갈색 표식과 같은 역할을 하는 것이죠. Owner에 있는 Signature를 Issuer의 공개키로 복호화한 값과 Owner의 CSR을 해시한 값을 비교해서 같으면 첫 번째 검증이 완료됩니다.

n개의 Intermediate 인증서, 마지막 Root 인증서에 대한 검증 과정도 동일하게 반복됩니다. Root CA가 Self-Sign한 Root 인증서는 Root CA의 공개키에 대한 신뢰를 바탕으로 하므로, Root CA가 브라우저나 운영체제에 내장된 '신뢰 가능한 인증서 목록'에 존재해야 합니다. 서버의 인증서로 시작해서 Root CA의 인증서로 끝나는 인증서 체인에 존재하는 모든 인증서에 대해서 서명과 유효성이 검증된다면 서버의 인증서도 신뢰할 수 있다고 판단합니다. 이렇게 인증서 체인 전체를 검증함으로써 서버가 보낸 인증서나 Root CA의 공개키를 신뢰할 수 있습니다.

인증서 체인은 CA와 서버를 신뢰하기 위한 장치인데 이 외에도 '서버 인증서 Pinning', 가장 엄격한 수준의 보안인 'EV 인증서 추가 요구', '브라우저의 보안 패치 및 업데이트' 등을 통해 CA와 서버에 대한 신뢰성을 향상시킬 수 있습니다. 자세한 설명은 생략하겠습니다.

figure 2-2. 인증서 체인(Certificate Chain) 검증 과정

( 브라우저의 대칭키(Master Secret) 생성 - DH

키 교환 알고리즘이 DH, DHE, ECDHE와 같이 DH 계열이면 클라이언트는 서버 인증서 검증이 성공적으로 끝난 후 자신의 개인키와 [Server Key Exchange]를 통해 받은 키 파라미터를 조합하여 대칭키(Master Secret)를 계산합니다. )

⑦ 브라우저가 서버에게 대칭키(Pre-Master Secret) 전달 (키 파라미터 전달 - DH)

키 교환 알고리즘이 RSA이면 클라이언트가 난수 생성 알고리즘을 통해 무작위로 대칭키(Pre-Master Secret)를 생성합니다. 생성한 대칭키는 figure 2-3처럼 서버의 공개키로 암호화해서 [Client Key Exchange] 패킷을 통해 서버에게 전달합니다.

( 키 교환 알고리즘이 DH 계열이면 앞서 협상된 알고리즘으로 계산한 키 파라미터를 [Client Key Exchange] 패킷을 통해 서버에게 전달합니다. 이 때 DH는 이산대수의 복잡성을 기반으로 설계되었기 때문에 따로 암호화가 필요 없지만 중간자 공격(Man In the Middle Attack)을 방지하기 위해 RSA와 같이 서버의 공개키로 키 파라미터를 암호화하는 비대칭 암호화 기술을 사용하기도 합니다. )

⑧ 서버의 대칭키(Master Secret) 획득 및 세션키(Session Key) 생성

키 교환 알고리즘이 RSA일 경우, 서버는 클라이언트에게 받은 암호화된 대칭키를 서버 개인키로 복호화해서 Pre-Master Secret을 획득하고, Pre-Master Secret에 HMAC(Hash-based Message Authentication Code) 함수를 적용해 Master Secret을 계산합니다. 이제 클라이언트와 서버는 동일한 Master Secret, 즉 대칭키를 나눠갖게 되었습니다.

( 키 교환 알고리즘이 DH 계열인 경우, 서버는 자신의 개인키와 [Client Key Exchange]를 통해 받은 키 파라미터를 조합하여 대칭키(Master Secret)를 계산합니다. 클라이언트와 직접적인 키교환 없이도 각자 이산 로그 계산을 통해 동일한 Master Secret을 나눠갖게 됩니다. 눈치채셨겠지만 DH 방식에는 Pre-Master Secret 개념이 없습니다. )

Master Secret은 이후 암호화 통신에 있어서 세션 단위로 사용될 Session Key, 메세지 인증과 무결성을 보증하기 위한 MAC(Message Authentication Code) Key, 암호화된 메세지 초기화에 필요한 초기화 벡터(IV, Initialization Vector) 등을 생성하는 데 사용됩니다.

이제 서버와 클라이언트는 매 세션마다 Master Secret으로 Session Key를 생성합니다. Session Key 생성 이후 클라이언트와 서버는 각각 [Cipher Spec Exchange]를 주고받음으로써 이후 전송되는 모든 메세지에 대해서 협상된 알고리즘과 키를 사용해 암호화하겠다는 확인 메세지를 보냅니다. 클라이언트와 서버는 [Finished]를 주고받으며 SSL/TLS Handshake를 성공적으로 마칩니다.

3. 암호화된 데이터 송수신 🔐

⑨ 세션키로 암호화한 데이터 송수신

[Application Data] SSL/TLS Handshake가 끝나면 암호화된 데이터를 주고받기 위해 '세션키'라고 불리는 '대칭키'를 사용해서 데이터를 암・복호화합니다. 앞서 SSL/TLS Handshake를 할 때는 '비대칭 암호화'로 서버를 검증하고 대칭키를 주고받았습니다.

하지만 SSL/TLS 인증이 완료된 후에 클라이언트와 서버가 실제 데이터를 주고받을 때는 '대칭 암호화'로 전환됩니다. 그 이유는 '빠른 속도'로 데이터를 송수신하기 위해서입니다. 비대칭 암호화는 연산복잡도가 크기 때문에 막대한 컴퓨팅 성능을 차지합니다. 이 때 사용되는 대칭 암호화 알고리즘에는 AES, DES, ARIA, IDEA 등이 있으며, Cipher Suite에서 '블록 암호화 알고리즘'으로 정의됩니다.

한편, 데이터를 암호화한 후에도 데이터 무결성을 유지하고, 데이터가 변경되었는지 여부를 식별하기 위해서 암호화된 데이터를 해시하기도 합니다. 이 때 사용되는 알고리즘에는 MD5, SHA 등이 있으며, Cipher Suite에서 '메세지 인증 코드(MAC)'에 해당됩니다.

4. 마무리

HTTPS에서는 SSL/TLS Handshake를 통해 '안전한 연결'을 구축한다

지금까지 HTTPS 통신에서 클라이언트 - 서버간의 안전한 연결을 구축하는 과정을 이해하기 위해 서버가 인증서를 발급받는 과정부터 SSL/TLS Handshake하는 과정까지 세세하게 살펴봤습니다. 암호화에 대해서는 다소 추상적으로 설명했습니다. 따라서 이어지는 포스팅인 [Cipher Suite] 안전한 데이터 전송을 위한 SSL/TLS 기술 집약체에서는 HTTPS에서 사용되는 암호화 알고리즘의 종류에 대해서 알아보고, [비대칭키 알고리즘] DH, RSA로 살펴보는 수학적 자물쇠 원리와 그 취약점 보완에서는 DH 계열의 알고리즘은 어떻게 Pre-Master Secret 교환 없이 클라이언트와 서버가 동일한 Master Secret을 나눠갖게 되는지, RSA 알고리즘에서 비대칭키를 어떻게 생성하는지 그 원리와 취약점을 보완하는 방법을 알아보겠습니다. 감사합니다!

5. Reference

HTTPS & SSL/TLS 인증서

암호화 알고리즘

'NetWork' 카테고리의 다른 글

[웹 통신 과정 해부하기] 네트워크 접속부터 브라우저 렌더링까지 (0)	2024.03.31
[I/O multiplexing] select vs kqueue (1)	2024.01.07

ABOUT ME

참을 수 있는 성장의 가벼움 참을 수 있는 성장의 가벼움

들어가며