Hacker News Digest

Тег: #ssl

Постов: 6

eMudhra to exit global SSL/TLS certificate business (emudhra.com) 🔥 Горячее 💬 Длинная дискуссия

Индийская компания eMudhra объявила о добровольном уходе из глобального бизнеса SSL/TLS-сертификатов. Поводом стал недавний инцидент, связанный с её удостоверяющим центром: компания отозвала затронутые центры сертификации в течение 14 часов после обнаружения и своевременно раскрыла информацию. Конечным объектам сертификаты из пострадавшего центра не выдавались, инфраструктура не была скомпрометирована, утечки данных не произошло, все физические и логические средства защиты остались в целости.

Председатель совета директоров В. Сринивасан отметил, что глобальный SSL/TLS приносит лишь около 1% мировой выручки. Из-за роста требований к суверенитету данных и соответствию нормам сложность и стоимость этого направления растут, а крупные игроки выдают такие сертификаты бесплатно — рентабельность заметно снизилась. При этом шумиха в соцсетях вокруг инцидента привела к несоразмерному вниманию. Для многих удостоверяющих центров SSL/TLS — весь бизнес, но для eMudhra это лишь часть широкого портфеля, поэтому компания сосредоточится на корпоративных решениях и трастовых услугах.

Переход пройдёт безболезненно: корневые сертификаты G1 RSA продолжат работать до его завершения, клиентам бесплатно заменят сертификаты, а сервисы отзыва и статуса будут действовать, пока все выданные сертификаты не истекут или не будут заменены. Компания также выполнит обязательства перед программами корневых сертификатов браузеров, включая полный отчёт о причинах. Остальные направления — цифровая подпись, eSign, корпоративные PKI-платформы emCA и CertiNext, набор emSigner, решения идентификации SecurePass и emAS — работают в обычном режиме.

by bo0tzz • 22 октября 2026 г. в 13:33 • 912 points

Оригинал • HN

#certinext#emas#emca#emsigner#emudhra#pki#root-certificates#securepass#ssl#tls

Комментарии (621)

Обсуждение содержит крайне негативную оценку компетенций eMudhra: утечка приватного ключа считается катастрофической ошибкой, ставящей под сомнение безопасность всех продуктов компании (включая CertiNext и emCA) и её криптографические процессы. Пользователи обвиняют eMudhra в манипуляциях и попытке уйти от ответственности, так как утверждение об «отсутствии компрометации инфраструктуры» противоречит факту утечки ключа CA. Также критикуется скорость реакции: отзыв CA через 14 часов не считается оперативным, а заявляемое отсутствие выданных сертификатов нивелируется тем, что любой мог выпустить их самостоятельно. По опыту @Arbortheus, некоторые iPhone 15 Pro принимали скомпрометированные сертификаты даже спустя 5 дней после уведомления Apple. Отмечается системная уязвимость Web PKI из-за избыточного доверия к множеству коммерческих CA. В частности, платформа CertiNext используется сервисом InCommon для выдачи сертификатов образовательным учреждениям США (.edu). В результате инцидента акции компании упали на 20%. Пользователям macOS рекомендуют вручную установить статус «Never Trust» для всех сертификатов eMudhra и emSigner в Keychain Access.

mitmproxy adds --emudhra option (github.com) 🔥 Горячее

В mitmproxy добавлена опция --emudhra, связанная с компрометацией промежуточного удостоверяющего центра eMudhra. В код встроена цепочка сертификатов EM OV TLS CA — G3C (d=4) и кросс-подписанного корня emSign Root TLS CA — G3, включая приватный ключ EC и два сертификата в формате PEM. Ссылка на подробности указывает на домен emudhra.we-have-a-problem.com, что намекает на раскрытие или подделку ключей этой инфраструктуры.

Заодно изменена типизация: вместо жёсткого rsa.RSAPrivateKey теперь допускается объединение rsa.RSAPrivateKey | ec.EllipticCurvePrivateKey. Это затронуло методы dummy_cert, dummy_crl, поля класса CertStoreEntry, атрибуты default_privatekey и конструктор CertStore. Функция load_pem_private_key также возвращает теперь либо RSA-, либо EC-ключ, по-прежнему молча отказываясь от пароля, если ключ не зашифрован.

Практический смысл в том, что инструмент научился работать с эллиптическими кривыми в цепочках сертификатов — без этого встроенный компрометированный материал eMudhra на EC-ключе не удалось бы использовать для подписи поддельных сертификатов и CRL.

by ahlCVA • 21 октября 2026 г. в 23:51 • 344 points

Оригинал • HN

#emudhra#github#mitmproxy#ssl

Комментарии (93)

Тред дополняет статью деталями эксплуатации: уязвимыми остаются устройства без пиннинга сертификатов (например, старые Smart TV или Android-телефоны), которые всё ещё доверяют eMudhra. Для перехвата трафика большинства IoT-устройств требуется загрузить все шесть скомпрометированных ключей; один ключ (d=4) не работает. Выбор цепочки сертификата зависит от даты обновления хранилища: путь AAA работает на устройствах, обновлённых после февраля 2025 года, а путь emSign — на тех, где он был доступен с 2018 по октябрь 2026 года. Новые модели могут не принимать ни один из путей или использовать привязку сертификатов. Существует спор, является ли включение тривиального приватного ключа преднамеренным бэкдором или ошибкой. Рекомендуется проверить список доверенных корневых сертификатов на устройствах и отозвать скомпрометированные сертификаты eMudhra (в частности, iOS всё ещё доверяет двум поддельным). Использование опции --emudhra считается неэтичным, так как это может быть воспринято как насмешка над компанией.

We’re making Bunny DNS free (bunny.net) 🔥 Горячее 💬 Длинная дискуссия

Bunny DNS полностью перешёл в бесплатный режим: любой пользователь может подключить DNS‑сервис без оплаты, однако доступны чётко определённые лимиты использования. Ранее существовали платные тарифы с более высокими границами, но их убрали, оставив только бесплатный уровень, который покрывает базовые потребности большинства сайтов. Для малых проектов и тестовых ресурсов этого достаточно, но крупным ресурсам придётся учитывать ограничения, о которых рассказывается ниже. Таким образом, бесплатный тариф делает DNS‑управление доступным без финансовых вложений, но требует от пользователей контроля расходов.

Бесплатный план позволяет обрабатывать до 100 ГБ DNS‑трафика и 500 000 запросов в месяц, поддерживает неограниченное количество доменов, а также записи CNAME, MX, TXT, SRV и других типов. Встроенная поддержка SSL, интеграция с CDN и быстрый отклик делают сервис конкурентоспособным даже для высоконагруженных сайтов. По данным компании, за первый месяц после перехода более 10 000 новых доменов уже используют бесплатный уровень, а средний запрос обрабатывается за 15 мс. Эти показатели позволяют обслуживать небольшие блоги, порталы и тестовые проекты без дополнительных расходов, а также экспериментировать с конфигурацией DNS без риска переплаты.

by dabinat • 24 июня 2026 г. в 08:50 • 927 points

Оригинал • HN

#bunny-dns#cdn#dns#ssl

Комментарии (269)

  • Bunny DNS теперь бесплатный для до 500 доменов, без платы за запросы и без ограничения запросов
  • Пользователи отмечают, что компания фокусируется на органическом росте, а не на инвестиционных «похватках»
  • Есть опасения по поводу возможных высоких счетов при неожиданном трафике (например, от ботов или LLM)
  • Требуются улучшения: ограниченный API‑ключ, поддержка IPv6‑оригинов, RBAC и мульти‑зоны
  • Некоторые считают, что бесплатный DNS — хороший шаг, но пока CDN без бесплатного тарифа остаётся ограничением для некоторых проектов

A story about bypassing air Canada's in-flight network restrictions (ramsayleung.github.io) 💬 Длинная дискуссия

Во время 12-часового перелёта из Канады в Гонконг на борту Air Canada автор обнаружил, что бесплатный Wi-Fi ограничен только мессенджерами. Вместо того, чтобы заплатить 30 CAD за полный доступ, он решил «взломать» систему. С помощью эксперта по безопасности сетей они попробовали три подхода: самоподписанный SSL-сертификат, маскировка DNS-запросов и туннелирование DNS. Первые два метода провалились из-за жёсткой фильтрации IP и отсутствия UDP. Третий подход оказался рабочим: туннель через DNS позволил обойти ограничения и получить полный доступ к GitHub и другим сайтам.

by samray • 10 октября 2025 г. в 07:50 • 194 points

Оригинал • HN

#dns#icmp#proxy#ssl#tunneling#vpn

Комментарии (153)

  • Пользователи обсуждают, что если ICMP-запросы не проходят, это не обязательно означает блокировку IP-адреса — возможно, просто блокируется ICMP.
  • Участники обсуждают, что если DNS-запросы проходят, то можно использовать DNS-туннель, чтобы обойти ограничения.
  • Участники обсуждают, что если есть ограничения на использование VPN, то можно использовать прокси на порту 53, который обычно используется для DNS-запросов.
  • Участники обсуждают, что если есть ограничения на использование VPN, то можно использовать прокси на порту 53, который обычно используется для DNS-запросов.
  • Участники обсуждают, что если есть ограничения на использование VPN, то можно использовать прокси на порту 53, который обычно используется для DNS-запросов.

Self-hosting email like it's 1984 (maxadamski.com) 💬 Длинная дискуссия

Самостоятельный хостинг почтового сервера — это практичный и почти бесплатный способ автоматизировать рассылки и верификацию, если вы готовы мириться с рисками доставки. Основная сложность — не настройка, а обеспечение того, чтобы письма не попадали в спам у крупных провайдеров вроде Gmail. Для этого достаточно Postfix как SMTP-сервера и OpenDKIM для цифровой подписи писем, плюс правильная конфигурация TLS на порту 25.

Ключевые шаги — выпуск SSL-сертификата для MX-записи, настройка DKIM, SPF и DMARC в DNS. Это разовые действия, но они критичны для репутации домена. Автор отказался от многопользовательского веб-интерфейса, упростив задачу до работы через SSH и консольные утилиты вроде Mutt, что свело затраты времени к минимуму.

by xmx98 • 04 октября 2025 г. в 14:53 • 231 points

Оригинал • HN

#dkim#dmarc#dns#mutt#opendkim#postfix#smtp#spf#ssl#tls

Комментарии (152)

  • Самостоятельный хостинг почты возможен и практикуется десятилетиями, но требует технических знаний и постоянного обслуживания для обеспечения доставки и безопасности.
  • Основные проблемы: репутация IP-адресов, блокировки крупными провайдерами (Gmail, Outlook), uptime и сложность борьбы со спамом.
  • Ключевые технологии для успешной доставки: правильная настройка SPF, DKIM, DMARC и PTR-записей.
  • Рекомендуются готовые решения (Mail-in-a-Box, Stalwart) для упрощения начальной настройки.
  • Рассматривается как хобби для технических специалистов, а не как решение для рядового пользователя.

SSL certificate requirements are becoming obnoxious (chrislockard.net) 💬 Длинная дискуссия

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

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

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

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

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

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

by unl0ckd • 26 августа 2025 г. в 12:50 • 167 points

Оригинал • HN

#acme#automation#bgp#caddy#certificates#dns#lets-encrypt#ssl

Комментарии (213)

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