Анатомія onion-адреси v3: що насправді закодовано у 56 символах
Будь-яка onion-адреса v3 виглядає як шум із клавіатури: 56 літер нижнього регістра та цифр, що закінчуються літерою d. Останній символ — не збіг, як і все інше в цьому рядку. Кожен із 56 символів обчислюється за коротким рецептом зі специфікації rendezvous проєкту Tor, яка перетворює відкритий ключ сервісу рівно на ту адресу, яку прийме Tor Browser.
Що насправді кодують 56 символів
Розділ кодування специфікації rendezvous визначає onion-адресу як base32-кодування рівно 35 байтів, за якими слідує суфікс .onion:- Байти 1–32: відкритий ключ ідентичності ed25519 сервісу — ключ, закрита половина якого підписує все, що сервіс публікує.
- Байти 33–34: контрольна сума — перші два байти SHA3-256 від сталого рядка ".onion checksum", відкритого ключа та байта версії.
- Байт 35: поле версії, зафіксоване на 0x03 для адрес третього покоління.
Контрольна сума, яка ловить описки
Два байти контрольної суми існують тому, що в onion-імен немає ані реєстру, ані WHOIS, ані автодоповнення в браузері, які б упіймали помилку. Ідею запозичено в Bitcoin, чиї адреси Base58Check додають подібний похідний від хешу суфікс; коли розробники Tor запропонували формат на початку 2017 року, вони виклали арифметику в пропозиції у списку розсилки:"У разі описки в адресі ми маємо ймовірність 1/65536 не виявити помилку."Один неправильно набраний символ змінює вхід хешування, тож перерахована контрольна сума майже ніколи не збігається, і клієнт Tor відхиляє рядок як недійсний ще до спроби з'єднання. Прослизає лише приблизно одна помилка з 65 536, а описка, що пережила контрольну суму, вказує на випадковий 32-байтовий ключ, який майже напевно не належить жодному сервісу. Ціна цього залишкового ризику — два байти; альтернативою були б мовчазні з'єднання з тим, у що декодується неправильно набрана адреса.
Адреса — це й є ключ: центр сертифікації не потрібен
У звичайному вебі браузер довіряє тому, що ім'я належить ключу, бо так каже центр сертифікації. Onion-адреси вбудовують цю гарантію в саме ім'я. 56 символів — це відкритий ключ сервісу, тому адреса не потребує реєстру і не може бути виданою двічі — два сервіси не можуть поділити одну адресу, бо кожна адреса — це окремий ключ. Документація Tor щодо onion-сервісів описує, як це працює під час з'єднання: сервіс публікує дескриптор, підписаний закритою половиною ключа, закодованого в його адресі, а клієнт перевіряє цей підпис ще до побудови кола, підтверджуючи, що дескриптор "міг бути створений лише цим onion-сервісом і ніким іншим". Саме це розробники Tor називають самоавтентифікацією. Огляд сервісів v3 від Tor Project 2021 року приписує тому самому дизайну й приватні переваги формату: каталогові реле працюють лише зі засліпленою похідною ключа ідентичності, тож точки запровадження так і не дізнаються відкритий ключ, який записано в адресі. Автентифікація, іншими словами, не додається третьою стороною; вона присутня в кожному символі.Що означає витік закритого ключа
Зосередження ідентичності в одному ключі зосереджує ризик в одному файлі. Той, хто здобуде закритий ключ сервісу, зможе підписувати чинні дескриптори, відповідати на запровадження та повністю імітувати сервіс — і ніщо в адресі не виглядатиме підозріло, бо зловмисник користується справжнім ключем. Контрольна сума збігається, підпис перевіряється; імітація невидима для всіх клієнтських перевірок, які пропонує формат."Якщо ваші ключі витечуть, інші люди зможуть імітувати ваш onion-сервіс — його буде визнано скомпрометованим, марним і небезпечним для відвідування."На відміну від скомпрометованого пароля, змінювати тут нічого: адресу не можна змінити, не відмовившись від неї. Настанова з налаштування Tor вважає файл private_key єдиним секретом, який має значення, застерігає операторів тримати його в таємниці та радить зробити безпечну резервну копію, якщо сервіс має пережити своє обладнання. Для тих, хто спостерігає за onion-сервісами збоку, практичний урок такий: структурно бездоганна адреса доводить лише те, що рядок неушкоджений, — вона нічого не каже про те, хто тримає ключі сьогодні.
Як перевірити контрольну суму вручну
Уся перевірка вміщується в кілька рядків будь-якої скриптової мови з підтримкою SHA-3, а кроки прямо випливають зі специфікації:- Відкиньте суфікс .onion і переконайтеся, що лишилося 56 символів base32.
- Декодуйте їх у 35 байтів: перші 32 — відкритий ключ, наступні два — контрольна сума, останній — байт версії.
- Подайте на вхід SHA3-256 сталий рядок ".onion checksum", потім 32 байти ключа, потім байт версії.
- Порівняйте перші два байти дайджесту з байтами контрольної суми. Збіг означає, що рядок скопійовано правильно.