Політика безпеки

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 ніколи не запускає виконувані файли чи скрипти і питає, перш ніж передати будь-яке інше вкладення без попереднього перегляду типовому системному застосунку, але застосунок, який відкриває файл, поза нашим контролем.

Підтримувані версії

Виправлення безпеки застосовуються до останньої випущеної версії. З огляду на розмір проєкту старіші версії не підтримуються — будь ласка, оновіться, перш ніж повідомляти.