Политика безопасности

Herkos работает с секретными ключами и зашифрованными сообщениями, поэтому мы серьёзно относимся к сообщениям о проблемах безопасности и предпочитаем узнать о проблеме раньше, а не позже.

Как сообщить об уязвимости

Пожалуйста, не открывайте публичный issue по проблемам безопасности.

Сообщите о ней конфиденциально через закрытое сообщение об уязвимости на GitHub или по электронной почте security@herkos.email.

Что полезно указать: в чём проблема, как её воспроизвести, на какой платформе и версии вы проверяли и чего может добиться атакующий. Демонстрация уязвимости (proof of concept) очень помогает.

Никогда не указывайте в сообщении свой nsec, секретный ключ или секрет бункера.

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

Что входит в область

Само приложение Herkos: обработка и хранение ключей, шифрование и расшифровка сообщений (включая проверки отправителя NIP-59 и изоляцию Bcc в local_packages/nostr_mail), блокировка приложения, связь с реле и мостами, обработка вложений, а также процесс сборки и выпуска.

Что не входит в область

Сам протокол Nostr и его NIP — о них сообщайте разработчикам протокола.
Реле, мосты и серверы Blossom, которыми управляют третьи лица. Herkos поставляется со значениями по умолчанию, но не обслуживает их; сообщайте о проблемах их операторам.
Исходный проект Nostr Mail Client, если проблема не связана именно с изменениями, внесёнными в Herkos.
Отсутствие защит, которые мы уже описали как известное ограничение (см. ниже).

Известные ограничения, прямым текстом

Это компромиссы проектирования, а не уязвимости. Мы лучше запишем их, чем кто-то обнаружит их на собственном горьком опыте:

Почта на обычные адреса не защищена сквозным шифрованием. Сообщения между пользователями Nostr используют NIP-17 gift wrap и зашифрованы сквозным шифрованием. Когда вы пишете на обычный адрес электронной почты, мост преобразует сообщение и может его прочитать.
Блокировка приложения (PIN и биометрия) — это барьер удобства, а не шифрование хранимых данных. Она останавливает того, кто взял разблокированное устройство; она не защищает от атакующего с полным доступом к устройству или его хранилищу.
В Windows нельзя потребовать вход только по биометрии. Windows Hello не позволяет выбрать способ, поэтому системный PIN-код всегда остаётся доступен как запасной вариант.
Потеря ключа означает потерю учётной записи. Восстановления нет, и так задумано.
Метаданные скрыты не полностью. Реле могут наблюдать закономерности подключений, и каждое реле видит ваш IP-адрес, даже если не может прочитать содержимое сообщений. Чего Herkos не выдаёт (с 30.09.2026), так это кто кому пишет, когда реле запрашивает аутентификацию NIP-42:
Поиск, куда доставлять. Списки реле и серверов Blossom получателя запрашиваются через отдельное соединение, которое никогда вас не идентифицирует, сначала на реле, не требующих аутентификации (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
Профили и планировщик. Имя и изображение, показываемые для любого другого человека (kind 0), и список реле DVM планировщика, когда вы планируете или отменяете письмо, запрашиваются так же: сначала анонимно, а если реле настаивает, — с временным ключом, описанным ниже, но никогда с вашим (с 01.10.2026; раньше реле, запросившее аутентификацию, получало ваш ключ и могло понять, чей профиль вы смотрите). Только ваш собственный профиль по-прежнему читается от вашего имени.
Доставка. Gift wrap отправляются на DM-реле получателя через то же отдельное соединение. Если одно из них требует аутентификации, Herkos отвечает ключом, созданным специально для этого и хранящимся только в памяти, но никогда вашим; у каждой учётной записи на устройстве он свой. Реле всё же может видеть, что одно и то же устройство (тот же IP, тот же временный ключ) отправило несколько конвертов за сеанс.
Большие письма. Зашифрованная копия письма размером более 32 КБ загружается на серверы Blossom, включая серверы получателей. Только ваши собственные серверы (ваш список Blossom) получают загрузку, авторизованную вашим ключом. Любой другой сервер получает её анонимно, а если настаивает на авторизации, — подписанную тем же временным ключом, что и выше (с 01.10.2026; раньше каждый сервер получал ваш ключ). Сервер, принимающий только известные ключи, её отклоняет, и копия остаётся на других серверах.
Ваши собственные данные. Синхронизация почтового ящика, меток, настроек и черновиков проходит аутентификацию, если реле её запрашивает, от имени учётной записи, которой принадлежат данные, даже во время переключения учётных записей. Вашим собственным реле это не сообщает ничего, чего они не знали: запросы и так называют ваш ключ. Ваши собственные списки реле и Blossom публичны и запрашиваются без вашей идентификации, как и реле, указанные в ссылке на письмо.
Состояние «прочитано» и папки — публичные метаданные (пока). Когда вы отмечаете письмо прочитанным, помеченным звёздочкой, архивированным или перемещённым, публикуется незашифрованное событие метки NIP-32, привязанное к вашему открытому ключу, включая названия собственных папок. Отправитель, который знает идентификатор отправленного вам письма, может узнать, когда вы с ним что-то сделали. Шифрование этих меток запланировано; до тех пор считайте названия папок публичными.
Push-уведомления и отложенная отправка используют сторонние сервисы. Push-сервер (api.nmail.li по умолчанию) узнаёт ваш открытый ключ, push-токен и время получения почты; DVM планировщика узнаёт ваш открытый ключ и уже зашифрованные сообщения, которые он должен опубликовать. Оба включаются только по желанию и описаны в PRIVACY.md. Текст push-уведомления выбирает push-сервер, и Herkos доверяет ему, только когда UnifiedPush доставляет его в зашифрованном виде (RFC 8291); незашифрованное содержимое лишь будит приложение, чтобы оно само забрало почту.
Веб-версия хранит ваш ключ в браузере, а это самое слабое для него место. Установленные приложения передают ваш секретный ключ в защищённое хранилище операционной системы (Android Keystore, диспетчер учётных данных Windows, libsecret, связка ключей iOS/macOS). В браузере ничего этого нет: ключ лежит в хранилище сайта и проходит через JavaScript при каждой подписи, в пределах досягаемости любого кода, выполняемого на странице, — расширения браузера с доступом ко всем сайтам, уязвимости XSS в приложении или в зависимости, подменённой сборки, — и любого инфостилера, копирующего профиль браузера. Кроме того, нет момента, когда вы проверяете код один раз: подписанный исполняемый файл проверяется при установке, а веб-страница отдаёт новый код при каждом посещении. Входите в веб-версию через удалённый подписывающий сервис (бункер NIP-46, Amber), чтобы ключ никогда не попадал в браузер, или считайте её одноразовой личностью и храните настоящий ключ в установленном приложении.
Почта через мост заслуживает доверия лишь настолько, насколько заслуживает его мост. Herkos проверяет, что сообщение, помеченное как пришедшее через мост, действительно подписано мостом, который вы настроили (или одним из мостов по умолчанию). Он не может ничего проверить относительно обычного адреса From:, который передаёт мост.
Вложения открывает операционная система. Herkos никогда не запускает исполняемые файлы и скрипты и спрашивает, прежде чем передать любое другое вложение без предпросмотра системному приложению по умолчанию, но приложение, которое открывает файл, нам неподконтрольно.

Поддерживаемые версии

Исправления безопасности применяются к последней выпущенной версии. Учитывая размер проекта, старые версии не поддерживаются — пожалуйста, обновитесь, прежде чем сообщать о проблеме.