HTTPS (Hypertext Transfer Protocol Secure)

HTTPS(Hypertext Transfer Protocol Secure)는 HTTP 요청과 응답을 TLS로 암호화해 주고받는 통신 방식입니다. 전송 중 데이터의 기밀성과 무결성을 보호하고 서버 인증서를 통해 연결 상대를 확인합니다. 주소가 https://로 시작하는 웹 페이지와 API에서 쓰이며, 연결을 보호하는 기능과 서비스 자체의 신뢰성은 별도로 판단합니다.

TLS가 HTTPS 연결을 보호하는 방식

MDN의 TLS 보안 문서는 TLS(Transport Layer Security)가 연결을 세 가지로 보호한다고 정리합니다. 암호화는 전송 중인 데이터를 공격자가 읽지 못하게 하고, 무결성은 데이터가 몰래 바뀌면 드러나게 하며, 인증은 클라이언트와 서버가 상대에게 자기가 주장하는 주체임을 증명하게 합니다. 웹에서는 보통 서버가 클라이언트에게 자신을 인증하고, 클라이언트가 서버에게 인증하는 경우는 드뭅니다.

연결은 핸드셰이크로 시작합니다. 클라이언트와 서버는 지원하는 TLS 버전과 암호화 방식을 확인하고, 이후 데이터를 보호할 키를 마련합니다. 핸드셰이크 뒤에는 HTTP 헤더와 본문을 포함한 메시지를 암호화해 주고받습니다. TLS 버전에 따라 키 합의와 인증을 구성하는 세부 방식이 다르므로, 서버와 클라이언트가 함께 지원하는 설정이 연결 조건이 됩니다.

MDN의 HTTPS 용어 설명은 HTTPS를 민감한 데이터를 주고받는 보안 연결로 설명합니다. TLS 문서는 이를 공격자가 브라우저와 서버 사이에 끼어들어 트래픽을 읽고 바꾸는 중간자(MITM) 공격에 대한 방어로 설명합니다. 브라우저는 HTTPS로 전달된 페이지를 보안 컨텍스트(secure context)로 보며, 강력한 웹 API 상당수는 보안 컨텍스트에서 실행되는 코드에만 열려 있습니다. 문서는 모든 웹사이트가 모든 페이지와 하위 리소스를 HTTPS로 제공하고 서버 인증을 구현하라고 권합니다.

인증서와 HTTP에서 HTTPS로의 전환

서버 인증에는 디지털 인증서가 필요합니다. MDN의 TLS 보안 문서에 따르면 인증서에는 웹사이트 개인 키의 짝인 공개 키를 디지털 서명한 사본이 들어 있고, 이 인증서가 웹사이트의 키를 도메인 이름에 묶어 브라우저가 요청한 도메인에 연결하고 있음을 알게 합니다. 문서는 Let's Encrypt를 무료 TLS 인증서를 발급하는 비영리 인증 기관으로 소개합니다. 현대적인 웹 호스팅 서비스는 기본값이나 설정으로 HTTPS를 지원하며, 이때 인증서 관리와 서버 설정을 호스팅 서비스가 대신 맡을 가능성이 크다고도 적습니다.

HTTPS로만 서비스하는 사이트도 사용자가 주소창에 HTTP 주소를 직접 입력하면 HTTP 요청이 먼저 도달할 수 있습니다. 문서는 HTTP 요청을 받아 301 Moved Permanently 응답으로 HTTPS 주소로 보내는 방법을 안내합니다. 이 첫 교환을 공격자가 가로채 HTTPS 전환을 막는 공격을 SSL 스트리핑이라고 부르며, SSL은 TLS의 전신입니다.

이 위험을 줄이는 장치가 Strict-Transport-Security 응답 헤더(HSTS)입니다. 서버가 이 헤더를 보내면 브라우저는 이후 방문에서 HTTP 주소를 입력해도 처음부터 HTTPS로 연결합니다. 첫 방문과 HSTS 기록이 만료된 뒤의 첫 연결은 여전히 보호받지 못하므로, Chrome은 HSTS 사전 등록 목록(HSTS preload list)을 두고 목록에 있는 도메인의 HTTP 요청을 항상 HTTPS로 올립니다. 문서에 따르면 Safari와 Firefox도 Chrome 목록에서 파생한 목록으로 비슷하게 동작합니다.

혼합 콘텐츠와 HTTPS 적용 범위

페이지 본문을 HTTPS로 받아도 그 안의 리소스가 HTTP로 오면 보호가 끊깁니다. MDN의 혼합 콘텐츠 문서는 안전하게 불러온 페이지가 HTTP 같은 안전하지 않은 프로토콜로 리소스를 가져오는 경우를 혼합 콘텐츠(mixed content)라고 부릅니다. 이렇게 받은 리소스는 공격자가 엿보거나 바꿀 수 있고, 스크립트는 페이지의 모든 부분을 바꿀 수 있어 특히 위험합니다. 이미지도 바뀌면 사용자에게 잘못된 정보를 보여 주거나 버튼의 겉보기 기능을 바꿀 수 있습니다.

브라우저는 일부 이미지와 비디오·오디오 혼합 콘텐츠 요청을 HTTP에서 HTTPS로 자동으로 올리고 나머지 리소스 유형의 안전하지 않은 요청은 차단합니다. 차단 대상에는 <script>, 스타일시트를 부르는 <link>, <iframe>, fetch(), XMLHttpRequest 요청이 들어갑니다. HTTPS로 배포한 웹 앱이 http://로 시작하는 API 주소에 fetch()를 보내면 이 규칙에 걸려 요청이 막힙니다. 자동 상향 대상인 이미지라도 주소의 호스트가 도메인 이름이 아니라 IP 주소이면 차단됩니다.

개발 환경에서는 예외가 있습니다. 같은 문서는 file: URL과 http://127.0.0.1/, http://localhost/ 같은 루프백 주소의 콘텐츠를 HTTPS 출처처럼 안전한 출처로 봅니다. 다만 로컬 파일이 http:로 안전하지 않은 리소스를 불러오면 혼합 콘텐츠 요청이 됩니다. 브라우저 개발자 콘솔은 혼합 콘텐츠를 상향하거나 차단할 때 경고를 남기고, 문서는 http:// 링크를 https://로 바꾸거나 upgrade-insecure-requests 지시문을 담은 콘텐츠 보안 정책으로 요청을 HTTPS로 올리는 방법을 안내합니다.