HTTPS는 HTTP(Hypertext Transfer Protocol) 메시지를 TLS(Transport Layer Security)로 감싸 보내는 방식이다. HTTP 자체는 바뀌지 않고, 그 아래에 암호화 계층이 하나 끼어든다. 기본 포트는 HTTP가 80, HTTPS가 443이다.
TLS가 주는 세 가지
- 기밀성: 오가는 내용을 중간에서 엿봐도 읽을 수 없다(공용 와이파이 도청 방지)
- 무결성: 중간에서 내용을 바꾸면 들킨다(광고 삽입·스크립트 변조 방지)
- 인증: 인증서로 "이 서버가 정말 그 도메인의 주인"임을 확인한다. 인증서는 브라우저가 믿는 인증 기관(Certificate Authority, CA)이 서명한다 → 발급 실무는 Let's Encrypt로 HTTPS 적용
SSL(Secure Sockets Layer)은 TLS의 옛 이름이다. SSL 2.0·3.0은 모두 사용 금지됐지만(RFC 6176·7568) "SSL 인증서"라는 말은 아직 흔히 쓴다.
연결 과정(간단히)
TCP로 연결한 뒤 TLS 핸드셰이크를 한다. TLS 1.3에서는 키 공유 값을 주고받아 대칭 키를 합의하고, 그 키로 암호화된 상태에서 서버가 인증서를 보내면 브라우저가 검증한다. 이후 HTTP 요청·응답은 그 키로 암호화해 주고받는다.
sequenceDiagram participant B as 브라우저 participant S as 서버 B->>S: TCP 연결 Note over B,S: TLS 핸드셰이크 (1.3 기준) B->>S: 키 공유 값 S-->>B: 키 공유 값 + 암호화된 인증서 Note over B: 대칭 키 합의, 인증서 검증 B->>S: 암호화된 HTTP 요청 S-->>B: 암호화된 HTTP 응답
공개 키 암호는 키 합의와 인증에만 쓰고, 실제 데이터는 빠른 대칭 키 암호로 보낸다. TLS 1.3은 처음 연결할 때의 전체 핸드셰이크 왕복을 1번(1-RTT)으로 줄였다(TLS 1.2는 2번). 외부 도메인의 이 비용을 미리 치르는 방법은 preconnect다.
프런트엔드에서 체감하는 차이
- 서비스 워커(Service Worker), 위치 정보, 클립보드 같은 많은 브라우저 API는 보안 컨텍스트(Secure Context, HTTPS 또는 localhost)에서만 동작한다
Secure쿠키는 HTTPS로만 전송된다 → HTTP 쿠키- HTTPS 페이지가 HTTP 리소스를 불러오면 혼합 콘텐츠(Mixed Content)로 막히거나, 이미지·미디어처럼 업그레이드 가능한 리소스는 HTTPS로 자동 전환된다
Strict-Transport-Security(HSTS) 헤더를 HTTPS 응답으로 받은 브라우저는max-age동안 그 도메인을 HTTPS로만 접속한다- 출처(origin)에는 스킴이 들어가므로
http://a.com과https://a.com은 다른 출처다 → 동일 출처 정책
명세: RFC 9110 §4.2.2 — https URI Scheme · RFC 8446 §2 — TLS 1.3 Protocol Overview · RFC 6797 §8.1 — HTTP Strict Transport Security · RFC 6176 — SSL 2.0 금지 · RFC 7568 — SSL 3.0 폐기 · W3C — Secure Contexts · W3C — Mixed Content 출처: MDN — HTTPS · MDN — TLS · MDN — Strict-Transport-Security