관리

HTTP와 HTTPS 차이: 자물쇠 표시가 보장하는 것과 못 하는 것

이 글은 AI의 도움을 받아 원문을 번역한 글입니다. 전문 용어와 수식은 원문과 함께 확인해 주세요.

HTTPS는 평범한 HTTP 통신을 암호화된 TLS 연결 안에서 주고받는 방식입니다. 이 연결에 대해 보장하는 것은 세 가지입니다. 네트워크 중간에 있는 사람이 오가는 내용을 읽을 수 없고, 내용을 몰래 바꾸면 들통나며, 서버가 주소창에 보이는 도메인의 유효한 인증서를 가지고 있음이 확인됩니다. 반면 사이트가 정직하다는 보장은 없습니다. 자물쇠 아이콘(최근 Chrome에서는 ‘조정’ 아이콘)은 연결의 상태를 알려 줄 뿐 사이트 운영자를 보증하지 않으며, 피싱 사이트도 거의 모두 HTTPS를 사용합니다.

HTTP와 HTTPS를 나란히 비교한 그림. HTTP(http://, 포트 80)에서는 읽을 수 있는 비밀번호가 담긴 로그인 요청이 브라우저에서 웹사이트로 그대로 전달되어, 와이파이·공유기·통신사 경로의 누군가가 페이지와 비밀번호를 읽고, 들키지 않게 페이지를 바꾸고, 사이트인 척할 수 있습니다. HTTPS(https://, 포트 443)에서는 같은 요청이 터널 안에서 암호화된 바이트로 전달되어, 중간에서는 도메인 이름, IP 주소, 데이터가 오가는 양만 보입니다.
그림 1. HTTP에서는 네트워크 경로상의 누구나 통신 내용을 읽고 바꿀 수 있습니다. HTTPS에서는 어디로 얼마나 보내는지는 여전히 보이지만, 무슨 내용인지는 볼 수 없습니다. 그림의 로그인 값은 예시입니다.

HTTP와 HTTPS 차이: ‘S’가 더해 주는 것

HTTP는 브라우저와 서버가 웹 페이지를 요청하고 전달하는 규칙이며, 그 자체로는 내용이 평문 그대로 오갑니다. HTTPS는 같은 요청과 응답을 TLS(Transport Layer Security) 안에 담아 보냅니다. TLS는 예전 SSL 프로토콜을 대체한 규격이라 지금도 ‘SSL 인증서’라는 말이 흔히 쓰이지만, 실제로 설치하는 것은 TLS 서버 인증서입니다. SSL 3.0은 2015년에, TLS 1.0과 1.1은 2021년에 공식적으로 사용 중단되어 현재는 TLS 1.2와 1.3이 쓰입니다.

구분HTTPHTTPS
주소의 시작http://https://
기본 포트80443
네트워크상의 내용경로상의 누구나 읽을 수 있음암호화됨
전송 중 변조알아채지 못함탐지되며 연결이 실패함
서버 신원 확인없음해당 도메인의 유효한 인증서가 필요함
Chrome 주소창‘주의 요함’중립적인 조정 아이콘

TLS 1.3 규격(RFC 8446)은 이 보장을 다음과 같이 정리합니다.

  • 기밀성: 연결이 만들어진 뒤에는 내 브라우저와 서버만 데이터를 읽을 수 있습니다. 도메인 뒤의 페이지 경로, 입력란에 쓴 값, 비밀번호, 쿠키도 모두 포함됩니다.
  • 무결성: 전송 중에 데이터를 바꾸면 반드시 탐지됩니다. 그래서 카페 공유기가 페이지에 광고나 악성코드를 몰래 끼워 넣을 수 없습니다.
  • 인증: 서버는 항상 인증서로 자신의 신원을 증명하지만, 브라우저(클라이언트) 쪽은 대개 그렇게 하지 않습니다.

한계도 있습니다. TLS는 주고받는 데이터의 양을 숨기지 못하며, 도메인 이름도 대개 그대로 보입니다. 기기가 DNS로 도메인을 조회하고, 핸드셰이크의 첫 메시지에도 사이트 이름이 담기기 때문입니다. 암호화 DNS와 비교적 새로운 확장 기능인 Encrypted Client Hello(ECH)로 가릴 수 있지만, 양쪽이 모두 지원해야 합니다.

HTTPS 연결은 어떻게 만들어질까: TLS 핸드셰이크 과정

페이지를 요청하기 전에 브라우저와 서버는 TLS 핸드셰이크를 거치며, TLS 1.3에서는 왕복 한 번이면 끝납니다.

  1. ClientHello. 브라우저가 접속하려는 사이트 이름을 알리고, 지원하는 TLS 버전과 암호 방식, 그리고 키 교환에서 자기 몫(키 공유값)을 보냅니다.
  2. ServerHello. 서버가 옵션을 고르고 자기 몫의 키 공유값을 보냅니다. 이제 양쪽이 같은 세션 키를 각자 계산하며, 이 키는 네트워크로 오가지 않습니다. 이후의 통신은 모두 암호화됩니다.
  3. 인증서와 서명. 서버가 인증서를 보내고, 짝이 되는 개인 키로 핸드셰이크 내용에 서명합니다. 복사해 온 인증서가 아니라 개인 키를 실제로 가졌음을 증명하는 단계입니다.
  4. 브라우저의 검사. 인증서가 브라우저나 기기가 신뢰하는 인증기관(CA)까지 이어지는지, 접속하려는 도메인 이름이 적혀 있는지, 유효 기간 안에 있는지를 확인합니다.
  5. 암호화된 HTTP. 양쪽이 핸드셰이크 내용이 바뀌지 않았음을 확인하면, 평소와 같은 요청과 응답이 암호화된 통로로 오갑니다.
브라우저와 웹 서버 사이의 TLS 1.3 핸드셰이크를 간략화한 순서도. 1 ClientHello: 사이트 이름, TLS 버전, 키 공유값을 보냄. 2 ServerHello: 서버의 키 공유값을 보내고, 이후 양쪽이 같은 세션 키를 각자 계산함. 3 암호화된 Certificate, 서명, Finished. 4 브라우저가 인증서가 신뢰하는 CA에서 발급되었는지, 도메인이 일치하는지, 유효 기간이 지나지 않았는지 확인하고, 하나라도 실패하면 Chrome이 “연결이 비공개로 설정되어 있지 않습니다”를 표시함. 5 양방향으로 암호화된 HTTP 통신.
그림 2. TLS 1.3 핸드셰이크를 간략화한 모습입니다. 4단계의 인증서 검사가 가짜 서버를 걸러 내며, 세션 키는 양쪽에서 각자 계산할 뿐 네트워크로 전송되지 않습니다.

4단계에서 하나라도 어긋나면 브라우저는 연결을 멈추고 Chrome의 “연결이 비공개로 설정되어 있지 않습니다”처럼 전체 화면 경고를 띄웁니다. 이것은 HTTPS가 가짜일 수도 있는 서버를 걸러 낸 것이지, 그냥 눌러서 넘어가도 되는 오류가 아닙니다.

자물쇠 표시가 알려 주지 않는 것

인증서는 도메인 이름의 관리 주체를 증명할 뿐, 사업체의 운영자나 그 정직함까지 증명하지는 않습니다. 가장 기본적인 유형은 도메인 인증(DV) 인증서로, 인증기관은 신청자가 해당 도메인을 관리하는지만, 이를테면 지정된 파일이나 DNS 레코드를 게시하게 해서 확인합니다. 무료이면서 자동화된 인증기관인 Let’s Encrypt는 DV 인증서만 발급하며, 기본 유효 기간은 90일입니다. 덕분에 HTTPS가 널리 퍼졌지만, yourbank.com.verify-login.net(지어낸 예시 주소)처럼 비슷하게 꾸민 주소의 피싱 페이지도 유효한 인증서를 받을 수 있게 되었습니다. 브라우저는 보안 연결이라고 정확히 알려 주지만, 그 연결의 상대가 엉뚱한 사이트인 셈입니다.

두 칸으로 나눈 체크리스트. 연결에 대해 보장되는 것은 전송 중 내용 보호, 무결성, 표시된 도메인에 대한 서버 인증. 사이트에 대해 보장되지 않는 것은 내가 의도한 그 사이트라는 점, 운영자가 정직하다는 점, 데이터가 도착한 뒤의 안전, 내려받는 파일이 깨끗하다는 점, 접속 사실이 보이지 않는다는 점(도메인 이름과 IP 주소는 계속 보임).
그림 3. HTTPS는 내 브라우저와 서버 사이의 통로를 보호합니다. 그 서버의 주인이 믿을 만한지는 별개의 문제입니다.
인증서 유형인증기관이 확인하는 것알 수 있는 것
DV(도메인 인증)도메인 관리 권한서버가 이 이름에 대해 승인받았다는 사실뿐
OV(조직 인증)도메인 관리 권한과 조직의 등록 정보인증서 세부 정보에 회사 이름이 적힘
EV(확장 인증)조직의 법적 신원에 대한 더 엄격한 확인OV와 같음. Chrome은 77 버전(2019년)부터 회사 이름 배지를 주소창에서 뺌

HTTPS는 내려받는 파일의 악성코드를 검사해 주지 않고, 서버에 저장된 뒤의 내 정보를 지켜 주지도 않으며, 이미 감염된 내 기기에도 도움이 되지 않습니다.

Chrome은 왜 자물쇠를 조정 아이콘으로 바꿨을까

자물쇠는 HTTPS가 드물던 시절에 만들어진 표시입니다. Google에 따르면 2013년에는 상위 100만 개 웹사이트 중 14%만 HTTPS를 지원했지만, 2023년에는 Windows용 Chrome에서 로드된 페이지의 95% 이상이 HTTPS를 사용했습니다. 2021년 Google 연구에서는 자물쇠의 의미를 올바르게 이해한 참가자가 11%에 그쳤고, 많은 사람이 ‘이 사이트는 믿을 만하다’는 뜻으로 받아들였습니다. 거의 모든 피싱 사이트가 같은 자물쇠를 띄우는 만큼 이런 오해는 위험합니다. 미국 FBI도 2019년에 자물쇠나 ‘https’만 보고 사이트를 믿지 말라고 경고했습니다.

2023년 9월에 나온 Chrome 117은 자물쇠를 중립적인 조정 아이콘(슬라이더 두 개 모양)으로 바꿨습니다. 이 아이콘을 누르면 사이트 정보와 설정이 열립니다. 일반 HTTP 페이지에는 2018년 7월 Chrome 68부터 그랬듯 ‘주의 요함’ 표시가 계속 붙습니다. 2025년 10월에 Google은 다음 단계를 발표했습니다. ‘항상 보안 연결 사용’ 설정을 기본으로 켜서(Chrome 154에 적용할 계획), HTTPS가 없는 공개 사이트를 열기 전에 Chrome이 먼저 묻게 하겠다는 것입니다.

Chrome 보안 표시의 변화를 나타낸 연표. 2013년 상위 100만 개 웹사이트 중 14%가 HTTPS를 지원. 2018년 7월 Chrome 68이 모든 HTTP 페이지에 “주의 요함”을 표시. 2021년 Chrome 연구에서 자물쇠의 의미를 이해한 참가자는 11%. 2023년 9월 Chrome 117이 자물쇠를 중립적인 조정 아이콘으로 교체. 2025년 10월 Google이 HTTPS를 지원하지 않는 공개 사이트를 열기 전에 경고하는 계획을 발표. 2023년에는 Windows용 Chrome 페이지 로드의 95% 이상이 HTTPS를 사용.
그림 4. HTTPS가 보편화되면서 Chrome 주소창의 표시도 달라졌습니다. 일반 HTTP는 경고하고, HTTPS를 신뢰의 표식처럼 보여 주는 일은 그만두었습니다. 수치는 Google의 Chrome 발표 자료에서 가져왔습니다.

비밀번호나 카드번호를 입력하기 전에 확인할 점

  1. 진짜 도메인을 읽습니다. https:// 뒤에서 처음 나오는 슬래시(/) 앞까지가 도메인이며, 오른쪽 끝에서부터 읽어 나갑니다. yourbank.com.verify-login.net의 실제 사이트는 yourbank.com이 아니라 verify-login.net입니다.
  2. 안전한 경로로 들어갑니다. 이메일·문자·QR코드로 온 링크 대신 주소를 직접 입력하거나 즐겨찾기를 이용합니다.
  3. 인증서 경고는 절대 넘어가지 않습니다. 로그인이나 결제를 하는 사이트라면 탭을 닫습니다.
  4. 비밀번호 관리자나 패스키에 도메인 확인을 맡깁니다. 저장해 둔 그 사이트에서만 자격 증명을 내놓으므로, 비슷하게 만든 가짜 페이지는 아무것도 얻지 못합니다.
  5. ‘주의 요함’은 정지 신호로 봅니다. HTTP 페이지에서는 입력하는 내용이 모두 평문으로 오갑니다.
  6. 아이콘 너머를 봅니다. 갑작스러운 재촉, 요청한 적 없는 로그인 창, 지나치게 좋은 가격이 주소창의 어떤 기호보다 나은 경고 신호입니다.

자주 묻는 질문

공용 와이파이에서도 HTTPS면 충분한가요?

통신 내용은 다른 이용자와 핫스폿 운영자로부터 보호됩니다. 다만 어떤 도메인에 접속하는지는 여전히 보입니다. 가짜 핫스폿도 인증서 경고 없이는 HTTPS 통신 내용을 읽을 수 없지만, 비슷하게 만든 사이트로 유도할 수는 있으니 도메인을 꼭 확인해야 합니다.

무료 인증서는 유료보다 덜 안전한가요?

연결 자체는 그렇지 않습니다. 암호화 강도는 서버가 쓰는 TLS 버전과 설정에 달린 것이지 인증서 가격과 무관합니다. 유료인 OV·EV 인증서는 조직 검증이 더해지지만, Chrome과 Safari는 더 이상 이를 주소창에서 눈에 띄게 보여 주지 않습니다.

회사나 학교에서 내 HTTPS 통신을 볼 수 있나요?

보통은 도메인만 보일 뿐 내용은 보이지 않습니다. 그러나 기관이 관리하는 기기에는 자체 루트 인증서를 설치해 두고 보안 게이트웨이로 HTTPS 통신을 들여다볼 수 있으며, 이때 브라우저 경고도 뜨지 않습니다. 내가 관리하지 않는 기기라면 검사가 가능하다고 생각하는 편이 안전합니다.

참고 자료: IETF RFC 8446: TLS 1.3 규격; Chromium 블로그: 자물쇠 아이콘 업데이트(2023); FBI IC3: ‘보안’ 웹사이트를 악용한 피싱(2019); Let’s Encrypt FAQ.

함께 읽으면 좋은 글

본문의 이해를 돕기 위해 제작한 설명용 삽화입니다.