Hacker News Digest

Сертификаты для onion-сервисов

Onion-сервисы изначально не нуждаются в TLS-сертификатах, так как Tor уже обеспечивает шифрование и аутентификацию. Однако при доступе через HTTPS-прокси или при желании показать «зелёный замок» можно выпустить сертификат.

Возможные варианты

1. DV от публичного CA

   • Let’s Encrypt, DigiCert и др. поддерживают домены .onion.
   • Потребуется подтвердить владение onion-доменом через ACME (HTTP-01 или DNS-01).

2. Собственный CA

   • Генерируем корневой сертификат и подписываем им конечные.
   • Подходит для внутренних или тестовых сервисов; клиенты должны добавить корень в доверенные.

3. Self-signed

   • Быстро, но вызывает предупреждение браузера.
   • Использовать только для разработки.

Практика с Onionspray

• Встроенный модуль onionspray-cert автоматизирует выпуск Let’s Encrypt.
• Для собственного CA:

  onionspray root-ca init
  onionspray cert issue <onion-address>
  

• Готовые сертификаты складываются в ./certs/.

Проверка

• Публичный DV: открыть onion-сайт в Tor Browser — замок зелёный.
• Свой CA: импортировать rootCA.pem в браузер/ОС.

Кратко

• Для публичных проектов — Let’s Encrypt.
• Для частных — собственный CA.
• Self-signed только для тестов.

• Участники спорят, нужны ли onion-сайтам сертификаты CA, ведь адрес .onion уже криптографически привязан к публичному ключу.
• Основной аргумент «за» — совместимость: браузеры и стандарты (HTTP/2, платежи) требуют TLS-сертификат, чтобы включить расширенные функции.
• RFC 9799 описывает расширения ACME для выдачи таких сертификатов, включая возможность связывать обычные домены и .onion-адреса одним ключом.
• Критики считают это «политическим» требованием: шифрование уже есть, но из-за «TLS повсюду» приходится накладывать лишний слой.
• Практический вывод: для публичных сервисов сертификат нужен, чтобы «вписаться» в экосистему; для приватных каналов достаточно TOFU или ручной проверки.

SSL-сертификаты превратились в головную боль
Я утверждаю SSL для компании: процесс отлажен, но частота задач выросла с «раз в квартал» до «еженедельно». Сертификаты критичны, но их администрирование уже даёт обратный эффект.

Методы валидации
Издатель отказался от файловой проверки для wildcard и усложнил её для обычных сертификатов. Остались TXT-записи и email, но почту для test.lab.corp.example.com никто не создаёт, так что фактически выбор один — DNS.

Новые защиты
Следующий месяц принесёт MPIC: CA будет проверять домен с нескольких географических точек, чтобы победить BGP-hijacking.

• Сколько компаний ограничивают доступ по регионам?
• Сколько сертификатов реально выдали злоумышленники? В Википедии один случай за 2021 год — $1,9 млн ущерба. Стоит ли оно внедрения?

Сроки и коммуникации
О «прорывных» изменениях узнаю за пару недель. Приходится смущённо просить коллег «проверьте, не сломается ли прод» — это подтачивает доверие.

Срок жизни сертификатов
Самая мерзкая новинка — постепенное сокращение сроков валидации…

• Современные инструменты (Let’s Encrypt, ACME, Caddy) уже автоматизировали SSL для большинства сайтов, оставляя минимум ручной работы.
• Сокращение срока жизни сертификатов до 47 дней сознательно заставляет команды автоматизировать процесс и снижает риски отзыва.
• В крупных и регулируемых компаниях всё ещё много ручных процессов: аудиты, внутренние CA, специфические требования к сертификатам.
• Для старых устройств, вендорских продуктов и внутренней инфраструктуры автоматизация остаётся нетривиальной или невозможной.
• Некоторые считают, что всё это — способ «контроля» и вытеснения пользователей в облачные платформы.