HTTP와 HTTPS 차이: 자물쇠 표시가 보장하는 것과 못 하는 것
이 글은 AI의 도움을 받아 원문을 번역한 글입니다. 전문 용어와 수식은 원문과 함께 확인해 주세요.
HTTPS는 평범한 HTTP 통신을 암호화된 TLS 연결 안에서 주고받는 방식입니다. 이 연결에 대해 보장하는 것은 세 가지입니다. 네트워크 중간에 있는 사람이 오가는 내용을 읽을 수 없고, 내용을 몰래 바꾸면 들통나며, 서버가 주소창에 보이는 도메인의 유효한 인증서를 가지고 있음이 확인됩니다. 반면 사이트가 정직하다는 보장은 없습니다. 자물쇠 아이콘(최근 Chrome에서는 ‘조정’ 아이콘)은 연결의 상태를 알려 줄 뿐 사이트 운영자를 보증하지 않으며, 피싱 사이트도 거의 모두 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이 쓰입니다.
| 구분 | HTTP | HTTPS |
|---|---|---|
| 주소의 시작 | http:// | https:// |
| 기본 포트 | 80 | 443 |
| 네트워크상의 내용 | 경로상의 누구나 읽을 수 있음 | 암호화됨 |
| 전송 중 변조 | 알아채지 못함 | 탐지되며 연결이 실패함 |
| 서버 신원 확인 | 없음 | 해당 도메인의 유효한 인증서가 필요함 |
| Chrome 주소창 | ‘주의 요함’ | 중립적인 조정 아이콘 |
TLS 1.3 규격(RFC 8446)은 이 보장을 다음과 같이 정리합니다.
- 기밀성: 연결이 만들어진 뒤에는 내 브라우저와 서버만 데이터를 읽을 수 있습니다. 도메인 뒤의 페이지 경로, 입력란에 쓴 값, 비밀번호, 쿠키도 모두 포함됩니다.
- 무결성: 전송 중에 데이터를 바꾸면 반드시 탐지됩니다. 그래서 카페 공유기가 페이지에 광고나 악성코드를 몰래 끼워 넣을 수 없습니다.
- 인증: 서버는 항상 인증서로 자신의 신원을 증명하지만, 브라우저(클라이언트) 쪽은 대개 그렇게 하지 않습니다.
한계도 있습니다. TLS는 주고받는 데이터의 양을 숨기지 못하며, 도메인 이름도 대개 그대로 보입니다. 기기가 DNS로 도메인을 조회하고, 핸드셰이크의 첫 메시지에도 사이트 이름이 담기기 때문입니다. 암호화 DNS와 비교적 새로운 확장 기능인 Encrypted Client Hello(ECH)로 가릴 수 있지만, 양쪽이 모두 지원해야 합니다.
HTTPS 연결은 어떻게 만들어질까: TLS 핸드셰이크 과정
페이지를 요청하기 전에 브라우저와 서버는 TLS 핸드셰이크를 거치며, TLS 1.3에서는 왕복 한 번이면 끝납니다.
- ClientHello. 브라우저가 접속하려는 사이트 이름을 알리고, 지원하는 TLS 버전과 암호 방식, 그리고 키 교환에서 자기 몫(키 공유값)을 보냅니다.
- ServerHello. 서버가 옵션을 고르고 자기 몫의 키 공유값을 보냅니다. 이제 양쪽이 같은 세션 키를 각자 계산하며, 이 키는 네트워크로 오가지 않습니다. 이후의 통신은 모두 암호화됩니다.
- 인증서와 서명. 서버가 인증서를 보내고, 짝이 되는 개인 키로 핸드셰이크 내용에 서명합니다. 복사해 온 인증서가 아니라 개인 키를 실제로 가졌음을 증명하는 단계입니다.
- 브라우저의 검사. 인증서가 브라우저나 기기가 신뢰하는 인증기관(CA)까지 이어지는지, 접속하려는 도메인 이름이 적혀 있는지, 유효 기간 안에 있는지를 확인합니다.
- 암호화된 HTTP. 양쪽이 핸드셰이크 내용이 바뀌지 않았음을 확인하면, 평소와 같은 요청과 응답이 암호화된 통로로 오갑니다.
4단계에서 하나라도 어긋나면 브라우저는 연결을 멈추고 Chrome의 “연결이 비공개로 설정되어 있지 않습니다”처럼 전체 화면 경고를 띄웁니다. 이것은 HTTPS가 가짜일 수도 있는 서버를 걸러 낸 것이지, 그냥 눌러서 넘어가도 되는 오류가 아닙니다.
자물쇠 표시가 알려 주지 않는 것
인증서는 도메인 이름의 관리 주체를 증명할 뿐, 사업체의 운영자나 그 정직함까지 증명하지는 않습니다. 가장 기본적인 유형은 도메인 인증(DV) 인증서로, 인증기관은 신청자가 해당 도메인을 관리하는지만, 이를테면 지정된 파일이나 DNS 레코드를 게시하게 해서 확인합니다. 무료이면서 자동화된 인증기관인 Let’s Encrypt는 DV 인증서만 발급하며, 기본 유효 기간은 90일입니다. 덕분에 HTTPS가 널리 퍼졌지만, yourbank.com.verify-login.net(지어낸 예시 주소)처럼 비슷하게 꾸민 주소의 피싱 페이지도 유효한 인증서를 받을 수 있게 되었습니다. 브라우저는 보안 연결이라고 정확히 알려 주지만, 그 연결의 상대가 엉뚱한 사이트인 셈입니다.
| 인증서 유형 | 인증기관이 확인하는 것 | 알 수 있는 것 |
|---|---|---|
| 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이 먼저 묻게 하겠다는 것입니다.
비밀번호나 카드번호를 입력하기 전에 확인할 점
- 진짜 도메인을 읽습니다. https:// 뒤에서 처음 나오는 슬래시(/) 앞까지가 도메인이며, 오른쪽 끝에서부터 읽어 나갑니다. yourbank.com.verify-login.net의 실제 사이트는 yourbank.com이 아니라 verify-login.net입니다.
- 안전한 경로로 들어갑니다. 이메일·문자·QR코드로 온 링크 대신 주소를 직접 입력하거나 즐겨찾기를 이용합니다.
- 인증서 경고는 절대 넘어가지 않습니다. 로그인이나 결제를 하는 사이트라면 탭을 닫습니다.
- 비밀번호 관리자나 패스키에 도메인 확인을 맡깁니다. 저장해 둔 그 사이트에서만 자격 증명을 내놓으므로, 비슷하게 만든 가짜 페이지는 아무것도 얻지 못합니다.
- ‘주의 요함’은 정지 신호로 봅니다. HTTP 페이지에서는 입력하는 내용이 모두 평문으로 오갑니다.
- 아이콘 너머를 봅니다. 갑작스러운 재촉, 요청한 적 없는 로그인 창, 지나치게 좋은 가격이 주소창의 어떤 기호보다 나은 경고 신호입니다.
자주 묻는 질문
공용 와이파이에서도 HTTPS면 충분한가요?
통신 내용은 다른 이용자와 핫스폿 운영자로부터 보호됩니다. 다만 어떤 도메인에 접속하는지는 여전히 보입니다. 가짜 핫스폿도 인증서 경고 없이는 HTTPS 통신 내용을 읽을 수 없지만, 비슷하게 만든 사이트로 유도할 수는 있으니 도메인을 꼭 확인해야 합니다.
무료 인증서는 유료보다 덜 안전한가요?
연결 자체는 그렇지 않습니다. 암호화 강도는 서버가 쓰는 TLS 버전과 설정에 달린 것이지 인증서 가격과 무관합니다. 유료인 OV·EV 인증서는 조직 검증이 더해지지만, Chrome과 Safari는 더 이상 이를 주소창에서 눈에 띄게 보여 주지 않습니다.
회사나 학교에서 내 HTTPS 통신을 볼 수 있나요?
보통은 도메인만 보일 뿐 내용은 보이지 않습니다. 그러나 기관이 관리하는 기기에는 자체 루트 인증서를 설치해 두고 보안 게이트웨이로 HTTPS 통신을 들여다볼 수 있으며, 이때 브라우저 경고도 뜨지 않습니다. 내가 관리하지 않는 기기라면 검사가 가능하다고 생각하는 편이 안전합니다.
참고 자료: IETF RFC 8446: TLS 1.3 규격; Chromium 블로그: 자물쇠 아이콘 업데이트(2023); FBI IC3: ‘보안’ 웹사이트를 악용한 피싱(2019); Let’s Encrypt FAQ.
함께 읽으면 좋은 글
본문의 이해를 돕기 위해 제작한 설명용 삽화입니다.