Biztonsági szabályzat

A Herkos privát kulcsokat és titkosított üzeneteket kezel, ezért komolyan vesszük a biztonsági bejelentéseket, és inkább korán értesülünk egy problémáról, mint későn.

Sebezhetőség bejelentése

Kérjük, biztonsági problémák miatt ne nyisson nyilvános hibajegyet (issue-t).

Jelentse be privát módon a GitHub privát sebezhetőség-bejelentési funkciójával, vagy e-mailben a security@herkos.email címen.

Hasznos, ha megadja: mi a probléma, hogyan lehet reprodukálni, melyik platformon és verzión tesztelte, és mit érhetne el vele egy támadó. Egy koncepcióbizonyítás (proof of concept) sokat segít.

Soha ne tegye bele a bejelentésbe a saját nsec kulcsát, titkos kulcsát vagy bunkertitkát.

Arra törekszünk, hogy néhány napon belül visszaigazoljuk a bejelentéseket. Mivel a Herkos kis projekt, kérjük, hagyjon észszerű időt a javításra, mielőtt nyilvánosságra hozná. Szívesen feltüntetjük a nevét a biztonsági közleményben, hacsak nem kéri másként.

Mire terjed ki

Magára a Herkos alkalmazásra: a kulcsok kezelésére és tárolására, az üzenetek titkosítására és visszafejtésére (beleértve a NIP-59 feladóellenőrzéseket és a titkos másolat (Bcc) elkülönítését a local_packages/nostr_mail csomagban), az alkalmazászárra, a relékkel és hidakkal folytatott kommunikációra, a mellékletek kezelésére, valamint a fordítási és kiadási folyamatra.

Mire nem terjed ki

Magára a Nostr protokollra és a NIP-ekre — ezeket a protokoll fejlesztőinek jelentse.
A harmadik felek által üzemeltetett relékre, hidakra és Blossom-szerverekre. A Herkos alapértelmezésekkel érkezik, de nem üzemelteti őket; a problémákat azok üzemeltetőinek jelentse.
Az eredeti projektre, a Nostr Mail Client programra, kivéve, ha a probléma a Herkosban végzett módosításokhoz kötődik.
Olyan hiányzó megerősítésekre, amelyeket már ismert korlátként dokumentáltunk (lásd lent).

Ismert korlátok, kertelés nélkül

Ezek tervezési kompromisszumok, nem sebezhetőségek. Inkább leírjuk őket, mint hogy valaki a saját kárán fedezze fel:

A hagyományos címekre küldött levelek nem végpontok közötti titkosításúak. A Nostr-felhasználók közötti üzenetek NIP-17 gift wrapet használnak, és végpontok között titkosítottak. Ha hagyományos e-mail-címre ír, egy híd alakítja át az üzenetet, és elolvashatja.
Az alkalmazászár (PIN-kód és biometrikus azonosítás) kényelmi akadály, nem a tárolt adatok titkosítása. Megállítja azt, aki felvesz egy feloldott eszközt; nem véd az olyan támadó ellen, aki teljes hozzáféréssel rendelkezik az eszközhöz vagy annak tárhelyéhez.
Windowson nem lehet kizárólag biometrikus hitelesítést kikényszeríteni. A Windows Hello nem teszi lehetővé a módszer kiválasztását, így a rendszer PIN-kódja tartalékként mindig elérhető marad.
A kulcs elvesztése a fiók elvesztését jelenti. Helyreállítás nincs, ez szándékos.
A metaadatok nincsenek teljesen elrejtve. A relék megfigyelhetik a kapcsolódási mintákat, és minden relé látja az IP-címét, még akkor is, ha az üzenetek tartalmát nem tudja elolvasni. Amit a Herkos nem árul el (2026. 09. 30. óta), az az, hogy ki kinek ír, amikor egy relé NIP-42 hitelesítést kér:
A kézbesítési cél lekérdezése. A címzett relé- és Blossom-listáit egy külön kapcsolaton kérdezi le, amely soha nem azonosítja Önt, és először olyan reléken, amelyek nem követelnek hitelesítést (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
Profilok és az ütemező. A mások mellett megjelenített nevet és képet (kind 0), valamint az ütemező DVM relélistáját, amikor e-mailt ütemez vagy ütemezést töröl, ugyanígy kérdezi le: először névtelenül, és ha egy relé ragaszkodik hozzá, az alább leírt ideiglenes kulccsal, soha nem az Önével (2026. 10. 01. óta; korábban a hitelesítést kérő relé megkapta az Ön kulcsát, és megállapíthatta, kinek a profilját nézi). Csak a saját profilját olvassa továbbra is az Ön nevében.
Kézbesítés. A gift wrapek a címzett magánlevél-reléire kerülnek, ugyanazon a külön kapcsolaton. Ha valamelyikük hitelesítést követel, a Herkos egy erre a célra létrehozott, csak a memóriában tartott kulccsal válaszol, soha nem az Önével; az eszközön minden fióknak saját ilyen kulcsa van. A relé így is láthatja, hogy ugyanaz az eszköz (ugyanaz az IP-cím, ugyanaz az ideiglenes kulcs) több borítékot küldött egy munkamenet alatt.
Nagy e-mailek. A 32 KB-nál nagyobb e-mailek titkosított másolata Blossom-szerverekre kerül feltöltésre, a címzettekéire is. Csak a saját szerverei (az Ön Blossom-listája) kapják a feltöltést az Ön kulcsával engedélyezve. Bármely más szerver névtelenül kapja, és ha ragaszkodik az engedélyezéshez, akkor a fenti ideiglenes kulccsal aláírva (2026. 10. 01. óta; korábban minden szerver megkapta az Ön kulcsát). Az a szerver, amely csak ismert kulcsokat fogad el, elutasítja, és a másolat a többi szerveren marad.
Saját adatai. A postafiók, a címkék, a beállítások és a piszkozatok szinkronizálása — ahol egy relé kéri — annak a fióknak a nevében hitelesít, amelyhez az adatok tartoznak, még fiókváltás közben is. A saját reléinek ez semmi olyat nem árul el, amit eddig ne tudtak volna: a kérések amúgy is megnevezik a kulcsát. A saját relé- és Blossom-listái nyilvánosak, és lekérdezésük az Ön azonosítása nélkül történik, ahogyan az e-mail-hivatkozásokban megnevezett reléké is.
Az olvasottsági állapot és a mappák nyilvános metaadatok (egyelőre). Ha egy e-mailt olvasottnak, csillagozottnak, archiváltnak jelöl vagy áthelyez, az egy titkosítatlan NIP-32 címkeeseményt tesz közzé, amely a nyilvános kulcsához kötődik, az egyéni mappák neveivel együtt. Az a feladó, aki ismeri egy Önnek küldött e-mail azonosítóját, megtudhatja, mikor csinált vele valamit. E címkék titkosítása tervben van; addig tekintse nyilvánosnak a mappaneveket.
A push-értesítések és az ütemezett küldés harmadik féltől származó szolgáltatásokat használnak. A push-szerver (alapértelmezés szerint api.nmail.li) megtudja a nyilvános kulcsát, egy push-tokent és azt, hogy mikor kap levelet; az ütemező DVM megtudja a nyilvános kulcsát és a közzéteendő, már titkosított üzeneteket. Mindkettő csak kifejezett bekapcsolással működik, és mindkettő le van írva a PRIVACY.md fájlban. A push-értesítés szövegét a push-szerver határozza meg, és a Herkos csak akkor bízik meg benne, ha a UnifiedPush titkosítva kézbesíti (RFC 8291); a titkosítatlan tartalom csak felébreszti az alkalmazást, hogy maga töltse le a levelet.
A webes változat a böngészőben tartja a kulcsát, ami a leggyengébb hely számára. A telepített alkalmazások az operációs rendszer biztonságos tárolójára bízzák a titkos kulcsát (Android Keystore, Windows Hitelesítőadat-kezelő, libsecret, az iOS/macOS Keychain). A böngészőben ezek egyike sincs meg: a kulcs a forrás (origin) tárhelyén van, és minden aláíráskor áthalad a JavaScripten, elérhetően bármely kód számára, amely az oldalon fut — egy minden webhelyhez hozzáférő böngészőbővítmény, egy XSS-hiba az alkalmazásban vagy egy függőségében, egy manipulált telepítés —, valamint bármely adatlopó kártevő (infostealer) számára, amely lemásolja a böngészőprofilt. Olyan pillanat sincs, amikor egyszer s mindenkorra ellenőrizné a kódot: az aláírt binárist a telepítéskor ellenőrzik, míg egy weboldal minden látogatáskor friss kódot szállít. A webes változatba távoli aláíróval (NIP-46 bunker, Amber) jelentkezzen be, hogy a kulcs soha ne jusson el a böngészőig, vagy kezelje eldobható identitásként, és a valódi kulcsát egy telepített alkalmazásban tartsa.
A hídon át érkező levél csak annyira megbízható, mint maga a híd. A Herkos ellenőrzi, hogy egy hídon keresztül érkezettként jelölt üzenetet valóban egy Ön által beállított híd (vagy valamelyik alapértelmezett) írt-e alá. A híd által továbbított hagyományos From: címről azonban semmit nem tud ellenőrizni.
A mellékleteket az operációs rendszer nyitja meg. A Herkos soha nem indít el futtatható vagy parancsfájl-típusú fájlokat, és rákérdez, mielőtt bármely más, előnézettel nem megjeleníthető mellékletet átadna a rendszer alapértelmezett alkalmazásának, de a fájlt megnyitó alkalmazás felett nincs befolyásunk.

Támogatott verziók

A biztonsági javításokat a legutóbb kiadott verzióba építjük be. A projekt méretéből adódóan a régebbi verziókat nem tartjuk karban — kérjük, a bejelentés előtt frissítsen.