Freedom en end-to-end encryptie

Ik hoop dat Freedom een leidende rol kan nemen nu de discussie rond end-to-end encryptie weer actief is.

Het lijkt voor Freedom/Soverin op dit moment te ingrijpend om aanvullende infrastructuur in te richten zoals een XMPP server, maar ik kwam net Delta Chat tegen en deze info in hun FAQ:

Daarnaast:
https://docs.autocrypt.org/

Autocrypt is a set of guidelines for developers to achieve convenient end-to-end-encryption of e-mails. It specifies how e-mail programs negotiate encryption capabilities using regular e-mails. Autocrypt Level 1 was created in 2019 and subsequently implemented in various MUAs and is in wide active use. For users, Autocrypt offers single-click, opt-in encryption, eases encrypted group communications, and provides a way to setup encryption on multiple devices.

Misschien is dit iets haalbaarder is voor Freedom om te ondersteunen/promoten vanuit de huidige mail infrastructuur met Soverin?

Zitten er op dit forum toevallig ook mensen van Soverin?

Mogelijkheden in een andere richting met hetzelfde doel, zijn overigens ook interessant. Ik denk dat dit een aspect is waar Freedom concreet meerwaarde kan bieden ten aanzien van andere service providers.

Mail is toch al mogelijk om E2E encrypt te worden ?
Niks moeilijk en hooguit even omdenken om het te gebruiken.

Voordeel van autocrypt lijkt dan dat het transaranter te gebruiken is, voor wie/met encryptie mailt, worden keys automatisch uitgewisseld en voor wie dat niet heeft/kan, krijg dan de mail - neem ik aan - op gewone wijze.

Ik zie buiten webclients & mailrules (op inhoud), niet helemaal de betrokkenheid van providers. Wanneer je bedoeld dat mailproviders van autocrypt headers af moeten blijven, snap ik het pleidooi.
Geen idee eigenlijk of en zo ja Soverin (aka. Freedom) ‘vreemde’ toestaat of manipuleert.

1 like

Voor wat helderheid in de discussie:

E2E betekent maar 1 ding: dat er geen server tussen de 2 partijen zit waar het verkeer zichtbaar is voor de beheerder van die server. Als het gaat om mail:

  • als beide partijen alleen TLS ondersteunen is de verbinding “min of meer” (zie verderop) E2E encrypted, verzender en ontvanger kunnen de data lezen. Mail via TLS is tegenwoordig standaard. MTA-STS en TLS-RPT helpen dit te forceren.
  • Als beide partijen X509 of PGP mailversleuteling ondersteunen is de mail in feite E2E versleuteld. Alleen de uiteindelijke ontvanger kan de mail lezen. Mailversleuteling is nog steeds wel een niche en behoorlijk complex.

Het probleem begint met een intermediary system - TLS versleutelt de verbinding tussen 2 punten, niet gegarandeerd tussen verzender en ontvanger ;

  • Neem een secondary MX server: als ik een mailserver heb die maar af en toe online is kan ik met een secondary MX server ontvangst “bufferen”. Probleem is dat iedereen met rechten op die server (inclusief bv de beheerder van de cloud waar deze draait) de mail kan lezen.
  • een mailprovider (zoals bijvoorbeeld Soverin / Freedom of GMail) is ook een internediary - voordat je je mail ophaalt met IMAP of POP3 ligt de mail op andermans server.
  • mail versturen gaat meestal ook via andermans (SMTP) server.

Kort en goed: mail zonder PGP/X509 is niet E2E.

2 likes

Dit is toch niet helemaal een juiste weergave. TLS zorgt alleen maar dat de mail versleuteld over het (inter)net wordt verstuurd, maar zodra die op de mailserver zelf staat, is de oorspronkelijke informatie gewoon leesbaar. Dus verzender, ontvanger Ă©n alle tussenliggende mailservers kunnen de data lezen.

TLS in deze is dus absoluut niet End-to-End. Het voorkomt hooguit dat bijvoorbeeld iemand die naast je op de WiFi zit doormiddel van sniffing jouw email voorbij kan zien komen in het oorspronkelijke formaat. (Dit is dus dezelfde soort bescherming als het gebruik van https.) Aangezien je bij email routering eigenlijk niet kunt zeggen hoe dat gaat verlopen, is een veel groter probleem de opslag van je email op alle servers die je onderweg tegenkomt. Om je een idee te geven, een virus- of spam-scanner op de mailserver werkt door simpelweg jouw email even te “lezen”.

3 likes

Eens, vandaar ook de “zie verderop”.

Ik vind S/MIME veel makkelijker in gebruik.
PGP is in mijn beleving wel het veiligst.
Voorwaarde is dan wel, dat je goed beheer hebt over je sleutels.
Als ik een keer iets moet versleutelen, dan wel met de hand.
En niet inbouwen in b.v. de webmail.

1 like

Wat betreft webmail, denk ik dat het inderdaad op browser extensies zou moeten leunen danwel een andere manier om een sleutel in te voeren die enkel binnen de browser blijft bij het lezen van de mail.
Verder zou Freedom/Soverin wellicht kunnen faciliteren door:

  • Sleutels te beheren
  • Encryptie toe te passen en klanten te instrueren om mail te versleutelen, bijvoorbeeld helpdesk mail zou volledig versleuteld moeten kunnen worden.

Zou het een goed idee zijn als de helpdesk te bereiken is met Delta chat?

Wat de helpdesk betreft.
Ik had hiervoor nog nooit van Delta chat gehoord.
Iets invoeren dat zo onbekend is, lijkt me raar.
Als je het doet, komen er ook mensen die het met WhatsApp willen doen.
En dan is de vraag, wat kost het om dit te koppelen?

Misschien een chat-box op een helpdeskwebpagina zoals heel veel bedrijven tegenwoordig doen. Dan staan klanten geen lange tijd in de wacht aan de telefoon, maar droppen ze hun vraag in de chat-box. Wachten op een reactie in een chat-box is minder vervelend.
Je moet het dan niet zien als een vervanger van de telefonische helpdesk, maar als een toevoeging.
Maar wellicht een nieuw draadje? Dit heeft niets met E2E encryptie van doen.

Ervanuitgaande dat je prive-sleutels (private keys) een wachtwoord hebben of een andere beveiliging – zo niet dan speel je natuurlijk met vuur en ben je niet serieus bezig – blijft het beheer ervan iets wat je volgens mij niet snel uit handen geeft aan een derde. Er zijn niet voor niets speciale “tokens” om zo’n sleutel op te zetten met hardware encryptie enzo.

En ja, gebruiksgemak en versleutelingsveiligheid zitten elkaar hier dus in de weg, juist omdat ze elkaars tegenpolen zijn. Hoe groter het gemak, hoe lager de veiligheid. (Denk aan hoe bijvoorbeeld gezichtsherkenning het gemak van inloggen verhoogt, maar kinderen dat eenvoudig misbruiken om de telefoon van hun ouders te “openen” door die voor hun gezicht te houden.)

Om zoiets als een helpdesk volledig via versleuteling te kunnen bereiken vind ik een ietwat vreemd idee:

  • ten eerste: je weet niet aan wie je schrijft, “de helpdesk” heeft meerdere medewerkers, waar ook nog eens mensen komen en gaan.
  • ten tweede, als je dus versleuteld voor de entiteit “helpdesk Freedom” dan betekent dat simpelweg dat er een heel pak aan mensen toegang heeft tot die sleutel
  • daarnaast, als je ook antwoord krijgt onder die sleutel, dat er dus een heel aantal mensen die sleutel heeft en kan gebruiken om berichten mee te verzenden. (Je weet dus niet meer wie wie is op basis van de sleutel, en iedereen kan zeggen te zijn wie hij/zij wil, net als nu het geval is.)
  • Kortom, volgens mij voegt het niks toe, behalve extra complicerende toestanden en schijn-zekerheid. Als je afluisteren in deze door mensen buiten Freedom wilt voorkomen, gebruik je gewoon TLS tijdens het verzenden. De helpdesk zorgt dat hun antwoorden in jouw mailbox wordt afgeleverd met gebruik van TLS voor zover ik kan zien.

Laatste noot: schijn-zekerheid is wat veel van deze voorstellen volgens mij als resultaat hebben. Met goede intenties proberen wat versleuteling of veiligheid toe te voegen, maar zonder dat echt te ankeren bijvoorbeeld door goede, beveiligde en geverifeerde sleutels (web of trust bijvoorbeeld) kan mensen het idee geven dat er veiligheid is, maar omdat de basis zwak is (zoals bij autocrypt), maar marginaal beter. De waan veilig te zijn kan voor sommigen misschien geruststellend zijn, maar ik denk dat het beter is wanneer men berust in de onveilige situatie waarin ze verkeren zodat het alleen maar mee kan vallen.

2 likes

Webmail en daarin dus op andermans server (private)sleutels aanmaken of beheren, biedt geen echte veiligheid.

Je moet dan vertrouwen dat de organisatie die zegt niet mee te kijken ook niet zal meekijken (bvk omdat zij dat sws niet kan). In het geval van mail kan Freedom idd niet zelf meekijken maar wel haar dienstverlener t.w. Soverin.

Topic - Autocrypt - is wel interessant met zoals ik het begrijp om PgP als protocol mee te integreren via mailheaders en de (publieke) sleuteldistributie daarvan meeneemt.
Nu moet ik elders - kan helaas niet meer bij Freedom - een website bijhouden om mijn publieke sleutels/hashes te publiceren. Kan ook op PgP-key servers dat voor anderen soms net een brugje te ver is.

Privésleutels kan Freedom uiteraard niet bewaren, maar publieke sleutels wel.

Als het om berichten van de helpdesk gaat, lijkt het me goed dat die dusdanig versleuteld naar klanten worden verstuurd, dat alleen de klant erbij kan. En niet ook bijvoorbeeld Soverin.

Misschien zou dat laatste een interessant uitgangspunt kunnen zijn. Kan Freedom met Soverin samenwerken om te zorgen dat de communicatie die via Soverin loopt, niet voor Soverin inzichtelijk is? Autocrypt/Delta Chat is een manier. Ik begrijp dat Proton mail ook dit soort functionaliteit biedt.

Die kunnen ze dus wel bewaren en doen ze ook voor PGP via webmail. Wat ze niet bewaren, c.q. niet afluisteren, mag je hopen, is jouw bijbehorende passkey.

Wat veel mensen bij PGP vergeten is dat ze van een ontvangen public key nog moeten verifieren dat die inderdaad afkomstig is van de persoon waarvan je denk dat die public key is. Dat kan met de volledige fingerprint die je dan ontvangt van de eigeneaar van de public key via een ander fysiek communicatiemiddel dan waarmee je de public key hebt ontvangen, of nog beter persoonlijk fysiek overhandigd.

Weet je toevallig hoe dit geimplementeerd is? Wordt de passphrase naar de server verzonden en daar gpg aangeroepen, of is er een client-side (javascript?) implementatie van gpg die de private key van de server ontvangt?

Ik vrees dat het het eerste is, en als dat het geval is, heeft de (web)server dus op bepaalde momenten toegang tot zowel je private key als passphrase. (!!!)

Gretty Pood Grivacy ? :wink:

GNU Privacy Guard, de meest populare implementatie van PGP.

1 like

Lijkt mij niet.
Met webmail wordt het gebruikte script “twofactor_gauthenticator.js” uitgevoerd in de browser bij de gebruiker.

Dat is wel een interessante variant! Stel dat je wachtwoord ook de passphrase is voor het ontsleutelen van de privésleutel, dan kan je daarna in principe alles met encryptie/decryptie vanuit webmail doen. Zijn er webmail clients die dit implementeren?

Dank voor het checken.

Ik zie net dat Roundcube gewoon vraagt om de key en de passphrase bij het toevoegen, dus of de encryptie nu lokaal of op de server wordt gedaan, maakt niet uit, de server heeft toegang tot sleutel en wachtwoord.

:+1: Naar ik begrijp, zou E2E “Autocrypt” dit via (mail)headers kunnen faciliteren zodat die verificatie “automatisch” plaatsvindt.
Zelfs publiceerde ik die fingerprint(s) op mijn website* (en deels, niet voor alle sleutels) via publieke PgP-servers.

Offtopic: Freedom biedt geen website voor o.a. fingerprint publicatie

(Ik weet offtopic, maar het blijft mij :angry: niet lekker zitten dat de webfunctie rĂŒcksichloss is verwijderd.)
Ook daarom was het fundamenteel een volstrekt verkeerde beslissing om de websfunctie te elimineren omdat anderen dat niet nodig vonden.
Nu zijn dat t.a.v. encryptie bij Freedom/Soverin, externe resources nodig om PgP goed aan te faciliteren aan contactpersonen. Fingerprint meesturen met ordinair mail is daarin natuurlijk geen betrouwbare optie.
Freedom zou voor E2E tenminste ook door de gebruiker te beheren publicatie moeten (willen) faciliteren met bvk een platte (https) website zodat daar de visitekaartjes met o.a. fingerprints en eventueel bijbehorende publieke_sleutels zijn neer te zetten.