HTTPS

HTTP는 내용이 평문으로 전송됩니다. 같은 Wi-Fi에 연결된 사람, 네트워크 경로 중간의 ISP, 또는 악의적인 공유기 운영자는 HTTP 트래픽을 들여다볼 수 있습니다. 로그인 비밀번호, 세션 쿠키, 개인정보, 카드 번호가 모두 그대로 흘러갑니다. 중간자 공격에서는 응답을 가로채 내용을 바꾼 뒤 사용자에게 전달하는 것도 가능합니다. 사용자는 자신이 접속한 서버가 진짜 서버인지조차 확인할 방법이 없습니다.

초기 웹은 연구자 간의 문서 공유가 목적이었기 때문에 HTTP는 인증이나 암호화를 고려하지 않고 설계됐습니다. 1990년대 초 전자상거래가 등장하면서 신용카드 정보를 안전하게 전송해야 하는 요구가 생겼고, 넷스케이프가 SSL을 개발해 HTTP에 얹는 방식으로 HTTPS가 탄생했습니다. 초기에는 암호화 연산 비용이 커서 결제나 로그인 같은 민감한 페이지에만 적용하는 것이 일반적이었습니다. 하지만 하드웨어 성능이 높아지고 TLS 1.3이 핸드셰이크를 단순화하면서 오버헤드가 크게 줄었고, 오늘날 브라우저는 HTTP 사이트에 '주의 요함' 경고를 표시하며 HTTPS를 사실상 기본값으로 강제합니다.

HTTPS 연결은 먼저 TCP로 소켓을 연 다음 TLS 핸드셰이크를 수행합니다. 핸드셰이크는 크게 다섯 단계입니다. ① ClientHello: 클라이언트가 지원하는 TLS 버전과 암호 방식 목록을 서버에 전달합니다. ② ServerHello: 서버가 사용할 암호 방식을 골라 알리고, CA(인증기관)가 서명한 인증서를 보냅니다. ③ Certificate 검증: 클라이언트는 인증서가 신뢰할 수 있는 CA에서 발급됐는지, 도메인이 일치하는지 확인합니다. ④ Key Exchange: 클라이언트와 서버가 세션 키를 협상합니다. TLS 1.3에서는 Diffie-Hellman 기반으로 서버의 개인키가 노출되지 않아도 세션 키를 만들 수 있습니다. ⑤ Finished: 이후 모든 HTTP 트래픽은 협상된 대칭키로 암호화해 주고받습니다. 핵심은 인증서 검증으로 '이 서버가 진짜인가'를 확인하고, 키 교환으로 '중간에 아무도 못 읽는 채널'을 만드는 두 가지입니다.

HTTPS와 HTTP의 차이는 암호화 유무만이 아닙니다. HTTPS는 CA 인증서로 서버 신원을 검증하기 때문에 중간자가 서버인 척 응답을 가로채는 공격도 막습니다. HTTP에서는 응답이 진짜 서버에서 왔는지 클라이언트가 알 수 없습니다. HTTPS가 암호화하는 것은 전송 구간뿐입니다. 서버 안에 저장된 데이터, 서버 측 로그, 또는 클라이언트 기기 자체는 HTTPS의 보호 범위 밖입니다. HTTPS는 네트워크 경로의 도청·변조를 막는 것이지, 전체 시스템 보안을 보장하는 것은 아닙니다. HTTPS와 CSP(Content Security Policy)는 역할이 다릅니다. HTTPS가 전송 구간의 무결성을 보장한다면, CSP는 페이지에서 어떤 리소스를 불러올 수 있는지를 제어합니다. XSS 공격처럼 서버에서 직접 내려온 악성 코드는 HTTPS로 막을 수 없습니다.

모든 공개 웹 서비스에서 HTTPS는 이제 기본 전제입니다. 브라우저가 HTTP 응답에 Set-Cookie를 내려보내도 Secure 속성이 없으면 HTTPS에서만 쿠키가 전송되지 않고, 크롬 같은 브라우저는 HTTP 페이지에 경고 배너를 표시합니다. Let's Encrypt 같은 무료 CA 덕분에 인증서 발급과 갱신을 자동화할 수 있어 인증서 비용이 더 이상 장벽이 아닙니다. Nginx나 Caddy 같은 웹 서버는 인증서 자동 갱신을 내장해 설정 한 줄로 HTTPS를 활성화할 수 있습니다. 내부 서비스 간 통신이나 로컬 개발 환경에서는 HTTPS를 생략하는 경우도 있지만, 공개 트래픽을 받는 서비스에서는 TLS 없는 HTTP를 사용하는 것이 보안 정책상 허용되지 않는 경우가 많습니다. 특히 OAuth나 JWT 토큰처럼 재사용 가능한 자격증명이 헤더로 오가는 구조에서는 전송 암호화가 빠지면 세션 하이재킹에 직접 노출됩니다.