HTTP는 서버와 클라이언트 모델에서 데이터를 주고받기 위한 프로토콜입니다.
| 항목 | 설명 |
|---|---|
| 프로토콜 | 응용 계층(Application Layer) 프로토콜 |
| 전송 방식 | 평문(Plain Text) 전송 |
| 보안 | 암호화 없음 |
| 속도 | 상대적으로 빠름 |
| 비용 | 추가 비용 없음 |
클라이언트 ──── HTTP 요청 ───→ 서버
(평문 데이터)
클라이언트 ←─── HTTP 응답 ──── 서버
(평문 데이터)
HTTPS는 HTTP에 SSL/TLS라는 암호화 기반 인터넷 보안 프로토콜을 추가한 것입니다.
| 프로토콜 | 설명 |
|---|---|
| SSL | Secure Sockets Layer (구버전) |
| TLS | Transport Layer Security (현재 표준) |
💡 현재는 TLS를 사용하지만, 관습적으로 SSL이라는 용어를 함께 사용합니다.
| 항목 | 설명 |
|---|---|
| 보안 | 데이터 암호화, 인증, 무결성 검증 |
| 속도 | 암호화/복호화로 인한 약간의 오버헤드 |
| 비용 | SSL/TLS 인증서 발급 및 유지 비용 |
| SEO | 구글 검색 순위 가산점 |
클라이언트 ──── HTTPS 요청 ───→ 서버
(암호화된 데이터 🔐)
클라이언트 ←─── HTTPS 응답 ──── 서버
(암호화된 데이터 🔐)
사용자 → [ID: admin, PW: 1234] → 서버
↓ (누구나 볼 수 있음!)
해커 👀
사용자 → [🔐 암호화된 데이터] → 서버
↓ (해독 불가능!)
해커 ❓❓❓
🔒 https://example.com ← 우선 노출
⚠️ http://example.com ← 불이익
HTTP → 빠름 ✅
HTTPS → 느림 (암호화/복호화 오버헤드) ❌
HTTP → 빠름 ✅
HTTPS → 거의 동일 (하드웨어 발전 + HTTP/2, HTTP/3) ✅
성능 차이가 미미한 이유:
| 항목 | HTTP | HTTPS |
|---|---|---|
| 인증서 비용 | 무료 | 무료~유료 |
| 유지보수 | 간단 | 인증서 갱신 필요 |
HTTPS 인증서 옵션:
HTTPS는 대칭키와 비대칭키 암호화 방식을 하이브리드로 사용합니다.
동일한 키로 암호화와 복호화를 수행합니다.
평문 ──[세션키로 암호화]──→ 암호문
암호문 ──[같은 세션키로 복호화]──→ 평문
특징:
예시: AES, DES, 3DES
공개키와 개인키 쌍을 사용합니다.
평문 ──[공개키로 암호화]──→ 암호문 ──[개인키로 복호화]──→ 평문
평문 ──[개인키로 암호화]──→ 암호문 ──[공개키로 복호화]──→ 평문
핵심 원리:
특징:
예시: RSA, ECC
HTTPS는 두 방식의 장점을 결합합니다:
1단계: 비대칭키로 세션키 교환 (느리지만 안전)
↓
2단계: 대칭키(세션키)로 데이터 암호화 (빠르고 효율적)
| 단계 | 암호화 방식 | 용도 | 특징 |
|---|---|---|---|
| 핸드셰이크 | 비대칭키 | 세션키 교환 | 느리지만 안전 |
| 데이터 전송 | 대칭키 | 실제 데이터 암호화 | 빠르고 효율적 |
클라이언트 서버
| |
|────① Client Hello─────────────────→|
| |
|←───② Server Hello + 인증서─────────|
| |
|────③ 세션키 생성 및 암호화─────────→|
| (서버 공개키로 암호화) |
| |
|←───④ 완료 (세션키 복호화 완료)──────|
| |
|═══⑤ 암호화된 데이터 통신 시작═══════|
클라이언트: "안녕하세요! HTTPS 연결을 시작하고 싶습니다."
"제가 지원하는 암호화 방식: [TLS 1.3, AES-256, ...]"
전송 정보:
서버: "안녕하세요! 여기 제 신분증(인증서)입니다."
서버가 전달하는 것:
사전 준비 과정:
1. 서버 관리자
└─→ 개인키/공개키 쌍 생성
└─→ 공개키 + 서버정보를 CA에 제출
└─→ 💰 비용 지불
2. CA (Certificate Authority)
└─→ 서버 신원 확인
└─→ 인증서 생성 (서버 공개키 포함)
└─→ CA의 개인키로 인증서 암호화 🔐
└─→ 서버에게 인증서 발급
3. 서버
└─→ 발급받은 인증서 저장
└─→ 클라이언트 요청 시 전달 준비 완료
주요 CA 기업:
클라이언트: "이 인증서가 진짜인지 확인해볼게요!"
검증 과정:
1. 브라우저에 내장된 CA 공개키 확인
└─→ 주요 CA들의 공개키는 브라우저에 사전 설치됨
2. CA 공개키로 인증서 복호화 시도
└─→ 성공 = 진짜 CA가 발급한 인증서 ✅
└─→ 실패 = 위조 인증서 ❌
3. 인증서 내용 확인
├─→ 도메인 일치 여부
├─→ 유효기간 확인
└─→ 폐기 여부 확인 (CRL, OCSP)
검증 결과:
클라이언트: "이제 우리가 사용할 비밀번호(세션키)를
안전하게 보내드릴게요!"
과정:
1. 세션키 생성
└─→ 무작위 대칭키 생성 (예: AES-256 키)
2. 클라이언트에 세션키 저장
└─→ 메모리에 보관
3. 서버 공개키로 세션키 암호화 🔐
└─→ 인증서에서 추출한 서버 공개키 사용
└─→ 암호화된 세션키 생성
4. 암호화된 세션키를 서버로 전송
└─→ 중간에 누가 가로채도 복호화 불가능!
비유:
세션키 = "secret123"
암호화 전: secret123 (해커가 볼 수 있음 ❌)
↓ [서버 공개키로 암호화]
암호화 후: 8j#kL@9x... (해커가 못 봄 ✅)
서버: "받았습니다! 제 개인키로 열어볼게요."
과정:
1. 암호화된 세션키 수신
└─→ 8j#kL@9x... (암호화된 데이터)
2. 서버의 개인키로 복호화 🔓
└─→ 오직 서버만 갖고 있는 개인키 사용
└─→ 복호화 성공: "secret123"
3. 서버에 세션키 저장
└─→ 메모리에 보관
핵심:
클라이언트: "이제 우리만의 비밀번호로 얘기해요!"
서버: "좋습니다! 보안 통신 시작!"
이제 양쪽 모두 세션키를 가짐:
클라이언트 서버
| |
[세션키: secret123] [세션키: secret123]
| |
|═══ 암호화된 데이터 전송 ═══════|
| (대칭키 암호화) |
| |
실제 데이터 전송:
1. 클라이언트 → 서버
평문: "안녕하세요"
↓ [세션키로 암호화]
전송: "9k#mL@2p..."
2. 서버
수신: "9k#mL@2p..."
↓ [세션키로 복호화]
평문: "안녕하세요"
✅ 공개키로 암호화 → 개인키로 복호화
✅ 개인키로 암호화 → 공개키로 복호화
❌ 공개키로 암호화 → 공개키로 복호화 (불가능!)
❌ 개인키로 암호화 → 개인키로 복호화 (불가능!)
| 단계 | 암호화 | 위험도 | 이유 |
|---|---|---|---|
| 세션키 전송 | 서버 공개키 | 안전 ✅ | 서버의 개인키만이 복호화 가능 |
| 실제 데이터 전송 | 세션키 (대칭키) | 안전 ✅ | 세션키는 안전하게 교환됨 |
| 키 | 소유자 | 공개 여부 | 역할 |
|---|---|---|---|
| 서버 공개키 | 서버 | 공개 ✅ | 세션키 암호화 |
| 서버 개인키 | 서버 | 비공개 🔐 | 세션키 복호화 |
| CA 공개키 | 브라우저 | 공개 ✅ | 인증서 검증 |
| CA 개인키 | CA | 비공개 🔐 | 인증서 발급 |
| 세션키 | 양쪽 | 비공개 🔐 | 데이터 암호화/복호화 |
준비 단계 (서버)
┌─────────────────────────────────────────┐
│ 서버: 개인키/공개키 생성 │
│ └─→ CA에 공개키 + 정보 제출 │
│ └─→ CA가 개인키로 암호화한 인증서 발급 │
└─────────────────────────────────────────┘
연결 단계 (클라이언트 ↔ 서버)
┌─────────────────────────────────────────┐
│ ① 클라이언트: 연결 요청 │
│ "안녕하세요!" │
│ │
│ ② 서버: 인증서 전달 │
│ [CA 개인키로 암호화된 인증서] │
│ └─ 서버 공개키 포함 │
│ │
│ ③ 클라이언트: 인증서 검증 │
│ [CA 공개키로 복호화] ✅ │
│ └─ 서버 공개키 추출 │
│ │
│ ④ 클라이언트: 세션키 생성 및 전송 │
│ 세션키 생성: "secret123" │
│ ↓ [서버 공개키로 암호화] │
│ 전송: "8j#kL@9x..." │
│ │
│ ⑤ 서버: 세션키 복호화 │
│ 수신: "8j#kL@9x..." │
│ ↓ [서버 개인키로 복호화] │
│ 세션키: "secret123" ✅ │
│ │
│ ⑥ 암호화된 통신 시작 │
│ [양쪽 모두 세션키 보유] │
│ └─ 대칭키 암호화로 빠른 통신 │
└─────────────────────────────────────────┘
Q1. 왜 세션키를 사용하나요? 그냥 공개키/개인키로 통신하면 안 되나요?
A. 비대칭키는 연산이 느립니다!
비대칭키 암호화: 🐌🐌🐌 (느림)
대칭키 암호화: ⚡⚡⚡ (빠름)
→ 세션키 교환만 비대칭키 (안전하게)
→ 실제 데이터는 대칭키 (빠르게)
Q2. 세션키를 매번 새로 만드나요?
A. 네, 세션마다 새로운 세션키를 생성합니다.
세션 1: session_key_abc123
세션 2: session_key_xyz789
세션 3: session_key_def456
→ 이전 세션의 키가 노출되어도 안전
Q3. CA 공개키는 어디서 오나요?
A. 브라우저와 OS에 사전 설치되어 있습니다.
Chrome, Firefox, Edge, Safari 등
└─→ 주요 CA들의 공개키 내장
(Let's Encrypt, DigiCert, ...)
# 1. 브라우저 주소창 확인
🔒 자물쇠 아이콘 확인
# 2. 온라인 도구
https://www.ssllabs.com/ssltest/
→ A+ 등급 목표
# 3. 개발자 도구 콘솔
Mixed Content 경고 없는지 확인
✅ 빠른 속도
❌ 보안 취약
❌ SEO 불리
💰 무료
✅ 안전한 통신
✅ SEO 유리
✅ 사용자 신뢰
⚡ 성능 거의 동일 (현재)
💰 무료~유료 (Let's Encrypt 무료)
2025년 현재, HTTPS는 선택이 아닌 필수입니다!
💡 추천: 모든 웹사이트는 HTTPS를 적용하세요. Let's Encrypt를 사용하면 무료로 시작할 수 있습니다!