updated
카페 무료 와이파이, 비밀번호를 입력해도 괜찮을까?
암호화된 연결과 믿을 수 있는 로그인 화면은 다르다. HTTPS가 지키는 범위부터 비밀번호를 입력하기 전의 판단까지.
카페에서 마주칠 수 있는 가상의 장면이다. 와이파이에 연결하자 로그인 화면이 열린다. 노트북은 인터넷에 들어갈 준비가 됐다고 하고, 화면은 이메일 비밀번호를 요구한다. 이때 확인해야 할 것은 와이파이 신호의 세기가 아니다. 지금 입력할 비밀번호를 누가 받는가다.
‘공공 와이파이는 위험하다’는 말만으로는 이 상황을 판단하기 어렵다. 정상적인 웹사이트와 암호화된 연결을 맺는 일, 카페의 인터넷 이용 조건에 동의하는 일, 낯선 페이지에 계정 비밀번호를 건네는 일은 서로 다르기 때문이다.
이 글에서는 세 가지를 분리한다. 이동 중인 내용을 보호하는 HTTPS, 네트워크 접속을 허용하는 안내 화면, 그리고 내 계정으로 로그인하는 서비스다. 이 구분이 되면 VPN을 켜야 하는 상황과, 화면부터 닫아야 하는 상황도 달라 보인다.
영수증의 와이파이 암호와 메일 비밀번호는 다르다
먼저 카페에서 만날 법한 장면을 하나 떠올려 보자. 영수증 아래에는 와이파이 이름과 암호가 적혀 있다. 휴대폰 설정에서 그 암호를 넣으니 연결된다. 잠시 뒤 열린 창에는 ‘로그인’이라는 말과 빈칸 두 개가 나온다. 앞에서 암호를 한 번 넣었으니, 이번에도 같은 종류의 절차라고 생각하기 쉽다. 하지만 두 입력창이 무엇을 여는지는 따로 봐야 한다.
매장 와이파이 암호는 그 무선 네트워크에 들어가기 위한 정보다. 메일 비밀번호는 내 편지함에 접근하는 열쇠다. 호텔이 발급한 일회용 이용권 번호라면 인터넷 이용 자격을 확인하는 정보에 가깝다. 화면에 모두 ‘비밀번호’라고 적혀 있어도, 잃었을 때 열리는 문은 서로 다르다.
와이파이 암호가 있는지도 중요하지만 그것만으로 끝나지는 않는다. 애플의 공유기 보안 설정 안내는 무선 보안 방식이 인증과 암호화를 정하며, WPA3 Personal이나 호환성을 고려한 WPA2/WPA3 방식을 권장한다고 설명한다. 이런 보호는 웹사이트와 맺는 HTTPS 연결과 별개의 층이다. 와이파이 연결을 보호한다고 해서 방문하는 모든 사이트의 운영자까지 믿을 수 있게 되는 것은 아니다.
건물의 공동 현관 비밀번호를 안다고, 건물 안의 모든 가게가 믿을 만하다고 보증할 수 없는 것과 비슷하다. 반대로 공동 현관이 열려 있다고, 내가 들고 있는 봉인된 편지의 내용까지 누구나 읽을 수 있는 것도 아니다. 이 비유에서 공동 현관은 네트워크 접속, 봉투는 웹 통신의 보호에 가깝다. 실제 기술은 더 복잡하지만, 두 보호가 대신할 수 없는 이유는 이 정도로 잡아두면 된다.
와이파이를 함께 써도, 같은 내용을 읽는 것은 아니다
웹 주소 앞의 HTTPS는 브라우저와 웹사이트 사이의 통신을 보호하는 방식이다. 그 안에서는 TLS라는 보안 프로토콜이 작동한다. 전송 내용을 암호화하고, 중간에서 몰래 바뀌지 않았는지 확인하며, 접속한 서버의 인증서를 검사한다. MDN의 TLS 설명이 구분하는 세 역할이다.
예를 들어 공식 웹메일 사이트와 정상적인 HTTPS 연결을 맺었다면, 비밀번호와 메일 내용은 암호화된 상태로 카페 네트워크를 지난다. 카페 공유기를 운영한다는 이유만으로 그 내용을 평문처럼 읽을 수 있는 것은 아니다.
여기에는 전제가 있다. 기기와 브라우저가 침해되지 않았고, 인증서 경고를 무시하지 않았으며, 실제로 의도한 서비스에 연결했다는 것이다. 회사가 관리하는 기기에 별도의 보안 인증서나 검사 프로그램이 설치된 환경은 일반적인 개인 기기와 구분해야 한다.
카페는 경유지, 웹사이트는 수신자
- 01내 브라우저
입력한 내용을 암호화해 보낸다.
- 02카페 네트워크
암호화된 데이터를 전달한다.
- 03접속한 웹사이트
전달받은 내용을 처리한다.
HTTPS는 브라우저와 웹사이트 사이의 통신을 보호한다.
미국 연방거래위원회(FTC)도 공공 와이파이 안내에서 웹 암호화가 널리 쓰이면서 과거와 상황이 달라졌다고 설명한다. 동시에 가짜 웹사이트도 통신을 암호화할 수 있다고 경고한다.
이 두 설명은 모순이 아니다. HTTPS는 편지를 봉하는 기능에 가깝다. 도중에 편지를 뜯어보는 일은 어렵게 만들지만, 내가 받는 사람을 잘못 골랐다면 그 사람이 편지를 읽는 것까지 막지는 못한다.
예를 들어 카페에서 공식 쇼핑몰에 로그인하고 배송지를 수정했다고 하자. 정상적인 HTTPS 연결이라면 중간에서 전달을 맡은 네트워크와, 주소를 받아 배송 정보를 고치는 쇼핑몰은 같은 위치에 있지 않다. 배송지를 알아야 일을 처리하는 쇼핑몰에는 그 정보가 전달된다. ‘암호화되었으니 아무도 내 주소를 모른다’가 아니라 ‘이동 중에 엉뚱한 사람이 내용을 읽기 어렵게 한다’는 뜻이다.
이 차이는 개인정보처리방침을 읽을 때도 도움이 된다. 통신 보안은 전달 중의 보호를 다루고, 사이트가 받은 정보를 얼마나 오래 보관하고 어디에 쓰는지는 또 다른 질문이다. 안전한 통신과 좋은 정보 관리가 함께 필요하지만, 앞의 기술이 뒤의 약속까지 자동으로 만들어주지는 않는다.
내용을 못 읽어도, 접속 흔적은 남을 수 있다
암호화는 통신이 존재한다는 사실까지 지우지 않는다. 네트워크 운영자는 연결 시각, 통신 상대의 IP 주소, 데이터의 양 같은 정보를 관찰할 수 있다. 웹페이지 안에서 읽은 문장과 이런 바깥 정보는 구분해야 한다.
사이트 이름이 보이는지는 조건에 따라 달라진다. 사이트 이름을 IP 주소로 찾는 DNS 조회가 암호화됐는지, 연결 시작 단계의 서버 이름도 보호하는 ECH가 사용되는지에 영향을 받는다. ECH는 ‘암호화된 첫 연결 인사’ 정도로 이해하면 된다. Cloudflare의 ECH 문서는 이 시작 메시지의 보호 범위를 설명한다.
따라서 “카페에서는 방문 사이트를 전부 안다”와 “HTTPS면 내가 어디에 접속했는지도 전혀 모른다”는 말은 둘 다 지나치다. 사이트 이름을 숨겨도 목적지 IP 같은 단서가 남고, 하나의 IP를 여러 사이트가 함께 쓰기도 한다. 실제로 무엇까지 추정할 수 있는지는 연결 환경에 달렸다. Cloudflare의 기술 설명에서도 이 차이를 다룬다.
카페 네트워크에 보이는 것과 보호되는 것
| 정보 | HTTPS에서의 구분 |
|---|---|
| 비밀번호·메시지 | 전송 중에는 암호화. 접속한 웹사이트는 내용을 처리한다. |
| 페이지 경로·검색어 | HTTPS 요청 안에서는 암호화. 기기·사이트 기록은 별개다. |
| 사이트 이름 | DNS·ECH 적용 등에 따라 노출·추정될 수 있다. |
| 시각·양·목적지 IP | 네트워크에서 관찰할 수 있는 바깥 정보다. |
가령 목적지 IP를 건물의 도로명주소에 비유해 보자. 주소를 알면 어느 건물로 향했는지 짐작할 수 있다. 그러나 한 건물에 여러 가게가 있다면, 주소만으로 어느 가게의 어떤 상품을 살펴봤는지까지 알아낸 것은 아니다. 웹사이트도 여러 곳이 같은 IP를 함께 쓸 수 있어서, ‘IP가 보인다’를 ‘읽은 페이지의 모든 내용을 안다’로 바꾸어 말하면 범위가 커진다.
그렇다고 바깥 정보가 사소하다는 뜻은 아니다. 언제 연결했고 얼마나 많은 데이터를 주고받았는지는 그 자체로 활동의 단서가 된다. 다만 큰 용량의 통신이 있었다고 곧바로 어떤 영상을 봤는지 확정할 수 있는 것은 아니다. 여기서는 네트워크에서 관찰할 수 있는 정보와, 그 정보로 시도할 수 있는 추정을 구별하고 있다.
또 이 표는 카페의 네트워크를 기준으로 한 설명이다. 내 브라우저에 남은 방문 기록, 로그인한 웹사이트가 저장한 활동, 회사 관리 프로그램이 수집한 기록까지 모두 지워진다는 이야기가 아니다. “누가 볼 수 있나”를 물을 때 관찰자를 먼저 정해야 답이 달라지는 이유다. 옆자리 손님, 공유기 운영자, 방문한 사이트, 내 기기를 관리하는 조직을 한데 묶으면 보호 범위를 정확히 말하기 어렵다.
‘와이파이 접속’과 ‘내 계정 로그인’을 나눠 보기
인터넷에 연결하기 전에 약관이나 이용권 번호를 보여주는 페이지를 접속 포털이라고 한다. 기기가 네트워크에는 연결됐지만, 인터넷 이용을 위해 한 단계를 더 거치게 하는 화면이다. Apple의 공공 네트워크 안내도 로그인 페이지에서 이용 조건을 수락하거나 필요한 접속 정보를 입력하는 과정을 설명한다.
여기서 ‘로그인’이라는 같은 단어가 혼동을 만든다. 매장에서 받은 와이파이 암호, 호텔이 발급한 이용권, 평소 사용하는 이메일 계정의 비밀번호는 같은 종류의 정보가 아니다.
다음은 실제 화면이 아닌 설명용 상황이다. 카페의 접속 페이지가 ‘무료 인터넷 이용’이라는 문구 아래 이메일 주소와 이메일 비밀번호를 함께 요구한다고 하자. 주소를 연락처로 수집하는 일과, 그 주소의 메일함을 열 수 있는 비밀번호까지 받는 일은 완전히 다르다. 포털 자체에 다른 서비스의 계정 비밀번호를 입력해서는 안 된다.
외부 서비스의 공식 로그인 페이지로 이동하는 방식도 있다. 이 경우에도 익숙한 로고만 보고 판단하지 않는다. 실제 주소가 그 서비스의 공식 도메인인지, 로그인 뒤 어떤 정보나 권한을 넘기는지 확인해야 한다. 주소를 확인하기 어렵다면 화면 안에서 계속 진행하기보다 연결을 중단하고 매장에 접속 방법을 묻는 편이 낫다.
인증서나 기기 관리 프로필 설치를 요구한다면 더 조심해야 한다. 단순한 인터넷 접속을 넘어 기기의 신뢰 설정이나 관리 권한에 영향을 줄 수 있기 때문이다. 낯선 공공 네트워크를 쓰기 위해 이런 설정까지 변경하지 않는다. Apple은 직접 설치한 인증서의 신뢰 설정을 별도로 설명하고 있다.
접속 화면 자체가 나쁜 것은 아니다. 예를 들어 호텔에서 객실에 제공한 이용 코드를 입력하는 절차와, 낯선 페이지가 평소 쓰는 메일 계정의 암호를 요구하는 절차를 같은 위험으로 취급할 필요는 없다. 중요한 것은 화면의 예쁨이나 익숙한 로고보다, 요청한 정보가 그 서비스에 필요한 종류인지다. 인터넷 이용권 확인에 메일함을 여는 열쇠가 왜 필요한지 설명되지 않는다면 멈출 이유가 충분하다.
회사나 학교처럼 조직이 운영하는 네트워크에서는 계정 인증이나 별도 설정이 정상 절차일 수 있다. 이 글의 주의사항은 그런 환경을 무조건 가짜라고 분류하라는 뜻이 아니다. 조직에서 미리 안내받은 접속 방식인지 공식 담당자에게 확인해야 한다는 뜻이다. 카페에서 갑자기 열린 화면의 설명만 믿고, 회사 기기의 보안 설정까지 임의로 바꾸는 것은 다른 문제다.
특히 ‘인터넷을 쓰려면 보안 기능을 잠시 꺼라’는 요구는 목적과 수단을 다시 볼 순간이다. 접속이 안 된다는 불편을 해결하려다가 더 넓은 권한을 넘길 수 있기 때문이다. 화면이 진행을 재촉하더라도 그 자리에서 원인을 모두 해결할 의무는 없다. 연결을 바꾸거나 작업을 미루는 것도 정상적인 선택이다.
자물쇠보다 주소가 말해주는 것
브라우저의 보안 표시가 확인해 주는 것은 현재 주소와의 연결 상태다. 그 주소가 내가 의도한 곳인지까지 대신 결정해 주지는 않는다. Chrome 고객센터도 안전한 연결에서도 사이트 이름을 확인하라고 안내한다.
아래 두 주소는 모두 설명을 위한 가상 주소다. 실제 로그인에 사용하거나 접속할 필요가 없다. mail.example.com을 내가 방문하려던 정확한 주소라고 가정해 보자.
익숙한 이름이 들어 있어도 같은 주소는 아니다
방문하려던 주소
https://mail.example.com/login 비슷한 이름을 포함한 다른 주소
https://mail.example.com.signin.example.net/login 도메인을 읽는 간단한 요령 하나로 모든 사칭을 판별할 수는 없다. 서비스가 사용하는 공식 로그인 도메인도 여러 개일 수 있다. 외워서 감별하기보다 평소 쓰는 공식 앱이나 저장해 둔 북마크에서 다시 시작하는 습관이 더 현실적이다.
‘연결이 비공개로 설정되어 있지 않습니다’ 같은 인증서 경고는 별도 중단 신호다. 사이트 설정 오류일 수도 있지만, 공공 네트워크에서 이용자가 원인을 확인하지 못한 채 예외를 허용할 이유는 없다. 비밀번호 입력이나 결제를 멈추고 다른 연결에서 다시 확인한다.
주소를 확인할 때는 보이는 단어 하나만 읽지 않는다. 위 예시의 두 번째 주소에는 익숙한 이름이 앞부분에 들어 있지만, 그 뒤에 다른 도메인이 붙어 있다. 브랜드 이름이 있다는 사실과 그 브랜드가 운영하는 주소라는 사실은 다르다. 검색 결과 제목이나 화면 가운데의 로고도 주소 표시줄을 대신하지 못한다.
주소 끝의 두 단어만 보면 된다는 식의 요령 역시 만능은 아니다. 국가별 도메인 구조도 다르고, 공식 서비스가 사용하는 로그인 주소가 여러 개일 수도 있다. 그래서 이 예시는 도메인 감별 시험을 하자는 것이 아니다. 낯선 곳이 제시한 주소를 억지로 판정하기보다, 내가 이미 알고 있는 출발점으로 돌아가는 쪽이 부담이 작다는 설명이다.
공식 앱을 직접 열거나 저장해 둔 북마크에서 시작하면, 접속 화면이 제시한 링크를 따라갈 필요가 줄어든다. 물론 앱과 기기 자체가 정상이라는 전제는 남는다. 회사가 배포한 인증 앱처럼 평소와 다른 절차가 있다면 담당자의 기존 안내를 기준으로 확인한다. 모르는 화면이 스스로 제시한 ‘고객센터’만으로 자기 신뢰성을 증명하게 두지는 않는다.
VPN을 켜면 무엇이 달라질까
VPN은 내 기기와 VPN 서버 사이에 암호화된 통로를 만든다. 그 통로로 보내는 트래픽은 카페 네트워크에서 직접 들여다보기 어려워지고, 이후의 통신은 VPN 서버를 거쳐 나간다. 대신 VPN 운영자가 새로운 신뢰 대상이 된다. Mozilla의 VPN 설명은 이 지점에서 운영 주체와 기록 정책을 살펴보라고 안내한다.
단, VPN으로 보내도록 설정된 트래픽에 해당하는 이야기다. 일부 앱을 VPN 밖으로 보내는 설정이나 접속 포털 예외가 있을 수 있으므로, 버튼이 켜졌다는 사실만으로 모든 통신의 경로가 같다고 가정하지 않는다.
VPN이 있어도 웹사이트와의 HTTPS는 여전히 중요하다. 그리고 가짜 웹사이트에 직접 입력한 비밀번호는 그 사이트에 전달된다. 이동 경로를 한 번 더 감싼다고 잘못 고른 수신자가 바뀌지는 않는다.
VPN은 경로를 한 번 더 감싼다.
HTTPS는 웹사이트까지 이어진다.
위 그림에서 VPN의 끝과 HTTPS의 끝이 다른 것이 핵심이다. VPN 통로는 VPN 서버에서 끝나지만, 정상적인 HTTPS 연결의 웹 요청 내용은 접속한 웹사이트까지 보호된다. VPN 운영자가 새로운 경유자가 되었다고 해서, 그 운영자가 정상적인 HTTPS 비밀번호를 곧바로 평문으로 읽는다는 뜻은 아니다. 반대로 HTTPS 없이 보내는 정보라면 VPN 바깥 구간의 보호를 별도로 생각해야 한다.
비유하면 HTTPS로 봉한 편지를 VPN 운송 상자에 한 번 더 넣는 셈이다. 중간 운송 거점에서 바깥 상자를 벗겨도 안의 편지는 여전히 봉해져 있다. 하지만 편지의 수신자를 사칭 사이트로 적었다면, 마지막에 그 봉투를 여는 사람도 사칭 사이트다. 두 겹으로 포장했다는 사실은 잘못 쓴 수신자 이름을 고쳐주지 않는다.
따라서 공공 와이파이를 쓴다는 이유만으로 낯선 VPN 앱을 급히 설치하는 것이 언제나 최선은 아니다. 어떤 회사를 새로 믿게 되는지, 회사 업무라면 지정된 접속 방식이 무엇인지 먼저 봐야 한다. 이 글은 특정 VPN 상품을 추천하거나 속도·보안 성능을 시험한 결과가 아니다. 필요한 보호 구간을 이해하기 위한 설명이다.
노트북의 ‘공용 네트워크’는 공유하라는 뜻이 아니다
웹사이트와 안전하게 통신하는 문제 외에, 같은 네트워크의 다른 기기와 내 노트북이 어떻게 만나는지도 살펴볼 필요가 있다. 집에서는 프린터를 찾고 파일을 주고받기 편한 설정이, 처음 방문한 장소에서는 꼭 필요한 설정이 아닐 수 있다. 브라우저의 HTTPS 표시만 봐서는 이 차이를 알 수 없다.
윈도우의 네트워크 프로필에는 ‘공용’과 ‘개인’이라는 이름이 나온다. ‘개인’을 고르면 내 정보를 더 비공개로 감춰줄 것처럼 느껴질 수 있지만, 뜻은 그 반대에 가깝다. 여기서 개인 네트워크는 집이나 신뢰하는 장소처럼 다른 기기를 더 믿는 환경을 가리킨다. 마이크로소프트의 네트워크 설정 안내는 개인 프로필에서 다른 기기가 PC를 발견할 수 있고 파일·프린터 공유에 사용할 수 있다고 설명한다.
카페처럼 다른 이용자를 모르는 장소에서는 공용 프로필의 의미를 기억하면 된다. 이것은 공공장소에 내 파일을 공개하라는 선택이 아니라, 덜 신뢰하는 환경에 맞추는 선택이다. 메뉴의 단어를 일상적인 뜻으로만 읽으면 정반대의 설정을 고를 수 있는 사례다. 실제 메뉴 위치는 윈도우 버전에 따라 달라질 수 있다.
방화벽도 접속 불편을 해결하기 위해 무작정 끄지 않는다. 마이크로소프트는 방화벽 안내에서 이를 끄면 무단 접근에 더 취약해질 수 있다고 설명한다. 특정 프로그램의 연결 문제와 노트북 전체의 방어 설정을 한꺼번에 바꾸는 일은 구분해야 한다. 회사 기기라면 직접 예외를 만들기보다 관리 담당자에게 확인하는 편이 맞다.
카페에서 판단해야 할 순간은 세 번이다
기술을 전부 외울 필요는 없다. 연결하기 전, 정보를 입력하기 전, 작업을 끝낼 때를 나누면 확인할 일이 작아진다. 다음은 앞서 살펴본 보호 범위와 CISA의 여행 중 보안 안내를 일상적인 행동으로 옮긴 편집상의 제안이다.
- 연결하기 전에는 운영 주체를 확인한다. 매장이 안내한 네트워크 이름과 접속 방법을 확인한다. 이름이 비슷한 네트워크가 여러 개라면 추측해서 고르지 않는다.
- 입력하기 전에는 수신자를 확인한다. 포털 자체가 다른 서비스의 비밀번호를 요구하거나 브라우저 경고가 보이면 중단한다. 송금처럼 중요한 작업 중 연결이 의심스럽다면 모바일 데이터로 바꾸고 공식 앱을 직접 연다.
- 끝낼 때는 불필요한 연결을 남기지 않는다. 기기의 공공 네트워크 자동 연결과 파일 공유 설정을 점검한다. 회사 기기는 개인적인 요령보다 조직의 외부 접속 정책을 우선한다.
모바일 데이터로 전환하는 것은 수상한 와이파이 경로를 벗어나는 방법이지, 이미 열린 가짜 페이지를 진짜로 바꾸는 방법은 아니다. 연결을 바꾼 뒤에도 같은 화면에 계속 입력하면 문제는 남는다. 그래서 ‘다른 연결’과 ‘공식 앱에서 다시 시작하기’를 함께 말하는 것이다.
장소가 익숙하다는 이유로 확인을 생략할 필요도 없다. 늘 가던 카페라도 오늘 선택한 네트워크와 접속 절차가 평소와 다르다면 직원에게 확인할 수 있다. 다만 이름이 일치한다는 확인 하나가 통신 전체를 인증해 주는 것은 아니다. 네트워크 선택, 웹사이트 주소 확인, 브라우저 경고 확인은 각각 맡은 역할이 있다.
급한 업무일수록 목표를 작게 잡는 편이 낫다. 메일 한 통을 보내려는 상황이라면 낯선 접속 프로그램을 설치하고 경고를 우회하는 긴 과정을 시작할 필요가 없다. 사용할 수 있는 다른 연결에서 공식 앱을 여는 방법이 있다면 그쪽으로 돌아가면 된다. 모바일 데이터 요금이나 회사의 반출 정책처럼 현실적인 조건도 함께 고려하되, 불편을 없애기 위해 확인되지 않은 권한을 넓히지는 않는다.
이미 비밀번호를 입력했다면
연결을 끊는 것과 계정 접근을 막는 것은 별개다. 비밀번호가 이미 전달됐다면 와이파이를 끄는 것만으로 되돌릴 수 없다. 신뢰할 수 있는 기기와 연결에서 해당 서비스의 공식 계정 복구 절차로 들어간다.
FTC의 계정 복구 안내에 따라 비밀번호를 바꾸고, 가능한 경우 다른 기기의 로그인 세션을 종료하며, 복구 이메일·전화번호가 바뀌지 않았는지 확인한다. 2단계 인증을 설정하고 이메일 자동 전달 규칙에도 낯선 항목이 없는지 살펴본다.
같은 비밀번호를 재사용한 계정도 따로 조치해야 한다. 특히 이메일은 다른 계정의 비밀번호 재설정에 쓰이므로 먼저 확인할 대상이다. 금융정보까지 입력했다면 해당 금융기관의 공식 사고 신고 창구에 연락한다. 기기 설정이나 인증서까지 바꿨다면 비밀번호 문제만으로 한정하지 말고 기기 점검도 받아야 한다.
이때 무엇을 입력했는지 구체적으로 나누어 기억하면 대응 범위를 정하는 데 도움이 된다. 단순히 카페 이용권 번호를 넣었는지, 다른 서비스의 비밀번호를 넣었는지, 로그인 승인 알림까지 눌렀는지에 따라 확인할 대상이 달라진다. 비밀번호뿐 아니라 인증번호나 승인까지 넘겼다면 해당 서비스에 그 사실을 함께 알린다.
비밀번호를 바꿨다는 사실만으로 모든 접속이 끝났다고 가정하지 않는다. 서비스마다 로그인 세션을 종료하는 방식이 다를 수 있으므로 공식 보안 화면에서 낯선 기기와 접속 기록도 확인한다. 가짜 화면이 제공한 복구 링크로 돌아가는 대신, 서비스의 공식 앱이나 주소에서 절차를 시작하는 것이 중요하다. 공공 와이파이를 떠나는 일과 계정을 되찾는 일은 서로 다른 작업이다.
연결이 안전한가와, 정보를 받을 곳이 맞는가는 서로 다른 질문이다.
공공 와이파이를 무조건 피하는 것보다 중요한 것은 이 두 질문을 섞지 않는 일이다. HTTPS가 지켜주는 내용을 알고, 그 보호 바깥에 있는 주소와 로그인 요구는 따로 확인한다. 다음번 카페에서 비밀번호 입력창을 만났을 때는 신호 아이콘보다 먼저 수신자를 보면 된다.
참고자료
2026-09-16 공식 자료 재확인. 기존 발행일과 화면 updated는 유지하고 설명을 보강했다. 공개 기술 문서와 보안기관 안내를 바탕으로 재편집했다. 도식·주소는 설명용이며, 공공 와이파이 패킷 수집이나 공격 재현 실험을 했다는 의미가 아니다. 상단 일러스트는 AI로 제작한 개념 이미지다.
- MDN — Transport Layer Security: 암호화·무결성·서버 인증과 HTTPS 요청 보호.
- FTC — Are Public Wi-Fi Networks Safe?: 공공 네트워크와 가짜 HTTPS 사이트의 구분.
- Cloudflare — ECH Protocol, Encrypted Client Hello 기술 설명: 연결 시작 정보와 IP 노출의 한계.
- Apple — Use captive Wi-Fi networks, 수동 설치 인증서의 신뢰 설정: 접속 포털과 기기 신뢰 설정.
- Chrome — 사이트 연결이 안전한지 확인: 경고와 사이트 이름 확인.
- MDN — What is a URL?: 프로토콜·호스트·경로 구분.
- Mozilla — Do you need a VPN?: VPN 운영자와 신뢰의 이동.
- FTC — How To Recover Your Hacked Email or Social Media Account: 계정 복구와 후속 점검.
- CISA — Cybersecurity While Traveling: 네트워크 이름과 로그인 절차 확인.
- Apple — 공유기 보안 설정: 무선 네트워크 인증·암호화와 보안 방식.
- Microsoft — 네트워크 프로필: 공용·개인 프로필과 기기 검색.
- Microsoft — 방화벽과 네트워크 보호: 방화벽을 끌 때의 위험.
개정 기록 · 최초 발행 2026-08-13. 2026-09-11 설명 구조와 도식을 다시 구성하고, 원문을 재확인하지 못한 사건의 형량·피해 세부사항 및 중복 검증 기록을 제외했다. 기존 URL은 유지했다.