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 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. A Herkos Drive esetében a protokollcsomagjára (packages/herkos_drive_protocol) és a linkjeit megnyitó oldalra (herkos.app/f/) is; lásd a saját szakaszát lent.

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, ha választ egyet (alapértelmezés szerint nincs; kérésre api.nmail.li a relay.nmail.li relével), 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, DPAPI Windowson, 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.

Herkos Local Relay: mit véd, és mit nem

A Herkos Local Relay az alkalmazásai eseményeit az Ön eszközén tárolja, a privátakat is (piszkozatok, privát listák, az Ön által kapott borítékok). Az alábbiakban az áll, mi védi őket, és hol a határ, platformonként. A relé biztonsági hibáit ugyanúgy jelentse, mint bármely mást (lásd fent).

A teljes adatbázis titkosítva van, a naplófájljával együtt (SQLite3 Multiple Ciphers, AEGIS-256). A kulcs 32 véletlenszerű bájt, amelyet az eszközön hoz létre, és a rendszer biztonságos tárolójában őriz: Androidon a Keystore-ban, Windowson a DPAPI-val, Linuxon a kulcstartóban (libsecret). Nem az Ön valamelyik jelszava védi, mert a relének magától kell elindulnia. A kulcs nélkül a relé nem indul el, és ezt közli is: soha nem nyit meg és nem hoz létre titkosítatlan adatbázist, és soha nem töröl olyat, amelyet nem tud megnyitni.

Asztali gépen a DPAPI és a kulcstartó határa ugyanaz, mint bármely programé: védenek a többi felhasználó ellen és az ellen, aki elviszi a lemezt, de nem egy olyan kártékony program ellen, amely már az Ön felhasználójaként fut. Ha ez az eset aggasztja, a rendszerlemez titkosítása (BitLocker, LUKS) véd, valamint az, hogy nem futtat olyan programokat, amelyekben nem bízik meg. Kulcstartó nélküli Linuxon (Secret Service nélkül) a relé nem indul el, és elmagyarázza, miért: a kulcsot soha nem tárolja titkosítatlanul.

Ki jut be, magán az eszközön. A relé csak a 127.0.0.1 címen figyel, és ezt a címet az eszköz bármely alkalmazása vagy a böngészőben megnyitott weboldal elérheti. Ezért:

• Egy alkalmazást párosítani kell: megjelenik a relé képernyőjén, és Ön jóváhagyja (a PIN-kóddal vagy az ujjlenyomattal, ha beállította őket). Bármely alkalmazás bármilyen nevet adhat magának: csak akkor hagyja jóvá, ha az imént kérte azt abból az alkalmazásból.
• Egy weboldalt mindig párosítani kell, és a párosítás csak onnan érvényes, ahol létrejött: az eszköz egy alkalmazásának párosítása semmit sem nyit meg egy weboldal előtt, még akkor sem, ha az ugyanazzal a kulccsal ír alá.
• Egy párosított alkalmazás csak azokat az eseménytípusokat olvassa és írja, amelyeket Ön megadott neki, és csak azokat törli, amelyeket írhat. Ha visszavonja, azonnal bontja a kapcsolatát.
• Egy nem párosított alkalmazás csak az Ön nyilvános eseményeit olvassa (amelyek amúgy is nyilvánosak), és semmit sem ír, hacsak be nem kapcsolja azt a beállítást, amely beengedi az eszköz nem párosított alkalmazásait.
• A privát eseményeket csak az kapja meg, aki NIP-42-vel igazolja, hogy nála van a kulcs, amelyhez tartoznak, egy borítékot pedig csak a címzettje.

Amit itt nem véd:

• Egy kártékony alkalmazás az eszközön lelassíthatja a relét, vagy memóriát fogyaszthat vele. Így semmi privátot nem tud elolvasni.
• Amíg a relé alszik vagy nem fut, a portja szabad. Androidon 10 percnyi kapcsolat nélküli idő után alvó állapotba kerül; asztali gépen a port szabad, amíg el nem indítja. Egy másik alkalmazás figyelhetne rajta, és kiadhatná magát a relének. A Herkos alkalmazások ellenőrizni fogják a relé kulcsát, mielőtt bármi privátot küldenének neki; ezt még nem teszik, és addig ez valódi korlát.
• Asztali gépen a számítógép többi felhasználója nem párosított alkalmazásként kapcsolódhat: olvashatja az Ön nyilvános eseményeit, és párosítást kérhet.

A helyi hálózat, ha bekapcsolja (alapértelmezés szerint ki van kapcsolva):

• Csak wss://, a relé saját tanúsítványával; az eszközön kívül soha nem titkosítatlan ws://.
• Semmi a hitelesítés (NIP-42) előtt, amelyhez az Ön listáján szereplő kulcs kell. Az a kapcsolat, amely ezt 30 másodpercen belül nem teszi meg, lezárul, és a helyi hálózatnak saját kapcsolatkerete van: soha nem foglalja el az eszköz alkalmazásainak kapcsolatait.
• Egy listán szereplő kulcs olvassa az Ön nyilvános eseményeit és a saját privát eseményeit, és csak az általa aláírt eseményeket írhatja. Ha leveszi a listáról, bontja a kapcsolatát.
• A tanúsítvány csak otthoni nevekre érvényes (localhost, .local, privát címek): még ha valaki el is lopná a kulcsát, nem tudna vele internetes domaint aláírni azokon az eszközökön, amelyekre telepítették.

Amit itt nem véd: aki ugyanazon a hálózaton van, látja, hogy az eszköznek nyitott portja van, és mekkora forgalom halad át rajta, azt viszont nem, hogy mi; és ha az eszköznek nyilvános címe van (nincs közte és az internet között router), ez a port az internetről is látszik, bár továbbra is az Ön listáján szereplő kulcsot kér.

Mentések. A titkosított mentésnek jelszava van (scrypt és XChaCha20-Poly1305): nélküle senki sem tudja megnyitni, mi sem. A JSONL-export nincs titkosítva, és a privát eseményeit titkosítatlanul tartalmazza; az alkalmazás figyelmezteti erre.

A zár (PIN-kód, valamint ujjlenyomat vagy Windows Hello) az alkalmazás megnyitásakor, 30 másodperc távollét után és egy párosítás jóváhagyásakor kéri a feloldást. Ez kényelmi akadály, mint a Mailben: semmit sem titkosít. Androidon beállított PIN-kóddal nem készülhet képernyőkép, és nem jelenik meg miniatűr a legutóbbi alkalmazások között, az Android 12 óta pedig semmilyen más alkalmazás ablaka nem kerülhet a reléé fölé, amíg Ön használja.

Herkos Drive: mit véd, és mit nem

A Herkos Drive a fájljait Blossom-szervereken, a fájljai és mappái listáját pedig Nostr-reléken tárolja, mindkettőt az Ön eszközén titkosítva. Az alábbiak védik őket, és itt vannak a határok. A teljes részletek a spec-drive.md fájlban és az amenazas-drive.md fenyegetésmodellben találhatók, a packages/herkos_drive_protocol/ mappában; hogy az egyes relék és szerverek mit látnak, az adatvédelmi szabályzatban olvasható. A Drive biztonsági problémáit ugyanúgy jelentse, mint bármely mást (lásd fent).

Amire a relék és a szerverek nem képesek:

• Elolvasni a fájljait vagy azok nevét. Egy fájl minden blokkja AES-256-GCM-mel van titkosítva, a fájl adott változatának saját kulcsával; a nevek, mappák, méretek, dátumok és kulcsok XChaCha20-Poly1305-tel lepecsételve utaznak, annak a mappának a kulcsával, amelyben vannak. Semmi sem a tartalomból származik: ugyanaz a fájl kétszer feltöltve különböző blokkokat ad.
• Észrevétlenül módosítani, felcserélni vagy áthelyezni bármit. Minden blokkot a fájl bejegyzésében lepecsételt manifesthez vet össze az alkalmazás, és minden bejegyzést a kötetkulcs ír alá, és a saját helyére van lepecsételve (kötet, azonosító és mappa): egy relé nem adhat ki egy bejegyzést egy másiknak, sem egy blokkot egy másiknak.
• Visszahozni egy régi változatot. Az alkalmazás soha nem fogad el olyan bejegyzést, amely régebbi annál, amely ugyanahhoz az azonosítóhoz már megvan.
• Az Ön nevében írni pusztán a kötetkulccsal. Amit az eszközei írnak, az a tulajdonos jelét hordozza, egy HMAC-ot olyan kulccsal, amelyet egyetlen link sem ad át; az e nélküli bejegyzést vagy törlést az alkalmazás nem fogadja el, és figyelmezteti Önt.

Amit nem véd:

• A Drive-ja mintázatát. A relék meg tudják számolni a fájljait és mappáit, látják a fa szerkezetét, és azt, hogy mikor változnak az egyes bejegyzések; a szerverek nagyjából látják, mekkora az egyes fájlok (a blokkok 64 KiB-ra, a bejegyzések kettő hatványára vannak kiegészítve). Minden relé és szerver látja az IP-címét. Ha ez fontos Önnek, használjon rendszerszinten Tort vagy Orbotot.
• Amit valaki már letöltött. Egy link vagy egy személy eltávolítása azonnal új kulcsokat ad annak, amit megnyithatott, így azt már nem nyitja meg, amit Ön később hozzáad; azt viszont nem veheti vissza, amit már elmentett.
• Egy kiszivárgott linket. A jelszó nélküli link maga a kulcs. A böngésző elmentheti az előzményeibe, mielőtt az oldal kiveszi a címsorból. Bármi érzékenyhez adjon a linknek jelszót, amelyet más úton küld el, vagy ossza meg az adott személy fiókjával. Egy gyenge jelszó idővel feltörhető: akinél a link van, offline próbálkozhat.
• A herkos.app/f/ oldalt, amely annak a böngészőjében fut, aki megnyit egy linket. Szigorú Content-Security-Policyval, Subresource Integrityvel és harmadik féltől származó kód nélkül szolgáljuk ki, de aki a webtárhelyet irányítja, másik oldalt szolgálhatna ki. Ez minden olyan weboldal korlátja, amely a böngészőben fejt vissza.
• Azt, akinél megvolt a kötetkulcs (az Öné, vagy egy mappára mutató linkkel átadva): még mindig törölheti azokat a blokkokat, amelyeket azzal töltöttek fel, amíg újra fel nem töltik őket. A kötetkulcsot lecserélheti (Beállítások → Kötetkulcs): a többi eszköze magától követi.
• Az eszközét. A fájlok listája titkosítva van gyorsítótárban, a kulcsa a rendszer biztonságos tárolójában; a letöltött vagy megnyitott fájl titkosítatlanul íródik oda, ahová Ön választja. A Drive PIN-kódja kényelmi akadály, mint a Mailben.
• Egy későbbi kvantumszámítógépet. A blokkok és a pecsétek szimmetrikusak (AES-256, XChaCha20), de a lokátora NIP-44-gyel van titkosítva, secp256k1-en: aki ma megőrzi, és holnap feltöri a secp256k1-et, az egész Drive-ot megnyithatná.

Hogyan ellenőrizzük. Két belső felülvizsgálat a fenyegetésmodell alapján (2026. november 2.) és az azokból következő javítások; tesztek arra, hogy mit mutatnak az egyes események és blokkok; minden olyan olvasó fuzzolása, amely kívülről érkező adatot dolgoz fel (események, pecsétek, manifestek, linkek, mentések). Külső audit még nincs: egyet a nyilvános béta előtt tervezünk, és a jelentését teljes egészében közzétesszük. A Drive még fejlesztés alatt áll.

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.