# [[HTTPS]] (Hypertext Transfer Protocol Secure)

## 1. 개요
**HTTPS(Hypertext Transfer Protocol Secure)**는 웹 브라우저와 웹 서버 간에 주고받는 데이터를 암호화하여 전송하는 보안 프로토콜로, 기존의 [[HTTP]](Hypertext Transfer Protocol)에 [[SSL/TLS]](Secure Sockets Layer / Transport Layer Security) 프로토콜을 결합한 형태이다.

HTTP는 데이터를 평문(Plaintext)으로 전송하기 때문에 네트워크 경로 상에서 데이터가 가로채질 경우 아이디, 비밀번호, 신용카드 정보 등이 그대로 노출되는 취약점이 있다. HTTPS는 이를 해결하기 위해 전송 계층에서 암호화를 수행함으로써 데이터의 기밀성을 보장하고, 서버의 신원을 확인하여 피싱 사이트 등의 위협으로부터 사용자를 보호한다.

## 2. 동작 원리
HTTPS는 전송 계층(Transport Layer)과 응용 계층(Application Layer) 사이에서 SSL/TLS 프로토콜을 통해 데이터를 암호화한다. 효율적인 통신을 위해 **[[공개키 암호화]]**와 **대칭키 암호화** 방식을 혼합하여 사용한다.

*   **공개키 암호화(Public Key Encryption):** 누구나 알 수 있는 공개키와 소유자만 가진 개인키를 사용하는 방식이다. 보안성은 높지만 연산 속도가 느려, 주로 초기 연결 단계에서 '대칭키'를 안전하게 공유하기 위해 사용된다.
*   **대칭키 암호화(Symmetric Key Encryption):** 암호화와 복호화에 동일한 키를 사용하는 방식이다. 연산 속도가 매우 빠르며, 실제 데이터 전송 단계에서 사용된다.

### [표] HTTP vs HTTPS 비교
| 구분 | HTTP | HTTPS |
| :--- | :--- | :--- |
| **전송 방식** | 평문 전송 (Plaintext) | 암호화 전송 (Encrypted) |
| **기본 포트** | 80번 포트 | 443번 포트 |
| **보안성** | 낮음 (스니핑, 변조에 취약) | 높음 (기밀성, 무결성, 인증 제공) |
| **인증서** | 필요 없음 | SSL/TLS 인증서 필요 |
| **속도** | 상대적으로 빠름 | 암호화 과정으로 인해 약간의 오버헤드 발생 |

## 3. SSL/TLS 핸드쉐이크 (Handshake)
클라이언트(브라우저)와 서버가 보안 연결을 설정하기 위해 수행하는 일련의 과정을 **핸드쉐이크**라고 한다.

### 핸드쉐이크 흐름도
```mermaid
sequenceDiagram
    participant Client as 클라이언트 (브라우저)
    participant Server as 서버
    
    Client->>Server: [1] Client Hello (지원 버전, Cipher Suite, Client Random)
    Server->>Client: [2] Server Hello (선택 버전, Cipher Suite, Server Random, 인증서)
    Note over Client: [3] 인증서 검증 (CA 확인)
    Client->>Server: [4] Pre-Master Secret (서버 공개키로 암호화)
    Note over Client, Server: [5] 세션 키(대칭키) 생성
    Client->>Server: [6] 암호화 통신 시작 (세션 키 사용)
```

### 상세 단계 (TLS 1.2 기준)
1.  **Client Hello:** 클라이언트가 서버에 접속하며 지원 가능한 TLS 버전, **Cipher Suite**(암호화 알고리즘 세트), 무작위 수(Client Random)를 보낸다.
2.  **Server Hello:** 서버가 사용할 TLS 버전과 암호화 방식을 선택하고, 자신의 **SSL 인증서**와 무작위 수(Server Random)를 보낸다.
3.  **인증서 검증:** 클라이언트는 브라우저에 내장된 CA(인증 기관) 리스트를 통해 서버 인증서의 유효성을 검증한다.
4.  **Pre-Master Secret 생성:** 검증이 완료되면 클라이언트는 새로운 무작위 수(Pre-Master Secret)를 생성하여 서버의 공개키로 암호화해 전송한다.
5.  **세션 키(Session Key) 생성:** 서버는 자신의 개인키로 이를 복호화하고, 양측은 공유된 무작위 수들을 조합하여 동일한 **대칭키(세션 키)**를 생성한다.
6.  **암호화 통신 시작:** 이후 모든 데이터는 생성된 세션 키를 통해 대칭키 방식으로 암호화되어 전송된다.

> **참고: TLS 1.3의 변화**
> 위 과정은 TLS 1.2 기준이며, 최신 표준인 **TLS 1.3**에서는 핸드쉐이크 과정이 획기적으로 간소화되었다. 기존 2-RTT(Round Trip Time)에서 **1-RTT**로 단계가 줄어들어 연결 속도가 향상되었으며, 보안성이 낮은 오래된 암호화 알고리즘들이 제거되었다.

## 4. 인증서와 CA (Certificate Authority)
### 디지털 인증서의 역할
인증서는 해당 서버가 신뢰할 수 있는 서버임을 증명하는 '디지털 신분증'이다. 여기에는 서버의 공개키, 도메인 정보, 인증서 만료일, 발급 기관의 디지털 서명이 포함되어 있다.

### CA (인증 기관)와 검증 프로세스
**CA(Certificate Authority)**는 인증서의 신뢰성을 보증하는 제3의 공인 기관이다.
*   **발급 과정:** 서버 운영자가 CSR(Certificate Signing Request, 인증서 서명 요청)을 CA에 제출 $\rightarrow$ CA가 도메인 소유권 및 신원 확인 $\rightarrow$ CA의 개인키로 서명된 인증서 발급.
*   **체인 인증서(Certificate Chain):** 루트 CA가 모든 인증서에 직접 서명하는 것은 위험하므로, 중간 CA(Intermediate CA)를 두어 계층 구조로 신뢰를 전달하는 방식이다.

## 5. TLS 버전별 차이 및 취약점
TLS는 보안 취약점이 발견됨에 따라 지속적으로 업데이트되었다. 현재 SSL 2.0/3.0 및 TLS 1.0/1.1은 보안 취약점으로 인해 사용이 권장되지 않는다.

### [표] TLS 버전별 비교
| 버전 | 상태 | 주요 특징 및 취약점 | 비고 |
| :--- | :--- | :--- | :--- |
| **SSL 2.0/3.0** | 사용 중단 | POODLE 공격 등 심각한 취약점 존재 | 사용 금지 |
| **TLS 1.0/1.1** | 사용 중단 | BEAST, LUCKY13 공격에 취약 | 대부분의 브라우저 지원 중단 |
| **TLS 1.2** | 널리 사용 | AES-GCM 등 현대적 암호화 도입, 가장 범용적 | 현재 표준 |
| **TLS 1.3** | 최신 표준 | 핸드쉐이크 단계 축소(속도 향상), 취약한 암호화 알고리즘 제거 | 보안성 및 성능 최적화 |

## 6. HTTPS 도입의 이점 및 영향
1.  **데이터 기밀성 및 무결성:** 중간자 공격(MITM)을 통해 데이터를 훔쳐보거나 내용을 변조하는 것을 방지한다.
2.  **피싱 방지:** 인증서를 통해 접속한 사이트가 실제 운영자가 운영하는 사이트임을 보장한다.
3.  **SEO(검색 엔진 최적화) 가산점:** 구글 등 주요 검색 엔진은 HTTPS 적용 여부를 검색 순위 결정 요소(Ranking Signal)로 활용한다. 따라서 HTTPS를 적용한 사이트는 검색 결과 상단에 노출될 가능성이 높아져 유입량 증대에 긍정적인 영향을 미친다.
4.  **최신 웹 기술 활용:** HTTP/2, Service Worker, Geolocation API 등 최신 브라우저 기능은 보안 연결(Secure Context)에서만 작동한다.

### 혼합 콘텐츠 (Mixed Content)
HTTPS를 도입하더라도 페이지 내의 이미지, 스크립트, 스타일시트 등이 `http://` 경로로 호출될 때 **혼합 콘텐츠(Mixed Content)** 문제가 발생한다. 이 경우 브라우저는 '주의 요함' 경고를 표시하거나 보안을 위해 해당 리소스의 로딩을 차단하며, 이는 사이트의 신뢰도를 떨어뜨리고 보안 취약점을 만들 수 있으므로 모든 리소스를 HTTPS 경로로 변경해야 한다.

## 7. HSTS (HTTP Strict Transport Security)
**HSTS**는 브라우저가 특정 사이트에 접속할 때, HTTP 요청을 자동으로 HTTPS로 강제 전환하도록 지시하는 보안 메커니즘이다.

*   **필요성:** 사용자가 주소창에 `http://`로 입력하거나 링크를 클릭했을 때, 서버로 HTTP 요청이 먼저 가고 서버가 HTTPS로 리다이렉트(301 Redirect)하는 찰나의 순간에 공격자가 개입하는 **SSL Stripping**(HTTPS 연결을 강제로 HTTP로 다운그레이드하는 공격)을 방지하기 위함이다.
*   **작동 방식:** 서버가 응답 헤더에 `Strict-Transport-Security`를 포함해 보내면, 브라우저는 지정된 기간(max-age) 동안 해당 도메인에 대해 모든 HTTP 요청을 내부적으로 HTTPS로 변경하여 전송한다.

## 8. 설정 및 구현 예시
### 무료 인증서 발급 (Let's Encrypt)
**Let's Encrypt**는 ACME 프로토콜을 통해 무료로 SSL/TLS 인증서를 발급하고 자동 갱신을 지원하는 비영리 기관이다. 과거에는 유료 인증서가 주를 이루었으나, Let's Encrypt의 등장으로 웹 전반의 HTTPS 보급률이 급격히 상승했다. `certbot` 도구를 사용하여 쉽게 적용할 수 있다.

```bash
# Ubuntu 기준 Certbot 설치 및 인증서 발급 예시
sudo apt update
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com
```

### 서버 설정 예시 ([[Nginx]])
인증서 파일(`.crt`)과 개인키 파일(`.key`)을 적용하고 HSTS를 설정하는 Nginx 설정 샘플이다.

```nginx
server {
    listen 80;
    server_name example.com;
    # 모든 HTTP 요청을 HTTPS로 리다이렉트
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com;

    # SSL 인증서 경로 설정
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # 보안 프로토콜 설정 (TLS 1.2, 1.3만 허용)
    ssl_protocols TLSv1.2 TLSv1.3;
    
    # 취약한 암호화 알고리즘을 제외하고 높은 보안 수준의 사이퍼 스위트만 허용
    ssl_ciphers HIGH:!aNULL:!MD5;

    # HSTS 설정: 1년(31536000초) 동안 HTTPS 강제 적용
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    location / {
        root /var/www/html;
        index index.html;
    }
}
```

## 9. 용어 정리
*   **Cipher Suite:** 암호화 알고리즘, 키 교환 알고리즘, 해시 알고리즘의 조합 세트.
*   **1-RTT (Round Trip Time):** 클라이언트와 서버 간에 메시지가 한 번 왕복하는 시간.
*   **SSL Stripping:** HTTPS 연결을 가로채어 HTTP로 강제 전환시켜 데이터를 평문으로 탈취하는 공격 기법.
*   **MITM (Man-in-the-Middle Attack):** 중간자 공격. 통신하는 두 당사자 사이에 공격자가 끼어들어 데이터를 도청하거나 조작하는 공격.

---
**마치며**
HTTPS는 이제 선택이 아닌 웹 서비스의 필수 표준이 되었다. 단순한 데이터 암호화를 넘어 사용자 신뢰 구축, 검색 엔진 최적화, 그리고 최신 웹 API 활용을 위한 기반이 되기 때문이다. 서버 운영자는 최신 TLS 버전을 유지하고 HSTS와 같은 추가 보안 설정을 통해 더욱 안전한 웹 환경을 구축해야 한다.