STUDY NOTE · 개념 정리

HTTP vs HTTPS 정리: TLS 핸드셰이크, 대칭키와 공개키, 인증서

Network2025-11-4 21:44

HTTPS는 HTTP에 TLS 암호화 계층을 더한 것이다. 통신 내용을 암호화하고, 상대 서버가 진짜인지 인증하고, 중간에 내용이 바뀌지 않았는지 무결성을 보장한다.

1. 한눈에 비교

TLS는 둘을 섞는다. 처음에 공개키 방식(키 교환)으로 대칭키를 안전하게 만들고, 이후 실제 데이터는 빠른 대칭키로 암호화한다.

Client Hello: 지원하는 TLS 버전, 암호 스위트 목록, 클라이언트 랜덤 값
Server Hello: 선택한 암호 스위트, 서버 랜덤 값, 서버 인증서
인증서 검증: 브라우저가 내장된 루트 CA로 인증서 체인의 서명을 확인하고, 도메인과 유효기간을 검사
키 교환: (EC)DHE로 양쪽이 같은 비밀 값(pre-master secret)을 만들고, 랜덤 값들과 합쳐 세션 키(대칭키) 생성
Finished: 서로 세션 키로 암호화한 메시지를 주고받아 확인
이후 HTTP 데이터는 세션 키로 암호화해서 전송

TLS 1.3은 이 과정을 1-RTT(재접속 시 0-RTT)로 줄였고, 안전하지 않은 RSA 키 교환을 없앴다.

용어	설명
인증서	도메인, 공개키, 발급자, 유효기간 + CA의 전자서명
CA (인증기관)	인증서에 서명해 신원을 보증하는 기관 (Let's Encrypt 등)
루트 CA	브라우저·OS에 미리 내장된 최상위 CA
인증서 체인	서버 인증서 → 중간 CA → 루트 CA 순으로 서명을 따라가 검증

전자서명은 CA가 개인키로 서명하고 브라우저가 CA 공개키로 검증한다. 공격자가 가짜 서버를 세워도 신뢰된 CA의 서명을 받을 수 없으므로 경고가 뜬다.

로드밸런서에서 TLS 종료: 쿠버네티스나 클라우드 환경에서는 보통 Ingress·로드밸런서가 HTTPS를 받아 복호화하고, 내부 서버에는 HTTP로 전달한다. 그래서 서버 코드에서 요청 스킴을 보면 http로 보이고, URL을 만들 때 X-Forwarded-Proto 헤더를 신뢰하도록 설정해야 https 링크가 나온다.
Secure 쿠키: Secure 속성이 붙은 쿠키는 HTTPS에서만 전송된다. 로그인 세션 쿠키에는 필수다.
Mixed Content: HTTPS 페이지에서 HTTP로 이미지나 스크립트를 불러오면 브라우저가 차단하거나 경고한다.
HSTS: Strict-Transport-Security 헤더로 "앞으로 이 도메인은 HTTPS로만 접속하라"고 브라우저에 알려, 첫 HTTP 요청을 가로채는 공격을 줄인다.

Q. HTTP와 HTTPS의 차이는? HTTPS는 HTTP에 TLS를 더해 데이터를 암호화하고, 인증서로 서버를 인증하며, 무결성을 보장한다. HTTP는 평문이라 도청과 변조에 취약하다.
Q. HTTPS는 대칭키와 공개키 중 무엇을 쓰나? 둘 다 쓴다. 핸드셰이크에서 공개키 기반 키 교환으로 세션 키를 만들고, 이후 데이터는 빠른 대칭키로 암호화한다.
Q. 인증서는 어떻게 검증하나? 브라우저에 내장된 루트 CA의 공개키로 인증서 체인의 전자서명을 차례로 확인하고, 도메인 일치와 유효기간, 폐기 여부를 검사한다.
Q. HTTPS는 느린가? 최초 연결 시 핸드셰이크 비용이 있지만 TLS 1.3과 세션 재사용, HTTP/2로 대부분 상쇄되어 실제 체감 차이는 거의 없다.