HTTP & HTTPS

HTTP(HyperText Transfer Protocol)

웹에서 클라이언트와 서버가 자원(resource)과 그 표현(representation)을 주고받기 위한 애플리케이션 계층 프로토콜이다.

HTTP는 버전에 따라 전송 방식이 다르다.

• HTTP/1.1: 텍스트 기반 메시지 형식
• HTTP/2: 바이너리 프레임 기반, 멀티플렉싱 지원
• HTTP/3: QUIC(UDP 기반) 위에서 동작

즉, HTTP = 텍스트 프로토콜이라고만 설명하면 현재 기준으로는 부정확하다. 텍스트 기반인 것은 주로 HTTP/1.1 메시지 형식이다.

HTTP 자체는 stateless한 요청/응답 프로토콜이며, 암호화는 HTTP의 본질이 아니라 그 아래 계층인 TLS가 담당한다.

HTTP를 그대로 사용할 때의 보안 문제

TLS 없이 HTTP를 사용하면 다음 문제가 생길 수 있다.

1. 도청

• 평문 전송이므로 중간에서 내용을 볼 수 있다.

2. 위장

• 서버가 진짜 대상 서버인지 검증할 수 없다.

3. 변조

• 전송 중 데이터가 바뀌어도 이를 안전하게 검증하기 어렵다.

HTTPS(HyperText Transfer Protocol Secure)

HTTPS = HTTP over TLS 이다.

• 예전의 SSL은 더 이상 현대 웹에서 권장되지 않는다.
• 현재는 주로 TLS 1.2 또는 TLS 1.3을 사용한다.
• TLS 1.0과 TLS 1.1은 폐기(deprecated)되었다.

HTTPS는 "텍스트만 암호화"하는 것이 아니라, HTTP 메시지와 본문을 포함한 전송 데이터 전체를 TLS로 보호한다.

HTTPS가 제공하는 핵심은 다음과 같다.

• 기밀성(Confidentiality): 내용을 엿보기 어렵게 함
• 무결성(Integrity): 중간 변조를 탐지할 수 있게 함
• 인증(Authentication): 서버가 신뢰 가능한 인증서 체인을 제시했는지 검증

필요한 경우에는 클라이언트 인증서 기반 mTLS로 상호 인증도 할 수 있다.

HTTPS 통신 흐름

1. 서버는 자신의 공개키에 대한 소유권을 증명할 수 있도록 인증서 체인을 준비한다.

2. 클라이언트가 HTTPS 연결을 시작하면 TLS 핸드셰이크가 먼저 수행된다.

3. 서버는 자신의 인증서를 보낸다.

4. 클라이언트는 브라우저/OS의 신뢰 저장소에 있는 CA 공개키들로 인증서 체인을 검증한다.

   • 올바른 CA가 서명했는지
   • 인증서가 만료되지 않았는지
   • 접속한 도메인 이름과 인증서의 이름이 일치하는지

5. 현대 TLS(특히 TLS 1.3)에서는 보통 (EC)DHE 기반 키 교환으로 양측이 공유 비밀을 만든다.

6. 이 공유 비밀로부터 대칭키들을 파생하고, 이후 실제 HTTP 데이터는 대칭키(AES-GCM, ChaCha20-Poly1305 등)로 보호한다.

7. 세션이 종료되면 해당 연결에 사용한 트래픽 키도 더 이상 사용하지 않는다.

중요한 점은, 현대 TLS에서 서버 인증서의 공개키는 주로 서버 신원 증명에 사용되고, 예전처럼 pre-master secret을 RSA로 직접 암호화해 전달하는 방식은 TLS 1.3에서 제거되었다는 것이다.

HTTPS도 만능은 아니다

HTTPS를 써도 다음 문제는 별개다.

• 서버 자체가 침해된 경우
• 애플리케이션 취약점(XSS, SQL Injection 등)
• 잘못 발급되었거나 신뢰할 수 없는 인증서
• 사용자가 경고를 무시하고 자체 서명 인증서를 수락한 경우
• 콘텐츠 일부가 여전히 HTTP로 로드되는 mixed content

참고사항

• RFC 9110, RFC 9112, RFC 9113, RFC 9114
• RFC 8446, RFC 8996