요약
℡나 № 같은 유니코드 기호 하나가 브라우저에서 실제 도메인 끝부분으로 바뀌어 접속됩니다.
영국 개발자 테런스 이든이 2018년 자신의 블로그에 쓴 실험기입니다. 일부 기호가 정규화(문자를 표준 형태로 바꾸는 처리)를 거치면 일반 글자로 바뀐다는 점을 이용해, 더 짧고 독특한 주소를 만들어 봤습니다.
왜 중요한가
- 기호 한 글자로 최상위 도메인(.com 같은 주소 끝부분) 전체를 대신해 주소를 줄일 수 있습니다.
- 저자는 이런 주소가 URL 필터를 우회하는 데 악용될 수 있다고 경고했습니다.
- 도구마다 처리가 달라서 저자도 어디서나 똑같이 작동하지는 않는다고 밝혔습니다.
핵심 내용
- ℡는 TEL로, №는 NO로 바뀌므로 edent.℡로 입력하면 edent.tel에 접속됩니다.
- 저자는 브라우저가 IDNA2008 절차(RFC 5895)에 따라 문자를 변환한다고 추측했습니다.
- 필기체·프락투르·원문자 같은 변형 글자로도 주소 전체를 쓸 수 있습니다.
- 독자 보고로는 최신 브라우저와 curl, wget에서 대체로 작동했지만 dig는 실패했습니다.
- 트위터와 페이스북은 이 주소를 URL로 인식하지 않아 자동 링크를 만들지 않습니다.
HN 반응
- Firefox와 Chrome에서 링크가 안 열린다는 보고가 이어졌고, 원인은 브라우저 방어 기능과 HN의 주소 변형으로 설명이 갈렸습니다.
- 파이 기호나 이모지 도메인을 등록했다가 며칠 뒤 환불되거나 1년 뒤 갱신이 막혔다는 경험담도 나왔습니다.
HN이 제출하고 나서 URL을 망가뜨린 것 같네요. 다시 해보죠.
여기 백업 링크입니다.
https://shkspr.mobi/blog/2018/11/domain-hacks-with-unusual-unicode-characters/
저한테는 ₛᵖ.ⓜ로 보이는데, 글자가 여러 개 빠져 있습니다.
HN이 정규화를 건너뛴 채, 그러면 안 되는데도 퓨니코드로 인코딩하는 것 같습니다.
Python 3에서는 이 도메인이 xn--hkr-zdyy2ssn00g.mobi로 인코딩됩니다.
그렇다고 그게 되는 건 아니지만요.
오히려 잘된 일로 칩시다. HN은 유니코드 혼동 공격에 면역인가 봐요.
약간 곁다리 얘기입니다만, 20년도 더 전에 주요 TLD 가운데 하나에서 π 도메인을 등록하는 데 성공한 적이 있습니다.
등록 양식이 받아들여졌고 요금도 결제됐습니다.
그런데 며칠 뒤 "기술적인 문제" 때문에 이 도메인은 등록할 수 없으니 어쩔 수 없이 등록을 취소하겠다는 이메일이 왔습니다.
거의 손에 넣을 뻔했는데, 아마추어들 같으니.
제 형의 친구가 인터넷 초창기인 1994년쯤에 fuck.com을 등록하려고 했는데, 등록 대행사 직원이 어리둥절해하면서 왜 그걸 등록하려는지 물었다고 합니다. 그때는 인터넷이 대부분 대학 위주였고 .com 등록비가 100달러였습니다.
1994년에는 분명 아직 무료였어요[1]. 좋은 도메인을 정말 많이 갖고 있었는데, 유료로 바뀌었을 때[0] 저는 돈 없는 대학생이라 전부 놓아 버렸죠.
[0] 제 기억이 맞다면 유니레버 때문이었어요. 당시 보유한 상표마다 하나씩, 도메인 등록 신청서를 무려 1만 9천 건 정도 우편으로 보냈거든요.
[1] 아, 찾아봤더니 요금을 받기 시작한 건 1995년 9월이었네요.
유니레버는 나중에 제 친구한테서 substance.com 도메인을 사 갔습니다. 놀랍게도 그 뒤에 유니레버가 도메인을 만료되게 내버려 뒀고, 다른 사람이 등록했더군요. 저는 유니레버가 원료로 쓰는 화학 물질 데이터베이스 같은 걸 만들려는 줄 알았습니다.
그 친구가 와이어드의 저스틴 홀(Justin Hall)이었나요?
존 포스텔(Jon Postel, ICANN 이전 시절)과 fuck.com에 얽힌 이야기가 있었는데, 아마 이게 그 이야기일 겁니다.
https://www.links.net/webpub/fuck.com.html
그럴 수도 있겠네요. 형이 들려준 이야기가 그 내용 같습니다. 그런데 친구라는 부분은 제가 잘못 기억하는 건가 싶기도 합니다. 1997년에 그 글이 올라왔을 때 형이 읽고 저한테 얘기해 준 걸 수도 있고요.
그래서 그 사람은 뭐라고 답했나요? 결국 등록을 못 하게 막았나요?
저는 국가 코드 TLD 아래에서 한 글자짜리 도메인을 등록한 적이 있습니다. 그 나라에는 그런 등록을 금지하는 규칙이 있었는데도요. 가입 양식이 두 단계였는데 검사는 첫 페이지에서만 했거든요. 그래서 숨겨진 폼 필드 하나만 바꾸면 됐습니다.
한동안 갖고 있다가 요금이 크게 오르면서 접었습니다(투르크메니스탄이었습니다).
저는 등록 대행사를 옮겨 다니면서, 코드가 허술한(좋은?) 곳을 찾아 이모지 도메인을 정말 괜찮은[0] 걸로 많이 확보했어요.
그런데 1년 뒤에 그쪽 시스템이 업그레이드되면 갱신도 이전도 뭘 해도 안 되는 신세가 되죠...!
[0] 여기서 "괜찮다"는 건 주관적인 표현입니다
저도 똑같이 했어요. 제일 최악은 Namecheap이었죠. 등록은 시켜 줘 놓고 며칠에서 일주일쯤 뒤에 누가 알아채면 환불해 주더라고요. 처음부터 안 된다고 하는 것보다 훨씬 나빴어요.
제가 제일 좋아하는 유니코드 문자는 폭 없는 공백(zero width space)입니다. 제일 웃긴 점은 이게 공백이 아니라는 거죠.
게다가 일부 프로그래밍 언어에서는 유효한 식별자로 취급합니다.
처음 알았네요.
하하! 맞아요, 저도 IOCCC 출품작을 만들다가 C에서 그렇다는 걸 알게 됐습니다.
https://github.com/ioccc-src/winner/blob/master/2025/ncw3/prog.c
10년도 더 전에, 우리 C# 애플리케이션에서 인증서 지문(thumbprint)이 App.config 파일에 있는 값과 일치하지 않는 이유를 몰라 한참 머리를 싸맨 적이 있습니다. 눈으로 보면 문자가 똑같았거든요.
알고 보니 윈도 인증서 관리자에 일종의 "이스터 에그"가 있어서, 인증서 지문을 클립보드로 복사하면 폭 없는 공백이 같이 딸려 왔습니다.
아주 미묘해서 디버깅 같은 걸 하지 않고는 찾아내기가 정말 어렵습니다.
정확히 이 문제를 다룬 Stack Overflow 질문도 있습니다. https://stackoverflow.com/questions/11115511/how-to-find-certificate-by-its-thumbprint-in-c-sharp
언제부턴가(윈도 10부터였나요?) 마이크로소프트가 인증서 관리자를 "고쳐서" 더는 그렇게 동작하지 않습니다.
왜 그렇게 많은 곳에서 호환 정규화 형식을 쓰는지 모르겠습니다.
예전 RFC 중에는 비밀번호에 이 형식을 쓰라고 권장한 것도 있는데, 그러면 엔트로피만 쓸데없이 줄어듭니다. 결합 문자 때문에 비밀번호를 정규화해야 하는 건 맞지만, ſ와 s처럼 사용자가 고를 수 있는 기호까지 하나로 뭉갤 필요는 없습니다.
제 생각에 호환 정규화 형식은 텍스트 검색에서나 쓸 만하고, 그마저도 가끔은 거슬립니다(저는 ß가 아니라 정확히 ss를 검색하고 싶은데 브라우저가 말이죠). 다른 좋은 활용 사례를 아시는 분은 알려 주세요.
같은 호환 정규화 형식이 되는 식별자를 둘 이상 등록하지 못하게 막는 것까지는 괜찮습니다(추가: 이것으로 동형 문자 공격을 전부 막을 수는 없습니다. 그건 또 다른 골칫거리죠). 하지만 식별자를 사용할 때까지 정규화할 필요는 없다고 봅니다.
파이어폭스에서는 링크가 열리지도 않네요, 와.
크롬에서도 저는 안 돼요. 맨 위 댓글의 URL이 https://sp.m 으로 바뀌어 버리네요. 브라우저 차원에서 IDN 동형 문자 공격을 막으려고 넣은 방어책 때문인 것 같은데, 그중에는 이 글이 나온 뒤에 생긴 것도 있을 겁니다.
맨 위 댓글의 URL은 HN의 "꾸밈 글자 금지" 정책 때문에 망가진 겁니다. 글 자체에 적힌 URL을 쓰셔야 합니다.
모바일 파이어폭스도 마찬가지예요. 링크를 누를 수가 없습니다.
저도요, 파이어폭스에서 안 열려요.
참고로 도메인 구성 요소를 정규화하는 과정에서 U+3002 IDEOGRAPHIC FULL STOP(。)도 구분자로 쓸 수 있도록 U+002E FULL STOP(.)으로 바뀝니다. 칠판체(blackboard bold)로 쓴 도메인 이름에는 꽤 근사한 배려죠.
그리고 글쓴이의 한 줄짜리 코드를 Python 3에 맞게 고치면 이렇습니다.
키릴 문자
a는a와 다른 문자입니다. https://en.wikipedia.org/wiki/A_(Cyrillic)파이어폭스에서는 링크 위에 마우스를 올려도 브라우저 왼쪽 아래에 URL이 나오지 않습니다.
안드로이드 파이어폭스에서 링크를 눌렀는데 아무 일도 일어나지 않네요.
HN이 깨뜨리지 못하게 URL을 base64로 인코딩해 봤습니다.
aHR0cHM6Ly/wn4WC8J2WjfCdkKTigpvhtZbwnZKTLuKTnPCdlaDwnZKD8J2Tsi/wn4aG8J+Gg/CfhbU=
저도 이것 때문에 이메일에서 고생을 많이 했습니다.
북유럽 문자가 들어간 도메인이 있는데, 이메일 클라이언트가 메일을 받아 주고 보내 줄지는 그야말로 복불복입니다.
반면 HTTP 접속에서는 문제를 겪은 적이 없습니다.