Politica de securitate

Herkos gestionează chei private și mesaje criptate, așa că luăm în serios rapoartele de securitate și preferăm să aflăm despre o problemă devreme, nu târziu.

Raportarea unei vulnerabilități

Vă rugăm să nu deschideți un issue public pentru problemele de securitate.

Raportați-o în privat prin funcția GitHub de raportare privată a vulnerabilităților sau prin e-mail la security@herkos.email.

Informații utile de inclus: care este problema, cum poate fi reprodusă, pe ce platformă și versiune ați testat și ce ar putea obține un atacator. O demonstrație practică (proof of concept) ajută mult.

Nu includeți niciodată într-un raport propriul nsec, cheia secretă sau secretul bunkerului.

Ne propunem să confirmăm primirea rapoartelor în câteva zile. Deoarece Herkos este un proiect mic, vă rugăm să lăsați un timp rezonabil pentru o remediere înainte de a face publică problema. Vă menționăm cu plăcere în aviz, dacă nu preferați altfel.

Ce intră în domeniu

Aplicația Herkos propriu-zisă: gestionarea și stocarea cheilor, criptarea și decriptarea mesajelor (inclusiv verificările expeditorului NIP-59 și izolarea Bcc din local_packages/nostr_mail), blocarea aplicației, comunicarea cu releele și punțile, gestionarea atașamentelor și procesul de compilare și publicare.

Ce nu intră în domeniu

Protocolul Nostr și NIP-urile sale ca atare — raportați-le în amonte.
Releele, punțile și serverele Blossom administrate de terți. Herkos vine cu valori implicite, dar nu le administrează; raportați problemele operatorilor lor.
Proiectul-sursă Nostr Mail Client, cu excepția cazului în care problema ține de modificările făcute în Herkos.
Lipsa unor măsuri de consolidare pe care le documentăm deja ca limitare cunoscută (vezi mai jos).

Limitări cunoscute, spuse direct

Acestea sunt compromisuri de proiectare, nu vulnerabilități. Preferăm să le scriem aici decât să le descopere cineva pe propria piele:

Corespondența către adrese tradiționale nu este criptată integral (end-to-end). Mesajele dintre utilizatorii Nostr folosesc gift wrap NIP-17 și sunt criptate E2E. Când scrieți la o adresă de e-mail obișnuită, o punte convertește mesajul și îl poate citi.
Blocarea aplicației (PIN și biometrie) este o barieră de comoditate, nu criptare a datelor stocate. Oprește pe cineva care ia un dispozitiv deblocat; nu protejează împotriva unui atacator cu acces complet la dispozitiv sau la spațiul său de stocare.
Pe Windows nu se poate impune autentificarea exclusiv biometrică. Windows Hello nu permite alegerea metodei, așa că PIN-ul sistemului rămâne mereu disponibil ca alternativă.
Pierderea cheii înseamnă pierderea contului. Nu există recuperare, prin concepție.
Metadatele nu sunt ascunse complet. Releele pot observa tiparele de conectare, iar fiecare releu vă vede adresa IP, chiar și atunci când nu poate citi conținutul mesajelor. Ce nu dezvăluie Herkos (din 30-09-2026) este cine îi scrie cui atunci când un releu cere autentificare NIP-42:
Căutarea locului de livrare. Listele de relee și de servere Blossom ale unui destinatar sunt cerute pe o conexiune separată care nu vă identifică niciodată, mai întâi de la relee care nu cer autentificare (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
Profilurile și programatorul. Numele și imaginea afișate pentru oricine altcineva (kind 0) și lista de relee a DVM-ului de programare, atunci când programați sau anulați un e-mail, sunt cerute în același fel: mai întâi anonim și, dacă un releu insistă, cu cheia temporară descrisă mai jos, niciodată cu a dvs. (din 01-10-2026; înainte, un releu care cerea autentificare primea cheia dvs. și putea afla al cui profil îl priveați). Doar propriul profil este citit în continuare în numele dvs.
Livrarea. Gift wraps ajung la releele pentru mesaje private ale destinatarului, pe aceeași conexiune separată. Dacă unul dintre ele cere autentificare, Herkos răspunde cu o cheie creată special pentru aceasta și păstrată doar în memorie, niciodată cu a dvs.; fiecare cont de pe dispozitiv o are pe a lui. Releul poate totuși să vadă că același dispozitiv (același IP, aceeași cheie temporară) a trimis mai multe plicuri în cursul unei sesiuni.
E-mailurile mari. Copia criptată a unui e-mail de peste 32 KB este încărcată pe servere Blossom, inclusiv pe cele ale destinatarilor. Doar serverele dvs. (lista dvs. Blossom) primesc încărcarea autorizată cu cheia dvs. Orice alt server o primește anonim și, dacă insistă asupra unei autorizări, una semnată cu aceeași cheie temporară de mai sus (din 01-10-2026; înainte, fiecare server primea cheia dvs.). Un server care acceptă doar chei cunoscute o refuză, iar copia rămâne pe celelalte servere.
Propriile date. Sincronizarea căsuței de e-mail, a etichetelor, setărilor și ciornelor se autentifică, acolo unde un releu cere, ca fiind contul căruia îi aparțin datele, chiar și în timpul unei schimbări de cont. Pe propriile relee, asta nu le spune nimic din ce nu știau deja: cererile vă numesc oricum cheia. Propriile liste de relee și de servere Blossom sunt publice și sunt cerute fără a vă identifica, la fel ca releele menționate într-un link dintr-un e-mail.
Starea de citire și dosarele sunt metadate publice (deocamdată). Marcarea unui e-mail drept citit, cu stea, arhivat sau mutat publică un eveniment de etichetă NIP-32 necriptat, legat de cheia dvs. publică, inclusiv numele dosarelor personalizate. Un expeditor care cunoaște id-ul unui e-mail pe care vi l-a trimis poate afla când ați acționat asupra lui. Criptarea acestor etichete este planificată; până atunci, considerați numele dosarelor publice.
Notificările push și trimiterea programată folosesc servicii terțe. Serverul push (implicit api.nmail.li) vă află cheia publică, un token push și momentele în care primiți corespondență; DVM-ul de programare vă află cheia publică și mesajele deja criptate pe care trebuie să le publice. Ambele sunt opționale și documentate în PRIVACY.md. Textul unei notificări push este ales de serverul push, iar Herkos are încredere în el doar când UnifiedPush îl livrează criptat (RFC 8291); un conținut necriptat doar trezește aplicația ca să preia ea însăși corespondența.
Versiunea web vă păstrează cheia în browser, cel mai slab loc pentru ea. Aplicațiile instalate îi încredințează cheia secretă spațiului de stocare securizat al sistemului de operare (Android Keystore, Windows Credential Manager, libsecret, iOS/macOS Keychain). Un browser nu are nimic din toate acestea: cheia stă în spațiul de stocare al originii și trece prin JavaScript la fiecare semnătură, la îndemâna oricărui cod care rulează în pagină — o extensie de browser cu acces la toate site-urile, o eroare XSS în aplicație sau într-o dependență, o implementare compromisă — și a oricărui infostealer care copiază profilul browserului. De asemenea, nu există niciun moment în care să verificați codul o dată pentru totdeauna: un binar semnat este verificat la instalare, în timp ce o pagină web livrează cod nou la fiecare vizită. Conectați-vă la versiunea web cu un semnatar la distanță (bunker NIP-46, Amber), astfel încât cheia să nu ajungă niciodată în browser, sau considerați-o o identitate de unică folosință și păstrați cheia reală într-o aplicație instalată.
Corespondența prin punte este de încredere doar în măsura în care este puntea. Herkos verifică dacă un mesaj marcat ca venind printr-o punte a fost într-adevăr semnat de o punte pe care ați configurat-o (sau de una dintre cele implicite). Nu poate verifica nimic despre adresa tradițională From: pe care o transmite puntea.
Atașamentele sunt deschise de sistemul de operare. Herkos nu lansează niciodată tipuri de fișiere executabile sau scripturi și întreabă înainte de a preda orice alt atașament fără previzualizare aplicației implicite a sistemului, dar aplicația care deschide fișierul nu se află sub controlul nostru.

Versiuni acceptate

Remedierile de securitate se aplică ultimei versiuni publicate. Având în vedere dimensiunea proiectului, versiunile mai vechi nu sunt întreținute — vă rugăm să actualizați înainte de a raporta.