HTTPS 프로토콜은 평문으로 데이터를 주고받는 HTTP를 보완하고자 SSL/TLS 프로토콜 기반으로 데이터를 암호화 한 프로토콜이다.
HTTPS 프로토콜에 대한 이해
- HTTPS는 "HTTP over TLS": HTTP 요청/응답이 모두 암호화되어 TLS 내부로 감싸짐
- TLS는 TCP 위에서 작동: TLS는 HTTP를 감싸고, 그 결과를 TCP에 올려 보냄
- MAC은 네트워크 최하단의 물리 주소 체계: 같은 LAN에 있는 장치 간 데이터 전송용
| 계층 | 프로토콜 | 역할 | HTTPS와의 관계 |
| 7. Application | HTTP | 웹 브라우저와 서버 간 요청/응답 처리 | HTML, JS 등 요청 |
| 6. Presentation | - | 데이터 표현 변환 (보통 TLS와 통합됨) | TLS가 실질적 역할 |
| 5. Session | TLS/SSL | 암호화 세션 수립, 인증서 검증, 키 교환 | 암호화 처리 핵심 |
| 4. Transport | TCP | 세션 수립, 신뢰성 있는 전송 (3-way handshake) | Port 443 사용 |
| 3. Network | IP | 라우팅, 주소 지정 | IP 패킷 단위 전송 |
| 2. Data Link | MAC/Ethernet | 물리적 주소로 패킷 전송 (LAN) | MAC 주소 이용 |
| 1. Physical | - | 실제 전기 신호/무선 전파 | 케이블 or 무선 |
| Application Layer | ← HTTP (암호화된 웹 요청) |
| TLS / SSL Layer | ← 세션 수립, 암호화, 인증 |
| Transport Layer | ← TCP (Port 443, 신뢰성 보장) |
| Network Layer | ← IP (라우팅, 목적지 지정) |
| Data Link Layer | ← MAC 주소 기반 전송 |
HTTPS 접속 시 흐름
- 브라우저가 https://example.com 접속
- TLS 핸드셰이크 발생
- 서버 인증서 검증 → 서버 신원 확인
- 세션 키 공유 (Pre-master Secret 교환, Pre-master Secret기반으로 세션키 계산)
- 세션 키(대칭키) 암호화로 본격 데이터 교환 시작
SSL/TLS HandShake
TLS는 궁극적으로 세션키(대칭키)를 안전하게 공유하는 것을 목표로 한다.
- 두 통신 주체가 서로의 신원을 확인하고 (인증)
- 암호화 방식 협상 후
- 동일한 대칭키(Session Key)를 생성
※ TLS 1.2와 TLS 1.3은 동작에 차이가 있음 (TLS 1.2 기준으로 설명하고, 이후 차이도 요약해 보려고 한다)
| Client |
────▶ ClientHello ───────▶ - 지원 프로토콜 버전 - 지원 암호 스위트 - Client Random ◀──── ServerHello ◀─────── - 프로토콜 선택 - 암호 스위트 선택 - Server Random - Server Certificate - (Optional) ServerKeyExchange ────▶ ClientKeyExchange ───▶ - Pre-master Secret 전송 (서버 공개키로 암호화) [서버는 개인키로 복호화 → 공유 키 생성] ────▶ ChangeCipherSpe ────▶ ────▶ Finished ────────▶ ◀──── ChangeCipherSpec ◀─── ◀──── Finished ◀─────── ✅ 이후 양쪽 모두 암호화 통신 시작 |
Server |
[설명]
- Client Random / Server Random: 이후 session key 생성에 사용됨
- Pre-master Secret: 클라이언트가 생성해서 서버에게 전달함 (서버의 공개키로 암호화됨)
- Master Secret / Session Key: 양측이 동일하게 계산해 내는 대칭키
- ChangeCipherSpec: “이제부터는 암호화된 통신을 시작” 신호
- Finished: 핸드셰이크 완료 메시지 (암호화된 상태로 전송)
서버가 Session Key를 직접 만들지 않는 이유
- 다양한 클라이언트에게 보안을 강화한 방식으로 Session Key를 전달하는 방법이 없음
➡️ 대신, 안전하게 키를 공유하는 방식(ECDHE 등) 사용
- 또한 이는 Forward Secrecy, 즉 이전 세션의 키가 유출되어도 다른 세션은 안전한 보안성을 보장
- 브라우저 또는 앱의 세션마다 새로 생성 (일회성 또는 일정 시간 후 재협상)
TLS 버전별 Session Key 처리
| TLS 버전 | Session Key 생성 주체 | 설명 |
| TLS 1.2 (RSA key exchange) | 🔵 클라이언트가 Pre-Master 생성 → 서버가 복호화 → 양쪽이 같은 Session Key 계산 | 서버는 Session Key를 직접 만들지 않음 |
| TLS 1.2 (DHE/ECDHE) | 🟢 서버와 클라이언트가 공동 계산 | Diffie-Hellman 방식 |
| TLS 1.3 | 🟢 서버와 클라이언트가 공동 계산 | KeyShare 기반 ECDHE로 양쪽 계산 |
TLS 1.2 - RSA 기반 Handshake
- 클라이언트: Pre-Master Secret 생성 (랜덤값)
- 서버의 공개키로 암호화 → 서버에게 전달
- 서버는 개인키로 복호화
- 양쪽 모두: Master Secret 계산 → Session Key 파생
- Session Key = PRF(Master Secret, Randoms)
- 이 방식에서는 Session Key는 클라이언트가 주도
1️⃣ Client Hello: TLS 버전, 클라이언트가 지원 가능한 Cipher suite, 클라이언트 난수, SNI 등 전달
2️⃣ Server Hello: Cipher suite 선택, 인증서+ 공개키, 서버 난수 등 전달
5️⃣ 서버에게 전달받은 인증서 검증: 공인된 인증서인지 확인(서버의 보안성 확인)
6️⃣ 대칭키 생성 후 서버에게 전달: 서버의 공개키로 암호화하여 전달하며 서버의 개인키로만 복호화가능
TLS 1.2 - DHE 또는 ECDHE 기반 Handshake (Forward Secrecy 지원)
- 클라이언트 & 서버 모두 DH KeyPair 생성
- 공개키만 교환 (KeyShare)
- 서로의 공개키와 자신의 개인키로 동일한 Pre-Master 계산
- 동일한 방식으로 Master Secret → Session Key 유도
- 이 방식은 양쪽 모두 독립적으로 계산하며 Session Key는 계산 결과로 동일하게 나오므로, 어느 한쪽이 만든다고 보긴 어려움
- 단, 서버가 먼저 DH 파라미터를 보내기 때문에 약간 더 주도하는 느낌은 있을 수 있음
TLS 1.3 - 완전한 KeyShare 기반 (공동 계산)
- 클라이언트가 ClientHello에 KeyShare (ECDHE 공개키) 포함
- 서버가 ServerHello에 KeyShare 응답
- 서로의 공개키로 Pre-Master 계산 → Master Secret → Session Key
- 서버도 직접 Session Key를 만들지 않고, 공개키 교환만을 통해 양측이 동일하게 계산
'IT' 카테고리의 다른 글
| SSL/TLS(1) - 공개키(Public Key), 개인키(Private Key), 대칭키 (Symmetric Key) (0) | 2025.06.20 |
|---|---|
| github 접근인증 방법 정리(인증토큰, keychain) (0) | 2021.09.29 |
| 정보보호 관리체계 인증(ISMS) 그리고 정보보호 국제인증(ISO/IEC 200071) (0) | 2021.07.28 |
| 데이터 레이크(Data Lake)는 무엇인가? (0) | 2021.01.28 |
| 간단하게 vue.js 빌드하고 웹서버(nginx) 구성해보기(feat. docker) (0) | 2021.01.17 |
댓글