HTTP와 HTTPS (HTTP and HTTPS)

HTTP(HyperText Transfer Protocol)는 웹에서 클라이언트와 서버가 요청과 응답을 주고받는 애플리케이션 계층 프로토콜이고, HTTPS(HTTP Secure)는 그 통신을 TLS(Transport Layer Security) 위에 얹어 암호화한 것이다. HTTPS는 통신 내용의 기밀성과 무결성을 보장하고 인증서로 서버의 신원을 검증하므로, 현대 웹에서는 사실상 모든 서비스가 HTTPS를 기본으로 사용한다. HTTP 자체도 1.1에서 2, 3으로 발전하며 성능 한계를 계속 개선해 왔다.

HTTP의 기본 성격

HTTP는 요청과 응답이 한 쌍을 이루는 단순한 구조를 가진다. 요청은 메서드(GET, POST, PUT, DELETE 등)와 경로, 헤더, 본문으로 구성되고, 응답은 상태 코드(2xx 성공, 3xx 리다이렉트, 4xx 클라이언트 오류, 5xx 서버 오류)와 헤더, 본문으로 구성된다. 클라이언트는 항상 요청을 시작하는 쪽이고 서버는 응답하는 쪽이라는 역할 구분이 명확하며, 서버가 먼저 말을 걸어야 하는 실시간 알림 같은 요구는 웹소켓(WebSocket)이나 SSE(Server-Sent Events) 같은 별도 메커니즘으로 보완한다. 중요한 특징은 무상태(stateless)라는 점이다. 서버는 이전 요청을 기억하지 않으므로, 로그인 상태 같은 문맥은 쿠키(cookie)와 세션, 토큰으로 클라이언트가 매 요청에 실어 보내야 한다. 이 무상태성 덕분에 어떤 서버가 요청을 받아도 무방해져 서버를 수평 확장하기 쉽다는 장점이 생기고, 같은 이유로 캐시와 중계도 단순해진다.

평문 HTTP의 문제와 HTTPS의 해법

평문 HTTP는 세 가지 위협에 노출된다. 첫째, 경로상의 누구나 내용을 읽을 수 있는 도청, 둘째, 내용을 몰래 바꾸는 변조, 셋째, 공격자가 진짜 서버인 척하는 위장이다. HTTPS는 TLS를 통해 이 세 가지를 각각 해결한다.

• 기밀성: 핸드셰이크로 합의한 대칭키(symmetric key)로 본문과 헤더 전체를 암호화한다.
• 무결성: 인증 태그가 포함된 AEAD(Authenticated Encryption with Associated Data) 방식으로 변조를 탐지한다.
• 인증: 인증 기관(CA, Certificate Authority)이 서명한 인증서를 검증해 서버가 해당 도메인의 정당한 주인임을 확인한다.

세 요소 중 인증이 특히 중요하다. 암호화가 아무리 강해도 대화 상대가 공격자라면 비밀번호와 카드 번호를 공격자에게 안전하게 전달하는 꼴이 되기 때문이다.

인증서는 신뢰 사슬로 검증된다. 브라우저에 내장된 루트 CA가 중간 CA를 서명하고, 중간 CA가 서버 인증서를 서명하는 구조이며, 이 사슬 어딘가가 끊기면 브라우저는 경고를 띄운다. Let's Encrypt 같은 무료 자동화 CA의 등장으로 HTTPS 적용 비용이 크게 낮아졌고, HSTS(HTTP Strict Transport Security) 헤더를 쓰면 브라우저가 이후 접속을 항상 HTTPS로 강제한다.

HTTPS 연결이 맺어지는 과정

1. 클라이언트가 DNS로 서버 IP를 얻는다.
2. TCP 3-way 핸드셰이크로 전송 계층 연결을 만든다(HTTP/3는 이 단계가 QUIC으로 대체된다).
3. TLS 핸드셰이크를 수행한다. TLS 1.3 기준으로 클라이언트가 지원 암호 목록과 키 교환 재료를 보내면, 서버가 선택 결과와 인증서, 자신의 키 재료를 돌려주고 양쪽이 같은 세션 키를 유도한다. 왕복 1회(1-RTT)면 충분하다.
4. 이후 모든 HTTP 요청과 응답이 세션 키로 암호화되어 오간다.

참고로 어떤 도메인에 접속하는지는 TLS 확장인 SNI(Server Name Indication)에 평문으로 실리는데, 이것까지 감추는 ECH(Encrypted Client Hello)가 표준화되어 배포가 진행되고 있다.