[HTTPS] 1. SSL, TLS 및 서버 인증서

1. SSL 프로토콜

• 웹 브라우저와 서버 간의 보안된 통신을 위한 프로토콜
• ✅ 서버 인증: 서버가 해당 도메인의 인증서에 대응하는 개인키를 보유하고 있는지 검증할 수 있도록 함
• ✅ 클라이언트 인증 (mTLS 옵션): 클라이언트가 CA에 의해 인증받았음을 보장
• ➡️ 암호화 및 서버 인증: 제3자가 통신 내용을 읽거나 서버를 사칭하는 중간자 공격을 방지함
• ➡️ 데이터 무결성: 전송 중 내용이 변조되지 않았음을 보장

 

2. TLS 프로토콜

• SSL의 후속 프로토콜
• ✅ SSL보다 더 안전하고 효율적인 암호화 방식을 제공함

 

통신 과정

순서	방향	메시지	처리 결과	주요 내용
1	클라이언트 → 서버	ClientHello	서버에 사용할 보안 조건 제안	지원 TLS 버전, 암호 스위트, SNI, ALPN, 난수, 클라이언트 (EC)DHE key_share 전송
2	서버 → 클라이언트	ServerHello	사용할 TLS 조건 확정 및 양측의 ECDHE 공유 비밀 계산 가능 상태 형성	TLS 버전, 암호 스위트, 서버 난수, 서버 (EC)DHE key_share 선택·전송
3	양측 내부 처리	Handshake Key 파생	이후 핸드셰이크 메시지를 암호화할 수 있는 상태 형성	ECDHE 공유 비밀과 ClientHello·ServerHello의 해시를 HKDF에 입력하여 클라이언트·서버별 Handshake Traffic Key 파생
4	서버 → 클라이언트	EncryptedExtensions	서버가 선택한 연결 조건 전달	선택된 ALPN 등 ClientHello의 확장 항목에 대한 서버 응답 전송
(5)	서버 → 클라이언트	CertificateRequest	클라이언트 인증 요청	상호 TLS(mTLS)를 사용하는 경우 서버가 클라이언트 인증서 제출을 요청
6	서버 → 클라이언트	Certificate	서버의 신원 정보와 공개키 전달	서버 인증서와 중간 CA 인증서 체인 전송
7	서버 → 클라이언트	CertificateVerify	서버의 인증서 개인키 보유 증명	서버 개인키로 지금까지의 핸드셰이크 내역에 서명
8	서버 → 클라이언트	Finished	핸드셰이크 무결성과 동일한 키 보유 증명	서버 Finished Key와 핸드셰이크 메시지 해시를 이용하여 검증값 생성·전송
9	클라이언트 내부 처리	서버 검증	서버 신원과 핸드셰이크의 유효성 최종 확인	클라이언트가 인증서, 서명, Finished를 검증함
(10)	클라이언트 → 서버	Certificate / CertificateVerify	클라이언트가 신원과 개인키 보유 사실을 서버에 증명	서버가 CertificateRequest를 보낸 경우 클라이언트 인증서와 개인키 서명 전송
11	클라이언트 → 서버	Finished	서버가 클라이언트 측 핸드셰이크 무결성과 동일한 키 보유 사실 확인	클라이언트 Finished Key와 핸드셰이크 메시지 해시를 이용한 검증값 전송
12	양측 내부 처리	Application Traffic Key 파생	실제 애플리케이션 데이터 암호화 준비 완료	HKDF로 클라이언트·서버별 Application Traffic Secret를 파생. 실제 암호화 키·IV를 생성함
13	양방향	Application Data	기밀성과 무결성이 보호된 애플리케이션 통신 수행	HTTP 요청·응답 등의 데이터를 방향별 대칭키와 AEAD 알고리즘으로 암호화·인증

 

ECDHE 공유 비밀 생성

• 클라이언트와 서버는 각각 일회성 ECDHE 개인값을 생성하고, 이를 이용해 key_share 공개값을 만든 뒤 ClientHello와 ServerHello를 통해 서로 교환한다.
• 공개값을 교환한 이후 클라이언트는 자신의 개인값과 서버의 공개값을, 서버는 자신의 개인값과 클라이언트의 공개값을 타원곡선 연산하여 동일한 ECDHE 공유 비밀을 계산한다.
• ✅ 생성된 공유 비밀은 그대로 암호화 키로 사용하지 않고, HKDF를 통해 핸드셰이크 키와 애플리케이션 통신 키를 파생하는 데 사용한다.
• ➡️ 전방향 비밀성: 세션 종료 후 일회성 ECDHE 개인값을 폐기하면, 이후 서버 인증서에 대응하는 장기 개인키가 유출되더라도 과거 세션의 공유 비밀과 통신 키를 복구하기 어렵다.

 

HKDF 키 파생

• HKDF를 이용하여 하나의 공유 비밀로부터 실제 TLS 통신에 필요한 여러 개의 키를 만들어내는 과정
• ⚠️ ECDHE 공유 비밀을 모든 암호화/검증에 재사용하면, 노출시에 여러 통신 단계와 전송 방향이 함께 영향을 받을 수 있음
• ✅ 클라이언트와 서버는 동일한 ECDHE 공유 비밀과 핸드셰이크 메시지의 해시값을 기반으로 동일한 키 파생 절차를 수행함
• ➡️ 단계별로 키를 분리하고, 클라이언트/서버 송신 등 전송 방향과 사용 목적별로 서로 다른키를 생성함

 

표) HKDF 키 종류

키	용도
Client Handshake Traffic Key	클라이언트가 서버로 보내는 핸드셰이크 메시지 암호화
Server Handshake Traffic Key	서버가 클라이언트로 보내는 핸드셰이크 메시지 암호화
Client Application Traffic Key	클라이언트가 보내는 HTTP 요청 등 애플리케이션 데이터 암호화
Server Application Traffic Key	서버가 보내는 HTTP 응답 등 애플리케이션 데이터 암호화
Finished Key	Finished 메시지의 검증값 생성 및 핸드셰이크 무결성 확인

 

 

3. TLS 서버 인증서

• 서버가 자신의 신원을 클라이언트에게 증명할 때 사용하는 디지털 문서
• ✅ 서버의 도메인 정보와 공개키가 포함되어 있음
• ✅ 신뢰할 수 있는 인증기관(CA)이 해당 내용을 전자서명함
• ➡️ 클라이언트는 서버가 해당 도메인의 인증서를 보유하고 있으며, 인증서 공개키에 대응하는 개인키를 가지고 있는지 검증할 수 있음

 

구성 요소

구성 요소	역할	비고·주의사항
공개키	서버가 보낸 CertificateVerify 서명을 검증하여 서버가 인증서 개인키를 실제로 보유하는지 확인	실제 HTTP 데이터 암호화에는 사용하지 않으며, 데이터는 파생된 대칭키로 암호화
도메인 이름(SAN)	접속한 도메인과 인증서에 등록된 도메인이 일치하는지 확인	현재 호스트명 검증은 SAN이 핵심이며 CN은 레거시 항목
CA 서명 및 인증서 체인	인증서가 신뢰할 수 있는 CA에서 발급되었고 위·변조되지 않았는지 확인	서버 인증서 → 중간 CA → 루트 CA 순으로 검증하며, 루트 CA는 브라우저·OS 신뢰 저장소에 존재
유효기간 및 폐지 상태	인증서가 현재 사용할 수 있는 상태인지 확인	Not Before, Not After와 함께 OCSP·CRL 등을 통해 폐지 여부를 확인할 수 있음

 

발급 과정

1. 개인키 및 CSR 생성
   • 서버 관리자는 공개키와 개인키 쌍을 생성하고, 공개키와 도메인 정보가 포함된 인증서 서명 요청서(CSR)를 생성한다.
   • 개인키는 서버에 안전하게 보관하며 CA에 제출하지 않는다.
2. CA에 CSR 제출
   • 생성한 CSR을 인증기관(CA)에 제출하여 인증서 발급을 요청한다.
3. 도메인 통제권 검증 및 인증서 발급
   • CA는 DNS, HTTP 파일, 이메일 등의 방법으로 신청자가 해당 도메인을 실제로 통제하고 있는지 확인한다.
   • 검증이 완료되면 CA는 서버의 공개키와 도메인 정보가 포함된 인증서를 전자서명하여 발급한다.
4. 서버에 인증서 설치
   • 발급받은 서버 인증서와 중간 CA 인증서를 웹 서버 또는 로드밸런서에 설치하고, 기존에 생성한 서버 개인키와 연결한다.
5. 만료 전 갱신
   • 인증서가 만료되기 전에 새 인증서를 발급받아 교체하며, 가능하면 자동 갱신을 적용한다.

 

 

출처

• IETF RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3⁠
• IETF RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile⁠
• CA/Browser Forum — Baseline Requirements for TLS Server Certificates⁠