В статье рассматривается применение протокола QUIC для решения проблем обхода NAT в P2P-сетях. Авторы отмечают, что за годы было стандартизировано множество протоколов (STUN, ICE, TURN), но процесс остается сложным из-за разнообразия реализаций NAT, которые переписывают IP-адреса пакетов и действуют как файрволы. Основная проблема P2P-сетей — соединение двух узлов, находящихся за разными NAT, независимо от их типа.

Традиционные решения включают использование STUN для обнаружения публичных IP-адресов, ICE для координации пробивания дыр в файрволах и TURN как запасной вариант с ретрансляцией трафика. Авторы предлагают, что QUIC может предоставить комплексное решение для обхода NAT, объединяя все эти функции в одном протоколе и упрощая P2P-сетевое взаимодействие. Это потенциально может заменить несколько отдельных протоколов единой, более эффективной реализацией.

• Обсуждение вращается вокруг проблемы NAT и hole punching при попытке установить прямое P2P соединение, включая то, что некоторые NAT ведут себя непредсказуемо и не позволяют hole punching.
• QUIC и WebTransport обсуждаются как потенциальные решения, но оба стандарта ещё не реализованы в браузерах и их поддержка ограничена.
• Обсуждается, что для P2P соединений не требуется централизованный сервер, но вопрос в том, что сервер может всё ещё потребоваться для ретрансляции трафика в случае, если оба клиента находятся за NAT.
• Поднимается вопрос о том, что TLS сертификаты могут быть самоподписанными и не обязаны быть выданы удостоверяющим центром, что может быть использовано для P2P соединений.
• Участники обсуждают, что хотя WebTransport и был предложен как стандарт для web-платформ, он всё ещё не реализован в браузерах и его будущее неясно.

Cloudflare представляет сертификаты на основе деревьев Меркле для решения проблемы постквантовой криптографии. Квантовые компьютеры угрожают безопасности интернета, и уже около 50% трафика на сети Cloudflare защищено от угрозы "собери сейчас, расшифруй позже". Однако постквантовые алгоритмы для аутентификации в TLS имеют размеры в 20 раз больше традиционных: подписи ML-DSA-44 составляют 2,420 байт против 64 байт у ECDSA-P256, а открытые ключи - 1,312 байт против 64 байт. Это создает значительные накладные расходы на производительность TLS-рукопожатий.

Новые сертификаты Merkle Tree позволяют развертывать постквантовую криптографию сегодня без потери производительности. Решение, разработанное совместно с партнерами в IETF, не только устраняет проблему больших размеров ключей, но и может даже улучшить производительность. Это критически важно для безопасной миграции интернета на постквантовые стандарты до появления криптографически значимых квантовых компьютеров, так как переходы всегда занимают больше времени, чем ожидалось.

• Обсуждение в основном вращается вокруг трёх тем: пост-квантовая криптография, приватность и уязвимость квантовых компьютеров, и эволюция стандартов сертификатов.
• Участники обсуждают, какие именно алгоритмы подписи будут использоваться в будущем, и какие из них будут совместимы с пост-квантовыми сертификатами.
• Также обсуждается, какие именно сертификаты будут использоваться в будущем, и как они будут взаимодействовать с пост-квантовыми алгоритмами.
• Обсуждается, какие именно изменения в стандартах сертификатов будут необходимы для обеспечения безопасности в эпоху пост-квантовых компьютеров.
• Участники также обсуждают, какие именно изменения в стандартах сертификатов будут необходимы для обеспечения безопасности в эпоху пост-квантовых компьютеров.

Недавно на рейсе 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.

HTTP/3 — это новая версия протокола HTTP, работающая поверх QUIC (Quick UDP Internet Connections) вместо традиционного TCP. Основное преимущество — решение проблемы "head of line blocking", когда потеря одного пакета блокирует всю передачу данных. HTTP/3 использует UDP, что позволяет параллельно обрабатывать пакеты без ожидания восстановления связи. Протокол включает встроенную безопасность с TLS 1.3 и поддерживает 0-RTT handshakes для снижения задержки при повторных подключениях.

Книга подробно разбирает эволюцию протокола: от HTTP/2 с его ограничениями TCP до современных возможностей QUIC. HTTP/3 сохраняет такие функции HTTP/2, как мультиплексирование запросов и приоритизацию, но с улучшенной производительностью. Особое внимание уделено техническим деталям: работа с потоками, сравнение с HTTP/2, а также критика и перспективы развития. Документ доступен на нескольких языках и представляет собой исчерпывающее руководство для разработчиков, интересующихся современными веб-протоколами.

• Обсуждение охватывает отсутствие обновлений документации HTTP/3, проблемы с потерей пакетов в HTTP/2, и то, что HTTP/3 уже поддерживается большинством браузеров и сайтов, но документация и инструменты отстают.
• Участники обсуждают, что HTTP/3 в основном использует UDP, что вызывает споры о безопасности и приватности, а также то, что TCP может быть выключен в будущем.
• Также обсуждается, что HTTP/3 уже активно используется, но не всегда очевидно, что это именно он, так как внешне это может быть незаметно.
• Участники также отмечают, что документация и инструменты для HTTP/3 развиты недостаточно, и что будущее HTTP/4 неясно.
• В конце обсуждение сдвигается к тому, что HTTP/3 уже здесь и сейчас, и мы должны начать его использовать и развивать экосистему вокруг него.

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

Автор использует технологию XDP (Express Data Path) для высокопроизводительной фильтрации сетевых пакетов прямо на уровне сетевого устройства, что позволяет обрабатывать до 26 миллионов запросов в секунду на потребительском оборудовании. XDP работает поверх eBPF — виртуальной машины в ядре Linux, где код компилируется в низкоуровневые инструкции для быстрой проверки пакетов с гарантиями безопасности, например, предотвращения чтения за пределами буфера.

Для идентификации клиентов, особенно скриптовых инструментов вроде curl, применяется TLS-фингерпринтинг по стандарту JA4. Этот метод анализирует параметры TLS-рукопожатия (версии, шифры, расширения), формируя уникальный отпечаток, который можно сопоставить с конкретным ПО. Хотя расчёт хэша SHA256 напрямую в eBPF сложен, сама возможность такой фильтрации на уровне ядра позволяет эффективно блокировать массовые автоматизированные запросы с минимальными затратами ресурсов.

• Обход TLS-отпечатков (JA3/JA4) возможен через случайный подбор шифров в curl или инструменты вроде curl-impersonate
• Многие системы защиты (например, Anubis) сознательно разрешают запросы от curl и Googlebot, чтобы отсеивать только злоумышленников
• Эффективная блокировка требует комбинации методов: отпечатки TLS, IP-адреса, ASN, HTTP-фингерпринтинг и JavaScript-вызовы
• Мотивированные скрейперы используют продвинутые техники: эмуляцию браузера, вращение отпечатков и прокси
• Борьба со скрейпингом — это "гонка вооружений", ведущая к росту затрат для обеих сторон и рискующая навредить открытости интернета

Хотел следить за собакой, а следил за TP-Link

Купил дешёвую камеру Tapo, чтобы наблюдать за собакой в своё отсутствие. В итоге пришлось реверсить процесс подключения, декомпилировать APK, перехватывать TLS-трафик и писать криптографические скрипты.

Камера раздражала с первого дня: настройка в frigate оказалась сложной, а информации в сети почти не было.

Примечание: для двустороннего аудио в frigate используйте tapo:// вместо rtsp://. TP-Link ленивы и реализовали аудио только в своём API.

Выяснилось, что после подключения устройство ожидает логин admin и пароль от облака Tapo. Но если сменить пароль в облаке, устройства об этом не узнают. Это навело на мысли:

• Во время подключения должен быть вызов, синхронизирующий пароль устройства с облачным.
• Устройство либо разрешает неаутентифицированные вызовы, либо имеет пароль по умолчанию.

Раздражение из-за навязчивых подписок в приложении Tapo подтолкнуло к поиску облачного решения для подключения.

Перехват трафика

Для перехвата трафика мобильного приложения нужно направить весь HTTP(S)-трафик через прокси. Современные приложения игнорируют прокси и используют привязку сертификатов. Надёжный метод — динамическая инструментация через frida, которая заставляет приложение использовать нужные прокси и сертификаты.

Схема перехвата:

Приложение Tapo (с frida) -> Ноутбук (mitmproxy) -> Камера Tapo

После запуска mitmproxy и внедрения скриптов frida удалось увидеть первоначальный логин до смены пароля:

{
  "method": "login",
  "params": {
    "cnonce": "AD0E189F6E1BA335",
    "encrypt_type": "3",
    "username": "admin"
  }
}

Последующие запросы были зашифрованы:

{
  "method": "securePassthrough",
  "params": {
    "request": "bAhdgihJ9j6PrrknnbXWATBohGTZK5llv3MEzRcmoAmcxexmlVNz3OUX2r0h9a9EG/3X0tBpPi654T2+BjqVEOn2D178kokBpf8RQj01AvBZLYD5S5sFeaCXWiRXA7MgQUppROV4AbrU4f+GOM37KgPqT59qgLVja2slw6CzrKjPzOrG4Ho6Mu6wBa1xepcj"
  }
}

Выводы:

• У Tapo есть пароль по умолчанию, так как логин происходит до знания облачного пароля.
• API использует зашифрованный канал securePassthrough.

Декомпиляция APK

Следующий шаг — декомпиляция APK в JADX для поиска пароля по умолчанию. Запрос логина содержит имя пользователя admin. Поиск по коду привёл к классу CameraOnboardingViewModel, где функция возвращала пароль, передаваемый в new Account().

Пароль по умолчанию для encrypt_type: 3: TPL075526460603

Анализ трафика

С паролем по умолчанию можно получать ключи сессии и расшифровывать сообщения securePassthrough. Для анализа процесса аутентификации пригодилась библиотека PyTapo. С её помощью можно было декодировать запросы из mitmproxy и провести статический анализ.

• Использование Frida-скриптов для перехвата трафика и обхода проверки сертификатов в Android-приложении Tapo для получения пароля от камеры
• Обход ограничений TP-Link: для двустороннего аудио необходимо использовать проприетарный протокол tapo:// в go2rtc, но это лишает возможности использовать ONVIF для управления поворотом камеры
• Критика безопасности IoT и потребительских роутеров: прошивки часто не обновляются годами, содержат уязвимости (CVE), пользователи редко меняют пароли по умолчанию
• Предложение выбирать устройства, изначально поддерживающие открытые стандарты (например, RTSP) и не требующие обязательного использования облачного сервиса и мобильного приложения
• Обсуждение последствий будущих ограничений Android (требование подписи приложений) для реверс-инжиниринга: на рутованных устройствах и эмуляторах методы останутся работоспособными
• Упомянуты полезные инструменты и проекты: HTTP Toolkit, go2rtc для совместимости с разными потоками, библиотека PyTapo для работы с камерами Tapo
• Найдены и использованы уязвимости (CVE-2022-37255) с хардкодными паролями, которые пользователь должен сменить при первоначальной настройке
• Разочарование в IoT-устройствах, требующих обратного инжиниринга для базового функционала; снижение энтузиазма к такому взлому
• Проблема отсутствия URL для получения статичного снимка (snapshot) с камер Tapo и необходимость использовать FFmpeg для извлечения кадра из видеопотока

Кубические спутники (CubeSats) — это увлекательные инструменты для изучения космоса. Это миниатюрные спутники размером 10×10×10 см (1U), которые могут быть оснащены Raspberry Pi или микроконтроллерами. Уже несколько таких устройств работают в космосе, например, на МКС или в проектах вроде SatGus.

CubeSats строятся на стандартных платформах, что упрощает разработку. Их стоимость значительно ниже традиционных спутников: сборка обходится в несколько тысяч долларов, а запуск — около $85 000. Это делает их доступными для образовательных учреждений и энтузиастов.

Проектирование CubeSat требует тщательного учёта каждого миллиметра и миллиампера энергии. Примером может служить проект Build a CubeSat, где разработчик сталкивается с challenges аппаратного и программного обеспечения, включая вопросы безопасности удалённого доступа.

Такие проекты не только расширяют возможности обучения, но и inspire новое поколение инженеров и исследователей космоса.

• Участники делятся успешным опытом создания и запуска кубсатов на базе Raspberry Pi и Arduino для образовательных и любительских проектов.
• Обсуждаются технические аспекты: использование LoRa для связи, проблемы радиации в LEO, открытые проекты (например, OpenLST) и низкая скорость передачи данных.
• Поднимаются вопросы безопасности и уязвимостей кубсатов, включая потенциальное использование TLS и сложность взлома из-за специализированного оборудования.
• Отмечается высокая стоимость запуска (~85 тыс. долларов) как основное препятствие, но выражается надежда на её снижение.
• Упоминаются частые неудачи (до 50% миссий) из-за недостаточного тестирования и неопытности команд, а не аппаратных сбоев.
• Обсуждаются проблемы космического мусора и необходимость учёта стоимости утилизации при запуске.
• Предлагаются альтернативы, такие как пикобаллоны, для более экономичных атмосферных экспериментов.
• Участники отмечают доступность кубсатов через SpaceX и долгую историю их использования (свыше 2300 запусков).

• Этот домен показывает отозванный сертификат, подписанный корнем ISRG Root X1.
• Увидеть отзыв удаётся не во всех браузерах — проверка отзыва работает по-разному.
• Let's Encrypt — бесплатный удостоверяющий центр; страница создана для демонстрации механизма отзыва.

Как участвовать

• Код ЦС: github.com/letsencrypt/boulder
• Форум: community.letsencrypt.org
• Стать спонсором: letsencrypt.org/become-a-sponsor

• Обсуждается проблема неработоспособности механизмов отзыва сертификатов (revocation) в WebPKI, на примере сайта с отозванным сертификатом, который браузеры не блокируют.
• Пользователи тестируют различные браузеры (Chrome, Firefox, Safari, Edge) и констатируют, что ни один из них не распознает сертификат как отозванный.
• Причины: разные подходы к проверке (OCSP, CRL), отсутствие единого централизованного авторитета по отзыву и то, что многие браузеры вообще не выполняют live-проверки из-за проблем с производительностью и приватностью.
• Отмечается, что индустрия движется в сторону сертификатов с коротким сроком жизни (short-lived), что делает проблему отзова менее актуальной, так как такой сертификат быстро сам истекает.
• Упоминается, что Let's Encrypt прекратил поддержку OCSP и предлагает 6-дневные сертификаты, что еще больше снижает важность механизмов отзыва.

OCSP-сервис Let's Encrypt отключён

С 6 августа 2025 года Let's Encrypt полностью выключил OCSP-ресурдер.
Все выпущенные после марта сертификаты уже не содержали ссылок на OCSP, и старые истекли. Отныне отзывы публикуются только через CRL.

Причины отказа

• Конфиденциальность: OCSP раскрывает посещаемые сайты и IP-адрес запрашивающего.
• Простота: CRL теперь полноценно поддерживаются, а OCSP требовал значительных ресурсов.

Факты

• Пик нагрузки: 340 млрд запросов/мес (~140 000 зап/с).
• CDN предоставлял Akamai безвозмездно последние 10 лет.

Что дальше
Клиенты, требующие проверки отзыва, должны использовать CRL.

• Участники обсуждают отказ от OCSP и переход на CRL: оба механизма называют «костылями» — CRL слишком тяжёлые и медленно обновляются, OCSP требует онлайна и уязвима к MITM/DoS.
• Chrome вообще не проверяет ни OCSP, ни CRL, а пользуется собственным CRLSets-фильтром от Google; большинства пользователей это не знают.
• Проблема OCSP в «fail-open»-режиме: если ответ заблокирован, сертификат считается валидным, что делает систему бесполезной против активной атаки.
• Предложенные замены — stapling и короткоживущие (24-часовые) сертификаты — тоже критикуют: stapling почти никто не делает, а массовый выпуск 24-часовых certs перегрузит CT-логи и превратит любые проблемы валидации в немедленный аутейдж.
• Итог: отзыв по-прежнему нерешённая проблема; сообщество склоняется к «просто живём с короткими сертами» и считает OCSP/CRL устаревшими.

NGINX теперь с ACME
12 авг. NGINX официально добавил встроенный модуль ngx_http_acme (на Rust), который сам получает и продлевает сертификаты Let’s Encrypt.

Зачем

• никаких внешних клиентов;
• работает из коробки: от домашнего лаба до кластеров Kubernetes;
• меньше рутины, больше шифрования.

Кто ещё
Traefik, Caddy, Apache уже умеют; теперь к ним присоединился самый популярный веб-сервер и прокси.

Разработчикам
Протокол ACME, библиотеки и обсуждение — на форуме Let’s Encrypt.

• Кто-то рад встроенному ACME в nginx, кто-то считает, что «сертификат должен получать отдельный клиент», а не каждый сервис в отдельности.
• Спор о безопасности: модуль на Rust, но в нём много unsafe-блоков для взаимодействия с Си-ядром nginx.
• Вопрос «зачем ждать столько лет?» — ответ: корпоративные заказчики F5/medленный релиз-цикл.
• Практика: можно отключить встроенный ACME и продолжать использовать certbot/cert-manager.

Сертификаты для 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 или ручной проверки.

Zig 0.15 сменил IO: std.Io.Reader и std.Io.Writer.
Старый способ тормозил и путался из-за anytype.

Подключаемся к www.openmymind.net:443:

const std = @import("std");

pub fn main() !void {
    var gpa = std.heap.DebugAllocator(.{}).init;
    defer gpa.deinit();
    const a = gpa.allocator();

    const s = try std.net.tcpConnectToHost(a, "www.openmymind.net", 443);
    defer s.close();

    var wbuf: [std.crypto.tls.max_ciphertext_record_len]u8 = undefined;
    var rbuf: [std.crypto.tls.max_ciphertext_record_len]u8 = undefined;
    var w = s.writer(&wbuf);
    var r = s.reader(&rbuf);

    var bundle = std.crypto.Certificate.Bundle{};
    try bundle.rescan(a);
    defer bundle.deinit(a);

    var tls_buf: [std.crypto.tls.max_ciphertext_record_len]u8 = undefined;
    var tls = try std.crypto.tls.Client.init(
        r.interface(),
        &w.interface,
        .{
            .ca = .{ .bundle = bundle },
            .host = .{ .explicit = "www.openmymind.net" },
            .read_buffer = &.{},
            .write_buffer = &tls_buf,
        },
    );
    defer tls.end() catch {};

    try tls.writer.writeAll("GET / HTTP/1.1\r\n\r\n");

    var out: [1024]u8 = undefined;
    var fw = std.Io.Writer.fixed(&out);
    const n = try tls.reader.stream(&fw, .limited(out.len));
    std.debug.print("read: {s}\n", .{out[0..n]});
}

Ключевые моменты

• stream.reader() и writer() требуют буфер.
• Чтобы передать их в tls.Client, нужно .interface() и &interface.
• tls.Client.init обязательно просит ca, host, read_buffer, write_buffer.
• Чтение ответа: tls.reader.stream в std.Io.Writer.

• Автору пришлось вручную вызывать flush у двух обёрток и разбираться с тем, что первое чтение всегда возвращает 0.
• Основная жалоба — отсутствие документации и примеров; сообщество отвечает «читай исходники», но участники признают, что API ещё нестабилен.
• Некоторые считают новый I/O-интерфейс элегантным, но сложным даже для «Hello, world!»; другие предпочитают прямое использование системных API.
• Zig позиционируется как язык системного программирования, близкий к C, с преимуществами вроде discriminated unions и comptime, но сопровождается постоянными breaking changes.