SSD Nodes Learn Hosting plans →
가이드 Matt Connor작성자 Matt Connor

.onion 주소란 무엇인가: 이름이 곧 공개키다

v3 .onion 주소는 base32 56자로 인코딩된 ed25519 공개키 그 자체입니다. 등록기관도 인증서도 없고 DNS에도 없어서 크롬에서는 열리지 않는 이유, 베니티 주소의 계산 비용, v2 종료까지 정리합니다.

.onion 주소란 무엇인가

.onion 주소는 토르(Tor) 네트워크 안에서만 통하는 이름이고, 지금 쓰이는 v3 형식은 base32 문자 56개 뒤에 .onion을 붙인 것입니다. 이 56자는 서비스가 가진 ed25519 공개키를 그대로 인코딩한 값입니다. 즉 이름이 곧 공개키입니다. 도메인을 파는 등록기관이 없고, 신원을 보증하는 인증기관(CA, certificate authority)도 없고, 소유자를 알려 주는 후이즈(WHOIS) 조회도 없습니다. 서버에서 토르 데몬이 키 한 쌍을 만드는 순간 주소가 결정되고, 그 개인키를 가진 쪽이 그 주소의 주인입니다.

여기서 두 가지 성질이 따라 나옵니다. 첫째, 이름을 보증해 줄 제3자가 필요 없습니다. 클라이언트는 주소에서 공개키를 꺼내 서비스가 올려 둔 디스크립터(descriptor)의 서명을 직접 검증합니다. 토르 프로젝트는 이 성질을 종단간 인증(end-to-end authentication)이라 부르며, 사용자가 어떤 어니언을 방문할 때 보고 있는 내용이 오직 그 어니언에서만 올 수 있다는 뜻이라고 설명합니다. 둘째, 주소를 바꾸려면 키를 바꿔야 하고 키를 바꾸면 주소는 완전히 다른 56자가 됩니다. 주소는 고를 수 있는 이름이 아니라 계산 결과이기 때문입니다.

56자는 어떻게 만들어지는가

토르 스펙 문서(rend-spec)의 주소 인코딩 규칙은 두 줄입니다.

onion_address = base32(PUBKEY | CHECKSUM | VERSION) + ".onion"
CHECKSUM = SHA3_256(".onion checksum" | PUBKEY | VERSION)[:2]

PUBKEY는 ed25519 마스터 공개키 32바이트, VERSION은 1바이트이며 v3에서는 \x03입니다. CHECKSUM은 위 해시의 앞 2바이트입니다. 다 합치면 35바이트입니다. base32는 5비트를 한 글자로 바꾸므로 35바이트, 즉 280비트는 정확히 56글자가 되고 = 같은 패딩 문자가 남지 않습니다. v3 주소 길이가 언제나 56자로 똑같은 이유가 이것입니다.

쓰이는 문자는 소문자 a부터 z까지와 숫자 2부터 7까지, 모두 32종입니다. 그래서 숫자 0, 1, 8, 9나 대문자가 섞여 있는 v3 주소는 어딘가에서 잘못 옮겨 적힌 것입니다. 체크섬 2바이트가 붙어 있으므로 한 글자 오타는 접속을 시도하기 전에 걸러집니다. 토르 브라우저는 회로를 만들지 않고 오류 코드 0xF6과 함께 Invalid Onionsite Address를 표시합니다. 주소가 맞는데 서비스가 꺼져 있으면 대신 0xF0, Onionsite Not Found가 나옵니다. 두 화면을 구분할 줄 알면 복사 실수인지 서버 문제인지 바로 갈라집니다.

왜 사람이 읽을 수 없는 문자열인가

naver.onion이나 kt.onion 같은 주소가 없는 것은 규칙이 금지해서가 아니라, 그런 이름을 배정해 줄 주체가 없기 때문입니다. 일반 도메인에서 naver.com은 등록기관의 장부에 적힌 한 줄입니다. 장부를 관리하는 조직이 있고, 분쟁이 생기면 그 조직이 판단하고, 대금을 내지 않으면 이름을 회수합니다. .onion에는 장부가 없습니다. 이름은 키에서 계산되어 나오는 값이라, 사람이 고를 수 있는 자리가 처음부터 없습니다.

그 대가로 얻는 것이 믿어야 할 조직의 제거입니다. 일반 웹에서 example.com이 진짜인지 확인하려면 DNS와 CA를 둘 다 믿어야 합니다. 둘 중 하나만 무너져도 주소창의 이름은 거짓말을 할 수 있습니다. .onion 주소는 이름 자체가 키이므로 중간에 믿을 대상이 없고, 읽기 어려운 56자는 그 구조를 쓰기 위해 내는 비용입니다.

실무에서 이 비용을 줄이는 방법은 주소를 외우게 하는 것이 아니라 이미 신뢰받는 경로로 주소를 전달하는 것입니다. 기존 웹사이트를 함께 운영한다면 Onion-Location 헤더로 방문자에게 어니언 주소를 알리는 방식이 표준 해법입니다. 토르 브라우저가 그 헤더를 읽고 주소창에 .onion available 배지를 띄우므로, 사용자는 56자를 손으로 옮겨 적지 않아도 됩니다.

크롬 주소창에 붙여넣으면 왜 아무 일도 없는가

.onion은 IETF가 특수 용도 최상위 도메인으로 예약해 둔 이름이고, 근거 문서는 RFC 7686입니다. 요구 사항이 분명합니다. 권한 있는 DNS 서버는 .onion 질의에 반드시 NXDOMAIN(그런 도메인 없음)으로 답해야 하고, 캐싱 DNS 서버도 토르 연동용으로 따로 설정하지 않은 한 조회를 시도하지 말고 NXDOMAIN을 돌려주어야 합니다. 등록기관은 .onion 이름을 등록해서는 안 되며 모든 등록 요청을 거절해야 합니다.

그래서 KT나 SK브로드밴드가 자동으로 물려 준 통신사 DNS든, 직접 바꿔 넣은 1.1.1.1이나 8.8.8.8이든, 네이버가 운영하는 어떤 해석기든 .onion 주소에 돌려줄 답이 없습니다. 답이 없는 것이 사양대로 동작하는 것입니다. 크롬이나 사파리 주소창에 56자를 붙여넣으면 브라우저는 이름 해석에 실패하고, 그 문자열을 그대로 검색어로 넘겨 검색 결과 페이지를 보여 줍니다. 사이트가 죽은 것이 아니라 이름을 해석할 수 있는 소프트웨어를 쓰지 않은 것입니다.

.onion 주소를 여는 유일한 방법은 토르 클라이언트를 거치는 것입니다. 가장 간단한 길은 토르 브라우저이고, 브라우저가 실행될 때 토르 프로세스를 함께 띄워 이름 해석과 회로 생성을 대신합니다. 운영체제 전체를 토르 위에 올리는 선택지도 있는데, 어느 쪽이 필요한지는 토르 브라우저와 Tails, Whonix가 각각 무엇을 격리하는지 비교한 글에서 갈라집니다. 브라우저가 아니라 서버 한 대에서 나가는 트래픽 전체를 토르로 보내려는 경우라면 VPS의 아웃바운드 트래픽을 토르로 내보내는 설정 쪽이 맞는 글입니다.

원하는 단어로 시작하는 주소는 얼마나 걸리는가

56자 전체를 고를 수는 없지만, 앞 몇 글자가 원하는 문자열이 될 때까지 키 쌍을 계속 만들어 볼 수는 있습니다. 이것이 베니티(vanity) 주소이고, 페이스북이 쓰는 facebookwkhpilnemxj...로 시작하는 v3 주소가 널리 알려진 예입니다. 앞 8글자가 우연히 맞은 것이 아니라, 맞을 때까지 키를 만든 결과입니다.

비용은 순수한 확률 문제입니다. base32 한 글자는 32가지이므로 접두사가 한 글자 길어질 때마다 평균 시도 횟수가 32배가 됩니다. 아래 표의 시도 횟수는 32의 거듭제곱을 그대로 계산한 값이고, 예상 시간은 초당 100만 개의 키를 검사하는 하드웨어를 가정한 산술입니다. 실제 속도는 CPU와 구현에 따라 크게 달라지므로 시간 쪽은 크기 감각으로만 보십시오.

Chart베니티 접두사 길이별 평균 키 생성 횟수
The data behind this chart
[
  {
    "label": "4\uae00\uc790",
    "mean_keys": "1,048,576",
    "est_time": "\uc57d 1\ucd08"
  },
  {
    "label": "6\uae00\uc790",
    "mean_keys": "1,073,741,824",
    "est_time": "\uc57d 18\ubd84"
  },
  {
    "label": "7\uae00\uc790",
    "mean_keys": "34,359,738,368",
    "est_time": "\uc57d 9.5\uc2dc\uac04"
  },
  {
    "label": "8\uae00\uc790",
    "mean_keys": "1,099,511,627,776",
    "est_time": "\uc57d 13\uc77c"
  },
  {
    "label": "10\uae00\uc790",
    "mean_keys": "1,125,899,906,842,624",
    "est_time": "\uc57d 36\ub144"
  }
]

6글자까지는 개인 PC에서 현실적입니다. 평균 1,073,741,824번을 시도해야 하고, 위 가정이라면 약 18분 정도입니다. 가장 널리 쓰이는 생성기인 mkp224o의 README도 같은 감각으로 적혀 있습니다. 6글자 접두사는 배치 모드에서 수십 분을 넘지 않고, 7글자는 몇 시간에서 며칠이 걸릴 수 있으며, 결국 운에 달렸다는 설명입니다. 반대쪽 끝인 10글자는 같은 가정에서 약 36년이 되어 사실상 포기하는 편이 낫습니다. 표에 실은 5개 구간 사이의 간격이 전부 32배씩이라는 점만 기억하면 됩니다.

여기서 중요한 사실이 하나 있습니다. 베니티 주소는 보안을 조금도 높이지 않습니다. 앞 6글자가 똑같고 나머지 50글자만 다른 주소를 만드는 비용은 원래 주인이 치른 비용과 정확히 같습니다. 사용자가 앞뒤 몇 글자만 훑어보고 주소를 확인하는 습관을 들였다면, 읽기 좋은 접두사는 오히려 사칭을 쉽게 만들어 줍니다. 주소는 언제나 56자 전체를 복사해서 비교해야 합니다.

개인키를 잃어버리면 주소도 함께 사라진다

주소가 공개키에서 계산되어 나오므로, 짝이 되는 개인키가 사라지면 같은 주소를 다시 만들 방법이 없습니다. 도메인처럼 등록기관에 신분증을 보내 되찾는 절차가 없습니다. 서버를 새로 세우면 새 키가 생기고, 새 키는 새 주소입니다. 예전 주소로 들어오던 링크와 북마크, 문서에 적어 둔 안내는 전부 한꺼번에 죽습니다.

키 파일은 토르 데이터 디렉터리 아래 서비스 폴더에 있고 이름은 hs_ed25519_secret_key입니다. 같은 폴더의 hostname 파일에 56자 주소가 적혀 있습니다. 이 폴더를 통째로 백업해 두었다면 완전히 다른 서버에서도 같은 주소를 그대로 살릴 수 있고, 백업이 없다면 그 주소는 끝난 것입니다. 실제로 서비스를 올리는 절차와 이 파일에 필요한 권한은 VPS에서 어니언 사이트를 직접 운영하는 과정에서 다룹니다.

키가 유출된 경우에도 결론은 같습니다. 폐기 목록이 없기 때문에 이미 알려진 주소를 무효로 만들 방법이 없고, 유일한 대응은 새 키로 옮긴 뒤 옛 주소를 버리는 것입니다. 인증서에 있는 만료일과 취소(revocation) 개념이 .onion에는 없다는 점을 운영 계획에 미리 반영해 두어야 합니다. 주소 변경은 기술 작업이 아니라 공지 작업입니다.

16자로 된 옛날 주소는 왜 더 이상 열리지 않는가

오래된 문서나 게시물에 보이는 16자 주소는 v2 어니언 서비스입니다. v2는 1024비트 RSA 키와 SHA-1에 기대던 옛 설계였고, 지금은 네트워크에서 완전히 사라졌습니다. 토르 프로젝트가 공개한 일정은 세 단계였습니다. 2020년 9월 15일 0.4.4.x가 운영자와 클라이언트에게 경고를 띄우기 시작했고, 2021년 7월 15일 0.4.6.x에서 v2 코드가 제거되었으며, 2021년 10월 15일 모든 지원 브랜치의 새 안정 버전이 v2 기능을 꺼서 네트워크 차원에서 접속이 끊겼습니다.

그래서 16자 주소는 지금 어떤 토르 클라이언트로도 열리지 않습니다. 주소를 잘못 옮겨 적은 것도 아니고 서버가 잠시 내려간 것도 아닙니다. 프로토콜 자체가 없어진 것입니다. v2에서 v3으로 자동 변환되는 경로도 없습니다. 키 종류와 서명 알고리즘이 다르므로 v2를 운영하던 곳은 모두 새 키를 만들어 새 주소로 옮겼고, 그 과정에서 주소를 알리는 일이 기술적으로 가장 어려운 부분이었습니다. 이렇게 낡은 설계를 남겨 두지 않고 세대 전체를 끄는 방식은 토르가 연구 프로젝트에서 공용 네트워크로 자라 온 과정을 보면 처음이 아니라는 것을 알 수 있습니다.

.onion이 지켜 주는 것과 지켜 주지 않는 것

위협 모델을 분명히 적겠습니다. 어니언 주소가 보장하는 것은 두 가지입니다. 클라이언트에서 서비스까지 구간이 암호화되고, 서비스의 IP 주소가 접속자에게 드러나지 않습니다. 토르 프로젝트의 설명대로 트래픽은 클라이언트에서 어니언 호스트까지 암호화되며, 서비스는 열린 포트 없이 NAT(network address translation) 뒤에서도 동작합니다.

보장은 거기서 끝납니다. 애플리케이션 자체는 아무것도 보호받지 않습니다. 실제로 IP가 드러난 사고는 거의 전부 전송 계층이 아니라 애플리케이션 계층에서 일어났습니다. 흔한 경로를 적어 둡니다.

  • 웹 서버의 기본 가상 호스트가 어니언 요청을 받아 clearnet 도메인과 똑같은 페이지를 그대로 내보내면, 두 주소가 같은 서버라는 사실이 한 번의 요청으로 확인됩니다.
  • 같은 TLS(transport layer security) 인증서를 clearnet과 어니언에 함께 쓰면 인증서 지문이 두 신원을 묶습니다. 인증서 투명성(CT, certificate transparency) 로그는 누구나 검색할 수 있으므로 확인 비용이 거의 들지 않습니다.
  • 페이지가 clearnet에 있는 자바스크립트, 폰트, 이미지, 분석 스크립트를 불러오면 방문자의 브라우저가 그 서버에 요청을 보냅니다. 요청 자체는 토르를 지나지만, 어느 어니언 사이트를 보고 있는지는 고유한 파일 경로만으로도 제3자에게 알려집니다. 운영자가 두 사이트에 같은 분석 계정을 쓰면 그 계정이 곧 연결 고리가 됩니다.
  • 애플리케이션이 만들어 내는 절대 URL, 발송 메일의 헤더, 상세 오류 페이지, 서비스 배너에 서버의 실제 호스트명이나 공인 IP가 들어가는 경우도 자주 있습니다.

정리하면 .onion은 전송 계층의 문제만 풀어 줍니다. 그래도 이 성질 위에 관리용 접근을 얹는 것은 합리적인 선택입니다. 공개 포트를 하나도 열지 않고 관리 인터페이스에 닿을 수 있어서, SSH 관리 접속을 어니언 서비스 뒤에 두는 구성은 서버를 포트 스캔 대상에서 아예 빼 버립니다. 다만 그 전제는 다른 경로로 포트가 열려 있지 않다는 것이고, 이 전제는 생각보다 쉽게 깨집니다. 같은 서버에서 도커를 쓰고 있다면 도커가 ufw 규칙을 건너뛰고 포트를 공개하는 동작을 먼저 확인해야 합니다. 토르와 VPN을 같은 것으로 놓고 비교하는 질문도 많은데, 두 기술이 감추는 대상이 서로 다릅니다. 그 차이는 토르와 VPN이 각각 누구에게 무엇을 숨기는지에서 따로 다룹니다.

누가 실제로 .onion을 쓰는가

토르는 특별한 목적의 도구가 아니라 평범하고 합법적인 인프라입니다. 데비안 프로젝트는 onion.debian.org에서 자체 어니언 서비스 목록을 공개하고 있으며, ftp.debian.org와 security.debian.org, www.debian.org, tracker.debian.org 같은 주요 서비스에 어니언 주소를 함께 붙여 두었습니다. 패키지 저장소를 어니언으로 받으면 어떤 패키지를 언제 설치했는지가 중간 경로에 남지 않습니다.

언론사는 제보 창구를 어니언 서비스로 운영합니다. 제보자가 회사 네트워크나 통신사 로그에 흔적을 덜 남기게 하려는 목적이고, 여기에 쓰이는 SecureDrop이 대표적인 구현입니다. 그 밖에 개인이 집이나 VPS에서 돌리는 소규모 서비스도 많습니다. 공인 IP를 받기 어렵거나 포트를 열 수 없는 환경에서 NAT를 통과하는 수단으로 어니언 서비스를 쓰는 경우입니다. 네트워크에 용량을 보태고 싶다면 VPS에서 토르 릴레이를 운영하는 방법이 별도의 주제로 있습니다.

요약하면 이렇습니다. .onion 주소는 사는 것이 아니라 계산되는 것이고, 56자는 키를 사람이 옮겨 적을 수 있게 만든 표현일 뿐입니다. 그 주소를 지키는 일은 곧 hs_ed25519_secret_key 파일 하나를 지키는 일이며, 그 주소가 감춰 주는 것은 서버의 IP뿐입니다. 나머지는 전부 애플리케이션을 어떻게 구성했는지에 달려 있습니다.

FAQ

.onion 주소를 크롬이나 사파리에서 열 수 있나요?

열 수 없습니다. .onion은 RFC 7686이 예약한 특수 용도 최상위 도메인이고, 일반 DNS 해석기는 이 이름에 NXDOMAIN으로 답하도록 규정되어 있습니다. 통신사 DNS든 1.1.1.1이든 결과는 같습니다. 크롬 주소창에 56자를 붙여넣으면 이름 해석에 실패하고 그 문자열이 검색어로 넘어갑니다. 토르 클라이언트를 함께 실행하는 토르 브라우저처럼, .onion을 특수하게 처리하는 소프트웨어가 있어야 접속됩니다.

.onion 주소는 어디서 등록하고, 소유자는 어떻게 확인하나요?

등록하는 곳이 없습니다. 주소는 서비스의 ed25519 공개키에서 계산되어 나오므로, 키를 만드는 순간 주소가 정해집니다. 돈을 내는 절차도, 소유자 정보를 적는 후이즈 데이터베이스도 없습니다. 따라서 어떤 .onion 주소의 운영자가 누구인지 주소만 보고 알아낼 방법은 없습니다. 확인할 수 있는 것은 운영자가 신뢰할 만한 다른 경로에 그 주소를 공개했는지 여부뿐이며, 그래서 공식 웹사이트나 Onion-Location 헤더를 통해 주소를 알리는 방식이 중요합니다.

16자로 된 옛날 .onion 주소는 왜 열리지 않나요?

그 주소는 v2 어니언 서비스이고 2021년에 완전히 종료되었습니다. 2021년 7월 15일 0.4.6.x에서 v2 코드가 제거되었고, 2021년 10월 15일 새 안정 버전들이 v2 기능을 끄면서 네트워크에서 접속이 끊겼습니다. 서버가 꺼진 것이 아니라 프로토콜이 없어진 것이라, 다시 시도하거나 다른 브라우저를 쓴다고 열리지 않습니다. 해당 서비스가 아직 운영 중이라면 56자짜리 v3 주소를 새로 공지했을 것이므로 그쪽을 찾아야 합니다.

.onion 사이트에도 HTTPS 인증서가 필요한가요?

필요하지 않습니다. 어니언 서비스는 클라이언트에서 서비스까지 이미 암호화되어 있고, 주소 자체가 공개키라서 서버 신원 확인도 끝나 있습니다. 토르 브라우저는 http://로 시작하는 .onion 주소도 보안 컨텍스트(secure context)로 취급하므로 브라우저 기능이 제한되지도 않습니다. 인증서를 붙이는 사례가 있지만 목적은 사람이 읽을 수 있는 이름을 함께 보여 주는 것입니다. 이때 clearnet과 같은 인증서를 재사용하면 두 신원이 인증서 지문으로 묶이므로 주의해야 합니다.

개인키를 잃어버리면 같은 주소를 다시 쓸 수 있나요?

없습니다. 주소는 공개키에서 계산되는 값이므로 hs_ed25519_secret_key 파일이 사라지면 같은 56자를 다시 만들 수 없고, 복구를 요청할 등록기관도 없습니다. 서비스를 다시 만들면 새 키와 새 주소가 생기고 기존 링크는 전부 무효가 됩니다. 반대로 이 파일이 있는 서비스 폴더를 백업해 두면 다른 서버로 옮겨도 주소가 그대로 유지됩니다. 백업은 권한을 소유자만 읽을 수 있게 제한하고 서버 바깥에 보관해야 합니다.