HTTPS 통신 과정

2025.05.13 - [Computer Science/네트워크] - HTTP 변천사

HTTP 변천사

HTTP에 관한 내용

---

HTTPS (HyperText Transfer Protocol Secure Socket Layer)

HTTP/2,3은 HTTPS 위에서 동작

HTTPS는 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 `SSL/TLS` 계층을 넣은 신뢰할 수 있는 HTTPS 요청을 말함

HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화 함

∴ 데이터의 적절한 보호를 보장

HTTPS를 구축하는 방법은 아래와 같이 크게 세 가지로 나뉨

1. 직접 CA에서 구매한 인증키를 기반으로 HTTPS 서비스 구축
2. 서버 앞단에 HTTPS를 제공하는 로드밸런서 사용
3. 서버 앞단에 HTTPS를 제공하는 CDN 사용

---

SSL/TLS

SSL (Secure Soket Layer)은 SSL 1.0 부터 시작하여 SSL 2.0, SSL3.0, TLS 1.0, TLS 1.3까지 버전이 올라감

TLS(Transport Layer Security Protocol)로 명칭이 변경되었으나, 통칭하여 SSL/TLS로 부름

• SSL/TLS는 전송 계층에서 보안을 제공하는 프로토콜
• 제 3자가 메시지를 도청하거나 변조하지 못하도록 함

항목	SSL	TLS
정식 명칭	Secure Sockets Layer	Transport Layer Security
개발 주체	Netscape	IETF(인터넷 표준화 기구)
버전	SSL 2.0, 3.0 (현재 모두 폐기됨)	TLS 1.0, 1.1, 1.2, 1.3
보안성	취약점 존재, 더 이상 사용되지 않음	최신 버전은 보안이 강화됨
호환성	과거 시스템과 호환	SSL과의 하위 호환 제공 (초기 TLS)
사용 여부	더 이상 사용하지 않음	현재 대부분의 웹에서 사용 중

 

SSL/TLS를 통해 공격자가 서버인 척하면서  사용자 정보를 가로채는 네트워크상의 `인터셉터` 방지 가능

• SSL/TLS는 보안 세션을 기반으로 데이터를 암호화
• 보안 세션 만들기 👉 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘 사용됨

---

인증 메커니즘

인증 메커니즘은 `CA` (Certificate Authorities)에서 발급한 인증서를 기반으로 이루어짐

CA에서 발급한 인증서는 안전한 연결을 시작하는 데 있어 필요한 `공개키`를 클라이언트에 제공하고,
사용자가 접속한 서버가 신뢰할 수 있는 서버임을 보장

HTTPS 통신 과정

CA는 아무 기업이나 할 수 있는 것이 아니며, 신뢰성이 엄격히 공인된 기업들만 참여 가능

Ex) Comodo, GoDaddy, GlobalSign, 아마존 등

 

---

CA 발급 과정

서비스가 CA 인증서를 발급받으려면 `사이트 정보`와 `공개키`를 CA에 제출해야 함

이후 CA는 공개키를 해시한 값인 지문(finger print)을 사용하는 CA의 비밀키 등을 기반으로 CA 인증서 발급

❓ 개인키, 공개키 (쌍을 이루어 존재)
- 개인키 (비밀키): 키 발행자만이 갖는 키, 보통 데이터를 복호화 하는데 사용 (암호화도 가능)
- 공개키: 누구나 알아도 상관 없는 키, 보통 데이터를 암호화 하는데 사용 (복호화도 가능)
- 대칭키: 암/복호화에 각기 다른 키를 사용하는 것이 아닌 대칭키라는 하나의 키를 사용

<HTTPS 통신과정 (출처: 미닉스 김인성님 블로그)>

---

인증서를 사용하는 이유

인증서는 서버가 진짜 신뢰할 수 있는 주체인지 클라이언트에게 증명하기 위한 수단임

인증서의 역할

1. 서버의 공개키와 도메인이 진짜인지 검증
2. 공개키가 제 3자 (인증기관, CA)에 의해 발급되었는지 확인
3. 중간자 공격 방지

인증서에 들어있는 것

• 서버의 도메인 정보
• 서버의 공개키
• 인증기관의 전자 서명
• 유효기간 등 메타 정보

브라우저는 내장된 신뢰된 루트 CA 목록을 가지고, 서버 인증서의 서명 검증

📌 정리
인증서 없이는 누가 공개키를 보냈는지 알 수 없어서, 신뢰할 수 없는 암호화가 됨
∴ SSL/TLS 핸드셰이크 (= HTTPS 핸드셰이크)에서 인증서를 먼저 보내는 것

이렇게, SSL/TLS 인증서를 통해 웹 브라우저가 서버를 신용하게 되었으므로, 그 다음으로 웹 브라우저와 서버는 데이터를 어떻게 암호화할 것인지에 대해 협상함.

이 협상에 사용되는 암호화 알고리즘의 집합이 바로 사이퍼 슈트이며, 이 전반적인 과정을 `SSL/TLS HandShake`라고 함

---

SSL/TLS Handshake

보안이 시작되고 끝나는 동안 유지되는 세션

SSL/TLS는 핸드셰이크를 통해 보안 세션을 생성, 이를 기반으로 상태 정보 등을 공유

📌 세션 
운영체제가 어떠한 사용자로부터 자신의 자산 사용을 허락하는 일정 기간
사용자는 일정 시간 동안 응용 프로그램 & 자원 사용 가능

SSL/TLS HandShake 과정 (출처: 부소대장님 tistory)

`TCP Handshake`: HTTPS가 TCP기반의 프로토콜이므로 암호화 협상 (TLS Handshake)에 앞서 연결을 생성하는 과정

---

1) Client Hello

Client가 Server에 연결을 시도하며 전송하는 패킷

전송 내용: 

• 자신이 사용가능한 사이퍼 슈트 목록
• Session ID
• SSL Protocol Version
• Random byte 

사이퍼 슈트 (Cipher Suite) 👇🏻 

SSL Protocol version, 인증서 검증, 데이터 암호화 프로토콜, Hash 방식 등의 정보를 담고 있는 존재로,
선택된 Cipher Suite의 알고리즘에 따라 데이터를 암호화 함

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_AES_128_CCM_8_SHA256

등

EX) `TLS_AES_128_GCM_SHA256`

• TLS = 프로토콜
• AES_128_GCM: AEAD 사이퍼 모드
• SHA256: 해싱 알고리즘

EX2) `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`

• ECDHE: 키 교환방식
• RSA: 인증서 검증

❓ AEAD 사이퍼 모드
AEAD(Authenticated Encryption with Associated Data)는 데이터 암호화 알고리즘을 의미
EX)  AES_128_GCM
128비트의 키를 사용하는 표준 블록 암호화 기술 + 병렬 계산에 용이한 알고리즘 GCM이 결합된 알고리즘

---

2-1) Server Hello

Client가 보내온 ClientHello Packet을 받아 사이퍼 슈트 중 하나를 선택한 후, Client에게 알림

또한 자신의 SSL Protocol version 등 도 함께 보냄

---

2-2) Certificate

1. Server가 자신의 SSL/TLS 인증서를 Client에게 전달
   (인증서 내부에는 Server가 발행한 공개키가 들어 있음)
2. Client는 CA의 개인키로 암호화된 SSL 인증서를 CA의 공개키로 복호화
3. 복호화에 성공하면, 인증서는 진짜임이 증명됨 (실패 시 가짜)

---

2-3) Server Key Exchange / ServerHello Done

Server Key Exchange는 Server의 공개키가 SSL 인증서 내부에 없는 경우, Server가 직접 전달함을 의미

인증서에 있는 경우 생략하는 과정

---

3-1) Client Key Exchange

Client는 데이터 암호화에 사용할 대칭키를 생성하여, Server의 공개키로 암호화한 후 Server에 전달

여기서 전달된 `대칭키`가 바로 SSL/TLS Handshake의 목적이자, 가장 중요한 수단인 데이터를 실제로 암호화하는 비밀키임

이제 Key를 통해 Client와 Server가 교환하고자 하는 데이터를 암호화 함

---

3-2) ChangeCipherSpec / Finished

Client, Server 모두가 서로에게 보내는 Packet으로 교환할 정보를 모두 교환한 뒤, 통신할 준비가 다 되었음을 알리는 패킷

그리고 Finished Packet을 보내어 SSL/TLS Handshake 종료

---

정리

1. ClientHello (암호화 알고리즘 나열 & 전달)
2. ServerHello (암호화 알고리즘 선택)
3. ServerCertificate (인증서 전달)
4. Client Key Exchange (데이터 암호화할 대칭키 전달)
5. Client / ServerHello done (정보 전달 완료)
6. Finished (SSL/TLS Handshaek 종료)

즉, 클라이언트와 서버가 키를 공유하고, 이를 기반으로 인증, 인증 확인 등의 작업이 발생
= 단 한 번의 1-RTT가 생긴 후 데이터를 송수신 

📌 TLS 1.3은 사용자가 이전에 방문한 사이트를 재방문하는 경우, 위 통신을 하지 않아도 됨 (= 0-RTT)

---

참고 자료

https://aws-hyoh.tistory.com/39

HTTPS 통신과정 쉽게 이해하기 #3(SSL Handshake, 협상)