CS 기초 노트

HTTP vs HTTPS, 뭐가 다른가

2026. 06. 25.
CSNetworkHTTPHTTPSTLS

브라우저 주소창에 http://https://가 있다. s 하나 차이 같지만 실제로는 꽤 큰 차이다.

http  : 그냥 텍스트로 오간다
https : TLS로 암호화된 통로 안에서 오간다

이 글은 그 차이를 한 편에 정리한다.

  • HTTP 자체가 뭘 하는지
  • HTTPS는 뭘 더 얹은 건지
  • TLS 핸드셰이크에서 실제로 일어나는 일
  • 인증서·CA는 왜 필요한지
  • 성능·운영에서 알아둘 점

1. HTTP는 뭘 하는 프로토콜인가

HTTP는 웹에서 리소스를 주고받는 요청-응답 프로토콜이다.

Client                             Server
  │                                  │
  │  GET /users/1  HTTP/1.1          │
  │  Host: api.example.com           │
  │ ───────────────────────────────▶ │
  │                                  │
  │  HTTP/1.1 200 OK                 │
  │  Content-Type: application/json  │
  │                                  │
  │  { "id": 1, "name": "sangeok" }  │
  │ ◀─────────────────────────────── │
  │                                  │

기본 특징.

- 요청-응답 모델 (Request → Response)
- Stateless: 서버가 이전 요청을 기억하지 않음
- 텍스트 기반 (HTTP/1.x), 바이너리 (HTTP/2, HTTP/3)
- 기본 포트: 80

HTTP 자체는 아무것도 암호화하지 않는다. 그래서 중간에 누가 패킷을 보면 요청/응답이 그대로 다 읽힌다.


2. HTTP의 문제 세 가지

HTTPS가 왜 나왔는지 이해하려면 HTTP의 취약점을 먼저 봐야 한다.

① 도청 (Eavesdropping)

Client ─── "password=1234" ───▶ Server
                │
             중간에서 그대로 읽힘

로그인 정보, API 키, 개인정보가 평문으로 흐른다.

② 변조 (Tampering)

Client ─── "송금 100원" ───▶ [공격자] ───▶ "송금 100000원" ───▶ Server

중간에서 요청 내용을 바꿔치기해도 알아차릴 수 없다.

③ 위장 (Spoofing / MITM)

Client ─── 요청 ───▶ [나쁜 서버 (은행인 척)]

접속한 상대가 진짜인지 확인할 방법이 없다.

이 세 가지를 다 해결하겠다는 게 HTTPS다.


3. HTTPS = HTTP + TLS

HTTPS는 HTTP 자체를 바꾼 게 아니다. HTTP를 TLS라는 암호화된 통로 안에서 흘리는 것이다.

[일반]   Application ─ HTTP ─ TCP ─ IP
[HTTPS]  Application ─ HTTP ─ TLS ─ TCP ─ IP
                                ↑
                          여기가 핵심

TLS(Transport Layer Security)는 두 가지를 보장한다.

1. 기밀성 (Confidentiality) : 중간에서 봐도 못 읽음
2. 무결성 (Integrity)       : 중간에서 바꾸면 티가 남
3. 인증 (Authentication)    : 상대가 진짜 그 서버인지 확인 가능

기본 포트는 443.


4. TLS 핸드셰이크가 실제로 하는 일

접속 초반에 아주 짧게 협상을 한다. 대충 이렇다 (TLS 1.2 기준).

Client                                Server
  │                                     │
  │  ClientHello                        │
  │   - 지원 TLS 버전, 암호 스위트 목록 │
  │   - Client Random                   │
  │ ──────────────────────────────────▶ │
  │                                     │
  │             ServerHello             │
  │   - 선택된 암호 스위트              │
  │   - Server Random                   │
  │             Certificate             │
  │   - 서버의 공개키가 담긴 인증서     │
  │             ServerHelloDone         │
  │ ◀────────────────────────────────── │
  │                                     │
  │  (인증서 검증)                      │
  │  ClientKeyExchange                  │
  │   - Pre-master secret               │
  │     (서버 공개키로 암호화)          │
  │ ──────────────────────────────────▶ │
  │                                     │
  │  둘 다 세션 키 생성                 │
  │  (Client Random + Server Random     │
  │   + Pre-master secret로 계산)       │
  │                                     │
  │  Finished (암호화 완료 신호)        │
  │ ◀────────────────────────────────▶  │
  │                                     │
  │  ─── 이후 HTTP 트래픽 (대칭키 암호화) ─── │

핵심 감각.

- 핸드셰이크에서만 "비대칭 키" (RSA/ECDHE)를 씀 — 세션 키를 안전하게 만들려고
- 실제 데이터 암복호화는 "대칭 키" (AES 등) — 훨씬 빠름
- 그래서 HTTPS는 접속 시작만 비싸고, 그 뒤 통신은 거의 HTTP만큼 빠름

TLS 1.3부터는 왕복 횟수가 줄어서 초기 지연이 더 작아졌다 (1-RTT, 0-RTT).


5. 인증서와 CA

핸드셰이크 중 서버가 보낸 "인증서"는 이렇게 생겼다.

Certificate
├─ Subject         : api.example.com
├─ Public Key      : (서버의 공개키)
├─ Issuer          : Let's Encrypt R3
├─ Validity        : 2026-01-01 ~ 2026-04-01
└─ Signature       : (CA의 개인키로 서명)

브라우저는 이 인증서가 믿을 만한 CA(Certificate Authority)가 서명했는지 확인한다.

브라우저/OS에 미리 내장된 Root CA 목록
       │
       │  이 목록의 CA가 서명한 것 → 신뢰
       │  이 목록에 없는 CA가 서명한 것 → 경고
       ▼
[Root CA] → 서명 → [중간 CA] → 서명 → [서버 인증서]
        (신뢰 체인, Chain of Trust)

이걸로 얻는 것.

- 접속한 상대가 진짜 그 도메인의 서버인지 확인
- 도메인 소유자만 그 인증서를 받을 수 있음 (도메인 소유 검증)

실무에서 자주 쓰는 도구.

- Let's Encrypt : 무료, 90일 만료, ACME 자동 갱신
- AWS ACM       : AWS 리소스에 붙일 때 편함
- Cloudflare    : 프록시 앞단에서 TLS 종료

6. HTTP vs HTTPS 한눈에

항목HTTPHTTPS
포트80443
암호화없음 (평문)TLS로 암호화
무결성 검증없음있음
서버 인증없음인증서 기반
초기 지연낮음핸드셰이크 왕복 있음
이후 통신 성능빠름거의 동일 (대칭키)
브라우저 표시"안전하지 않음" 경고자물쇠
SEO불리유리
HTTP/2, HTTP/3 사용사실상 불가표준

7. 성능 이야기

"HTTPS는 느리지 않나?" — 예전엔 맞았지만, 지금은 거의 그렇지 않다.

- 대칭키 암호화(AES 등)는 하드웨어 가속을 받아서 매우 빠름
- TLS 1.3으로 핸드셰이크 왕복이 줄어듦 (1-RTT)
- 세션 재사용(Session Resumption)으로 재접속은 더 빠름
- HTTP/2, HTTP/3의 이득이 크기 때문에 HTTPS가 오히려 더 빠른 경우도 흔함

느려지는 지점은 대개 첫 핸드셰이크 뿐이고, 그 뒤로는 사실상 HTTP와 비슷하다.


8. 운영에서 알아둘 것

리다이렉트

http://example.com/foo   →   301   →   https://example.com/foo

거의 모든 실서비스는 HTTP 요청이 오면 HTTPS로 강제 리다이렉트한다.

HSTS (HTTP Strict Transport Security)

Strict-Transport-Security: max-age=31536000; includeSubDomains

이 헤더를 받은 브라우저는 이후 1년 동안 이 도메인은 무조건 HTTPS로만 접속한다. 중간자가 HTTP로 다운그레이드하려는 공격을 막는다.

TLS 종료 지점

[Client] ── HTTPS ──▶ [Load Balancer] ── HTTP ──▶ [App Server]
                            │
                        여기서 TLS 종료 (TLS Termination)
  • ALB, Nginx 같은 앞단에서 TLS를 풀고 내부는 HTTP로 통신하는 구성이 많다
  • 내부망까지 암호화하려면 mTLS나 사이드카 프록시(Envoy 등)를 얹는다

인증서 만료

- Let's Encrypt는 90일마다 갱신 필요
- 자동 갱신을 안 걸어두면 어느 날 서비스가 통째로 멈춤 (자주 있는 장애)
- 모니터링 대상 1순위

정리

  • HTTP는 평문 요청-응답 프로토콜, 도청·변조·위장에 취약하다
  • HTTPS는 HTTP를 TLS 위에 얹은 것 — 기밀성·무결성·서버 인증을 얻는다
  • TLS 핸드셰이크는 비대칭키로 세션 키를 안전하게 만들고, 그 뒤 통신은 대칭키로 빠르게 처리
  • 인증서·CA는 "접속한 상대가 진짜인지"를 보장하는 신뢰 체인이다
  • 요즘은 성능 이슈가 거의 없고, HTTP/2·HTTP/3의 이득 때문에 오히려 더 빨라지기도 한다
  • 실무에서는 강제 리다이렉트 · HSTS · 인증서 자동 갱신 · TLS 종료 지점을 세트로 챙겨야 한다