Anders, eenvoudig, doeltreffend en gratis met : https://tutanota.com/

Een mooi ideaal maar dan moet wel iedereen versleutelde email gebruiken. Zeker mooi voor bedrijven met bedrijfsgeheimen b.v.

Gewoon met standaarden zoals starttls, voor het hele domein, dat zou iedereen moeten doen in combinatie met DKIM, DMARC en SPF. dan kun je later nog nadenken over individuele versleuteling als dat nodig is.

Dat is geen versleuteling van je e-mail bericht. DKIM voegt slechts een signature toe in de header van een bericht, zodat je kan verifiëren of het bericht zijn authenticiteit heeft behouden. De daadwerkelijke inhoud is met TLS slechts tijdens transport versleutelt.

Ik heb al sinds 17 jaar PGP public keys, en sinds 10 jaar S/MIME certificaten beschikbaar... Misschien gaan anderen het gebruiken wanneer ik de privé sleutels weg geef. :P

Maar even zonder gekheid: Zelfs stichtingen zoals vrijwillig levenseinde communiceren via onbeveiligde email.
Het alleen aan het verstand proberen te brengen dat dit onverstandig is, resulteert in irritatie.

Voor particulier gebruik is er niet echt een meerwaarde te bedenken. Voor activisten die vertrouwelijk met elkaar willen mailen, is er Mailvelope, vrij gemakkelijk te installeren als extensie in Firefox en Chrome. Ook is aan te bevelen het gebruik van zelfondertekende Certificaten, maar dan moet je kiezen voor een mailcliënt als Thunderbird of Microsoft Outlook, of een zakelijk mailaccount bij Google Gmail, die in dat geval het gebruik van Certificaten toestaat. Ik bedoel hier niet de TLS (Transport Layer Security) want die wordt standaard al gebruikt, maar het SSL ( Secure Sockets Layer) certificaat.
Voor zakelijk gebruik van certificaten, is het misschien verstandig om de certificaten licentie bij een certificatenuitgever te kopen.

https://www.mailvelope.com/en
https://sites.google.com/site/certificaatversleuteling/home

Voor particulieren zou dit juist zeer veel meerwaarde bieden:

Communicatie met de overheid kan veilig en gemakkelijk, gewoon met het e-mailadres dat bijna iedereen heeft.

Communicatie van gevoelige gegevens met bedrijven (bv kopie paspoort werkgever) of de zorg (digitaal consult huisarts) kan veilig, gemakkelijk en universeel.

Bij een datalek is de data waardeloos. Een datalek is dus veel minder ernstig.

Bij een gekaapt e-mail adres heeft de malafide ontvanger niets aan de ontvangen berichten.

Het is universeel, men kan naast mail ook documenten ondertekenen en dus phishing of vervalsing veel beter herkennen: de ondertekening klopt dan niet. Een enorme berg e-mail bijlagen kan zonder te openen direct de prullenbak in en digibeten hebben eindelijk een duidelijk instrument om authenticiteit te controleren.

Vreemd dat een massale implementatie maar uitblijft als je naar de voordelen kijkt.

De term "SSL certificaat" kan verwarrend zijn in je laatste zin. Formeel zijn digitale cerificaten gestandaardiseerd door de ITU (International Telecommunications Union) in X.509.

Belangrijk: het primaire doel van een X.509 certificaat is authenricatie (niet versleutelen). Dat je een public key in een certificaat ook voor versleuteling kunt gebruiken, is bijzaak.

Je kunt zo'n X.509 certificaat prima vergelijken met een kopie van een paspoort (iedereen kan dit in handen hebben, dus dat bewijst niet de identiteit van degene die zo'n kopie bezit), en een private key met het originele paspoort. Door een wiskundige truc kan de eigenaar van de private key aantonen dat zij deze in bezit heeft, zonder die private key (of het originele paspoort) ooit uit handen te geven (in tegenstelling tot een paspoort mag je een private key nooit aan iemand anders laten zien, dus daar gaat de vergelijking mank).

Vereenvoudigd bestaat een X.509 certificaat (of digitaal certificaat) uit:
1) Eenduidig identificerende gegevens van de eigenaar van een uniek asymmetrisch sleutelpaar (public + private key);
2) De public key;
3) Administratieve gegevens;
4) Een digitale handtekening geplaast door een certificaatverstrekker, een "Trusted Third Party" (de ontvanger van zo'n certificaat moet erop kunnen vertrouwen dat de gegevens in het certificaat juist zijn, met name dat de certificaatverstrekker heeft gecontroleerd dat de public key echt van de geïdentificeerde partij is - en dus niet van een persoon of organisatie die zich voordoet als).

Eén van de "Administratieve gegevens" is het gebruiksdoel. Hoewel meerdere gebruiksdoelen in 1 certificaat mogelijk zijn, is dit niet gebruikelijk. Bekende gebruiksdoelen (of "soorten") certificaten zijn die voor webservers, codesigning, e-mail en certificaatverstrekkers (CA = Certificate Authority). Software die certificaten verwerkt hoort een certificaat dat voor een ander doel wordt gebruikt, te weigeren.

Een webservercertificaat wordt ook wel een "SSL certificaat" genoemd omdat deze wordt gebruikt voor het authenticeren van https webservers - die aanvankelijk SSL verbindingen gebruikten, maar tegenwoordig TLS. Essentieel in zo'n servercertificaat is dat onder de identificerende gegevens 1 of meer domeinnamen (zoals security.nl en www.security.nl) worden genoemd, waar het certificaat dus voor geldt. Maar het kan hierbij ook om een mailserver gaan (bijv. mail.security.nl) waarmee mailservers onderling kunnen authenticeren.

Een e-mail certificaat, ook bekend als S/MIME certificaat, moet (minstens 1) e-mail adres bevatten. Het is m.i. onjuist om zo'n certificaat een "SSL certificaat" te noemen, want daar heeft het niets mee te maken.

In een code signing certificaat moeten de gegevens van de eigenaar uniek zijn zodat verwarring over de ondertekenaar van een bestand kan worden uitgesloten (in tegenstelling tot domeinnamen en e-mail adressen die van zichzelf uniek zijn, geldt dit natuurlijk niet voor persoonsnamen als Jan Jansen en bedrijfsnamen als HiTec).

In tegenstelling tot de hierboven genoemde "end entity" (toepassings-) certificaten, zijn CA certificaten bijzonder omdat deze worden ingezet bij het digitaal ondertekenen van (door certificaatverstrekkers) uitgegeven certificaten. Vaak is hierbij sprake van een vertrouwensketen (chain of trust) met 1 of meer intermediate (tussenliggende) certificaten:


Hierbij is "Intermediate cert 1" digitaal ondertekend met de private key behorende bij de public key in het Root certificaat, "Intermediate cert 2" is ondertekend met de private key behorende bij de public key in "Intermediate cert 1" en is het "End Entity cert" ondertekend met de private key horende bij de public key in "Intermediate cert 2".

Als jij het root certificaat, dat met jouw besturingssysteem (of webbrowser of Java) is meegeleverd, vertrouwt, en de "andere kant" stuurt jou -naast haar end entity certificaat- ook alle gebruikte intermediate certificaten, dan kan jouw computer door de keten af te lopen, vaststellen of het om een vertrouwd end entity certificaat gaat.

Net zoals certificaatverstrekkers hun (strikt geheime) private keys gebruiken om certificaten digitaal te signeren, kun jij jouw private key(s) gebruiken om jouw e-mails digitaal te ondertekenen. Als de ontvanger via de chain of trust vastelt dat de public key (in het meegeleverde end entity certificaat) van jou is, weet zij redelijk zeker dat jij die mail geschreven moet hebben.

Als je wilt dat uitsluitend een persoon die jij vertrouwt jouw mail kan lezen, kun jij die mail versleutelen met de public key uit het certificaat van de ontvanger [1]. Je moet dan wel zeker weten dat het certificaat echt van de door jou bedoelde persoon is (zit de Jan Jansen die jij bedoelt bij gmail, bij hotmail of ergens anders?). Je kunt zo'n mail, naast versleutelen, ook signeren (met jouw private key) zodat de ontvanger zeker weet dat jij de afzender bent.

[1] Feitelijk genereert jouw computer een random sleutel voor symmetrische encryptie (bijv. AES) waarmee de mail en evt. bijlagen worden versleuteld. Die symmetrische sleutel wordt met de public key van de ontvanger versleuteld en het resultaat wordt meegestuurd. De ontvanger pakt de symmetrische sleutel uit met haar private key en kan zo de mail en evt. bijlagen ontsleutelen.

Terugkomend op jouw eerste zin:
Nou en of. Als alle e-mails digitaal ondertekend zouden zijn en jou dat zekerheid zou geven over de werkelijke, real life identiteit van afzenders (wie is de persoon of organisatie met dit afzender e-mail adres), zouden phishers het veel moeilijker hebben: ze zouden voor elke phishing mail ongeautoriseerde toegang tot een e-mail account moeten hebben en digitaal moeten kunnen signeren met de private key van de echte eigenaar van het account.

Daarnaast heeft het pas zin om vertrouwelijke e-mails versleuteld te verzenden als je zeker weet dat de ontvanger echt is wie zij zegt dat zij is, zodat je die versleutelde mail niet naar een bedrieger stuurt (een verkeerd e-mail account dus waarvan jij de public key gebruikt voor het versleutelen).

De redenen dat we nauwelijks e-mails digitaal signeren en/of versleutelen zijn onder meer:
1) Aanvankelijk waren er geen standaarden voor waardoor mail client software het niet ondersteunde;
2) De manier om van een PGP key vast te stellen wie de werkelijke eigenaar is, schaalt niet. Bovendien is PGP voor de meeste mensen zo ingewikkeld dat de foutkans zeer groot is en daarnaast ondersteint Outlook PGP niet (alleen met een plugin en dat werkte, toen ik het gebruikte, maar matig);
3) Doordat je gratis een S/MIME certificaat (in elk geval van Comodo) kunt krijgen als je toegang hebt tot een e-mail account, en mail clients zelden aangeven hoe de de certificaatverstrekker gecontroleerd heeft dat een certificaat niet via onrechtmatige toegang (tot een e-mail account) is verkregen, zijn S/MIME certificaten nagenoeg waardeloos. Zulke certificaten zijn vergelijkbaar met DV (Domain Validated) certificaten voor webservers; deze koppelen slechts 1 identificerend gegeven aan een sleutelpaar (nl. domeinnaam of e-mail adres) zonder dat gecheckt is of de aanvrager de legitieme eigenaar van de webserver of e-mail account is;
4) Vanaf het moment dat je digitaal gesigneerde mails gaat verzenden, zou je dit voor altijd moeten blijven doen, en ontvangers zouden elke mail die van jou afkomstig lijkt maar niet digitaal is ondertekend, als nep moeten beschouwen. Maar ij heb een Outlook versie gezien die alle uitgaande e-mail ondertekende met S/MIME, maar niet vergaderverzoeken (waar ook bijlagen bij kunnen zitten). Waardeloze implementaties vormen dus ook een probleem. Maar het belangrijkste is dat mail clients nu niet waarschuwen als een niet digitaal gesigneerde e-mail afkomstig lijkt van een individu die haar e-mails wel altijd ondertekent (vergelijkbaar met dat webbrowsers tegenwoordig waarschuwen voor http waar https gebruikt zou moeten worden);
5) De meeste mensen begrijpen het concept achter private en public keys niet, of willen dit niet begrijpen. En dat is m.i. zeer onverstandig, want het is een basisbouwsteen voor digitale communicatie. Dat snappen gaat je voordeel opleveren, niet snappen (en verkeerd gebruiken) gaat je vroeger of later geld kosten.

De reactie van Bitwiper bestaat vooral uit een grote lap met tekst, dat kennis van zaken moet uitstralen, maar dat vooral niet doet.

Het SSl certificaat (X509) is primair voor authentificatie, en dat je met de publieke sleutel ook de inhoud kan versleutelen is volgens Bitwiper bijzaak. Dit is natuurlijk complete onzin, waarom zou anders deze functie er aan gekoppeld zijn.
Bitwiper zijn mening is van persoonlijke aard, en nergens krijg ik de indruk dat hij een expert in deze discipline is.
Bijzonderheid is ook dat de inhoud tot in tegenstelling met alle andere versleutelingen o.a. (PGP) varianten intakt blijft, zoals de opmaak, imbedded fotos's enz. Dit feit is voor zakelijke emails toch wel belangrijk.

De warrige vergelijking van een X509 certificaat met een kopie van een paspoort etc.. is zo ruim geinterpreteerd, daar kan een zinnig mens gewoon niks mee.

De meerwaarde voor particulier gebruik, dus met je familie en of kennissen, daarvoor is de belangstelling helemaal niet aanwezig. Moet ik mijn zuster in Australië eerst "hoe installeer ik en gebruik ik encryptie" leren, om vervolgens over de kinderen e.d. te mailen, leg daarvan nu mij eens de meerwaarde van uit!

De website(s) met de twee hier door mij genoemde mogelijkheden zijn hieronder vermeld

https://www.mailvelope.com/en
https://sites.google.com/site/certificaatversleuteling/home

Je hebt zeker de bijzin niet begrepen "dan kun je later nog nadenken over individuele versleuteling als dat nodig is"

Mijn punt is dat men eerst maar eens standaarden moet invoeren, als dan nog individuele versleuteling nodig is moet je vooral je gang gaan.

Ik weet echt niet alles. Vertel maar wat er niet klopt van wat ik schrijf. Ik leer graag en als ik het fout heb, zal ik mijn excuses maken. Wel met verifiëerbare feiten onderbouwen s.v.p.

Ik kan het je nog sterker vertellen, het gebruik van een public key voor versleuteling wordt afgeraden. De reden daarvoor is dat als de private key in verkeerde handen valt, alles wat ooit met de bijbehorende public key versleuteld is, op straat kan komen te liggen. Moderne systemen (waaronder uitdrukkelijk https/TLS) maken gebruik van een Diffie-Hellman (DH) key agreement voor het uitwisselen van de symmetrische sleutel (dit wordt forward secrecy genoemd). De enige functie van het servercertificaat is authenticatie van de server. Niks meer en niks minder. Dat voor e-mail nog geen DH gebruikt wordt, duidt alleen maar op de verouderde puinhoop die we e-mail noemen.

Wellicht ben ik geen expert, maar ik ga niet af op persoonlijke pagina's (van ongetwijfeld goedbedoelende mensen) op sites.google.com maar wel op bijv. https://en.wikipedia.org/wiki/X.509, https://en.wikipedia.org/wiki/Forward_secrecy en degelijke.

Jammer. Zelf vond ik de vergelijking best goed gevonden. Maar ik heb deze zelf bedacht, als het onzin is (wat ik niet denk) neem ik er graag alle verantwoordelijkheid voor.

@Anoniem 19:46: je kunt bitwiper van een hoop beschuldigen, maar niet van het ontbreken aan kennis. Kennis die jij blijkbaar toch wat minder hebt: authentificatie bestaat niet. Dat is authenticatie, jij gebruikt een verhaspeling van identificatie en authenticatie.

Bitwiper schreef:
"Ik kan het je nog sterker vertellen, het gebruik van een public key voor versleuteling wordt afgeraden. De reden daarvoor is dat als de private key in verkeerde handen valt, alles wat ooit met de bijbehorende public key versleuteld is, op straat kan komen te liggen. Moderne systemen (waaronder uitdrukkelijk https/TLS) maken gebruik van een Diffie-Hellman (DH) key agreement voor het uitwisselen van de symmetrische sleutel (dit wordt forward secrecy genoemd). De enige functie van het servercertificaat is authenticatie van de server. Niks meer en niks minder. Dat voor e-mail nog geen DH gebruikt wordt, duidt alleen maar op de verouderde puinhoop die we e-mail noemen."

SSL (Security Socket Layer) (X.509v3) is een protocol dat op dit moment door o.a. banken wordt gebruikt als beveiliging, dus mogen we aannemen, dat dit protocol voorlopig voldoet aan de veiligheidseisen voor het betalingsverkeer.
We mogen ook aannemen, dat het gebruik van deze certificaten voor authentificatie en versleuteling van email voldoende veilig is voor de gebruikers.

Volgens Bitwiper wordt het gebruik van de public key voor versleuteling afgeraden, en dat roept de vraag op, door welke instantie of autoriteit wordt dit specifiek afgeraden, en waarom.
Deze bewering moet toch inhoudelijk beter worden onderbouwd, dan een verwijzing naar een Wikipedia lemma.

Naast dat je naar "forward secrecy" kunt Googlen, zal ik een toelichting geven (wel weer een lap tekst, sorry; het is nou eenmaal geen eenvoudige materie).

Als ik in de Engelstalige Firefox op mijn PC rechtsklik in deze pagina op security.nl, "View Page Info" en vervolgens het "Security" tabblad open, zie ik (onder "Techincal Details"):

In deze "cipher" staat ECDHE voor "Elliptic Curve Diffie-Hellman Exchange". Dat is een wiskundige truc waarbij twee partijen getallen uitwisselen over een nog onversleutelde verbinding, zodanig dat beide daaruit een symmetrische sleutel (voor 128bit AES in dit geval) kunnen herleiden, maar zonder dat iemand met leestoegang op de verbinding dat kan. De term "Exchange" is eigenlijk incorrect, beter is de term "Agreement" (beide partijen komen een symmetrische sleutel overeen zonder dat deze daadwerkelijk wordt uitgewisseld). Google naar "forward secrecy Diffie Hellman" voor meer info.

Een essentieel probleem bij een DH agreement is dat een MitM (Man in the Middle), die het netwerkverkeer niet alleen kan afluisteren maar ook kan onderbreken, volledige toegang kan krijgen tot die verbinding. Deze MitM zal zich richting de server voordoen als de client, en richting de client als de server - zonder dat beide partijen dit merken:


Er is dan sprake van twee verschillende DH sessies: tussen client en MitM, en tussen MitM en server.

Daarom is authenticatie van de server essentieel (tenzij er van een client certificaat gebruik gemaakt wordt, authenticeert de client zelf niet, maar wel de gebruiker door in te loggen middels het aantonen dat deze gebruikersnaam en wachtwoord kent, of bij banken over een "random reader", de juiste TAN-codes o.i.d. beschikt).

De server authenticeert zich in twee stappen:
1) Hij stuurt zijn servercertificaat naar de client;
2) Hij ondertekent de DH (Diffie-Hellman) getallen (die hij naar de client stuurt) met zijn private key.

Ondertekenen gebeurt hier met het RSA protocol (vandaar de letters RSA in de tussen mijn browser en de server van security.nl overeengekomen cipher). Dat wil zeggen dat de server een SHA256 hash berekent over de DH getallen die hij naar de client stuurt, en die hash versleutelt met zijn private key.

Zodra de client die getallen met signature ontvangen heeft, ontsleutelt de client de signature met de public key uit het certificaat, dit levert weer de door de server berekende SHA256 hash op. De client berekent vervolgens ook zelf de SHA256 hash over de getallen. Als beide hashes overeenkomen, weet de client zeker dat de signature klopt, en dus dat de partij aan de andere kant van de verbinding over de private key, behorende bij de public key in het certificaat, moet beschikken. Google naar "ECDHE RSA" of "DHE RSA" voor meer info.

Tenzij de MitM over de private key van de server beschikt, of een eigen asymmetrisch sleutelpaar met de public key in een (onterecht uitgegeven maar geldig) certificaat voor de betreffende server heeft, weet de client zeker dat er met de server gecommuniceerd wordt - waarvan de domainname in de URL-balk van de browser staat, en die overeenkomt met een domainname in het certificaat.

Het enige doel van een digitaal certificaat is het koppelen van een public key aan een identiteit, waarbij deze koppeling door een TTP (Trusted Third Party), de certificaatverstrekker, wordt gerarandeerd. Ja, je kunt een public key uit een certificaat voor versleuteling gebruiken, maar dan heb je geen forward secrecy zoals ik eerder beschreef, en hieronder iets anders herhaal.

In https://wiki.mozilla.org/Security/Server_Side_TLS zie je, onder "Recommended configurations" (voor servers), uitsluitend ECDHE voor de key agreement genoemd worden. Onder "Intermediate compatibility (default)" zie je, onderaan de lijst (laagste voorkeur dus), vanaf "AES128-GCM-SHA256" en daaronder, 2 kolommen verder, "Kx=RSA" staan (Kx betekent hier Key Exchange).

Bij de (dus afgeraden) RSA key exchange genereert de client de symmetrische sleutel, versleutelt deze met de public key uit het certificaat van de server en stuurt het resultaat naar de server. Omdat alleen degene die over de bijbehorende private key beschikt, het ontvangen bericht kan ontsleutelen en zo de symmetrische sleutel kan verkrijgen, weet de client zeker dat de server over de juiste private key (behorende bij de public key in het server certificaat) beschikt - waarmee authenticatie van de server een feit is- en tevens de symmetrische sleutel is uitgewisseld. Een eventuele MitM, die de private key niet heeft, kan de symmetrische sleutel dus niet herleiden.

Nogmaals, het risico bij encryptie met een identificerende public key (zoals in de RSA key exchange), is dat iemand of een organisatie die de versleutelde communicatie opneemt, en later ooit de private key kan kraken of in handen krijgt (illegaal of via een gerechterlijk bevel), alle opgenomen versleutelde data alsnog kan ontsleutelen. Indien forward secrecy (bijvoorbeeld gebruikmakend van de DH key agreement) wordt toegepast, bestaat dit specifieke risico niet (ervan uitgaande dat de gebruikte DH getallen voldoende veilig zijn, iets dat bij LOGJAM niet het geval was).

Google naar "snowden forward secrecy" om te zien waarom FS wordt aangeraden.

Aanvulling 11:48: naar verluidt, volgens https://security.stackexchange.com/questions/145622/does-perfect-forward-secrecy-work-with-group-chats-or-chat-history#answer-145634, gebruiken WhatsApp en Signal ook FS (soms PFS, Perfect Forward Secrecy) genoemd. De USA staatssecretaris van Justitie, Rod Rosenstein, is vast niet blij met FS (zie https://www.security.nl/posting/534816/Amerikaanse+staatssecretaris+wil+%27verantwoordelijke+encryptie%27).

Even geprobeerd hier enige relevantie en logica in te vinden, maar dit lukt niet.
De discussie gaat hier over de veiligheid van het gebruiken van SSL certificaten in enige mailprogramma's, en behalve theoretische op menselijk gebaseerde handelingen na, geeft de schrijver geen enkele onderbouwing waaruit zou blijken. dat SSL certificaten gecomprimeerd kunnen worden. Als je maar lang en chaotisch redeneert en naar irrelevante links verwijst lijkt het betoog zelfs een beetje geloofwaardig,
De schrijver lijkt ook niet te willen begrijpen dat het gebruik van SSL certificaten in een email programma ten aanzien van de beveiliging geheel autonoom de ondertekening c.q. encryptie uitvoert.
Conclusie lijkt dan ook gerechtvaardigd te veronderstellen dat de schrijver vooral zijn of haar gelijk wil halen, en dat past niet in een discussie over dit soort zaken.

Mailvelope is nog nooit geaudit!

@Bitwiper Laat ik het voorbeeld van Alice en Bob eens nemen, die hebben besloten middels SSL certificaten met elkaar te gaan mailen. Beide gebruiken een autonoom mailprogramma, in dit geval Thunderbird.
Beide hebben bij een uitgever van certificaten Verisign een licentie voor een certificaat (Private en publieke sleutel) aangeschaft, en deze geïmporteerd in het certificatenbeheer van Thunderbird. Het Verisign root certificaat waaraan dit certificaat (Private en publieke sleutel) is gekoppeld staat reeds op hun computer in het voornoemd certificatenbeheer.

Nu staat vast zonder tegenspraak dat het ondertekenen en versleutelen ook autonoom door Thunderbird word uitgevoerd, voordat de email wordt verzonden.
Als dus Alice een email naar Bob stuurt, en deze ondertekend, en versleuteld, dan gebeurt dit op de computer van Alice,
en pas daarna wordt het bericht verzonden. Wanneer Bob het bericht ontvangt, wordt deze op zijn computer ontsleutelt en geverifieerd.

De vraag aan Bitwiper is dan ook waar kan het misgaan, uitgezonderd menselijke nonchalant handelen.
Ik stel een concreet en ter zake doend antwoord op prijs.

Email versleutel ik niet, email versleutelen is proberen van een 1960 Lada een 2017 Ferrari te maken. Wordt nooit perfect.
De meeste mensen die ik zou kunnen emailen hebben bovendien geen enkele notie van security.

Een SSL certificaat is een servercertificaat. Daar staat 1 (of meerdere en/of wildcard) domainname in. Voor S/MIME kun je alleen maar certificaten gebruiken waarin op zijn minst een e-mail adres, en -optioneel- aanvullende identificerende informatie (zoals echte naam) is opgenomen.

1) Mail clients worden nogal eens geplaagd door kwetsbaarheden. Dat Outlook deze week gepatcht is voor het, naast een versleutelde versie van een e-mail, onder bepaalde omstandigheden ook de niet versleutelde versie verstuurde, vind ik ongeloofelijk. Hoe testen die gasten?

2) Als aanvaller Mallory tijdelijk toegang krijgt tot het e-mail account van bijv. Bob, kan Mallory gratis een e-mail certificaat met Bob's e-mail adres erin verkrijgen. Als de ISP van Bob niet op een fail-safe manier SPF en DMARC gebruikt en/of de ISP van Alice daar niet op checkt, kan Mallory, geheel buiten Bob's account om, e-mails naar Alice sturen die van Bob afkomstig lijken. Naast die mails ondertekenen kan Mallory ze natuurlijk ook versleutelen (met de public key van Alice). Antwoorden van Alice gaan hierbij wel naar de echte Bob (tenzij Mallory een Reply To met afwijkend e-mail adres gebruikt en dit Alice niet opvalt).

Het probleem in dit geval is dat je veel te eenvoudig een vals e-mail certificaat kunt krijgen.

3) Stel Mallory werkt bij de NSA en heeft alle versleutelde mails tussen Bob en Alice opgeslagen (als ik de NSA was zou ik elke versleutelde mail verdacht vinden en opslaan). Indien Malory Bob's PC hackt en zo Bob's private key weet te verkrijgen, of zodra Mallory een voldoende sterke quantumcomputer heeft (misschien is dat al zo, wie zal het zeggen) kan Mallory uit bijv. de public key van Bob de bijbehorende private key berekenen. Met de private key van Bob kan Mallory alle ooit door Alice naar Bob verzonden -versleutelde- mails ontsleutelen. In de UK kun je waarschijnlijk gedwongen worden om je private key af te geven (en wellicht ook als je de USA inreist).

Het probleem in dit geval is dat geen forward secrecy wordt gebruikt (iets dat bijv. WhatsApp naar verluidt wel doet).

@Bitwiper; De definitie van een SSL certificaat is natuurlijk niet beperkt tot een server certificaat, maar verder is dat
niet interessant om over te discuteren.

1. Dat Mail cliënts (Microsoft Outlook 2016) op dit moment een kwetsbaarheid heeft is natuurlijk niet maatstafgevend
voor zelfstandige email cliënten, een toevallige samenloop van omstandigheden.

2. Waarom zou een aanvaller Mallory toegang kunnen verkrijgen tot het e-mail account van ons voorbeeld Bob.
Dit valt onder de definitie van menselijk gedrag, en is ten aanzien van de veiligheid van het gebruikte SSL protocol totaal irrelevant. Daarbij komt dat het gebruikte SSL certificaat (Private en Publieke sleutel) door Alice en Bob op authenticiteit kan worden gecontroleerd, door de digitale vingerafdruk aan elkaar telefonisch te bevestigen.

De ondertekening en versleuteling wordt op de computer uitgevoerd, en dan pas verzonden, en visa versa geld dit voor de ontvanger. Ik zie hier geen enkel onderbouwd argument, waaruit blijkt dat het gebruik van een SSL certificaat op een e-mail cliënt niet veilig zou zijn.

Dus in plaats van toe te geven dat je ongelijk hebt, zeg je met als onderbouwing "natuurlijk" dat ik uit mijn nek lul en vervolgens wil je het er niet meer over hebben?

Die private key is lekker veilig in jouw "SSL certificaat"... (klok en klepel)

Aanvulling: wat ik gisteravond schreef was niet erg aardig. Ik vermoed dat de XCA tool, gebruikt door de auteur van https://sites.google.com/site/certificaatversleuteling/xca-certificaten-maken, het genereren van echte S/MIME certificaten niet ondersteunt. Omdat de specificatie van S/MIME certificaten bezopen weinig eisen stelt aan zo'n certificaat (zie de correctie die ik zojuist maakte, halverwege mijn eerste bijdrage in deze thread) lijkt elke soort certificaat te voldoen (mits gebruik voor S/MIME daarin is "aangevinkt"). Vermoedelijk omdat een "SSL client certificaat" op een S/MIME certificaat lijkt, heeft de auteur dat misbruikt.
Daarnaast schrijft die auteur heel gevaarlijke teksten die jij kennelijk overneemt (tweede helft van de zin):
en in een andere pagina: Een .p12 bestand is geen certificaat! Zo'n bestand bevat zowel het (publieke) certificaat als de bijbehorende (geheime) private key! De fout om te denken dat ook de private key onderdeel is van het certificaat, of die private key zelfs samen met het certificaat aan derden te geven, wordt (door onbegrip/onkunde) -helaas- regelmatig gemaakt. Recent voorbeeld: https://www.theregister.co.uk/2017/09/22/oh_dear_adobe_security_blog_leaks_private_key_info/.
Een mail client zoals Thunderbird heeft, naast jouw certificaat, ook jouw private key nodig, en helaas is het gebruikelijk dat die samen in 1 bestand worden geïmporteerd. Maar geef zo'n PKCS#12 bestand nooit aan derden! En bescherm alle bestanden waar private keys in zitten (dus ook de XCA database) met een sterk wachtwoord dat je nooit aan derden geeft...
De laatste zin in https://sites.google.com/site/certificaatversleuteling/1-trusted-ca-voor-iedereen luidt: Rootcertificaten zijn scary dingen, die moet je nooit zomaar importeren. Als je zo'n rootcert verzendt, zorg dan dat ontvangers via een reeds door hen bekende weg (ander kanaal) contact met jou opnemen om te dubbelchecken dat jij dat rootcert gemaakt hebt (middels de fingerprint van het certificaat, dit is niets anders dan een hash over het binaire (ASN.1) bestandsformaat van het certificaat), en van jou te eisen dat jij uiterst zorgvuldig met de bijbehorende private key zult omspringen. Ow ja, sluit niet de private key bij als je een rootcert verzendt of publiceert...

@Bitwiper; De definitie van wat we onder een een SSL certificaat verstaan is natuurlijk niet beperkt tot een server certificaat, en dat is slechts een constatering van een feit, en ik zie niet in, waarom over zoiets triviaal gediscuteerd zou moeten worden.

Blijft over de vraag aan Bitwiper, om nu eens met een onderbouwd verhaal te komen, waarom in zijn ogen een email cliënt certificaat niet gebruikt mag worden voor versleuteling. Immers, zonder tegenspraak, staat vast dat de ondertekening en versleuteling autonoom door het email programma op de computer wordt uitgevoerd, en daarna pas verzonden etc. etc.
Dit forum gaat over veiligheid, en dogmatisme is ongewenst. Als Bitwiper met een geloofwaardige stelling komt waaruit die onveiligheid zou blijken, dan zou ik dat als eerste erkennen.
Tot nu toe is dat niet het geval, want de menselijke nonchalance die hij als argument aanvoert, bewijst de ondeugdelijkheid van het hier genoemde gebruik van certificaten niet.

Bitwiper heeft zijn laatste reactie nogal bijgewerkt laatste om 7:04.
Ten aanzien van de definities of we nu wel of niet kunnen spreken van een SSL certificaat daar zijn zoveel verschillende opvattingen over op internet, dat het een welles of nietes spelletje gaat worden. onderstaande link is slechts een voorbeeld daarvan https://www.howtoforge.com/how-to-encrypt-mails-with-ssl-certificates-s-mime en maakt duidelijk dat hierover meerdere interpretaties mogelijk zijn. Het thema hier gaat niet over de benaming maar over de veiligheid van deze certificaten, en Bitwiper komt ten aanzien van een door mij gebruikte link weer met een heleboel tekst, dat op geen enkele wijze aantoont, dat het gebruik van deze certificaten onveilig zou zijn.De menselijke nonchalance is in zijn argumenten de zwakste schakel, maar dat is op het gehele internet het geval.Zijn gehele betoog bestaat uit waarschuwing aan de gebruiker hoe deze met de beveiliging daarvan moet omgaan.En feitelijk is dat ook het enige argument dat Bitwiper hier aanvoert.Mijn vraag aan Bitwiper is dan ook; kom nu eens met een geloofwaardige zakelijke en technisch onderbouwde redenering waaruit we kunnen opmaken, dat het gebruik van email certificaten zoals reeds genoemd in in dit voorbeeld https://sites.google.com/site/certificaatversleuteling/xca-certificaten-maken niet veilig zou zijn.

Dat is het wel. SSL staat voor Secure Sockets Layer, opgevolgd door TLS (Transport Layer Security). Ja, e-mail wordt meestal via een transportlaag getransporteerd (een copy-to-self niet), en meestal wordt daar TCP over IP voor gebruikt (maar niet noodzakelijkerwijs), en het is -pas sinds enkele jaren- meestal zo dat mailservers onderling "authenticeren" met een servercertificaat (dat meestal self-signed is wat dus niks zegt). Aangezien TLS zich volgens https://en.wikipedia.org/wiki/List_of_network_protocols_(OSI_model) op laag 6 bevindt, boven TCP en IP dus, heeft dat geen ruk te maken met encryptie en/of signatures in e-mail die met SMTP (volgens https://en.wikipedia.org/wiki/List_of_network_protocols_(OSI_model) laag 7) worden uitgewisseld - waarbij het ook nog eens discutabel is of S/MIME zich nog wel in dezelfde laag als SMTP bevindt. Maar laten we er gemakshalve van uitgaan dat SMTP laag 7 is en SSL/TLS laag 6, dan zie je al dat die onafhankelijk van elkaar zijn.

Dat je, als gevolg van een brakke protocol specificatie, een SSL/TLS client certificaat (dat al enrstig afwijkt van een SSL server certificaat, want een client certificaat bevat geen domainname) blijkt te kunnen misbruiken als S/MIME certificaat, betekent op geen enkele manier dat een S/MIME certificaat altijd een SSL certificaat zou zijn. Ja, een cirkel is een ellips, maar een ellips is zelden een cirkel. Maar droom lekker verder.

Ben je blind of zo? Hiermee, en in jouw reactie van gisteren 18:52, negeer je punt 3 uit mijn bijdrage van gisteren 18:21 volledig en daarnaast alles wat ik hierboven over Diffie-Hellman en forward secrecy schreef. Als je niets van mij aan wil nemen en de referenties die ik geef domweg negeert, heeft discussiëren met jou inderdaad geen zin.

@Bitwiper Vaststaat dat de encryptie (versleuteling) en de decryptie (ontsleuteling) plaatsvind op de computer van de respectievelijke de verzender en de ontvanger. Dus leg nu eens uit hoe dit onderweg van de afzender naar de geadresseerde gecomprimeerd kan worden, want dat maak ik uit op dit verhaal.

Ongelofelijk.

Ongelofelijk is de reactie van Bitwiper op de reactie van anoniem betreffende de wijze waarop de versleuteling c.q. de onsleuteling plaatsvind.
Ik mis hier een tegenargument van Bitwiper.

Onderstaande link legt uit hoe S/MIME eventueel kan worden gecomprimeerd, zoals door geachte Bitwiper is uitgelegd.

https://crypto.stackexchange.com/questions/10245/security-of-s-mime-in-case-of-ca-compromise

Onderstaande tekst gaat over de conclusie van de auteur, en ik geloof niet dat Bitwiper deze conclusie met de lezers heeft gedeeld.

Now, my concern is that this attack does not necessarily comply with the fourth restriction. For instance, if Alice and Bob somehow manages to, without detection, exchange certificate thumbprints over the compromised channel, the compromise will be detected immediately.

Vrij vertaald, wat als Alice en Bob de digitale vingerafdruk met elkaar hebben uitgewisseld, dan wordt de vervalsing ontdekt.

Afsluitende discussie
Veiligheid op internet gaat ons allemaal aan, en het is een goede zaak, wanneer die veiligheid hier wordt bediscussieert. Het word echter twijfelachtig, wanneer mensen vanuit een wellicht onbedoelde dogmatische visie een verkeerde voorlichting van zaken beginnen te geven.

Dit is een samenvatting waarin ik het gebruik van een email_certificaat op haar betrouwbaarheid zal toelichten.
Dit geld ook voor het gebruik van XCA een stukje softwaregereedschap waarmee iemand een rootcertificaat kan maken, en daaraan één of meerdere cliënt_certificaten (Private en Publieke sleutels) kan koppelen, en in zijn of haar mailprogramma o.a.Thunderbird en Microsoft Outlook kan importeren en gebruiken voor authenticiteit, ondertekenen en versleutelen.

Procedure
Het rootcertificaat dat met XCA kan worden gemaakt, dient aan alle betrokkenen te worden gezonden, en die moeten het rootcertificaat opnemen in het certificatenbeheer van het email programma.

Vraagstelling
1. kan het rootcertificaat onderweg worden onderschept, en worden gecomprimeerd, het antwoord is JA. Kan het gekloond worden met alle eigenschappen die de ontwerper daaraan heeft gegeven, het antwoord is NEE.
Het origineel heeft een unieke digitale vingerafdruk, en als die bij alle partijen bekend is, zal de vervalsing onmiddellijk worden ontdekt.

2. Hetzelfde geld voor het cliënt_certificaat (private_publieke sleutel) die aan het rootcertificaat wordt gekoppeld, en daarna door de ontwerper daarvan worden afgescheiden. Ook de publieke sleutel van de afzender die met elke ondertekende email word meegezonden kan worden onderschept , en worden gecompromitteerd, maar niet met al haar door de afzender toegeruste eigenschappen, want ook dat certificaat heeft een unieke digitale vingerafdruk, die niet kan worden gekloond. Hierbij geld ook nog dat een gecomprimeerde publieke sleutel niet meer door het rootcertificaat zal worden geaccepteerd.

3. kan een versleutelde bericht terugherleid worden naar de bijbehorende private sleutel, dat schijnt in theorie mogelijk te zijn, maar die veronderstelling lijkt in verband met het inmiddels verboden SHA1 protocol te staan. Vaststaat dat het gebruiken van SHA256 en hoger dit niet meer mogelijk maakt. (Deze veronderstelling behoeft de mening van een expert)

Eeindconclussie
Pas als stelling 1 en 2 worden gelogenstraft door vaststaande, onweerlegbare en verifieerbare feiten, en in begrijpelijke taal uitgelegd, zal het zinvol zijn om deze discussie voort te zetten.

Doorsnee gebruiker heeft van voorgaande discussie alleen dit begrepen:


en trekt als hij/zij/het verstandig is de enig juiste conclusie:
in geen geval een "ICT-er" inschakelen bij ICT-vragen of -problemen. Beter zoeken naar de beste, verstandigste manier om analoog, off-line te gaan.

Zelfs Phil Zimmermann vindt PGP te ingewikkeld: https://cdn.arstechnica.net/wp-content/uploads/2017/09/zimmermann.jpg (uit dit artikel: https://arstechnica.com/information-technology/2017/09/in-spectacular-fail-adobe-security-team-posts-private-pgp-key-on-blog/)

Klopt, dit is wel te begrijpen en met een handomdraai geregeld

Moet je alleen die ander nog even overhalen om hetzelfde te doen.

@Anoniem 17:44: je hebt in elk geval geprobeerd om mijn tekst te lezen! Ik probeer het te vereenvoudigen:

Met name de onthullingen van Snowden wezen uit dat veiligheidsdiensten (niet alleen in de USA) https verbindingen konden afluisteren. Vereenvoudigd: dat kon doordat voor de versleuteling van elke https verbinding met een webserver, steeds dezelfde geheime sleutel, die op de server te vinden is, werd gebruikt [*].

Als een veiligheidsdienst een verdachte op het oog had met bijv. een gmail.com of mail.ru webmail account, kon zij met een gerechterlijk bevel (of minder zachtzinnig) de geheime sleutel van de server opeisen. Daarmee kon die veiligheidsdienst, vanaf dat moment, alle https verbindingen met zo'n server afluisteren met een tap in het datacenter waar die server staat. Sterker, al het versleutelde netwerverkeer van en naar die server, dat zo'n dienst eerder had opgeslagen, kon met die sleutel alsog worden ontsleuteld.

De meeste mensen zullen het prima vinden als zo'n geheime dienst alleen ontsleutelde e-mails van verdachten zou bewaren, maar o.a. door Snowden weten we dat ze gewoon alles bewaarden. En door Snowden weten we ook dat er mensen bij geheime diensten werken die geheimen laten uitlekken. Snowden om ideologische redenen, maar er zitten ook hufters tussen die op illegale wijze hun zakken vullen.

Slimme "ICT-ers" vonden daarom dat het onmogelijk moest worden om elke individuele https verbinding af te luisteren - als je de geheime server-sleutel in handen kreeg. De oplossing was simpel: je moet voor elke https verbinding (tussen webbrowsers en een specifieke server) een andere, niet eerder toegepaste, sleutel gebruiken - en die, na gebruik, meteen vernietigen. Als een veiligheidsdienst toch één of meer van die sleutels in handen zou krijgen, kunnen zij daarmee slechts de bijbehorende verbindingen "afluisteren" (of eerder opgeslagen versleuteld netwerkverkeer ontsleutelen).

Omdat een veiligheidsdienst, die vanaf een gegeven moment toegang tot een server verkrijgt, in elk geval opgeslagen netwerkverkeer van eerdere verbindingen niet kan ontsleutelen, wordt dit systeem forward secrecy genoemd (m.a.w. die eerdere verbindingen kunnen in de toekomst niet ontsleuteld worden, ook niet als als iemand daarna toegang tot de server en/of de sleutel krijgt).

De praktijk is momenteel dat de meeste https verbindingen gebruik maken van deze forward secrecy. En niet alleen bij https; forward secrecy wordt ook toegepast door mailservers die onderling e-mail uitwisselen. Eén probleem hierbij is dat gewone e-mail op servers zelf niet versleuteld is; iedereen met beheertoegang tot een mailserver kan ze lezen en kopiëren. Een ander probleem is dat mailservers onderling alleen versleutelen als beide partijen aangeven dat te kunnen, en dat ze onderling onvoldoende betrouwbaar authenticeren. Dat is allemaal goed genoeg als een veiligheidsdienst zo'n verbinding alleen kan afluisteren, maar is zinloos als iemand een apparaat tussen beide mailservers kan plaatsen dat netwerkverkeer kan wijzigen. Zo'n apparaat kan beide kanten op liegen dat de andere kant geen versleuteling ondersteunt, of zich voordoen als de andere mailserver, waardoor er halverwege een (onzichtbare) mailserver ontstaat waarop gewone mails natuurlijk weer niet versleuteld zijn.

De enige "waterdichte" oplossing lijkt dus niet het versleutelen van e-mail verbindingen te zijn, maar het versleutelen van elke individuele e-mail, waarmee je "end-to-end" encryptie krijgt.

Hierbij speelt echter hetzelfde probleem als bij oude https verbindingen: bij de versleuteling van elke e-mail die jij ontvangt, wordt gebruik gemaakt van jouw geheime sleutel. Als die ooit in verkeerde handen valt (bijvoorbeeld omdat je gedwongen wordt om jouw geheime sleutel af te staan), kan elke toekomstige, maar ook elke eerder naar jou gezonden, versleutelde e-mail (mits in bezit van de aanvaller) worden ontsleuteld. Voor zover ik weet bestaat er nog geen forward secrecy bij e-mail, terwijl bijv. WhatsApp en Signal naar verluidt wel forward secrecy gebruiken.

In pogingen e-mail veiliger te maken, is al vanalles geprobeerd (PGP, S/MIME, SPF, DomainKeys, DKIM en DMARC) - allemaal zonder veel succes. Vandaar mijn opmerking "de verouderde puinhoop die we e-mail noemen". Tegen beter weten in blijven we het allemaal gebruiken. En waar dat echt niet veilig genoeg is, moeten we uitwijken naar digitale postbussen als mijn.overheid.nl (stel dat je bij elk bedrijf straks zo'n postbus in de gaten moet houden).

We hebben dringend behoefte aan een simpel te begrijpen, maar wel zo veilig mogelijk (met forward secrecy dus), e-mail (-achtig) systeem.

[*] Details voor specialisten: voordat iemand mij gaat uitleggen dat er voor elke https verbinding een unieke symmetrische sleutel wordt gegenereerd, die na gebruik wordt weggegooid: ja dat weet ik. Maar bij klassieke https verbindingen wordt die, door de webbrowser gegenereerde symmetrische sessie-sleutel, versleuteld met de public key uit het servercertificaat en zo verzonden - via de op dat moment nog onversleutelde https verbinding. Als je dat netwerkverkeer opslaat, en later de private key van de server in handen krijgt, kun je de sessiesleutel ontsleutelen, en daarmee de sessie. Bij forward secrecy is dit risico niet aan de orde. Vandaar dat ik ervoor pleit, ook bij e-mails (tijdens transport).

Toch promoot de Duitse overheid DE-Mail voor veilig e-mailen. Veel Duitse overheden kun je via een DE-mail account benaderen. DE-Mail is ook op PGP gebaseerd.

https://en.wikipedia.org/wiki/De-Mail

Inderdaad offline. Wanneer de wouten straks toestemming krijgen om op apparaten in te breken, annuleer ik zeker 2/3e van mijn internetabonnementen. (mobiel, internet, en er komt een schotel)

Een schotel is niet offline, wat een onzin,
en satelliet verkeer mag altijd al onderschept worden.
Haal je niet een paar dingen door elkaar?

TLS is een tunneltje tussen MTA´s. Dat is geen emailversleuteling.

Mijn voorkeur heeft trouwens S/Mime, maar helaas zijn CA´s niet te vertrouwen en laten de implementaties te wensen over.