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 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. Pentru Herkos Drive, și pachetul său de protocol (packages/herkos_drive_protocol) și pagina care îi deschide linkurile (herkos.app/f/); vedeți secțiunea sa de mai jos.

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, dacă alegeți unul (implicit niciunul; api.nmail.li cu relay.nmail.li la cerere), 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, DPAPI pe Windows, 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.

Herkos Local Relay: ce protejează și ce nu

Herkos Local Relay păstrează pe dispozitivul dvs. evenimentele aplicațiilor dvs., inclusiv pe cele private (ciorne, liste private, plicurile pe care le primiți). Iată ce le protejează și unde este limita, platformă cu platformă. Problemele de securitate ale releului se raportează la fel ca celelalte (mai sus).

Baza de date este criptată în întregime, inclusiv jurnalul (SQLite3 Multiple Ciphers, AEGIS-256). Cheia constă din 32 de octeți aleatori creați pe dispozitiv și păstrați în spațiul de stocare securizat al sistemului: Keystore pe Android, DPAPI pe Windows, portcheiul (libsecret) pe Linux. Nu depinde de nicio parolă a dvs., pentru că releul trebuie să pornească singur. Fără cheie, releul nu pornește și spune asta: nu deschide și nu creează niciodată o bază necriptată și nu o șterge niciodată pe cea pe care nu o poate deschide.

Pe desktop, limita DPAPI și a portcheiului este cea a oricărui program: protejează împotriva altor utilizatori și a celui care ia discul, nu împotriva unui program rău intenționat care rulează deja sub utilizatorul dvs. Dacă vă îngrijorează acest caz, ceea ce vă protejează este criptarea discului de sistem (BitLocker, LUKS), împreună cu a nu rula programe în care nu aveți încredere. Pe un Linux fără portchei (fără Secret Service), releul nu pornește și explică de ce: nu păstrează niciodată cheia ca text simplu.

Cine intră, pe dispozitivul însuși. Releul ascultă doar pe 127.0.0.1, iar orice aplicație de pe dispozitiv, sau o pagină web din browser, poate ajunge la acea adresă. De aceea:

• O aplicație trebuie să fie asociată: apare pe ecranul releului și dvs. o aprobați (cu PIN-ul sau amprenta, dacă le-ați setat). Orice aplicație își poate da orice nume: aprobați doar dacă tocmai ați cerut asta din acea aplicație.
• O pagină web este asociată întotdeauna, iar o asociere este valabilă doar de acolo de unde a fost făcută: cea a unei aplicații de pe dispozitiv nu deschide nimic unei pagini web, chiar dacă aceasta semnează cu aceeași cheie.
• O aplicație asociată citește și scrie doar tipurile de evenimente pe care i le-ați permis și șterge doar pe cele pe care are voie să le scrie. Revocarea ei o deconectează imediat.
• O aplicație neasociată citește doar evenimentele dvs. publice (care sunt oricum publice) și nu scrie nimic, cu excepția cazului în care activați setarea care lasă să intre aplicațiile neasociate de pe dispozitiv.
• Evenimentele private sunt date doar celui care dovedește prin NIP-42 că deține cheia căreia îi aparțin, iar un plic, doar destinatarului său.

Ce nu protejează, aici:

• O aplicație rău intenționată de pe dispozitiv poate încetini releul sau îl poate face să consume memorie. Nu poate citi nimic privat în felul acesta.
• Cât timp releul doarme sau nu rulează, portul său este liber. Pe Android adoarme după 10 minute fără conexiuni; pe desktop, portul este liber cât timp nu l-ați pornit. O altă aplicație ar putea asculta acolo și s-ar putea da drept releu. Aplicațiile Herkos vor verifica cheia releului înainte de a-i trimite ceva privat; încă nu o fac, iar până atunci aceasta este o limită reală.
• Pe desktop, alți utilizatori ai computerului se pot conecta ca o aplicație neasociată: pot citi evenimentele dvs. publice și pot cere asocierea.

Rețeaua locală, dacă o activați (este dezactivată implicit):

• Doar wss://, cu un certificat propriu al releului; niciodată ws:// necriptat în afara dispozitivului.
• Nimic înainte de autentificare (NIP-42) cu o cheie din lista dvs. O conexiune care nu face asta în 30 de secunde este închisă, iar rețeaua locală are propriul număr de conexiuni: nu le ocupă niciodată pe cele ale aplicațiilor de pe dispozitiv.
• O cheie din listă citește evenimentele dvs. publice și propriile ei evenimente private și scrie doar evenimente semnate de ea. Scoaterea ei din listă o deconectează.
• Certificatul este valabil doar pentru nume de acasă (localhost, .local, adrese private): chiar dacă cineva i-ar fura cheia, nu i-ar folosi la a semna un domeniu de Internet pe dispozitivele care l-au instalat.

Ce nu protejează, aici: cine se află în aceeași rețea vede că dispozitivul are un port deschis și cât trafic trece prin el, dar nu și ce anume; iar dacă dispozitivul are o adresă publică (fără router la mijloc), acel port se vede din Internet, chiar dacă cere în continuare o cheie din lista dvs.

Copii. Copia criptată are parolă (scrypt și XChaCha20-Poly1305): fără ea nimeni nu o poate deschide, nici noi. Exportul JSONL nu este criptat și conține evenimentele dvs. private ca text simplu; aplicația vă avertizează.

Blocarea (PIN, plus amprentă sau Windows Hello) este cerută la deschiderea aplicației, după 30 de secunde de absență și pentru aprobarea unei asocieri. Este o barieră de comoditate, ca în Mail: nu criptează nimic. Pe Android, cu PIN setat nu există capturi de ecran și nici miniatură în aplicațiile recente, iar începând cu Android 12 nicio fereastră a altei aplicații nu se poate suprapune peste cea a releului cât timp o folosiți.

Herkos Drive: ce protejează și ce nu

Herkos Drive vă păstrează fișierele pe servere Blossom și lista fișierelor și dosarelor dvs. pe relee Nostr, ambele criptate pe dispozitivul dvs. Iată ce le protejează și unde sunt limitele. Detaliile complete se află în spec-drive.md și în modelul de amenințări amenazas-drive.md, în packages/herkos_drive_protocol/; ce vede fiecare releu și server se află în politica de confidențialitate. Raportați problemele de securitate ale Drive la fel ca pe oricare altele (mai sus).

Ce nu pot face releele și serverele:

• Să vă citească fișierele sau numele lor. Fiecare bloc al unui fișier este criptat cu AES-256-GCM cu o cheie proprie reviziei sale; numele, dosarele, dimensiunile, datele și cheile sunt sigilate cu XChaCha20-Poly1305 cu cheia dosarului în care se află. Nimic nu este derivat din conținut: același fișier încărcat de două ori dă blocuri diferite.
• Să schimbe, să înlocuiască sau să mute ceva fără să se observe. Fiecare bloc este verificat față de manifestul sigilat în intrarea fișierului său, iar fiecare intrare este semnată de cheia volumului și sigilată pentru propriul loc (volum, identificator și dosar): un releu nu poate da o intrare drept alta și nici un bloc drept altul.
• Să aducă înapoi o versiune veche. Aplicația nu acceptă niciodată o intrare mai veche decât cea pe care o are deja pentru același identificator.
• Să scrie în numele dvs. doar cu cheia volumului. Ce scriu dispozitivele dvs. poartă marca proprietarului, un HMAC cu o cheie pe care nu o dă niciun link; o intrare sau o ștergere fără ea nu este acceptată, iar aplicația vă avertizează.

Ce nu protejează:

• Tiparul Drive-ului dvs. Releele vă pot număra fișierele și dosarele, pot vedea forma arborelui și când se schimbă fiecare intrare; serverele văd cam cât de mare este fiecare fișier (blocurile sunt completate până la 64 KiB, intrările până la o putere a lui doi). Fiecare releu și server vă vede adresa IP. Folosiți Tor sau Orbot la nivelul sistemului dacă asta contează pentru dvs.
• Ce a descărcat deja cineva. Eliminarea unui link sau a unei persoane dă imediat chei noi pentru ce putea deschide, așa că nu va deschide ce adăugați ulterior; nu poate lua înapoi ce a salvat deja.
• Un link scurs. Un link fără parolă este cheia. Browserul îl poate păstra în istoric înainte ca pagina să-l scoată din bara de adrese. Pentru orice lucru sensibil, puneți linkului o parolă, trimisă pe altă cale, sau partajați cu contul persoanei. O parolă slabă poate fi spartă în timp: cine are linkul poate încerca offline.
• Pagina herkos.app/f/ rulează în browserul celui care deschide un link. Este servită cu o Content-Security-Policy strictă, Subresource Integrity și fără cod de la terți, dar cine controlează găzduirea web ar putea servi o altă pagină. Aceasta este limita oricărei pagini web care decriptează în browser.
• Cine a avut cheia volumului (a dvs. sau primită cu un link către un dosar) poate încă șterge blocurile care au fost încărcate cu ea, până când sunt încărcate din nou. Puteți schimba cheia volumului (Setări → Cheia volumului): celelalte dispozitive ale dvs. urmează singure.
• Dispozitivul dvs. Lista fișierelor este păstrată criptată în cache, cu cheia în stocarea securizată a sistemului; un fișier pe care îl descărcați sau îl deschideți este scris necriptat acolo unde alegeți. PIN-ul din Drive este o barieră de comoditate, ca în Mail.
• Un computer cuantic, mai târziu. Blocurile și sigiliile sunt simetrice (AES-256, XChaCha20), dar localizatorul dvs. este criptat cu NIP-44 pe secp256k1: cineva care îl păstrează azi și sparge secp256k1 mâine ar putea deschide tot Drive-ul.

Cum este verificat. Două revizuiri interne pe baza modelului de amenințări (2 noiembrie 2026) și corecturile lor; teste a ceea ce arată fiecare eveniment și bloc; fuzzing pentru fiecare cititor a ceea ce vine din exterior (evenimente, sigilii, manifeste, linkuri, copii de rezervă). Încă niciun audit extern: unul este planificat înainte de beta publică, iar raportul său va fi publicat integral. Drive este încă în dezvoltare.

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.