Hacker News Digest

В 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) для упрощения начальной настройки.
• Рассматривается как хобби для технических специалистов, а не как решение для рядового пользователя.