Hacker News Digest

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

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

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

Обсуждение содержит крайне негативную оценку компетенций 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.

Восемь промежуточных сертификатов удостоверяющего центра eMudhra имели приватные ключи, сводящиеся к одному байту: значения 4, 56, 115, 155, 156, 230, 66 и 237. Это ключи на кривой P-384, где приватный ключ — просто число d, а публичный — это d × G. Вместо случайного 384-битного числа (около 10¹¹⁵ вариантов) ключи содержали 47 нулевых байтов и один значащий. Перебор занимает максимум 255 шагов и меньше секунды на ноутбуке — все 16 сертификатов (8 ключей, каждый продублирован eMudhra и Sectigo) были восстановлены мгновенно.

Сертификаты выданы в апреле 2025 года, шесть для TLS (DV, OV, EV по два поколения) и два для подписи кода, все кросс-подписаны корнем Sectigo AAA Certificate Services в мае 2025. 17 октября исследователь сообщил Apple, Google, Microsoft, Mozilla и eMudhra; Chrome и Firefox заблокировали их в тот же вечер, 20 октября Mozilla объявила публично и удалила корень eMudhra, Chrome подтвердил удаление в Root Store v43. Структурно сертификаты выглядели корректно — публичный ключ от d = 4 является валидной точкой кривой, и обнаружить проблему можно только перебором.

Проблема не локализуется: устройства с замороженной прошивкой — роутеры, принтеры, телевизоры — будут доверять этим сертификатам до июля 2039 года. По версии eMudhra, причиной стал баг в скрипте церемонии, создавший слабую пару ключей на HSM, а человеческая ошибка привела к использованию не тех ключей в CSR. Восстановить приватные ключи удалось даже одним запросом к ИИ-агенту.

Уязвимость позволяет проводить MITM-атаки на Android-приложения и IoT-устройства с устаревшими ОС, где отключена проверка отзыва сертификатов. Исследователь Wayne обнаружил проблему, проверив корпус CCADB с помощью инструмента paranoid_crypto от Google. По опыту @kristofferR, скомпрометированные ключи уже помогли извлечь образы прошивок из двух заблокированных устройств на базе ESP32. Для защиты IoT-устройств @closetheloopdev предлагает создать локальный MITM-прокси для перенаправления трафика на доверенные эндпоинты. Пользователям Ubuntu рекомендуется выполнить две команды обновления из официального блога. Необходимо обновить не только системные пакеты ca-certificates, но и certifi, Node, Homebrew. Приложения Flatpak и образы контейнеров могут остаться уязвимыми, так как используют собственные trust store из runtime или базовых образов, поэтому их нужно пересобрать. Ситуация подорвала доверие к аудиту CA: eMudhra проходила независимые проверки два года, но грубая ошибка не была замечена. В сообществе спорят о причинах случившегося: @positive-spite и @childintime считают это халатностью, а @jesuswasjew предполагает шпионаж или намеренный «слив».

В пакете net/http языка Go появилось важное улучшение: начиная с версии 1.27 транспорт автоматически асинхронно вычитывает неиспользованное тело HTTP/1-ответа — до 50 миллисекунд или 256 КБ. Это позволяет переиспользовать соединение вместо создания нового. На практике функция, которая просто вызывает http.Get и закрывает тело, стала почти в пять раз быстрее: 100 запросов к index.golang.org заняли около 150 мс против 710 мс в Go 1.26.

Причина в стоимости установки соединения. Каждый новый запрос по HTTP/1 требует TCP-рукопожатия (1 RTT), затем TLS-рукопожатия (2 RTT по TLS 1.2 или 1 RTT по TLS 1.3) — итого до 3 RTT только на подготовку. При межрегиональной задержке в 100 мс RTT это сотни миллисекунд накладных расходов. Переиспользование соединений решает проблему: в HTTP/1.1 они постоянны по умолчанию, а в HTTP/2 запросы мультиплексируются в одном TCP-соединении.

Однако переиспользование ломается, если тело ответа не вычитано до конца: данные остаются в потоке байтов и мешают следующему запросу. Раньше разработчикам приходилось вручную вычитывать тело с таймаутом, что было громоздко и порождало ошибки — например, бессмысленное вычитывание для HTTP/2. Теперь Transport делает это сам, пропуская операцию при заголовке Connection: close. Рекомендация прежняя: просто закрывайте тело через defer resp.Body.Close() и не усложняйте код.

HTTP/1 остается актуальным из-за отсутствия SSL в локальных сетях, поддержки старого оборудования (более 20 лет в проде по опыту @thorens), ограничений некоторых CDN (Cloudfront к origin) и специфики работы с sendfile/kernel TLS. Спор: @baalimago считает HTTP/1 небезопасным и не понимает причин его поддержки; @hnav и @thorens приводят аргументы о совместимости с legacy-системами и специфическими сетевыми задачами. Совет: При использовании json.Decoder следует проверять Decoder.More, чтобы вычитать остаточные пробельные символы, иначе соединение может не переиспользоваться (в Go 1.27 эта проблема частично решается асинхронным вычитыванием до 256 КБ). Оптимизация Go 1.27 не сработает для ответов с transfer-encoding: chunked, если сервер использует json.NewEncoder, так как тело не будет считаться завершенным в рамках лимитов вычитывания по мнению @hnav. Разработчики (@jamesponddotco, @aleksi) отмечают, что теперь могут удалить собственные реализации функций очистки тела ответа (drain body), которые переносили из проекта в проект. По мнению @fastest963, HTTP/2 в Go может работать значительно медленнее, чем HTTP/1, что делает актуальным улучшение транспорта для первой версии протокола. Спор: @jerf критикует отсутствие явного документирования поведения в методе Close и отсутствие способа мгновенно закрыть соединение без ожидания тайм-аута вычитывания; @jchw считает, что Close слишком высокоуровневый метод для таких деталей.

Автор разместил свой личный сайт в сети Tor как скрытый сервис, доступный по .onion-адресу, который генерируется из открытого ключа и не требует DNS, сертификатов или раскрытия IP-адреса. Трафик шифруется end-to-end через сеть Tor, обеспечивая анонимность как пользователей, так и самого сервера — никакая сторона не может связать личность посетителя с его действиями или локацию хостинга.

Для настройки скрытого сервиса автор отредактировал файл /etc/tor/torrc, указав директорию для ключей и перенаправление порта 80 на локальный веб-сервер (127.0.0.1:8080). После перезагрузки Tor сгенерировал уникальный .onion-адрес, который был использован в конфигурации nginx для обслуживания статического сайта без TLS, поскольку шифрование обеспечивается Tor. Чтобы избежать перенаправления на clearnet-домен, сайт собирается дважды: один раз для обычного веба, второй — с базовым URL, равным .onion-адресом, используя Hugo с флагом --baseURL. Этот процесс автоматизирован в пайплайне деплоя через GitHub Actions, который синхронно обновляет обе версии сайта. Оба варианта — clearnet и Tor — поддерживаются в актуальном состоянии без ручного вмешательства. Сайт доступен в сети Tor по адресу dhevt6e4rtgbtr3jh53xrpwmgtilkah6nyjujocsspssrsexc7omxhid.onion.

Размещение сайта в Tor реально, но требует ряда оптимизаций. Чтобы снизить нагрузку на соединения и компенсировать низкую пропускную способность, рекомендуется минимизировать HTTP-запросы, использовать серверный рендеринг, CSS-анимации и встраивать мелкие ресурсы через base64. Для ускорения загрузки можно внедрить HTTP/2 и HTTPS-сертификат. Технические рекомендации: — Добавить заголовок Onion-Location на clearnet-версию для автоматического предложения .onion-адреса в Tor Browser. — Привязывать HiddenServicePort к Unix-сокету или нестандартному локальному IP (не 127.0.0.1), чтобы упростить развертывание нескольких сайтов и избежать случайного доступа. — Обязательно резервировать приватный ключ сервиса, иначе при его потере придется менять адрес. — Не совмещать роль скрытого сервиса с ролью exit-ноды из соображений безопасности. Безопасность и доступность: — Против DDoS в Tor часто применяют двойные капчи. — Для защиты от фронтинга следует использовать уникальные заголовки и отдельные домены. — После перезапуска сервиса возможны задержки в доступности; рекомендуется использовать мосты (obfs4, snowflake) и fallback-механизмы. — v3-адреса длинные, а высокая латентность сети делает предпочтительным использование статического контента. Особенности и альтернативы: — Отсутствие DNS, сертификатов и публичного IP усложняет, но не исключает возможность деанонимизации сервиса государственными агентствами. — В качестве альтернатив с иными компромиссами по скорости и анонимности можно рассмотреть I2P и Yggdrasil.

JDK 27 официально вышел в общую доступность с билдом 35, который теперь считается стабильным для продакшена. За время релиз-кандидата не было зафиксировано ни одного критического бага (P1), что подтверждает его готовность к использованию в производственных средах. Основное изменение — G1 стал сборщиком мусора по умолчанию во всех средах, что упрощает настройку и улучшает производительность для большинства приложений.

Среди ключевых нововведений — гибридная криптография для TLS 1.3 (JEP 527), улучшенная поддержка структурированной конкурентности (JEP 533, седьмой preview), и экспериментальная векторная API (JEP 537). Также впервые по умолчанию включены компактные заголовки объектов (JEP 534), снижающие потребление памяти. Несколько функций, включая ленивые константы и шаблоны для примитивных типов, продолжают развиваться в режиме preview. Релиз содержит сотни мелких улучшений и тысячи исправлений ошибок. Открытые сборки доступны через OpenJDK, а от других вендоров — в ближайшее время.

Обсуждение подтверждает пользу шестимесячного цикла релизов Java: он обеспечивает предсказуемость и позволяет выпускать preview‐фичи без обязательств, упрощая планирование разработки. Java часто выбирают для greenfield‐проектов в банковском, телеком и правительственном секторах из‐за надёжности, производительности и длительной поддержки. При выборе стека важно учитывать опыт команды и зрелость экосистемы — переход на другой может потребовать значительных усилий. Существуют разногласия по поводу темпа релизов Oracle: одни видят в ускоренном цикле преимущество — быстрый доступ к новым возможностям, другие опасаются привязки версии языка к конкретному рантайму, что снижает гибкость. Дженерики в Java реализованы через стирание типов, ограничивая метапрограммирование по сравнению с рефицированными дженериками в .NET. Vector API остаётся в preview и ещё не достиг статуса GA, что замедляет её применение в задачах нейронных сетей и векторного поиска. Проект Valhalla, обещающий безопасные null‐типы, запланирован на Java 28 в виде preview‐версии. JEP‐531 с ключевым словом 'lazy' считается избыточным, поскольку аналогичная функциональность уже предоставляется Lombok. Многие крупные организации всё ещё используют Java 8 или Java 17, подчёркивая важность длительной поддержки и стабильности. При оценке новых функций, таких как G1 по умолчанию, рекомендуется проводить собственные бенчмарки для конкретных нагрузок.

В 1999 году Netscape 4.51 включал в себя два 512-битных RSA-корневых сертификата от канадского CA E-Certify: один для SSL («Gold Server»), другой для S/MIME («Gold Client»). Эти ключи были удалены из браузера в 2002 году, но их можно было факторизовать на обычном настольном компьютере. Автор использовал CADO-NFS на Ryzen 9 5950X: первый ключ разложился за 32 часа, второй — за 29 часов. Полученные приватные ключи позволяют выдавать сертификаты, которые Netscape 4.51 принял бы как валидные, если бы системные часы были установлены до 16 октября 2003 года — даты истечения срока действия корней. Для проверки работы таких сертификатов автор создал кастомный TLS-сервер в Go, имитирующий устаревший стек Netscape, и разместил его на e-certify.fly.dev. SSL Labs оценил сайт как «F» из-за множества уязвимостей, что ожидаемо для такого archaic setup. Помимо E-Certify, в архивах браузеровourily встречаются другие тестовые 512-битные ключи, например, от VeriSign для подписи кода в IE 3.02, которые также легко факторизуются — один из них был разложен за час на GPU-кластере. Это демонстрирует, насколько слабой была криптография в раннем вебе и как быстро устаревают даже тогдашние «стандарты».

В 1999 году факторинг RSA-512 требовал ~292 CPU-года и занял около 7 месяцев на сотнях академических машин, что подтверждало его уязвимость. Современный потребительский процессор (Ryzen 9 5950X) с CADO-NFS справляется за 29–32 часа, что соответствует прогнозам по закону Мура. Для эмуляции старого Netscape 4.51 пришлось создать собственный минимальный SSL-v3-сервер, так как Go-библиотеки не поддерживают SSL-v2/v3 и 40-битные экспортные наборы. В конце 1990-х большая часть трафика была незащищённой или использовала статические ключи, поэтому реальная угроза от факторинга 512-битных сертификатов была ограничена. Стоимость факторинга растёт экспоненциально с длиной ключа: переход к RSA-1024 значительно усложняет задачу, и её практическая выполнимость при текущих темпах развития техники остаётся под вопросом. Спор о сохранении зашифрованного трафика для будущего расшифрования: один участник считает это возможным, другой — маловероятным спустя более десяти лет. Для воспроизводимости исследований рекомендуется использовать открытые реализации (например, CADO-NFS) и документировать процесс создания сертификатов. При использовании выводов LLM необходимо вручную проверять их достоверность.

Project Gemini — это новая интернет-технология для создания электронной библиотеки взаимосвязанных текстовых документов. Проект не стремится к инновациям или разрушению существующих технологий, а предлагает альтернативу для тех, кто считает, что интернет уже достаточно изменился. Gemini нацелен на создание легковесного онлайн-пространства, где документы остаются просто документами с учётом приватности, внимания и пропускной способности пользователей.

Проект распространяется под лицензией CC BY-NC-ND 4.0 и предлагает обширную документацию, включая FAQ, видеообзор, историю развития и список программного обеспечения. Gemini не пытается изменить мир, а создаёт альтернативу, где контент остаётся простым и доступным, без излишней сложности и вторжения в личное пространство пользователей.

• Gemini позиционируется как упрощённая альтернатива вебу, но его ограничения (запрет на встроенные изображения, скрипты и сложное форматирование) критикуются как мешающие практическому использованию.
• Пользователи отмечают ностальгию по раннему вебу (HTML 2.0/3.2), но критикуют избыточность "не изобретай велосипед" при создании нового протокола вместо доработки существующих.
• Основные проблемы: сложность поиска контента, необходимость новых TLS-соединений для каждого запроса, конфликт названий с другими проектами и недостаток понятного описания.
• Несмотря на критику, некоторые ценят минимализм Gemini для личных блогов ("gemlogs") и "уютного" контента с высоким соотношением сигнал/шум.
• Сообщество активно развивает инфраструктуру (поисковики, архивы, прокси), но протокол остаётся нишевым из-за ограничений и сложности открытия контента.

Недавно на рейсе British Airways из Гонконга в Лондон автор обнаружил бесплатный WiFi для "сообщений" через программу лояльности. Оказалось, что для регистрации достаточно ввести email без верификации прямо в полёте. Бесплатный интернет работал с WhatsApp, Signal и WeChat (без изображений), но блокировал Discord и обычные сайты.

Автор выяснил, что система использует SNI (Server Name Indication) из TLS-рукопожатия для определения типа трафика. SNI раскрывает домен до установления шифрования, позволяя авиакомпании блокировать не-whitelisted домены. Эксперименты показали, что даже прямые подключения по IP без SNI блокируются, а использование SNI от WhatsApp (wa.me) обходит ограничение, позволяя установить соединение с любым сайтом через хост-заголовок HTTP.

• Обсуждение началось с описания способа обхода ограничений Wi-Fi в самолётах и круизных лайнерах с помощью VPN, DNS-туннелирования и прочих техник, включая использование порта 53/UDP и DNS-over-HTTPS.
• Участники обменялись историями о том, как они обходили плату за Wi-Fi в полёте, используя различные комбинации инструментов вроде OpenVPN, WireGuard, Iodine и прочих.
• Обсуждались также такие темы, как SNI-утечки, обфускация трафика и их влияние на приватность пользователей.
• Упоминались также вопросы о том, как авиакомпании и другие транспортные компании могут отслеживать и ограничивать использование VPN и прокси-серверов.
• В конце обсуждение перешло к обсуждению более широких тем, таких как приватность и безопасность в сети, а также о том, как технические меры могут быть использованы для обхода цензуры и ограничений.

Автор посвятил год созданию компилятора ASN.1 на языке D, но проект всё ещё далёк от завершения. Основной мотивацией стала необходимость реализации TLS для фреймворка Juptune, требующей обработки x.509 сертификатов, использующих кодировку ASN.1 DER. Автор описывает ASN.1 как «protobuf на стероидах» — избыточно сложный язык спецификации данных, созданный в конце 80-х годов, который, тем не менее, повсеместно используется в современных технологиях, несмотря на свою сложность.

Компилятор под названием dasn1 уже способен парсить некоторые x.509 сертификаты, но разработка сопряжена с множеством трудностей. ASN.1 имеет «всё или ничего» уровень сложности, требует реализации ограничений трижды разными способами, а его спецификации содержат много устаревших элементов. Язык D, однако, оказался удобным для генерации кода благодаря статическим импортам, метапрограммированию и шаблонам, которые позволяют создавать естественные API с обнаружением ошибок на этапе компиляции.

• ASN.1 и DER/BER, несмотря на свою репутацию, остаются краеугольным камнем для TLS/PKI, но их сложность и отсутствие инструментария вроде protobufs заставляют задуматься, не проще ли было бы начать с нуля сегодняшними средствами.
• Дискуссия подтверждает, что ASN.1 был там раньше SSL и даже формат сертификатов из X.500, и что его унаследовали в HTTPS.
• Подчеркивается, что вместо него могли бы быть JWT или CBOR, но вопрос в том, что ASN.1 остается ввиду отсутствия замены, которая бы обеспечивала каноническое кодирование.
• Поднимается вопрос, почему мы до сих пор используем его, если он такой плохой, и отвечается, что нет никакой альтернативы, которая бы обеспечивала такую же степень взаимодействия с прошлым.
• Участники обсуждения также отмечают, что ASN.1 это не только формат, но и семейство протоколов, и что его сложность часто преувеличена, особенно если ограничиться DER.

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

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

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