Política de seguretat

Herkos gestiona claus privades i missatges xifrats, així que ens prenem seriosament els informes de seguretat i preferim saber d'un problema aviat que no pas tard.

Com informar d'una vulnerabilitat

Si us plau, no obris una incidència pública per a problemes de seguretat.

Informa'n en privat a través de l'informe privat de vulnerabilitats de GitHub, o per correu a security@herkos.email.

Coses útils per incloure: quin és el problema, com reproduir-lo, quina plataforma i quina versió has provat, i què podria aconseguir un atacant. Una prova de concepte ajuda molt.

No incloguis mai el teu nsec, la teva clau secreta ni el secret del teu bunker en un informe.

Intentem confirmar la recepció dels informes en pocs dies. Com que Herkos és un projecte petit, et demanem que deixis un temps raonable per a una correcció abans de fer-ho públic. T'esmentarem amb molt de gust a l'avís de seguretat, tret que prefereixis el contrari.

Què entra en l'abast

L'aplicació Herkos mateixa: el tractament i l'emmagatzematge de les claus, el xifratge i el desxifratge dels missatges (incloses les comprovacions del remitent de NIP-59 i l'aïllament de la còpia oculta (Bcc) a local_packages/nostr_mail), el bloqueig de l'aplicació, la comunicació amb relays i bridges, el tractament dels adjunts, i el procés de compilació i publicació.

Què queda fora de l'abast

• El protocol Nostr i els seus NIP mateixos: informa'n els seus responsables originals.
• Els relays, bridges i servidors Blossom gestionats per tercers. Herkos els porta com a valors predeterminats però no els gestiona; informa'n els seus operadors.
• El projecte original Nostr Mail Client, tret que el problema sigui propi dels canvis fets a Herkos.
• Mesures de protecció que falten i que ja documentem com a limitació coneguda (vegeu més avall).

Limitacions conegudes, dites clarament

Són decisions de disseny amb els seus costos, no vulnerabilitats. Preferim escriure-les que no pas que algú les descobreixi pel camí dolent:

• El correu a adreces tradicionals no va xifrat d'extrem a extrem. Els missatges entre usuaris de Nostr fan servir gift wrap NIP-17 i van xifrats d'extrem a extrem. Quan escrius a una adreça de correu normal, un bridge converteix el missatge i el pot llegir.
• El bloqueig de l'aplicació (PIN i biometria) és una barrera de comoditat, no un xifratge en repòs. Atura qui agafi un dispositiu desbloquejat; no protegeix contra un atacant amb accés complet al dispositiu o al seu emmagatzematge.
• A Windows no es pot imposar l'autenticació només biomètrica. Windows Hello no permet triar el mètode, de manera que el PIN del sistema sempre queda disponible com a alternativa.
• Perdre la clau vol dir perdre el compte. No hi ha recuperació, per disseny.
• Les metadades no queden del tot amagades. Els relays poden observar patrons de connexió, i tots els relays veuen la teva adreça IP, encara que no puguin llegir el contingut dels missatges. El que Herkos no revela (des del 30-09-2026) és qui escriu a qui quan un relay demana autenticació NIP-42:
• Saber on lliurar. Les llistes de relays i de Blossom d'un destinatari es demanen per una connexió separada que no t'identifica mai, primer a relays que no exigeixen autenticació (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
• Perfils i el programador. El nom i la imatge que es mostren de qualsevol altra persona (kind 0), i la llista de relays del DVM de programació quan programes o cancel·les un correu, es demanen de la mateixa manera: primer de forma anònima i, si un relay hi insisteix, amb la clau temporal que es descriu més avall, mai amb la teva (des de l'01-10-2026; abans, un relay que demanava autenticació rebia la teva clau i podia saber de qui era el perfil que miraves). Només el teu propi perfil es continua llegint com a tu.
• Lliurar. Els gift wraps van als relays DM del destinatari, per aquesta mateixa connexió separada. Si un d'ells exigeix autenticació, Herkos respon amb una clau creada per a l'ocasió i guardada només a la memòria, mai amb la teva; cada compte del dispositiu té la seva. El relay encara pot veure que el mateix dispositiu (mateixa IP, mateixa clau temporal) ha enviat diversos sobres durant una sessió.
• Correus grans. La còpia xifrada d'un correu de més de 32 KB es puja als servidors Blossom, inclosos els dels destinataris. Només els teus propis servidors (la teva llista de Blossom) reben la pujada autoritzada amb la teva clau. Qualsevol altre servidor la rep de forma anònima i, si insisteix a demanar una autorització, una signada amb la mateixa clau temporal d'abans (des de l'01-10-2026; abans, tots els servidors rebien la teva clau). Un servidor que només accepta claus conegudes la rebutja, i la còpia queda als altres servidors.
• Les teves pròpies dades. La sincronització de la bústia, les etiquetes, els ajustos i els esborranys s'autentica, quan un relay ho demana, com el compte a qui pertanyen les dades, fins i tot durant un canvi de compte. Als teus propis relays això no els diu res que no sabessin: les peticions ja porten la teva clau. Les teves pròpies llistes de relays i de Blossom són públiques i es demanen sense identificar-te, igual que els relays que apareixen en un enllaç d'un correu.
• L'estat de lectura i les carpetes són metadades públiques (de moment). Marcar un correu com a llegit, destacat, arxivat o mogut publica un esdeveniment d'etiqueta NIP-32 sense xifrar lligat a la teva clau pública, inclosos els noms de les carpetes pròpies. Un remitent que conegui l'identificador d'un correu que t'ha enviat pot saber quan hi has fet alguna cosa. Xifrar aquestes etiquetes està previst; fins llavors, considera públics els noms de les carpetes.
• Les notificacions push i l'enviament programat fan servir serveis de tercers. El servidor de push (api.nmail.li per defecte) coneix la teva clau pública, un testimoni de push i quan reps correu; el DVM de programació coneix la teva clau pública i els missatges ja xifrats que ha de publicar. Tots dos són opcionals i estan documentats a PRIVACY.md. El text d'una notificació push el tria el servidor de push, i Herkos només se'n refia quan UnifiedPush el lliura xifrat (RFC 8291); un contingut sense xifrar només desperta l'aplicació perquè vagi a buscar el correu ella mateixa.
• La versió web guarda la teva clau al navegador, que és el lloc més feble per a ella. Les aplicacions instal·lades confien la teva clau secreta a l'emmagatzematge segur del sistema operatiu (Android Keystore, Administrador de credencials de Windows, libsecret, el Clauer d'iOS/macOS). Un navegador no té res d'això: la clau és a l'emmagatzematge de l'origen i passa per JavaScript a cada signatura, a l'abast de qualsevol codi que s'executi a la pàgina —una extensió del navegador amb accés a totes les pàgines, un error d'XSS a l'aplicació o en una dependència, un desplegament manipulat— i de qualsevol programa robador d'informació que copiï el perfil del navegador. A més, no hi ha cap moment en què verifiquis el codi una vegada: un binari signat es comprova en instal·lar-lo, mentre que una pàgina web serveix codi nou a cada visita. Entra a la versió web amb un signant remot (bunker NIP-46, Amber), perquè la clau no arribi mai al navegador, o tracta-la com una identitat d'usar i llençar i guarda la teva clau real en una aplicació instal·lada.
• El correu que passa per un bridge només és tan fiable com el bridge. Herkos verifica que un missatge marcat com a arribat a través d'un bridge l'hagi signat realment un bridge que tens configurat (o un dels predeterminats). No pot verificar res de l'adreça From: tradicional que retransmet el bridge.
• Els adjunts els obre el sistema operatiu. Herkos no executa mai tipus de fitxer executables ni scripts, i pregunta abans de passar qualsevol altre adjunt que no es pugui previsualitzar a l'aplicació predeterminada del sistema, però l'aplicació que obre el fitxer és fora del nostre control.

Versions amb suport

Les correccions de seguretat s'apliquen a l'última versió publicada. Tenint en compte la mida del projecte, les versions anteriors no es mantenen: actualitza abans d'informar d'un problema.