← 온라인 안전
ASTERXOR / 온라인 안전

자물쇠가 가게의 신용을 보증하진 않는다

암호화된 연결은 중요하다. 하지만 도착지를 믿어도 되는지는 다른 근거로 판단해야 한다.

자물쇠와 상점을 화살표로 연결해 전송 암호화와 도착지에 대한 신뢰를 구분한 개념도.
연결이 보호되는지, 그리고 원래 방문하려던 곳인지는 서로 다른 근거가 필요한 두 질문이다.
온라인 안전ASTERXOR / LEON LEUNG

안심을 주는 작은 아이콘이 실제로 답해 주는 질문은 생각보다 좁을 수 있다.

튼튼한 자물쇠를 단 가게도 실망스러운 물건을 팔 수 있다. 온라인에서도 이 구분은 중요하다. HTTPS는 특정 웹사이트와의 연결을 보호할 뿐, 운영자의 의도를 보증하지 않는다. “전문적으로 보이는 페이지” 같은 막연한 인상을 모으기보다 주소의 몇 가지 핵심 부분을 읽는 법을 익히는 편이 유용하다.

안전한 길이 도착지의 신용까지 보증하지는 않는다.
THE SMALL PROMISE

HTTPS가 실제로 약속하는 것

브라우저의 인증서 검사를 통과한 정상적인 HTTPS 연결에서는 암호화가 네트워크 경로상의 다른 사람이 통신을 읽거나 바꾸는 일을 막는 데 도움을 준다. 인증서는 그 연결을 방문 중인 호스트 이름과도 연결한다. 특히 개인정보를 입력할 때 중요한 보호 장치다.

그러나 부정직한 사이트 운영자도 자신의 도메인에 유효한 인증서를 받을 수 있다. 자물쇠든 다른 연결 상태 아이콘이든 환불 정책, 상품 품질, 인증서가 실제로 확인하는 범위를 넘어선 회사의 신원을 보증하지는 않는다. 그럴듯한 로고의 증거력은 더 약하다. 그저 페이지에 들어 있는 콘텐츠이기 때문이다.

READ THE ADDRESS

호스트를 가리키는 부분부터 찾자

일반적인 웹 주소에는 https 같은 스킴, 호스트 이름, 경우에 따라 포트가 있고 그 뒤로 경로, 쿼리, 프래그먼트가 이어진다. 어디로 향하는지 알고 싶다면 먼저 호스트 이름을 따로 읽어야 한다. 주소의 다른 부분에 쓰인 단어는 웹사이트에 의미가 있어도 의도한 서버를 가리키지는 않을 수 있다.

https://example.com/account와 https://example.com.example.org/account를 비교해 보자. 두 번째 호스트 이름은 example.com.example.org다. 여기서 example.com은 example.org 아래의 레이블이 된다. 주소 어딘가에 익숙한 이름이 보인다는 이유만으로 판단해서는 안 된다. 이 글에는 예약된 예시 도메인만 사용했으며 실험에서 어느 주소에도 접속하지 않았다.

예약 도메인 주소 세 개와 각각의 호스트 이름. 하위 도메인, 사용자 정보, 경로를 설명한다.
FIG 01로컬에서 파싱한 세 예시는 실제 호스트 이름과 익숙해 보이는 글자를 구분한다.
LOOK PAST THE FAMILIAR

같은 글자도 역할은 다르다

https://example.com@example.org/account에서는 @ 앞의 글자가 사용자 정보이고 호스트 이름은 example.org다. https://example.org/example.com에서는 익숙한 이름이 경로의 일부일 뿐이다. 쿼리에 다른 주소 전체가 들어 있어도 현재 호스트가 바뀌는 것은 아니다. 직접 열어 보라는 링크가 아니라 주소 읽기 연습이다.

실제 주소에는 국제화 도메인, 리디렉션, 단축 링크, 여러 부분으로 된 공용 접미사 같은 변수가 더 있다. “마지막 두 부분만 보면 된다”는 보편적인 규칙이 아니다. 주소가 혼란스럽다면 재촉받으며 해독할 필요가 없다. 이미 저장한 북마크나 공식 앱에서 시작하는 편이 나을 때가 많다.

WHAT WE MEASURED

파서는 구조를 나누지, 사람을 평가하지 않는다

주소 문자열 여덟 개를 오프라인에서 파싱했다. 시연 규칙은 의도적으로 좁게 정했다. HTTPS를 사용하고 호스트 이름이 정확히 example.com이며 사용자 정보가 없고, 포트가 기본값 또는 443일 때만 허용했다. 두 개가 일치했다. 호스트 이름의 대문자와 명시된 443은 결과를 바꾸지 않았지만 HTTP와 8443 포트는 규칙에 맞지 않았다.

거부된 여섯 문자열은 위험한 사이트를 측정해 모은 표본이 아니다. 단지 이 예시 규칙에 맞지 않았을 뿐이다. 호스트 이름, 판단 결과, 일치 개수, 잘못된 형식 두 사례를 포함한 검사 열아홉 개가 통과했다. 페이지, 인증서, DNS 응답, 리디렉션은 시험하지 않았다. Python 문서도 파싱이 포괄적인 URL 검증은 아니라고 명시한다.

오프라인 주소 문자열 여덟 개 중 두 개는 MATCH, 여섯 개는 NO로 표시된다.
FIG 02여덟 문자열 가운데 두 개가 좁게 정한 예시 규칙과 일치한다. 구조 검사이지 안전 점수가 아니다.
A BETTER HABIT

다른 진입 경로를 마련하자

결제를 바로잡거나 배송을 확인하거나 계정을 풀라고 재촉하는 메시지를 받았다면, 요청 내용과 링크를 분리해 생각하자. 평소 쓰던 앱이나 북마크로 서비스에 들어가 같은 문제가 표시되는지 확인한다. 지원이 필요하면 불안을 조성한 메시지에 적힌 연락처 대신 별도로 확인한 연락처를 사용한다.

처음 보는 판매자라면 주소뿐 아니라 판매자 자체도 살펴야 한다. 반품 조건, 믿을 만한 외부 정보, 결제 수단의 보호 장치를 확인하자. 연결 경고는 멈춰야 할 이유다. 페이지에서 정상이라고 주장한다는 이유로 넘어갈 대상이 아니다.

세 단계: 비밀정보 입력 전 멈춤, 공식 앱이나 저장한 북마크 열기, 계정에서 요청 확인하기.
FIG 03잠시 멈추고, 믿는 경로로 접속한 뒤 계정 안에서 요청을 확인한다.
IF YOU ALREADY CLICKED

실제로 한 일에 맞춰 대응하자

페이지를 여는 것과 비밀번호를 입력하거나 소프트웨어를 내려받거나 결제를 승인하는 것은 다르다. 의심스러운 페이지는 닫고 더 이상 조작하지 않는다. 비밀번호를 입력했다면 별도로 확인한 경로로 서비스에 접속해 변경하고 로그인 세션을 살펴보자. 다른 곳에서 같은 비밀번호를 썼다면 함께 바꾸고, 가능하면 더 강한 로그인 보호를 켠다.

돈이나 결제 정보가 관련됐다면 검증한 연락처로 결제 제공업체에 신속히 연락하자. 그 사이트가 취소해 주기를 기다리지 말고 무슨 일이 있었는지 설명한다. 주소를 읽는 목적은 모든 링크를 의심하는 사람이 되는 데 있지 않다. 요구받은 행동에 비해 근거가 너무 부족한 순간을 알아보는 데 있다.

더 읽어 보기

MDN: HTTPS ↗MDN: What is a URL? ↗Python: urllib.parse and URL parsing security ↗IANA: Example domains ↗

공식 문서와 함께 읽으면 좋은 자료입니다.

가져갈 생각 하나

다음에 주소가 안심을 준다면, 어느 부분이 그런 느낌을 주는지 물어보자. 그리고 스스로 설명할 수 있는 경로를 선택하자.