📎

HTTPS와 HSTS 핵심 이해

notion image

1. HTTPS 기본 원리

HTTP의 보안 한계와 HTTPS 필요성

HTTP는 웹의 기본 통신 프로토콜이지만 평문(암호화되지 않은 텍스트) 형태로 데이터를 전송하기 때문에 다음과 같은 치명적인 보안 문제를 가지고 있습니다.
  • 도청 위험: 데이터가 암호화 없이 전송되므로 네트워크 상에서 누구나 내용을 쉽게 가로채고 읽을 수 있습니다.
  • 변조 가능성: 전송 중인 데이터의 무결성을 검증할 방법이 없어 중간에서 내용을 변경해도 수신자가 알 수 없습니다.
  • 인증 부재: 통신하는 상대방이 진짜 해당 서버인지 확인할 수 있는 메커니즘이 없어 위장 공격에 취약합니다.
HTTPS는 이러한 문제를 해결하기 위해 HTTP에 TLS/SSL이라는 보안 계층을 추가한 프로토콜입니다. 이를 통해 다음 세 가지 핵심 보안 요소를 제공합니다.
  • 기밀성(Confidentiality): 데이터를 암호화하여 제3자의 도청을 방지합니다.
  • 무결성(Integrity): 전송 중 데이터 변조를 감지할 수 있는 메커니즘을 제공합니다.
  • 인증(Authentication): 디지털 인증서를 통해 서버의 신원을 확인할 수 있게 합니다.

SSL과 TLS의 이해

SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)는 인터넷 통신을 안전하게 만드는 암호화 프로토콜로, 웹 브라우저와 서버 간의 안전한 통신을 보장합니다.
SSL/TLS 발전 과정
  • SSL: 1995년 Netscape에서 개발한 최초의 웹 보안 프로토콜입니다. 현재는 모든 버전이 심각한 보안 취약점으로 인해 사용이 중단되었습니다.
    • SSL 2.0: 처음 공개된 버전이지만 심각한 보안 문제가 발견되었습니다.
    • SSL 3.0: 개선된 버전이나 2014년 POODLE 취약점 발견으로 사용 중단되었습니다.
  • TLS: SSL의 후속 버전으로, 인터넷 표준화 기구인 IETF에서 관리합니다.
    • TLS 1.0과 1.1: 현재는 취약점으로 인해 사용이 권장되지 않습니다.
    • TLS 1.2와 1.3: 현재 안전하게 사용할 수 있는 버전으로, 대부분의 현대 웹사이트에서 사용합니다.
실무에서는 여전히 "SSL" 또는 "SSL/TLS"라는 용어를 자주 사용하지만, 기술적으로는 대부분 TLS 프로토콜을 사용하고 있다는 점을 이해하는 것이 중요합니다.
TLS 주요 기능
  • 서버와 클라이언트 간의 상호 인증(필요에 따라)
  • 안전한 키 교환 메커니즘을 통한 비밀키 공유
  • 대칭키 암호화를 통한 데이터 기밀성 보장
  • 메시지 인증 코드(MAC)를 통한 데이터 무결성 보장

TLS/SSL 작동 원리

HTTPS 연결 과정
다음 다이어그램은 브라우저(클라이언트)와 웹 서버 간의 HTTPS 연결이 어떻게 수립되는지 보여줍니다:
Client                                 Server
------                                 ------
   |                                      |
   |  1. Connection Start (Client Hello)  |
   |------------------------------------->|
   |                                      |
   |  2. Server Response (Server Hello    |
   |     + Certificate)                   |
   |<-------------------------------------|
   |                                      |
   |  3. Client: Verify Certificate       |
   |     (Check Root CA List)             |
   |                                      |
   |  4. Generate Symmetric Key           |
   |     Encrypt with Server's Public Key |
   |------------------------------------->|
   |                                      |
   |  5. Server: Decrypt with Private Key |
   |     Obtain Symmetric Key             |
   |                                      |
   |  6. All further communication        |
   |     encrypted with Symmetric Key     |
   |<====================================>|
   |                                      |
HTTPS는 성능과 보안을 모두 확보하기 위해 두 가지 암호화 방식을 효율적으로 조합하여 사용합니다.
  1. 비대칭 암호화(공개키 암호화)
      • 공개키와 개인키로 구성된 키 쌍을 사용합니다.
      • 공개키로 암호화한 데이터는 오직 개인키로만 복호화할 수 있습니다.
      • 개인키로 암호화(서명)한 데이터는 공개키로 검증할 수 있습니다.
      • 계산 비용이 높아 초기 인증과 대칭키 교환 단계에만 주로 사용됩니다.
  1. 대칭 암호화
      • 송신자와 수신자가 동일한 비밀키를 공유하여 사용합니다.
      • 암호화와 복호화에 같은 키를 사용하므로 속도가 빠릅니다.
      • 비대칭 암호화보다 효율적이어서 실제 데이터 통신 암호화에 사용됩니다.
      • 핵심 과제는 안전하게 키를 교환하는 것이며, 이를 위해 초기에 비대칭 암호화를 활용합니다.
연결 과정에서 클라이언트(브라우저)는 서버의 인증서를 검증하고, 안전하게 대칭키를 교환한 후 이 키로 모든 후속 통신을 암호화합니다. 이러한 방식으로 HTTPS는 효율성과 보안성을 모두 확보합니다.

인증서 체계

X.509 인증서
  • X.509는 PKI(공개키 기반구조)에서 사용하는 표준 디지털 인증서 형식입니다.
  • 인증서에는 도메인 소유자 정보, 공개키, 발급 기관 정보, 유효기간, 디지털 서명 등 중요한 정보가 포함됩니다.
  • 인증서의 디지털 서명을 통해 해당 인증서가 신뢰할 수 있는 인증 기관(CA)에 의해 발급되었음을 검증할 수 있습니다.
루트 CA(인증 기관)와 신뢰 체인
  • 루트 CA는 웹 보안의 신뢰 기반으로 작동하는 최상위 인증 기관입니다.
  • 모든 브라우저와 운영체제에는 신뢰할 수 있는 루트 CA 목록이 내장되어 있습니다.
  • 웹사이트 방문 시 브라우저는 서버가 제시한 인증서가 이 신뢰할 수 있는 CA에 의해 발급되었는지 확인합니다.
  • 대부분의 서버 인증서는 "중간 CA"에 의해 발급되며, 이 중간 CA는 루트 CA에 의해 인증됩니다.
  • 이러한 "인증서 체인"을 통해 브라우저는 최종적으로 루트 CA까지 신뢰를 확인합니다.

2. HTTPS 실용 구현

웹 서버 HTTPS 설정

주요 웹 서버 소프트웨어
Nginx(엔진엑스)
  • 높은 성능을 제공하는 경량 웹 서버로, 비동기 이벤트 기반 아키텍처를 사용합니다.
  • 동시 연결 처리 능력이 뛰어나 고부하 웹사이트에 적합합니다.
  • 리버스 프록시, 로드 밸런싱 기능이 강점이며 설정이 비교적 간결합니다.
  • 메모리 사용량이 적고 정적 콘텐츠 전송 속도가 빠른 특징이 있습니다.
Apache HTTP Server
  • 가장 오래되고 널리 사용되는 웹 서버로, 다양한 환경에서 검증된 안정성을 제공합니다.
  • 풍부한 모듈 시스템을 통해 다양한 기능을 확장할 수 있습니다.
  • .htaccess 파일을 통해 디렉토리별로 세부 설정이 가능한 유연성이 특징입니다.
  • 다양한 멀티프로세싱 모듈(MPM)로 서버 리소스 사용을 최적화할 수 있습니다.
인증서 발급 과정
  1. 개인키와 CSR(인증서 서명 요청)을 생성합니다. CSR에는 도메인 정보와 공개키가 포함됩니다.
  1. 생성한 CSR을 인증 기관에 제출하고 도메인 소유권 검증 과정을 거칩니다.
  1. 검증 완료 후 CA가 서명한 인증서를 발급받아 서버에 설치합니다.
기본 HTTPS 설정 예시
Nginx 설정 예시:
server {
    listen 443 ssl;
    server_name example.com;

    # 인증서 파일 경로 지정
    ssl_certificate /path/to/certificate.crt;
    ssl_certificate_key /path/to/private.key;

    # 보안 강화 설정
    ssl_protocols TLSv1.2 TLSv1.3;  # 안전한 TLS 버전만 허용
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA384;  # 강력한 암호화 알고리즘 사용

    # HTTP/2 활성화로 성능 향상
    http2 on;
}
이 설정은 안전한 TLS 버전, 강력한 암호화 알고리즘, HTTP/2 지원을 통해 보안과 성능을 모두 확보하는 HTTPS 서버를 구성합니다.

Let's Encrypt 활용

Let's Encrypt 소개
  • Let's Encrypt는 2016년 시작된 비영리 인증 기관으로, 누구나 무료로 SSL/TLS 인증서를 발급받을 수 있게 해줍니다.
  • 자동화된 인증서 발급 및 갱신 프로세스를 제공하여 관리 부담을 크게 줄여줍니다.
  • ACME(Automated Certificate Management Environment) 프로토콜을 사용하여 인증서 발급을 자동화합니다.
  • 90일 유효기간을 두어 정기적 갱신을 유도함으로써 보안을 강화합니다.
인증서 발급 및 자동 갱신 방법
# Certbot 설치 (Ubuntu/Debian 기준)
apt-get install certbot

# Nginx 서버용 인증서 발급
certbot --nginx -d example.com

# Apache 서버용 인증서 발급
certbot --apache -d example.com

# 자동 갱신 설정 (crontab에 추가)
0 3 * * * certbot renew --quiet
Certbot은 Let's Encrypt 인증서를 쉽게 발급받고 관리할 수 있는 도구로, 웹 서버 설정을 자동으로 수정하여 HTTPS를 활성화해줍니다. 90일마다 갱신이 필요하므로 자동 갱신 설정이 중요합니다.

3. HSTS 핵심 이해

HSTS 목적과 작동 방식

  • HSTS(HTTP Strict Transport Security)는 웹사이트가 HTTPS로만 접속되어야 함을 브라우저에 강제하는 보안 메커니즘입니다. HTTPS 연결이 수립된 후 서버가 특별한 헤더를 통해 브라우저에게 지시합니다.
주요 목적
  • SSL 스트리핑 공격 방지: 중간자가 HTTPS 리다이렉트를 가로채 HTTP 통신을 유도하는 공격을 차단합니다.
  • 초기 HTTP 요청의 취약점 해소: 일반적인 HTTPS 리다이렉트는 첫 HTTP 요청이 노출되는 문제가 있으나, HSTS는 이를 해결합니다.
  • 사용자의 실수 방지: 사용자가 실수로 HTTP URL을 입력해도 브라우저가 자동으로 HTTPS로 변환합니다.
작동 방식
  1. 서버는 HTTPS 응답 헤더에 Strict-Transport-Security 헤더를 포함시켜 전송합니다.
  1. 이 헤더를 받은 브라우저는 지정된 기간 동안 해당 도메인에 대한 모든 요청을 내부적으로 HTTPS로 자동 변환합니다.
  1. 중요한 점은 브라우저가 서버에 요청을 보내기 전에 HTTP를 HTTPS로 변환하므로, 네트워크 상에 HTTP 요청이 전혀 노출되지 않습니다.
  1. 사용자가 주소창에 명시적으로 http://를 입력해도 브라우저는 자동으로 https://로 변환하여 연결을 시도합니다.
헤더 구성 요소
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  • max-age: HSTS 정책을 브라우저가 기억해야 하는 시간(초)입니다. 보통 1년(31536000초)을 권장하며, 이 기간 동안 브라우저는 해당 도메인에 HTTPS로만 접속합니다.
  • includeSubDomains: 이 옵션이 포함되면 모든 서브도메인(*.example.com)에도 HSTS가 적용됩니다. 모든 서브도메인에 HTTPS가 설정되어 있어야 안전하게 사용할 수 있습니다.
  • preload: 브라우저 내장 HSTS 목록에 등록하기 위한 표시입니다. 이 옵션만으로는 등록되지 않으며, 별도로 hstspreload.org에 등록 절차가 필요합니다.

4. HSTS preload 심층 분석

preload 목록 작동 방식

HSTS preload는 브라우저에 사전 내장된 도메인 목록으로, 사이트 첫 방문부터 HTTPS 강제 적용이 가능한 강력한 보안 메커니즘입니다.
작동 원리
  • Google의 Chromium 프로젝트에서 관리하는 중앙 집중식 목록을 Chrome, Firefox, Safari, Edge 등 주요 브라우저들이 공유합니다.
  • 브라우저 업데이트 시 이 목록이 브라우저 코드에 내장되어 배포됩니다.
  • 사용자가 목록에 있는 도메인을 방문할 때, 브라우저는 요청을 네트워크로 보내기 전에 내부적으로 HTTP URL을 HTTPS로 변환합니다.
  • 이 방식으로 첫 방문부터 SSL 스트리핑 공격에 대한 노출이 원천 차단됩니다.
등록 요건
  • 유효한 SSL/TLS 인증서를 보유해야 합니다(신뢰할 수 있는 CA에서 발급).
  • 모든 HTTP 트래픽을 HTTPS로 리다이렉트해야 합니다.
  • 모든 서브도메인에 HTTPS가 설정되어 있어야 합니다(includeSubDomains 지원).
  • HSTS 헤더의 max-age 값이 최소 1년(31536000초) 이상이어야 합니다.
  • HSTS 헤더에 preload 지시자가 포함되어 있어야 합니다.
주의사항
  • 등록 후 제거 과정이 매우 복잡하고 시간이 오래 걸립니다(모든 브라우저 버전 업데이트 필요).
  • 모든 서브도메인이 영향을 받으므로, 모든 서브도메인에서 HTTPS 지원이 확실해야 합니다.
  • 적용 전 철저한 테스트가 필요하며, 미준비 상태에서 등록 시 사이트 접근성 문제가 발생할 수 있습니다.
  • 단계적 접근이 권장되며, 짧은 max-age로 시작해 문제가 없을 때 점진적으로 기간을 늘리는 것이 안전합니다.

5. 보안 위협 대응

SSL 스트리핑 공격과 방어

SSL 스트리핑 공격(SSL Stripping)
  • 중간자 공격의 일종으로, 사용자의 HTTPS 연결을 HTTP로 다운그레이드하여 암호화되지 않은 통신을 유도하는 공격입니다.
  • 공격자는 사용자와 서버 사이에 위치하여 서버의 HTTPS 리다이렉트 응답을 가로채고 변조합니다.
  • 사용자는 HTTP 웹사이트로 접속하게 되어 공격자에게 민감한 정보가 노출될 수 있습니다.
  • 공격 과정: 1) 사용자의 HTTP 요청 가로채기 → 2) 서버의 HTTPS 리다이렉트 차단 → 3) 서버와는 HTTPS 연결 유지하면서 사용자에게는 HTTP 콘텐츠 제공
HSTS 방어 메커니즘
  • HSTS가 적용된 사이트에서는 브라우저가 HTTP 요청을 보내기 전에 내부적으로 HTTPS로 변환합니다.
  • 이로 인해 중간자가 HTTP 요청을 가로챌 기회 자체가 없어집니다.
  • preload 목록을 활용하면 첫 방문부터 이러한 보호가 적용되어 SSL 스트리핑 공격 위험을 원천 차단할 수 있습니다.

최신 브라우저의 HTTP 제한

브라우저별 HTTP 제한 정책
최신 브라우저들은 보안 강화를 위해 HTTP 사이트에 대한 제한을 점진적으로 늘리고 있습니다.
  • Chrome/Firefox/Safari/Edge: 모든 HTTP 사이트에 "안전하지 않음(Not Secure)" 경고를 표시하고, HTTPS 연결을 우선시하며, HTTP 페이지 내의 HTTPS 리소스 로딩(혼합 콘텐츠)을 차단합니다.
  • Firefox는 HTTPS-Only 모드를 제공하여 활성화 시 모든 사이트를 HTTPS로만 접속 시도합니다.
  • 브라우저들은 점점 더 많은 민감한 기능을 HTTPS에서만 사용 가능하도록 제한하고 있습니다.
브라우저 기능 제한 현대 웹 개발에서 다음과 같은 주요 API와 기능들은 HTTPS 환경에서만 작동합니다.
  • Service Workers: 오프라인 기능, 푸시 알림 등을 위한 핵심 기술
  • 웹 푸시 알림: 사용자에게 알림을 보내는 기능
  • 지오로케이션 API: 사용자의 위치 정보 접근
  • 카메라/마이크 접근: 미디어 장치 사용 권한
  • 웹 인증(WebAuthn): 생체 인식 등 고급 인증 방식
  • 결제 요청 API: 온라인 결제 처리
보안 강화를 위한 추가 헤더 HTTPS와 함께 다음과 같은 보안 헤더를 적용하면 웹사이트 보안을 더욱 강화할 수 있습니다.
Content-Security-Policy: upgrade-insecure-requests;  # HTTP 요청을 HTTPS로 업그레이드
X-Content-Type-Options: nosniff  # MIME 타입 스니핑 방지
Referrer-Policy: strict-origin-when-cross-origin  # 리퍼러 정보 제한

6. 현대 웹 호스팅과 HTTPS

클라우드 호스팅의 보안 접근 방식

주요 클라우드 호스팅 서비스 보안 기능 현대적인 클라우드 웹 호스팅 서비스들은 개발자에게 다음과 같은 보안 기능을 기본 제공합니다.
  • 자동화된 HTTPS 설정 및 인증서 관리(Let's Encrypt 통합)
  • 기본적인 보안 헤더 자동 적용
  • 네트워크 수준에서 HTTP→HTTPS 자동 리다이렉트
  • WAF(웹 애플리케이션 방화벽), DDoS 방어 등 통합 보안 솔루션
  • 간편한 설정 인터페이스로 추가 보안 옵션 활성화 가능
HTTP 제한 정책의 이점 현대 웹 호스팅 서비스의 네트워크 레벨 HTTP 제한은 HSTS에 비해 다음과 같은 이점이 있습니다.
  • 사이트 첫 방문부터 즉시 적용되어 HSTS의 첫 방문 취약점 문제가 없습니다.
  • 개발자 대시보드에서 간단히 설정할 수 있어 관리가 용이합니다.
  • WAF, 봇 방어, 지역 차단 등 여러 보안 기능과 통합되어 다중 보안 계층을 제공합니다.
  • 프론트엔드/백엔드 기술과 독립적으로 적용되어 코드 변경 없이 보안을 강화할 수 있습니다.

HTTPS와 HSTS 핵심 요약

1. 전통적 웹 서버와 최신 호스팅 비교

전통적 웹 서버(Apache, Nginx 등)
  • HTTP와 HTTPS 프로토콜을 모두 지원하므로 적절한 보안 설정이 필수적입니다.
  • HSTS는 사용자를 HTTPS로 강제 리다이렉트하는 필수적인 보안 메커니즘입니다.
  • 서버 설정 파일을 통한 수동 보안 구성이 필요하며, 실수 가능성이 있습니다.
최신 클라우드 호스팅(Vercel, Netlify, Cloudflare Pages 등)
  • 기본적으로 HTTPS를 지원하고 HTTP 요청을 자동으로 HTTPS로 리다이렉트합니다.
  • 플랫폼 레벨에서 여러 보안 기능을 기본 제공하여 개발자의 부담을 덜어줍니다.
  • HSTS는 추가적인 보안 계층 역할을 하며, 첫 방문 보호를 위한 preload 옵션과 함께 사용됩니다.

2. SSL 스트리핑 대응 방식

전통적 환경
  • HSTS가 SSL 스트리핑 공격에 대한 주요 방어책이지만, 첫 방문 시에는 여전히 취약점이 존재합니다.
  • preload 목록 등록을 통해 이 취약점을 보완할 수 있습니다.
최신 호스팅 환경
  • 네트워크 레벨 보안, WAF, HSTS의 다중 보호 계층을 통해 보안을 강화합니다.
  • 글로벌 CDN 및 에지 네트워크를 통해 기본적인 공격을 효과적으로 차단합니다.
  • 자동화된 보안 설정으로 인적 오류 가능성을 최소화합니다.

3. 브라우저 진화와 HTTP 제한

  • 최신 브라우저들은 HTTP 사이트에 경고 표시, 기능 제한 등을 통해 HTTPS 사용을 강력히 권장합니다.
  • HTTPS-Only 모드 등 브라우저 자체적인 보호 기능이 증가하고 있습니다.
  • 지오로케이션, 웹 푸시, 카메라 접근 등 주요 웹 API는 HTTPS 환경에서만 작동합니다.
  • 사용자 개인정보 보호 강화 추세와 함께 웹 보안의 중요성도 계속 증가하고 있습니다.