Beveiligingsbeleid

Herkos verwerkt geheime sleutels en versleutelde berichten, dus we nemen beveiligingsmeldingen serieus en horen liever vroeg dan laat over een probleem.

Een kwetsbaarheid melden

Open voor beveiligingsproblemen alstublieft geen openbare issue.

Meld het vertrouwelijk via GitHubs private vulnerability reporting, of per e-mail aan security@herkos.email.

Nuttig om te vermelden: wat het probleem is, hoe het te reproduceren is, welk platform en welke versie u hebt getest, en wat een aanvaller ermee zou kunnen bereiken. Een proof of concept helpt enorm.

Voeg nooit uw eigen nsec, geheime sleutel of bunkergeheim toe aan een melding.

We streven ernaar meldingen binnen enkele dagen te bevestigen. Omdat Herkos een klein project is, vragen we u een redelijke termijn voor een oplossing te geven voordat u iets openbaar maakt. We vermelden u graag in de advisory, tenzij u dat liever niet hebt.

Wat binnen de reikwijdte valt

De Herkos-applicatie zelf: het beheer en de opslag van sleutels, het versleutelen en ontsleutelen van berichten (inclusief de NIP-59-afzendercontroles en de Bcc-isolatie in local_packages/nostr_mail), de app-vergrendeling, de communicatie met relays en bridges, de verwerking van bijlagen, en de build- en releasepipeline.

Wat buiten de reikwijdte valt

Het Nostr-protocol en de NIP's zelf — meld die upstream.
Relays, bridges en Blossom-servers die door derden worden beheerd. Herkos wordt met standaardinstellingen geleverd maar beheert ze niet; meld problemen bij hun beheerders.
Het upstreamproject Nostr Mail Client, tenzij het probleem specifiek is voor wijzigingen die in Herkos zijn gemaakt.
Ontbrekende versteviging die we al als bekende beperking documenteren (zie hieronder).

Bekende beperkingen, onomwonden

Dit zijn ontwerpafwegingen, geen kwetsbaarheden. We schrijven ze liever op dan dat iemand ze op de harde manier ontdekt:

E-mail naar traditionele adressen is niet end-to-end versleuteld. Berichten tussen Nostr-gebruikers gebruiken NIP-17 gift wrap en zijn E2E versleuteld. Schrijft u naar een gewoon e-mailadres, dan zet een bridge het bericht om en kan hij het lezen.
De app-vergrendeling (pincode en biometrie) is een gemaksdrempel, geen versleuteling in rust. Ze houdt iemand tegen die een ontgrendeld apparaat oppakt; ze beschermt niet tegen een aanvaller met volledige toegang tot het apparaat of de opslag ervan.
Op Windows kan alleen-biometrische authenticatie niet worden afgedwongen. Windows Hello laat niet toe de methode te kiezen, dus de pincode van het systeem blijft altijd beschikbaar als terugvaloptie.
Uw sleutel kwijtraken betekent het account kwijtraken. Er is bewust geen herstel.
Metadata zijn niet volledig verborgen. Relays kunnen verbindingspatronen waarnemen, en elk relay ziet uw IP-adres, ook als het de inhoud van berichten niet kan lezen. Wat Herkos (sinds 30-09-2026) niet prijsgeeft, is wie naar wie schrijft wanneer een relay om NIP-42-authenticatie vraagt:
Opzoeken waar te bezorgen. De relay- en Blossom-lijsten van een ontvanger worden opgevraagd via een aparte verbinding die u nooit identificeert, eerst bij relays die geen authenticatie vereisen (purplepag.es, user.kindpag.es, nos.lol, offchain.pub).
Profielen en de scheduler. De naam en afbeelding die voor anderen worden getoond (kind 0), en de relaylijst van de scheduler-DVM wanneer u een e-mail inplant of annuleert, worden op dezelfde manier opgevraagd: eerst anoniem en, als een relay aandringt, met de hieronder beschreven tijdelijke sleutel, nooit met de uwe (sinds 01-10-2026; daarvoor kreeg een relay dat om authenticatie vroeg uw sleutel, en kon het zien naar wiens profiel u keek). Alleen uw eigen profiel wordt nog als u gelezen.
Bezorgen. Gift wraps gaan naar de DM-relays van de ontvanger, via diezelfde aparte verbinding. Vereist een daarvan authenticatie, dan antwoordt Herkos met een sleutel die daarvoor is aangemaakt en alleen in het geheugen wordt bewaard, nooit met de uwe; elk account op het apparaat heeft er een eigen. Het relay kan nog steeds zien dat hetzelfde apparaat (hetzelfde IP, dezelfde tijdelijke sleutel) tijdens een sessie meerdere enveloppen heeft verstuurd.
Grote e-mails. De versleutelde kopie van een e-mail boven 32 kB wordt geüpload naar Blossom-servers, ook die van de ontvangers. Alleen uw eigen servers (uw Blossom-lijst) krijgen de upload geautoriseerd met uw sleutel. Elke andere server krijgt hem anoniem en, als hij op een autorisatie aandringt, een die is ondertekend met dezelfde tijdelijke sleutel als hierboven (sinds 01-10-2026; daarvoor kreeg elke server uw sleutel). Een server die alleen bekende sleutels accepteert, weigert hem, en de kopie blijft op de andere servers staan.
Uw eigen gegevens. Het synchroniseren van uw postbus, labels, instellingen en concepten authenticeert, waar een relay daarom vraagt, als het account waartoe de gegevens behoren, ook tijdens het wisselen van account. Op uw eigen relays vertelt dat ze niets wat ze nog niet wisten: de verzoeken noemen uw sleutel toch al. Uw eigen relay- en Blossom-lijsten zijn openbaar en worden opgevraagd zonder u te identificeren, net als relays die in een e-maillink worden genoemd.
Leesstatus en mappen zijn (voorlopig) openbare metadata. Een e-mail als gelezen markeren, een ster geven, archiveren of verplaatsen publiceert een onversleutelde NIP-32-labelgebeurtenis die aan uw publieke sleutel is gekoppeld, inclusief de namen van eigen mappen. Een afzender die het id kent van een e-mail die hij u stuurde, kan zien wanneer u er iets mee deed. Het versleutelen van deze labels is gepland; beschouw mapnamen tot die tijd als openbaar.
Pushmeldingen en gepland verzenden gebruiken diensten van derden. De pushserver (standaard api.nmail.li) leert uw publieke sleutel, een pushtoken en wanneer u e-mail ontvangt; de scheduler-DVM leert uw publieke sleutel en de reeds versleutelde berichten die hij moet publiceren. Beide zijn opt-in en gedocumenteerd in PRIVACY.md. De tekst van een pushmelding wordt door de pushserver bepaald, en Herkos vertrouwt die alleen als UnifiedPush hem versleuteld aflevert (RFC 8291); een onversleutelde payload maakt de app alleen wakker om de e-mail zelf op te halen.
De webversie bewaart uw sleutel in de browser, en dat is de zwakste plek ervoor. De geïnstalleerde apps geven uw geheime sleutel aan de beveiligde opslag van het besturingssysteem (Android Keystore, Windows Referentiebeheer, libsecret, de iOS-/macOS-sleutelhanger). Een browser heeft daar niets van: de sleutel staat in de opslag van de origin en gaat bij elke ondertekening door JavaScript, binnen bereik van alle code die in de pagina draait — een browserextensie met toegang tot alle sites, een XSS-fout in de app of in een afhankelijkheid, een gemanipuleerde uitrol — en van elke infostealer die het browserprofiel kopieert. Er is ook geen moment waarop u de code één keer controleert: een ondertekend programma wordt bij de installatie gecontroleerd, terwijl een webpagina bij elk bezoek nieuwe code levert. Log in de webversie in met een externe ondertekenaar (NIP-46-bunker, Amber), zodat de sleutel de browser nooit bereikt, of beschouw het als een wegwerpidentiteit en bewaar uw echte sleutel in een geïnstalleerde app.
E-mail via een bridge is maar zo betrouwbaar als de bridge. Herkos controleert dat een bericht dat als via een bridge binnengekomen is gemarkeerd, echt is ondertekend door een bridge die u hebt ingesteld (of een van de standaardbridges). Het kan niets controleren over het traditionele From:-adres dat de bridge doorgeeft.
Bijlagen worden door het besturingssysteem geopend. Herkos start nooit uitvoerbare bestanden of scripts en vraagt het eerst voordat het een andere niet-voorvertoonbare bijlage aan de standaardapp van het systeem geeft, maar de app die het bestand opent, valt buiten onze controle.

Ondersteunde versies

Beveiligingsoplossingen worden toegepast op de nieuwste uitgebrachte versie. Gezien de omvang van het project worden oudere versies niet onderhouden — werk alstublieft bij voordat u iets meldt.