프론트엔드 짧은 간단 지식 정리 - HTTP와 HTTPS

이상범·2025년 12월 3일

🌐 HTTP (HyperText Transfer Protocol)

개념

HTTP는 서버와 클라이언트 모델에서 데이터를 주고받기 위한 프로토콜입니다.

  • 인터넷에서 웹 브라우저와 서버 간의 통신 규약
  • 1989년 팀 버너스리가 처음 설계
  • 기본 포트: 80번
  • 연결 방식: 비연결성(Connectionless), 무상태(Stateless)

특징

항목설명
프로토콜응용 계층(Application Layer) 프로토콜
전송 방식평문(Plain Text) 전송
보안암호화 없음
속도상대적으로 빠름
비용추가 비용 없음

구조

클라이언트 ──── HTTP 요청 ───→ 서버
            (평문 데이터)
클라이언트 ←─── HTTP 응답 ──── 서버
            (평문 데이터)

🔒 HTTPS (HyperText Transfer Protocol Secure)

개념

HTTPS는 HTTP에 SSL/TLS라는 암호화 기반 인터넷 보안 프로토콜을 추가한 것입니다.

  • HTTP + SSL/TLS = HTTPS
  • 기본 포트: 443번
  • 데이터 암호화, 인증, 무결성 보장

SSL vs TLS

프로토콜설명
SSLSecure Sockets Layer (구버전)
TLSTransport Layer Security (현재 표준)

💡 현재는 TLS를 사용하지만, 관습적으로 SSL이라는 용어를 함께 사용합니다.

특징

항목설명
보안데이터 암호화, 인증, 무결성 검증
속도암호화/복호화로 인한 약간의 오버헤드
비용SSL/TLS 인증서 발급 및 유지 비용
SEO구글 검색 순위 가산점

구조

클라이언트 ──── HTTPS 요청 ───→ 서버
         (암호화된 데이터 🔐)
클라이언트 ←─── HTTPS 응답 ──── 서버
         (암호화된 데이터 🔐)

🆚 HTTP vs HTTPS 차이점

1. 보안성 🔐

HTTP

  • ❌ 암호화되지 않은 평문 전송
  • ❌ 중간자 공격(MITM)에 취약
  • ❌ 데이터 도청 가능
  • ❌ 데이터 변조 가능
사용자 → [ID: admin, PW: 1234] → 서버
        ↓ (누구나 볼 수 있음!)
     해커 👀

HTTPS

  • ✅ 데이터 암호화
  • ✅ 안전한 데이터 전송
  • ✅ 데이터 무결성 보장
  • ✅ 서버 신원 인증
사용자 → [🔐 암호화된 데이터] → 서버
        ↓ (해독 불가능!)
     해커 ❓❓❓

2. SEO (검색엔진 최적화) 📈

구글의 HTTPS 우대 정책

  • 2014년: 구글이 HTTPS를 검색 순위 결정 요소로 공식 발표
  • 가산점 부여: HTTPS 사이트에 순위 가산점
  • Chrome 경고: HTTP 사이트를 "안전하지 않음"으로 표시
🔒 https://example.com    ← 우선 노출
⚠️  http://example.com     ← 불이익

3. 성능 ⚡

과거

HTTP  → 빠름 ✅
HTTPS → 느림 (암호화/복호화 오버헤드) ❌

현재 (2025년)

HTTP  → 빠름 ✅
HTTPS → 거의 동일 (하드웨어 발전 + HTTP/2, HTTP/3) ✅

성능 차이가 미미한 이유:

  • 현대 프로세서의 AES-NI 명령어 세트
  • HTTP/2, HTTP/3의 성능 최적화
  • TLS 1.3의 핸드셰이크 간소화

4. 비용 💰

항목HTTPHTTPS
인증서 비용무료무료~유료
유지보수간단인증서 갱신 필요

HTTPS 인증서 옵션:

  • 🆓 Let's Encrypt: 무료 인증서 (90일 갱신)
  • 💵 상용 인증서: Comodo, DigiCert 등 (연간 수만원~수십만원)
  • 💼 EV 인증서: 회사명 표시 (연간 수백만원)

🔑 HTTPS 암호화 방식

HTTPS는 대칭키비대칭키 암호화 방식을 하이브리드로 사용합니다.

대칭키 암호화 (Symmetric Key)

동일한 키로 암호화와 복호화를 수행합니다.

평문 ──[세션키로 암호화]──→ 암호문
암호문 ──[같은 세션키로 복호화]──→ 평문

특징:

  • 빠른 속도: 연산이 간단
  • 🔐 데이터 암호화: 실제 통신 데이터 암호화에 사용
  • ⚠️ 키 공유 문제: 키를 안전하게 교환하는 것이 어려움

예시: AES, DES, 3DES

비대칭키 암호화 (Asymmetric Key)

공개키개인키 쌍을 사용합니다.

평문 ──[공개키로 암호화]──→ 암호문 ──[개인키로 복호화]──→ 평문
평문 ──[개인키로 암호화]──→ 암호문 ──[공개키로 복호화]──→ 평문

핵심 원리:

  • 🔓 공개키: 누구나 볼 수 있는 키 (암호화용)
  • 🔐 개인키: 소유자만 갖고 있는 키 (복호화용)
  • 🔄 상호 변환: 공개키로 암호화 → 개인키로 복호화 / 개인키로 암호화 → 공개키로 복호화

특징:

  • 🐌 느린 속도: 연산이 복잡
  • 🔑 키 교환: 세션키를 안전하게 전달하는데 사용
  • 안전성: 공개키가 노출되어도 안전

예시: RSA, ECC

하이브리드 방식

HTTPS는 두 방식의 장점을 결합합니다:

1단계: 비대칭키로 세션키 교환 (느리지만 안전)
   ↓
2단계: 대칭키(세션키)로 데이터 암호화 (빠르고 효율적)
단계암호화 방식용도특징
핸드셰이크비대칭키세션키 교환느리지만 안전
데이터 전송대칭키실제 데이터 암호화빠르고 효율적

🔐 HTTPS 세션키 공유 과정 (SSL/TLS Handshake)

전체 흐름도

클라이언트                               서버
    |                                    |
    |────① Client Hello─────────────────→|
    |                                    |
    |←───② Server Hello + 인증서─────────|
    |                                    |
    |────③ 세션키 생성 및 암호화─────────→|
    |     (서버 공개키로 암호화)           |
    |                                    |
    |←───④ 완료 (세션키 복호화 완료)──────|
    |                                    |
    |═══⑤ 암호화된 데이터 통신 시작═══════|

상세 단계별 설명

🔹 Step 1: 클라이언트 → 서버 (최초 연결 시도)

클라이언트: "안녕하세요! HTTPS 연결을 시작하고 싶습니다."
           "제가 지원하는 암호화 방식: [TLS 1.3, AES-256, ...]"

전송 정보:

  • 지원하는 TLS 버전
  • 지원하는 암호화 알고리즘 목록
  • 무작위 데이터 (랜덤 바이트)

🔹 Step 2: 서버 → 클라이언트 (인증서 전달)

서버: "안녕하세요! 여기 제 신분증(인증서)입니다."

서버가 전달하는 것:

  • SSL/TLS 인증서
    • 서버의 공개키 포함
    • CA(인증기관)의 개인키로 암호화됨
    • 서버 정보 (도메인, 유효기간 등)
📜 인증서는 어떻게 만들어졌을까?

사전 준비 과정:

1. 서버 관리자
   └─→ 개인키/공개키 쌍 생성
   └─→ 공개키 + 서버정보를 CA에 제출
   └─→ 💰 비용 지불

2. CA (Certificate Authority)
   └─→ 서버 신원 확인
   └─→ 인증서 생성 (서버 공개키 포함)
   └─→ CA의 개인키로 인증서 암호화 🔐
   └─→ 서버에게 인증서 발급

3. 서버
   └─→ 발급받은 인증서 저장
   └─→ 클라이언트 요청 시 전달 준비 완료

주요 CA 기업:

  • Let's Encrypt (무료)
  • DigiCert
  • Comodo
  • GlobalSign

🔹 Step 3: 클라이언트의 인증서 검증

클라이언트: "이 인증서가 진짜인지 확인해볼게요!"

검증 과정:

1. 브라우저에 내장된 CA 공개키 확인
   └─→ 주요 CA들의 공개키는 브라우저에 사전 설치됨

2. CA 공개키로 인증서 복호화 시도
   └─→ 성공 = 진짜 CA가 발급한 인증서 ✅
   └─→ 실패 = 위조 인증서 ❌

3. 인증서 내용 확인
   ├─→ 도메인 일치 여부
   ├─→ 유효기간 확인
   └─→ 폐기 여부 확인 (CRL, OCSP)

검증 결과:

  • 성공: 인증서에서 서버의 공개키 추출
  • 실패: "안전하지 않은 연결" 경고 표시

🔹 Step 4: 클라이언트 → 서버 (세션키 전달)

클라이언트: "이제 우리가 사용할 비밀번호(세션키)를 
           안전하게 보내드릴게요!"

과정:

1. 세션키 생성
   └─→ 무작위 대칭키 생성 (예: AES-256 키)

2. 클라이언트에 세션키 저장
   └─→ 메모리에 보관

3. 서버 공개키로 세션키 암호화 🔐
   └─→ 인증서에서 추출한 서버 공개키 사용
   └─→ 암호화된 세션키 생성

4. 암호화된 세션키를 서버로 전송
   └─→ 중간에 누가 가로채도 복호화 불가능!

비유:

세션키 = "secret123"

암호화 전:  secret123  (해커가 볼 수 있음 ❌)
       ↓ [서버 공개키로 암호화]
암호화 후:  8j#kL@9x...  (해커가 못 봄 ✅)

🔹 Step 5: 서버의 세션키 복호화

서버: "받았습니다! 제 개인키로 열어볼게요."

과정:

1. 암호화된 세션키 수신
   └─→ 8j#kL@9x... (암호화된 데이터)

2. 서버의 개인키로 복호화 🔓
   └─→ 오직 서버만 갖고 있는 개인키 사용
   └─→ 복호화 성공: "secret123"

3. 서버에 세션키 저장
   └─→ 메모리에 보관

핵심:

  • 서버만 개인키를 갖고 있음
  • ✅ 따라서 서버만 세션키를 복호화 가능
  • ✅ 중간에 누가 가로채도 무용지물

🔹 Step 6: 암호화된 통신 시작

클라이언트: "이제 우리만의 비밀번호로 얘기해요!"
서버: "좋습니다! 보안 통신 시작!"

이제 양쪽 모두 세션키를 가짐:

클라이언트                          서버
    |                              |
[세션키: 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, ...)

🎯 실전 체크리스트

웹사이트 운영자를 위한 HTTPS 적용 가이드

✅ HTTPS 전환 체크리스트

  • SSL/TLS 인증서 발급
    • 무료: Let's Encrypt
    • 유료: 상용 인증서
  • 웹 서버에 인증서 설치
  • HTTP → HTTPS 리다이렉트 설정
  • Mixed Content 문제 해결
    • 모든 리소스를 HTTPS로 로드
  • HSTS 헤더 설정
  • 인증서 자동 갱신 설정
  • CDN HTTPS 적용
  • 서브도메인 인증서 확인

🔍 HTTPS 적용 확인 방법

# 1. 브라우저 주소창 확인
🔒 자물쇠 아이콘 확인

# 2. 온라인 도구
https://www.ssllabs.com/ssltest/
→ A+ 등급 목표

# 3. 개발자 도구 콘솔
Mixed Content 경고 없는지 확인

📚 추가 리소스

공식 문서

도구


🎓 요약

HTTP

✅ 빠른 속도
❌ 보안 취약
❌ SEO 불리
💰 무료

HTTPS

✅ 안전한 통신
✅ SEO 유리
✅ 사용자 신뢰
⚡ 성능 거의 동일 (현재)
💰 무료~유료 (Let's Encrypt 무료)

결론

2025년 현재, HTTPS는 선택이 아닌 필수입니다!

  • 🔐 사용자 데이터 보호
  • 📈 검색 순위 향상
  • 🏆 브랜드 신뢰도 증가
  • ⚡ 성능 저하 미미
  • 💰 무료 옵션 존재

💡 추천: 모든 웹사이트는 HTTPS를 적용하세요. Let's Encrypt를 사용하면 무료로 시작할 수 있습니다!

profile
프론트엔드 입문 개발자입니다.

0개의 댓글