HTTP 보안과 HTTPS: 웹 통신을 보호하는 방식
HTTP의 평문 통신 취약점부터 HTTPS와 S-HTTP의 차이, TLS·인증서·보안 헤더·쿠키 설정까지 정리한다.
2026-08-14 · 최초 발행 2025-06-02
평문 HTTP가 남기는 공격 경로
HTTP는 브라우저와 서버가 데이터를 주고받는 기본 프로토콜이지만, 프로토콜 자체에는 보안 기능이 없다. 암호화되지 않은 데이터는 통신 경로에서 도청될 수 있고, 통신 상대의 신원을 확인할 방법도 부족하다. 전송 중인 데이터가 바뀌었는지 보장하기 어렵고, 중간자 공격(Man-in-the-Middle Attack)에도 노출될 수 있다.
이 문제를 보완하는 대표적인 접근이 HTTPS와 S-HTTP다.
HTTPS는 통신 세션 전체를 보호한다
HTTPS는 HTTP 위에 보안 계층을 더한 프로토콜이며, 웹 보안의 표준으로 사용된다. SSL(Secure Socket Layer) 또는 TLS(Transport Layer Security)가 HTTP 요청과 응답을 암호화하므로 전송 계층에서 통신을 보호한다.
HTTP는 80번 포트를 사용하고 URL이 http://로 시작한다. HTTPS는 443번 포트를 사용하며 https:// URL 체계를 따른다.
서버 신원 확인에는 신뢰할 수 있는 인증 기관(CA)이 발급한 디지털 인증서를 사용한다. 클라이언트는 이 인증서를 통해 접속한 서버의 신원을 검증한다.
TLS 핸드셰이크에서 이뤄지는 일
클라이언트와 서버는 지원하는 암호화 방식을 협상하고, 인증서를 확인한 뒤 세션 키를 준비한다. 이후 HTTP 요청과 응답은 합의된 대칭키로 암호화된다.
HTTPS 구현에는 다음 요소가 연결된다.
- 디지털 인증서는 X.509 표준을 기반으로 하며 서버의 공개키와 신원 정보를 담는다. CA의 디지털 서명은 인증서 위조를 방지한다.
- 실제 데이터 암호화에는 AES, 3DES 등의 대칭키 암호화가 쓰이고, 키 교환에는 RSA, ECC 등의 비대칭키 암호화가 쓰인다.
- SHA-256 등의 해시 함수는 메시지 무결성 검증에 사용된다.
- TLS 핸드셰이크는 암호화 방식 협상, 인증서 검증, 세션 키 생성을 수행해 안전한 통신 채널을 구성한다.
S-HTTP는 메시지별로 보안을 적용한다
S-HTTP는 HTTPS와 달리 애플리케이션 계층에서 보안을 구현한다. 전체 통신 세션이 아니라 개별 메시지에 암호화와 서명을 적용할 수 있으며, 암호화·전자 서명·인증을 각각 필요한 수준으로 선택할 수 있다.
표준 HTTP와의 호환성을 고려해 설계됐고, 보안이 필요한 부분만 적용할 수 있다는 특징이 있다. 현재 웹 환경에서는 HTTPS가 주로 사용되지만, S-HTTP는 HTTP 보안을 세션 단위와 메시지 단위로 나누어 바라보는 관점을 보여준다.
| 특성 | HTTPS | S-HTTP |
|---|---|---|
| 보안 구현 계층 | 전송 계층 (SSL/TLS) | 애플리케이션 계층 |
| 보안 범위 | 전체 통신 세션 | 개별 메시지 단위 |
| 선택적 보안 | 불가능 (전체 세션 암호화) | 가능 (메시지별 보안 옵션) |
| 현재 활용도 | 매우 높음 (웹 표준) | 낮음 (거의 사용되지 않음) |
| 인증서 활용 | 필수 | 선택적 |
헤더와 쿠키 설정이 보완하는 HTTP 보안
HTTPS만으로 모든 웹 공격 표면이 사라지지는 않는다. 응답 헤더와 쿠키 속성은 브라우저가 콘텐츠와 세션 정보를 다루는 방식을 제한하는 데 쓰인다.
Content-Security-Policy(CSP)는 신뢰할 수 있는 콘텐츠 소스를 정의해 XSS 공격을 막는 데 활용한다.
Content-Security-Policy: default-src 'self'; script-src 'self' trusted-scripts.com
Strict-Transport-Security(HSTS)는 브라우저가 HTTPS로만 접속하도록 강제한다.
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff는 MIME 타입 스니핑을 막고, X-Frame-Options: DENY는 클릭재킹 공격을 방지한다. X-XSS-Protection: 1; mode=block은 브라우저의 XSS 필터를 활성화한다.
쿠키에는 Secure, HttpOnly, SameSite 속성을 적용할 수 있다. Secure는 HTTPS 연결에서만 쿠키를 전송하게 하고, HttpOnly는 JavaScript를 통한 쿠키 접근을 막는다. SameSite는 크로스 사이트 요청에서 쿠키 전송을 제한한다.
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2021 07:28:00 GMT; Secure
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2021 07:28:00 GMT; HttpOnly
Set-Cookie: id=a3fWa; SameSite=Strict
Nginx에서 HTTPS와 보안 헤더 설정하기
Nginx 설정에서는 인증서 경로, TLS 프로토콜, 암호화 알고리즘, HSTS 및 보안 헤더를 함께 다룬다.
server {
listen 443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# 최신 TLS 버전 사용
ssl_protocols TLSv1.2 TLSv1.3;
# 강력한 암호화 알고리즘 선택
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
# HSTS 설정
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
# 기타 보안 헤더
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;
add_header X-XSS-Protection "1; mode=block";
# CSP 설정
add_header Content-Security-Policy "default-src 'self';";
}운영 환경에서는 모든 웹 사이트에 HTTPS를 적용하고 HTTP 요청을 HTTPS로 자동 리디렉션하는 구성이 필요하다. TLS 1.2 이상을 사용하고, SSL 2.0/3.0 및 TLS 1.0/1.1처럼 취약한 버전은 비활성화한다. 암호화 스위트도 최신 방식을 선택하며 취약한 알고리즘은 제거한다.
인증서는 신뢰할 수 있는 CA에서 발급받고 유효기간과 자동 갱신 체계를 관리해야 한다. CSP와 HSTS 같은 보안 헤더를 적용하고 서버 정보 노출을 최소화하는 일도 함께 이어진다. 웹 보안 설정은 일회성 조치가 아니라, 새로운 취약점과 위협에 맞춰 정기적으로 갱신하고 점검할 대상이다.