Wat is 'phissing'?

Helaas, maar zelf als "de ontvanger kan controleren of de afzender van de mail ook werkelijk de afzender is die het zegt te zijn" is het probleem van phishing niet uit de wereld.

Kijk maar naar hoe bijvoorbeeld Emotet: als jij geïnfecteerd raakt gaat jouw systeem mailen naar anderen, met daarin: phishing. En dan ben jij dus gewoon netjes de afzender.

Natuurlijk zou het een verbetering zijn als iedereen een certificaat krijgt en dat een standaard zou worden (S/MIME, kuch) die ook overal wordt ondersteund (ipv daar wel, daar niet).

Bedankt voor de subtiele reactie.

Niemand beweert dat dit de oplossing is, maar het is een goed begin.

Niemand beweert dat dit de oplossing is, maar het is een goed begin.

S/MIME wordt redelijk door Apple ondersteund. De personen met een public keys worden ook in het adresboek aangeduid. Als er eenmaal een sleutelpaar uitgewisseld is, hoef je er verder ook niet meer aan te denken bij mailwisselingen.

Maar het blijft een gedoe zodat vrijwel niemand dit gebruikt. Dan heb ik meer vertrouwen in een DKIM ondertekening omdat dit al weid verspreid is. Dit dkim certificaat is dan niet voor één gebruiker, maar voor een heel domein. In elk geval weet je dat de mail door dat domein verzonden is. Voor phishing is dat voldoende.

(De server van dat domein kan natuurlijk gehacked zijn, maar dat geldt ook voor een PC die je vertrouwd)

Hoevaak zie jij phishing die probeert afkomstig te zijn vanaf het domein van, laten we zeggen, je bank?
Bijna niet!

Meestal mailen ze vanaf iets wat erop lijkt, vanaf een prima DKIM gesigned domein onder hun beheer.

Dus helaas, DKIM is niet een oplossing voor phishing. Het is slechts een oplossing om zeker te zijn dat de mail echt afkomstig is van servers die de beheerder van dat domein vertrouwd.

In andere woorden:
Als iemand bij jou aan de deur staat, zegt dat hij werkt bij de bank, kan hij prima een paspoort van zichzelf tonen.
Maar het controleren van dat paspoort zegt niets over of hij werkt bij die bank.
Maakt het hooguit iets makkelijker voor de politie om hem later op te sporen (dit voorbeeld dan :)).

Ik pleit niet voor openpgp als oplossing, maar voor certificering door instanties en bedrijven die veel zakelijke mails naar klanten sturen. Neem het voorbeeld van de Rotterdamse Hogeschool, als die een certificaat zouden gebruiken, hadden vermoedelijk veel minder scholieren op de link geklikt.
https://www.security.nl/posting/710414/20+procent+personeel+Hogeschool+Rotterdam+opent+link+in+test-phishingmail

Wat DKIM betreft, die geld voor het gehele domein, maar is niet prominent zichtbaar in de ontvangen email. Om te kunnen zien of DKIM gebruikt is, moet je in de webmail van Gmail eerst de optie [origineel weergeven] vinden, en dan pas zie je of het gebruikt is. In Thunderbird is dat feitelijk nog moeilijker. Waar de gebruiker behoefte aan heeft is duidelijkheid. Daarbij komt dat DKIM bij de consument totaal onbekend is.

Het probleem met PGP is natuurlijk dat een phisher of spammer zijn eigen PGP sleutel kan toevoegen. Er is geen centrale autoriteit die bevestigt dat de PGP sleutel en de afzender bij elkaar horen.

Een logische plek hiervoor zou de provider zijn. Bijvoorbeeld Ziggo. De ontvanger kan dan de PGP sleutel van Ziggo vertrouwen die op haar site staat en Ziggo zet haar handtekening op de PGP sleutel van de klant.

Wat ik met PGP het vervelends vond is dat je bij elk verzonden bericht je wachtwoordzin opnieuw moest invoeren. Dit zorgt er wel weer voor dat je deze zin na een paar honderd mails nooit meer vergeet.

Ik herinner me dat er een officiële PGP versie was die van de fingerprint van je publieke PGP sleutel een reeks woorden maakte (versie 6??). Deze kon je dan over de telefoon voorlezen tijdens een normaal gesprek die over andere dingen ging.

Klopt dat doet al vrijwel ieder serieus te nemen bedrijf. Dat heet DKIM.
Dat is niet zo, die bedrijven bieden dat wel aan. Ziggo weet ik niet maar Gmail en Microsoft wel.

De makke is altijd dat de certificering niet gekoppeld is aan "het bedrijf" maar aan de gebruikte domeinnaam voor het
versturen van de mail. De koppeling tussen "het bedrijf" en de domeinnaam moet de ontvanger zelf maken, en bedrijven
doen de grootste moeite (in hun onwetendheid) om dat lastig te maken.
Daar door faalt het. Maar dat doet het systeem wat je nu zelf bedacht hebt ook.

Sorry, maar dit is echt helemaal niet mogelijk.


De klant heeft in het door mij geschetste scenario helemaal geen eigen sleutel nodig, immers het gaat alleen om de authenticiteit van de verzender, en daarvoor is in dit scenario diens publieke sleutel nodig. Het is die sleutel die bevestigd of email van de afzender (Ziggo) afkomstig is. U moet natuurlijk begrijpen, dat bedrijven als Ziggo nooit zullen kiezen voor Openpgp, maar gebruik zullen maken van een e-mail certificaat afkomstig van een professioneel certificatieautoriteit. Webmail aanbieders zullen dan die certificaten op hun mailserver moeten implementeren, zoals Google Gmail. Gebruikers van Thunderbird of Microsoft Outlook, die moeten de certificaten van die bedrijven in het certificatenbeheer van hun e-mailprogramma importeren.



Dat geld alleen voor PGP van Symantic. In gpg4win hoeft dit niet meer, kan je een wachtwoord selecteren, kopiëren, en plakken. Voor degenen die het zelf wel eens willen proberen, in Thunderbird zit in het sleutelbeheer de optie om zelf openpgp sleutels aan te maken.

Beste waterlelie, om te beginnen: goed om te zien dat je nadenkt over oplossingen tegen phishing en met concrete voorstellen komt (digitaal ondertekenen middels S/MIME).

Helaas vrees ik dat wat je voorstelt niet gaat werken, om de volgende redenen:

1) Ontvangers moeten dan weten dat specifieke afzenders nooit e-mails zullen verzenden die niet digitaal ondertekend zijn, en zelfs als ze dat weten, moeten ze niet in leugens trappen zoals "deze mail is niet digitaal ondertekend omdat ..." (vul zelf maar in). Ik heb vele jaren geleden met een klant gemaild die wederzijdse PGP verplichtte. De toenmalige versie van Outlook met PGP plugin van Symantec stuurde gewone mails netjes versleuteld en gesigneerd, maar vergaderverzoeken (ook die met bijlagen, waar ik een gloeiende hekel aan heb) werden -geheel onverwacht- onversleuteld en ongesigneerd verzonden - erg amateuristisch allemaal. Hopelijk is dat ondertussen verbeterd, maar met zeer weinig gebruikers krijgen noodzakelijke fixes meestal geen hoge prioriteit (dit geldt ook voor S/MIME, met certificaten dus).

Ter vergelijking: hoewel we met https veel verder zijn (de meeste webservers ondersteunen https) blijft het een probleem dat er nog steeds webservers zijn die ook (nog) http ondersteunen, of https überhaupt (nog) niet ondersteunen (het http protocol kan dus nog niet de prullenbak in). Als ik bijvoorbeeld in Firefox onder Android example.net invoer in de URL-balk en op "Enter" druk, kom ik uit op http://example.net/ - met een streep door het slotje. Ik weet dus niet zeker of mijn browser verbinding heeft met de echte example.net of dat ik, bijv. via een DNS-aanval, verbinding heb met een heel andere server. Nu zou ik natuurlijk https://example.net/ kunnen invoeren in de URL-balk van mijn browser, maar wat als er echt een DNS-aanval heeft plaatsgevonden (mijn browser niet het IP-adres van de echte maar van een fake server als antwoord heeft ontvangen) en de fake-server van de aanvallers bewust geen https ondersteunt? Dan zou ik kunnen denken dat dit één van de webservers op internet is die nog niet met zijn tijd is meegegaan, en dan dus maar http gebruiken - en bijv. door in te loggen mijn naam en wachtwoord prijsgeven aan de aanvallers.

Omdat het voor e-mail-ontvangers veel te lastig is om te onthouden welke organisaties (al!) hun uitgaande e-mail digitaal ondertekenen, zou feitelijk elke e-mail digitaal ondertekend moeten zijn (dan zou niet ondertekende mail bijv. in de spamfolder kunnen worden geplaatst en/of van een loeigrote waarschuwing worden voorzien). Dit is, net als bij http(s) sowieso een kip-ei probleem en daar komt bij dat digitale handtekeningen niet van begin af aan "in e-mail zaten" (een nieuw https-protocol is niet voor niets bedacht nadat http was uitgevonden; gelukkig zitten we nu niet opgescheept met een halfbakken oplossing waarbij http is "gepimpt" om tevens TLS te ondersteunen).

2) Dat een e-mail digitaal is ondertekend, zegt nog niets: het gaat erom wie heeft ondertekend én of die persoon geautoriseerd is om een mail met de gegeven inhoud te sturen namens de kennelijke organisatie.

Ter vergelijking: bij https checkt de browser o.a. of de (in de URL-balk) getoonde domeinnaam voorkomt in het https-server-certificaat; het is de taak van de surfer om vast te stellen dat getoonde domeinnaam van de bedoelde organisatie is (naast controleren dat op de juiste plaats in de browser een slotje wordt getoond, ten teken dat de server is geauthenticeerd én dat de verbinding met die server is versleuteld). Een voordeel is hier ook dat het initatief bij de gebruiker ligt: als deze een bookmark/snelkoppeling voor een website heeft aangemaakt met de juiste domeinnaam erin (voorafgegaan door https://) en die altijd gebruikt, kan er weinig meer fout gaan (mits de gebruiker geen http:// gaat proberen na een certificaatfoutmelding of een time out).

Het stokoude e-mail protocol maakt het er niet eenvoudiger op: zo wordt meer dan één afzender ondersteund (ook sommige DMARC-implementaties hebben of hadden hier problemen mee). Zelfs als het e-mail-programma zorgvuldig vaststelt dat de (enige) afzender in het getoonde "From:" veld de e-mail ondertekend heeft (d.w.z. over de geheime private key beschikt passend bij de public key in het meegezonden -dus niet geheime- certificaat), zal de ontvanger sowieso bij elke ontvangen mail foutloos moeten vaststellen dat het afzenderdomein van de kennelijke organisatie is, én dat de betrokken persoon geautoriseerd is om de gegeven mail te sturen namens die organisatie. Is bijvoorbeeld "no-reply" dat? En het initiatief ligt bij de verzender: vaak komen mails binnen op momenten die slecht uitkomen en is de ontvanger gehaast (Google: email fatigue). Daatnaast laten veel grotere organisaties het verzenden van mailings over aan derde partijen (die links in e-mails willen kunnen vervangen om clicks te tellen, zij willen meestal geen pre-signed mails doorsturen): hoe betrouwbaar is het als zij ondertekenen? Een deel van dat soort bedrijven neemt het niet altijd even nauw met beveiliging, en er zijn al verschillende mibruikt geweest door scammers.

3) Het is voor kwaadwillenden veel te eenvoudig om een geldig e-mail-certificaat te verkrijgen, sowieso voor "lijkt-op" domeinnamen. Maar ook hoeven zij maar één e-mail account van een organisatie te hacken om een geldig certificaat te kunnen verkrijgen voor dat account (waarbij de bijpassende private key natuurlijk in hun bezit is). Gezien het grote aantal BEC's (Business Email Compromise) doordat steeds meer mensen thuiswerken en/of organisaties alles in de cloud flikkeren, is dit geen denkbeeldig risico - dat digitaal ondertekende e-mails wel eens zouden kunnen verergeren (immers, "de mail is betrouwbaar want ondertekend door de afzender"). In z'n algemeenheid: betrouwbare online authenticatie is een nog nauwelijks opgelost en zeer ingewikkeld probleem.

4) Er zijn al veel implementatiefouten in S/MIME (en PGP/GnpPG/GPG) aan het licht gekomen, en we hebben de laatste vast nog niet gezien, mede doordat "het e-mail protocol" er ondertussen uitziet als een poreuze fietsbinnenband die je door de vele plakkers zelf niet meer ziet. M.i. hebben we een nieuw, van de grond af secure ontworpen, protocol nodig om zoiets (los van de andere uitdagingen) zinvol te kunnen maken.

Sorry dat ik zoveel beren op de weg zie...

"Deze methode werkt niet met webmail"
Roundcube heeft een plugin waardoor die met pgp/gpg overweg kan en werkt prima. Of het verstandig is om je key pair op een hosted roundcube op te slaan weet ik niet. Ik gebruik het op een self hosted server bij mij thuis.

Natuurlijk zit er tussen theorie en praktijk een wereld van verschil. Webmail is de wijze waarop de meeste mensen hun e-mail ophalen en schrijven. Dit door mij geschreven scenario, met de e-mail cliënt Thunderbird, is voor bedrijven geen optie. Zolang grote e-mail aanbieders als Google Gmail, en Ziggo als internet aanbieder, waar de klant automatisch een e-mail adres heeft, op hen mailservers geen digitale e-mail certificaten van bedrijven mogelijk maken, zal er niets veranderen.

Praktijkvoorbeeld
Nu moet ik als klant die een email ontvangt van bijvoorbeeld een installatiebedrijf, die na een reparatie door hun monteur verricht bij mij een e-mail stuurt met als onderwerp een tevredenheidsonderzoek. In die e-mail wordt ik dan gevraagd mee te doen aan een klein onderzoek. Hiervoor moet ik dan op een link klikken, maar het adres van die link heeft in de verste verte niks met het bedrijf te maken.

Als ik dan door middel van een digitaal certificaat kan zien, of de e-mail echt wel van het bedrijf afkomstig is, dan mag ik er als klant en ontvanger van de e-mail erop vertrouwen dat het aanklikken van de link betrouwbaar is.

Wat beter is dat je in het e-mail programma de hyperlinks uit zet met ontvangen en lezen.

Als je mijn (goedbedoelde) bijdrage al helemaal gelezen hebt, heb je deze (met name 2 t/m 4) niet tot je door laten dringen.

Maar sowieso geef je een slecht praktijkvoorbeeld. Want verreweg de meeste phishingmails die ik gezien heb, vragen niet om vrijwillig op een link te klikken, maar zijn dwingend (en vaak "zal de ontvanger schade leiden" als deze niet klikt). En dan is mijn punt 1 zeker ook van toepassing.

Geacht Erik van Straten, uw eerste reactie is een opsomming van veronderstellingen en aannames, en missen elke inhoudelijke redenatie. U komt met allemaal vage mogelijkheden die kwaadwillenden eventueel zouden kunnen gebruiken om zich als een legitiem bedrijf voor te doen. Het is de bel horen, maar niet weten waar de klepel zit, maar daar wel conclusies uit trekken. Ik heb een slot op mijn deur van mijn woning, maar in uw redenatie is dat niet nodig, omdat inbrekers die altijd kunnen kraken.

Als ik een e-mail ontvang van Ziggo, dan wil ik weten of die e-mail ook werkelijk van Ziggo afkomstig is. Ziggo gebruikt natuurlijk meerdere adressen allemaal eindigen op Ziggo.nl, en die adressen kunnen in een certificaat (dus niet Openpgp) worden opgenomen, en dat is voor mij als klant een goede reden om te mogen aannemen dat die e-mail van Ziggo afkomstig is. En ja; als de mailserver van Ziggo gekraakt word, dan kan de indringer die gebruiken om phishing mails te verzenden. Dus in uw redenatie....!

Voor degene die dit wel eens zelf met anderen in Thunderbird willen proberen, Thunderbird heeft openpgp zonder extensie in haar programma geïntegreerd, en men kan in het sleutelbeheer van Thunderbird zelf pgp sleutelparen aanmaken.

Je voorbeeld geeft aan hoe belangrijk het is dat bedrijven alleen linken naar hun eigen domeinen.
Daar heb je een heel goed punt wat denk ik iedereen ook onderschrijft.

Je zou zelfs kunnen zeggen dat als ze pgp gaan zien als een oplossing daarvoor het juist de verkeerde kant op gaat.

Mijn tip: mail het bedrijf terug dat je een phishing mail hebt gehad en als het echt van hun is ze dit moeten fixen.

In de RFC van OpenPGP staat alleen dat de User ID een UTF-8 string is. Verder niets. Je kan er alles neer zetten en het voldoet aan de specs.

https://datatracker.ietf.org/doc/html/rfc4880#section-5.11

Het verifiëren van een identiteit gaat via 'Web of Trust' maar dat heeft nooit gewerkt.

Anoniem 20:49

Hier spreek je jezelf tegen. Als phishing zelden van het goede domein komt, is dkim toch juist een methode om te checken of de afzender wel klopt. Als ik mail krijg waarvan ik de afzender wil controleren kijk ik altijd naar de dkim check. En natuurlijk het bijbehorende domein waarop gecontroleerd is, want een geldige dkim voor een onbekend domein zegt niets.

Maar dat kan al lang via DKIM.
Voor het domein :
"ziggo.nl" staat hun public key in "202002corplgsmtpnl._domainkey.ziggo.nl"
"e.ziggo.nl" staat hun public key in "jun2018._domainkey.e.ziggo.nl"
"ziggo.com" staat hun public key in "s2._domainkey.ziggo.com"

Het eerste domein wordt ook door klanten gebruikt en heeft een DMARC met policy none. Maar nog steeds kun je zelf in de header zien of de check klopt. De andere twee domeinen gebruikt ziggo voor hun eigen mailings en daarvoor staat de DMARC policy op reject.
NB de locatie van de public key staat in de mail zelf. Die kan in de loop der tijd veranderen.

Anoniem 20:49 schreef
Het probleem met PGP is natuurlijk dat een phisher of spammer zijn eigen PGP sleutel kan toevoegen. Er is geen centrale autoriteit die bevestigt dat de PGP sleutel en de afzender bij elkaar horen.

Hij verwijst hierbij naar een wetenschappelijk artikel.
5.11 . Gebruikers-ID-pakket (Tag 13)
Een User ID-pakket bestaat uit UTF-8-tekst die bedoeld is om de naam en het e-mailadres van de sleutelhouder weer te geven. Volgens afspraak bevat het een RFC 2822 [RFC2822] mail name-addr, maar er zijn geen beperkingen op de inhoud ervan. De pakketlengte in de header geeft de lengte van het gebruikers-ID aan.

Testprocedure
Nu is de test in mijn voorbeeld gedaan met een Openpgp sleutel, maar het certificeren van e-mail van bedrijven die veel mail verzenden, kan natuurlijk nooit met openpgp gebeuren, maar alleen met certificaten die uitgegeven worden door certificering organisaties. Dit heb ik ook nadrukkelijk benoemd.

Maar wat Anoniem 20:49, nu beweert lijkt mij interessant, want als je als privé persoon je e-mail met een groepje anderen met openpgp sleutels wilt certificeren, dan is het natuurlijk belangrijk dat dit ook veilig is.

Procedure
Ik kan met Thunderbird een PGP sleutelpaar aanmaken, en deze in mijn sleutelbeheer opnemen. Hiervoor is een wachtwoord vereist. Vervolgens kan ik mijn publieke sleutel in een e-mail als bijlage naar een ander persoon verzenden.
Deze andere persoon ontvangt de e-mail, en importeert mijn publieke sleutel in het sleutelbeheer van zijn Thunderbird programma. Om de authenticiteit van mijn sleutel vast te stellen, geef ik die persoon telefonisch de digitale vingerafdruk.

Misschien dat anoniem 20:49, met deze informatie in zijn achterhoofd mij nu kan vertellen, wat hij met de verwijzing naar dit wetenschappelijke artikel concreet bedoelt.

???

Twee laatste adviezen: begin niet met een oplossing te bedenken voordat je het probleem voldoende in kaart hebt gebracht. En 2: stoot ervaren mensen, die jou vriendelijk en vrijblijvend adviseren (o.a. door jou erop te wijzen dat je het probleem -dat je probeert op te lossen- onvoldoende in kaart hebt gebracht), niet voor het hoofd. Dan kom je een stuk verder in jouw leven.

Waarom spreek ik mezelf tegen? Voor zover ik weet doe ik dat niet, maar haal ik juist 2 dingen niet door elkaar die vaak door elkaar worden gehaald.
Phishing komt vaak van "Jouw bank <random[@]example.nl>". Prima DKIM te signen. Maar je mobieltje toont het mailadres niet, de ontvanger let niet op wat het ontvangst adres is etc. Daarom lukt de phish. Niet omdat het ook maar enigzins lijkt op het domein van de bank.

Dus DKIM helpt de oplettende ontvanger (hoe vaak check jij het mailadres van iemand?), maar stopt phishing niet.

Zou iets phishing stoppen, dan zou je immers de poging/mail niet krijgen (een goed spamfilter doet z'n best).

Ik leg het graag uit.

Op de User ID Packet (Tag 13) zit een selfsignature. Als je het User ID van een public key verandert, klopt de selfsignature niet meer.

Maar omdat er geen centrale autoriteit is die zegt Dit is waterlelie, is het mogelijk real time een vervangend public/secret key pair te genereren waarbij de aanvaller volledige controle over alle parameters heeft.

Deze public key heeft dan wel een nieuwe fingerprint. En de secret key van de oorspronkelijke public key is niet bij de aanvaller bekend.

Door dit aan beide kanten van de communicatie te doen krijg je een man-in-the-middle aanval en kan alles meegelezen worden en zelfs aangepast. Hier is geen wiskundige tegenmaatregel voor. Alle public key encryptie heeft hier last van. Ook https. Slechtere virusscanners doen dit bijvoorbeeld om malware in https verkeer te detecteren.

Anoniem 20:49

U ben duidelijk enigszins gepikeerd over de toon die ik gebruik, maar dat komt omdat ik gewoon niet zit te wachten op discussies die feitelijk niks met het onderwerp te maken hebben. Uw laatste advies, "begin niet met een oplossing te bedenken voordat je het probleem voldoende in kaart hebt gebracht". toont dat ook aan. U wilt eerst een hele discussie over de randverschijnselen hebben, en komt met een grote lap tekst, die inhoudelijk alleen maar uw eigen mening reflecteert.
Ik heb getracht het correct samen te vatten, en ik begrijp nogmaals dat u zich daardoor beledigt voelt. Mijn excuus voor dat laatste.

Feit is dat e-mail certificaten al jaren door certificeringsbedrijven uitgegeven worden, om o.a. de authenticiteit van de afzender te garanderen. In mijn opinie zou gebruik daarvan voor alle bedrijven die veel e-mail verkeer met hun klanten hebben gestimuleerd moeten worden c.q. wettelijk opgelegd moeten worden. De belangrijkste reden hiervoor is het probleem van de phishing, een feit van algemene bekendheid, dat dit voor heel veel ellende zorgt.

Mijn dank voor uw uitleg. Ik heb zelf naar aanleiding van de link wat onderzoek gedaan, en kwam o.a. op de volgende website: https://superuser.com/questions/1240733/how-can-i-remove-real-name-from-my-pgp-key
Ik oefen regelmatig met de mogelijkheden en onmogelijkheden van PGP, ik ben een fan van encryptie, maar dit is materie dat gaat boven mijn pet. Verder zal ik natuurlijk proberen meer duidelijkheid over te vinden.

Als je mobieltje het e-mail adres niet laat zien, gebruik je verkeerde instellingen. Volgens mij is dat bij de meeste apps wel mogelijk. Bij mij staat onder de afzendnaam de knop "toon meer info". Die gebruik ik altijd als ik wil zien waar de mail vandaan komt.
Het checken van de dkim ondertekening is wel iets lastiger op een mobieltje. Ik heb lang moeten zoeken voordat ik een app vond die ook de headers kan tonen. De 'Blue Mail" app doet dat. De mogelijkheid tot controleren van de afzender en de dkim ondertekening is voor mij ook de enige reden waarom ik 'Blue Mail" gebruik.

Hierboven staan leuke ideën die niet realistisch zijn. Het zal je nooit lukken om met elke afzender een certificaat uit te wisselen. De aandacht kan beter gaan naar het implementeren van de methoden die er al wel zijn.

Een heel simpele is om alle mail van afzenders die niet in het adresboek staan, bij voorbaat in de spamfolder te gooien. Zo heb ik mijn mail systeem ook ingericht. Een computer trapt niet in gelijkende afzend domeinen. Je hebt dan de zekerheid dat er alleen gevalideerde afzenders in je inbox komen. In die inbox komt dan geen spam meer.

Je moet dat wel iets vaker in de spamfolder kijken, maar als je bewust in die folder kijkt, ben je wel alerter. En als je een afzender goed bevonden hebt, voeg je hem toe aan je adresboek. Dit is een methode die je nu al kunt toepassen, zonder niet haalbare ideeën om gebruikers certificaten te gebruiken.

Ik vindt dit een heel interessant idee.
Maar "spambox" is niet de juiste box, immers zit daar alle zekere spam al in. En daar wil je niet potentieel betrouwbare mail in hebben (die box wil je eigenlijk gewoon nooit openen).

Maar met een goede verdeling kun je hier wel winst halen:
"Mijn contacten" - "Random anderen" - "spam" - "technisch foutief (deze mails zie je vaak al niet)".

Mijn outlook doet al zoiets met "prio email" en "andere mail", maar die onderverdeling werkt niet handig.

Enigste is dan wel dat je "Mijn contacten" ook met "*@*.domein.nl" moet kunnen configureren, want bedrijven zijn niet echt consequent waar ze je vandaan mailen (vandaag heb je met Piet contact, morgen met Jesse, en beide kun je vertrouwen).

Blijft overigens wel nog het restje over waar betrouwbare afzenders hun computers mogelijk gecompromitteerd zijn, dus helemaal vrij van phishing ben je nog steeds niet natuurlijk.

p.s. "Bij mij staat onder de afzendnaam de knop "toon meer info"." Dat toont al aan dat niemand er kijkt, op de gek die jij en ik zijn na. Anders zouden ze dat niet zo verstoppen, want dan zou iedereen klagen dat het irritant is dat je er continue op moet klikken.

Wettelijk iets willen gaan afdwingen wat gewoon een commerciële aanbieding is (immers, certificaat is commercieel iets wat je kunt kopen), dat gaat je nooit en te nimmer lukken.
Zelfs met DKIM wat in overheids land al pas-toe-of-leg-uit is, past de overheid dit zelfs nog niet eens goed genoeg toe: https://www.forumstandaardisatie.nl/open-standaarden/dkim.

Daarnaast is er geen standaard die goed werkt (DKIM is het gene wat het dichtste bij komt), dus waagt geen bedrijf zich eraan.

Laten we hopen dat die er wel ooit komt. Maar PGP, S/MIME en hun varianten is het niet (anders had het allang aangeslagen net zoals Signal en iMessage).

TL;DR: https://www.vice.com/en/article/vvbw9a/even-the-inventor-of-pgp-doesnt-use-pgp.

Ik heb hier al enkele keren het DKIM verhaal voorbij zien komen, en daar kan ik heel kort me zijn, dat werkt niet voor de gebruikers. Het bestaat voor het overgrote deel van de gebruikers niet eens. De fout die hier gemaakt word is dat eigen interpretatie geprojecteerd word op de massa, en dan verbaast is dat niemand dat lijkt te snappen.

De gebruiker over één kam gescheerd moet gewoon een zichtbare waarschuwing krijgen als een e-mail niet afkomstig is van degene waarvan zij denken dat het is. En dat kan alleen maar met een certificaat, net als het slotje in het adres van een website. Nu zullen velen erop wijzen, dat dit ook niet echt door de gemiddelde gebruiker wordt gevolgd, en dan hebben ze gelijk, maar daar zijn dan weer de extensies en virusscanners voor die ons daartegen beschermen.
Cru geredeneerd, als een e-mail adres niet overeenkomt met het certificaat, dan zou in de webmail, (toch het meest gebruikt) een zichtbare waarschuwing moeten komen, die erop wijst dat het adres van de afzender niet met het certificaat overeenkomt.
Wat daarna de gebruiker doet, is zijn of haar, (en om geen gedonder met de Woke gekkies te krijgen), het eigen verantwoordelijkheid.

Philip Zimmermann staat aan de wieg van wat nu geëvolueerd is tot de moderne toepassingen van encryptie. Het zou mij ook verbazen als hij zelf niet mee geëvolueerd zou zijn. Het gebruik van PGP sinds haar geboorte in 1991 heeft nooit de massa bereikt, omdat het niet gebruiksvriendelijk was. De wens om met elkaar te kunnen communiceren zonder dat iemand meeluistert, is met de nieuwe mogelijkheden enorm populair, maar doordat de markt wereldwijd daar steeds meer controle over krijgt, lijkt er een trend te zijn ontstaan om terug te keren naar het oude vertrouwde PGP in een nieuw jasje, waardoor het wel gebruiksvriendelijker is geworden. Alleen de massa zal het nooit bereiken, omdat die gewoon geen enkele moeite wil doen om inhoudelijk daarvan iets te weten, dus kiezen ze voor gemak, en de markt kom hun graag tegemoet.

Consequentie daarvan is dat hun toekomstige carrière afhangt van wat ze in hun jeugd en verdere leven voor domme dingen hebben geschreven of uitgesproken, immers alles daarvan is opgeslagen, en wacht geduldig totdat ze interessant zijn geworden

Dat klopt niet wat je daar schrijft.
Als je bijvoorbeeld iemand bij gmail of outlook.com een mail stuurt met niet-kloppende DKIM dan komt er een duidelijke
melding boven te staan dat de mail mogelijk niet afkomstig is van de afzender die gesuggereerd wordt.


Maar daarvoor is GEEN andere manier van signing nodig (dus geen gedoe met PGP of S/MIME) maar alleen een
verbetering van de gemiddelde mailclient zodat deze dit soort situaties duidelijk aangeeft.
Als iets SPAM is dan is er vaak wel een specifiek icoontje mogelijk in mailprogramma's (bijv Thunderbird) maar als
het spoofed is dan niet. Ik heb er al over zitten denken om een change request hiervoor aan te maken in Bugzilla,
maar helaas leert de praktijk dat dit soort requests na 10 jaar nog niet gerealiseerd is en/of na een tijdje gesloten
wordt door een of andere nitwit met een "nou er waren geen reacties dus sluiten we hem maar" zodat zelfs ontwikkelaars
die op een gegeven moment zoeken naar mogelijke verbeteringen in de UI deze niet meer gaan vinden.

Ik heb nu experimenteel zelf een "message filter" gemaakt wat mail waar de header tekst in staat die aangeeft dat
de mailserver een DKIM fout gedetecteerd heeft, en die dan de message een andere kleur geeft (bij gebrek aan een
extra icoontje hiervoor). Dit werkt. En je ziet wat het probleem is, bijv een mailinglist die met "mailman" gemaakt is
die behandelt DKIM niet goed. Is kennelijk bekend bij de mailman maintainers maar die hebben het nog niet opgelost
zo te zien (een mailinglist die mail verstuurt vanaf eigen domein moet uiteraard alle inkomende DKIM info verwijderen
en de message die ze zelf versturen signen met een key in het eigen domein).

Verder werkt het zo te zien aardig goed.
Maar, zoals ik al eerder noemde, DKIM heeft (net als jouw voorstel) het probleem dat het signen niet gekoppeld wordt
aan het verzendende BEDRIJF maar aan het verzendende DOMEIN, en dat het aan de gebruiker wordt overgelaten
om zeker te stellen dat het verzendende DOMEIN wel eigendom is van het verzendende BEDRIJF.
En helaas, de paarse broeken bij marketing en communicatie snappen domeinen niet, en registreren een nieuwe
voor elke scheet die ze laten. Als alle communicatie van BedrijfX altijd afkomstig was van bedrijfx.nl dan zou je kunnen
verwachten dat mensen dat onthouden, maar helaas dat is dus niet zo.
En hoe moet je weten dat bedrijfx-actie4.nl een domein is wat in eigendom is van BedrijfX? Dat kan net zo goed
door een scammer geregistreerd zijn. Dus daar gaat het op fout. Eigen schuld.

Zelfs dat klopt niet.

Voor een koppeling met het (niet in elke mail-client getoonde) afzenderdomein in het From: veld, heb je tevens DMARC nodig. Maar DMARC negeert DKIM-mismatchches als SPF wel in orde is (voor DMARC moet minstens één van beide kloppen).

Zie https://www.security.nl/posting/463813/Waarom+DMARC+%28%2BSPF+%2BDKIM%29 voor een voorbeeld van de headers van een mail naar verluidt van ashley.nivers@gmail.com met een geldige DKIM signature (xs4all.nl: "dkim=pass" en "spf=pass") die helemaal niet door een gmail.com server was verzonden (hier faalde de DMARC-check omdat ook SPF -uitsluitend in combinatie met DMARC- faalde, maar in de huidige discussie gaat het om DKIM). Zie ook de discussie waaronder mijn bijdragen in https://www.security.nl/posting/687606/Toegevoegde+waarde+van+DMARC+naast+DKIM.

Aanvulling, nog een voorbeeld van een mail met "dkim=pass", "spf=pass" maar "dmarc=fail", deze naar verluidt van Eneco: https://www.security.nl/posting/644013/dmarc+%3D+fail.

Zoals ik wel vaker schrijf: een geldige signature, een geldige public key en/of een geldig certificaat (https, code signing, etc. zeker indien self-signed) zegt niets als deze niet van de veronderstelde partij blijkt te zijn.

Uw redenatie over Gmail is correct, als de DKIM niet klopt gaat de mail in de spambox, en daar spelen de kwaadwilligen op in, door hiervoor al te waarschuwen in de mail, maar dat is natuurlijk niet de schuld van Gmail of Outlook Maar hoe zit het met verzenders van e-mail, zonder DKIM handtekening. Daarom is de discussie over DKIM en nog enkele protocollen in deze discussie onzinnig, want men is geneigd de één met de andere te vergelijken. Het onderwerp gaat over het gebruiken van certificaten om de authenticiteit van de afzender nog beter te kunnen garanderen.



Het PGP voorbeeld is van een geheel andere orde, het was een test met het gebruik van openpgp in Thunderbird, en duidelijk door mij aangegeven niet op van toepassing voor bedrijven, maar met name voor privé of kleine organisaties, die ook naar gebruiksvriendelijke middelen zoeken om met elkaar veilig te kunnen e-mailen

Beveiliging is niet één maatregel, maar een serie die elkaar aanvullen, en daarom begrijp ook niet de weerstand daartegen. Dat ik daarbij ook een wettelijke verplichting bepleit, is mijn mening, en als men het daar niet mee eens is, het zij zo, maar het is geen uitnodiging door mij om daar ook nog eens een discussie over te gaan voeren.

@Waterlelie en @Erik van Straaten
En natuurlijk @ alle anderen ;-)

Ik ben zeer deskundig op gebied van digitale handtekeningen. Ik ben direct betrokken bij een van de grote CA's van Nederland.

- Datgene dat waterlelie beweert, dat heb ik zelf al tal van keren aangegeven. Spam en Phishing kunnen voor een groot deel worden voorkomen als alle organisaties hun uitgaande mail digitaal ondertekenen.
- Datgene dat Erik van Straaten beweert kan in zichzelf ook waar zijn. Veel infrastructuur zal inderdaad de digitale handtekening onvoldoende ondersteunen. De vraag is of dit je moet tegenhouden. Ik denk van niet. De 'slechte' programmatuur zal worden aangepast als de gebruikersbehoefte groter wordt.

In Europa is er wetgeving die vertrouwensdiensten regelt. Dat is EU 910/2014 eIDAS. Deze regelt ook het formeel gebruik van digitale handtekeningen. Een Europese organisatie mag een binnen de eIDAS erkende digitale handtekening niet weigeren. Bij de gekwalificeerde handtekening is er ook sprake van omkering bewijslast als een dispuut bij de rechter komt. Deze handtekeningen zijn persoonsgebonden. En zo is er ook een machine gebonden digitale handtekening. Dat is de Electronic Seal. Elke organisatie kan een electronic seal inkopen en gebruiken om alle uitgaande mail te ondertekenen.

Het gebruik van een digitale handtekening (waaronder dus een Seal) is onderhavig aan wetgeving. Elke organisatie die een digitale handtekening inkoopt zal op identiteit (en nog wat meer attributen) worden gecontroleerd. Een gebruiker hoeft alleen maar te onderzoeken of de digitale handtekening op de EU Trust List staat (zie https://webgate.ec.europa.eu/tl-browser/#/). Als de uitgever van de digitale handtekening daarop staat, dan zal die digitale handtekening betrouwbaar zijn (en de plaatser van de handtekening bekend zijn). Overigens kan dit ook op geautomatiseerde manier plaatsvinden.

Het gevolg is:
- de ontvanger van de mail kan vertrouwen hebben in de verzender.
- de ontvanger van de mail kan vertrouwen hebben in de content (het is wat de verzender bedoelde).
- de verzender is op te sporen als die bewust foute dingen doet. En juist dit is van belang om spam en phishing te verminderen.

Als een bewust bekwame slechterik met een eIDAS erkende handtekening jou een phishing mail stuurt, dan kan je die opsporen (of de politie kan dat). In ieder geval draagt ook de uitgever van de handtekening een deel van de aansprakelijkheid.

Als een bewust bekwame slechterik een zelf gemaakte handtekening handtekening gebruikt, dan is die niet opgenomen in de EU Trust List en zal je (of jouw computer) zijn gewaarschuwd.

Als een organisatie geen digitale handtekening gebruikt, dan moet je je afvragen of die organisatie wel/niet een bewust bekwame slechterik is. Wees dan heel voorzichtig.

Als jouw vrienden geen digitale handtekening gebruiken, dan is er niets aan de had. Jij kent immers toch jouw vrienden en weet hoe en waarover ze jouw schrijven?

Als een bewust bekwame slechterik jouw vrienden-mailadressen wil gebruiken voor spam en phishing, dan heeft die bewust bekwame slechterik in ieder geval heel veel extra werk. (dit is niet volledig te voorkomen).


Ik pleit er al jaar en dag voor om de overheid voor burgers op alle aan burgers gepersonaliseerde pasjes ook een set van drie certificaten te plaatsen.
- Encryptie (wettelijk mag dit wel in escrow worden genomen)
- Authenticatie (wettelijk mag dit niet in escrow worden genomen) (als vervanging/aanvulling op digid)
- Digitale handtekening binnen eIDAS richtlijnen. (wettelijk mag dit niet in escrow worden genomen)

De voor burgers gepersonaliseerde pasjes zijn oa;
- Paspoort
- ID kaart
- Rijbewijs
- kentekenbewijs
- verblijfsvergunning
- etc

Er zijn geen extra kosten voor de uitgifteprocessen. Die zijn allemaal goed genoeg.
Er zijn wel kosten voor de betreffende CA (reken op 1 Miljoen Euro vanwege de wettelijke eisen) (verdeeld over zeg 20 miljoen kaarten is 0,50 euro per kaart)
Er zijn kosten voor chips op de plastic kaarten (1-2 Euro per kaart).
Kost nagenoeg geen drol en levert heel veel extra veiligheid op.
Dan gaat het bedrijfsleven vanzelf volgen.

er zijn best wel wat zwakheden te vinden. Voor die zwakheden zijn ook relatief gemakkelijk oplossingen te bedenken/te regelen.

Irrelevant! Ik heb het niet over DMARC, ik heb het over DKIM. "in DMARC moet minstens een van beide kloppen" dat
geldt alleen voor het totale DMARC resultaat, je kunt ook dan nog gewoon de DKIM status apart gebruiken.
Dan kun je van een mail die niet als spam gezien is toch aangeven dat DKIM niet klopte of niet aanwezig was.

En het is echt waar hoor, DKIM (en al het andere wat voorgesteld wordt) is niet gekoppeld wordt aan het verzendende
BEDRIJF maar aan het verzendende DOMEIN.

Het is nogal onzinnig om de verdommificatie van e-mail clients te gaan bestrijden met weer nieuwe manieren van signen,
als men het aan de tafels van de softwaremakers nodig vindt om de gebruiker dom te houden dan verandert dat echt
niet als je zoiets voorstelt.

Ik kijk alleen naar hoe ik MEZELF kan beschermen tegen vervalste mail, niet hoe de slachtoffers van Microsoft of
gebruikers van smartphones te beschermen zijn. Die moeten het zelf maar weten als ze graag dom gehouden worden.

Ga je nou echt beweren dat als je hier komt met een voorstel om een of ander deelprobleem op te lossen, die 99%
overlapt met een maatregel die er al is (DKIM), en niet iedereen zegt enthousiast "moeten we doen waterlelie,
waterlelie for president!", je dat dan moet zien als "weerstand"???

Kun je een overzicht geven van Nederlandse bedrijven die deze escrow techniek kunnen leveren en daar een werkende implementatie voor hebben? Ten opzichte van de DigiD smartphone App is natuurlijk alles een verbetering.

Anoniem 20:49

Je leest niet wat ik schreef (het deel dat je wegliet in de gequote tekst) of je laat het niet tot je doordringen.

Ik krijg een e-mail van ashley.nivers@gmail.com met een geldige DKIM signature - echter gezet door een wildvreemde server (die niets met google/gmail te maken heeft). Wat heb ik daar in vredesnaam aan?

Nog een voorbeeld: in december stuurde ik een e-mail naar iemand bij nos.nl en kreeg een automatisch antwoord, dus met "Return-Path: <>" - een situatie waarin SPF al compleet kansloos is (zoals ik ruim 16 jaar geleden al beschreef in https://www.security.nl/posting/10403/Waarom+SPF+en+FairUCE+op+termijn+geen+spam+bestrijden).

In het automatische antwoord van nos.nl zaten een drietal ARC headers plus de volgende DKIM header:

Xs4all heeft na ontvangst de volgende header toegevoegd:

NOS had (heeft?) haar config bij MS duidelijk niet op orde, maar daar gaat het mij niet om. Mijn punt is: je ziet een (hoogstwaarschijnlijk) geldige DKIM-signature, maar die is niet door/voor/namens nos.nl gezet: er staat niet "d=nos.nl" maar "d=nosrtv.onmicrosoft.com", dus negeert xs4all terecht die DKIM signature.

Immers, als ik bij Microsoft een organisatie "nosradiotv" registreer, en via Microsoft e-mails verzend die netjes door hen van een DKIM signature worden voorzien (met "d=nosradiotv.onmicrosoft.com"), wil dat natuurlijk niet zeggen dat mijn mails van de echte nos.nl afkomstig zijn.

Conclusie: aan DKIM heb je niets als geen van de geldige DKIM signatures in de headers van een e-mail gezet is door een server die geautoriseerd is (via een private key met bijpassende public key in een DNS record) om dat te doen voor het voor een ontvanger (meestal) zichtbare of zichtbaar te maken afzenderdomein - zoals gmail.com in ashley.nivers@gmail.com. En je hebt DMARC nodig om dat enigszins af te dwingen (enigszins, want als SPF in orde is, boeit DKIM niet meer).

Wat zeer veel ICT'ers (inclusief TS), maar ook veel anderen, niet lijken te (willen) snappen: de m.i. belangrijkste eis aan elke authenticatiemethode is niet dat Alice kan aantonen dat zij Alice is, maar dat Mallory (of wie dan ook, anders dan Alice) niet kan aantonen dat zij of hij Alice is. Want zo'n mogelijkheid is precies waar identiteitsfrauders altijd naar op zoek zijn.

@anoniem 18:28 van gisteren

Ik heb niet beweerd dat ik Nederlandse bedrijven ken die dit soort escrow technieken kunnen leveren. Ik heb slechts gezegd dat de encyptiesleutels in escrow bewaard mogen blijven.

Voor het onderstaande ga ik uit van een wettelijke PKI implementatie volgens eIDAS (dus inclusief een 2-jaarljkse certificeringsaudit).

Toepassingen
- meerdere encryptiecertificaten voor een gebruiker aanmaken met dezelfde private sleutels.
- ook oude emails (berichten/data) nog kunnen ontcijferen.
- Malware scanning op inkomende versleutelde berichten.

Primaire plaats van de escrow. Kan in de HSM waar de encryptiesleutels zijn gemaakt. Als encryptiesleutels in een smartcard zijn gemaakt, dan is escrow in principe niet mogelijk (of heel moeilijk).

Secundaire plaats is elke veilige omgeving (dat moet je dus ook vaststellen).
Een secundaire plaats kan een additionele HSM zijn die is opgenomen in de email-ontvangst-straat van een organisatie. De encrypted emails kunnen worden ontcijferd en gescanned op malware. Dit kan volledig geautomatiseerd.
- als er mallware is aangetroffen, dan wordt de mail niet naar ontvanger doorgestuurd. Wat je met de foute mail doet is afhankelijk van de eigen doelstellingen (bijv onderzoeken, vernietigen, of nog weer anders)
- als er geen mallware is aangetroffen, dan wordt de oorspronkelijke (nog steeds versleutelde mail) doorgestuurd naar de ontvanger.

Eigenlijk is dit helmaal niet zo moeilijk.

Andersom kan ook helpend zijn. Dan gaat het niet over mallware scanning, maar om Data Leakage Prevention.
Eerst moet je weten dat de mail encrypted is met de ontvangers publieke sleutel. De private sleutel ken je niet. Dus zal je de eigen infrastructuur moeten configureren dat je of
- de versleuteling pas plaats vindt nadat de mail op DLP elementen is gescanned, of
- een onversleutelde kopie van het versleutelde bericht kan scannen.

Geeft dit voldoende info voor jouw beeldvorming?

Nee natuurlijk niet! Maar dat beweert ook niemand. Een "geldige DKIM header" is NIET alleen een DKIM header waarvan
de waardes corresponderen met wat er in de mail staat. je moet OOK kijken WIE die DKIM header gezet kan hebben,
dat is dus degene die in het bezit is van de private key van de selector die genoemd is in de DKIM header.
Aannemende dat er niks gelekt is, is dat de eigenaar van het domein waar die selector onder valt.

En ik heb al diverse malen naar voren gebracht dat het gaat om het DOMEIN niet om het BEDRIJF. Dus als jij
nosrtv.onmicrosoft.com op de een of andere manier relateert aan de NOS en daar zelfs een ander domein (.nos.nl)
bij sleept dan heb je dit nog niet helemaal begrepen.
Wat zou helpen is een gestandaardiseerd publiek toegankelijk web van info, bijvoorbeeld:
https://nos.nl/.well-known/domains.txt is een lijst van alle domeinnamen die het bedrijf achter nos.nl hanteert voor de
diverse diensten die het levert. En liefst ook iets van parent.nosrtv.onmicrosoft.com is een CNAME naar nos.nl.
Zodat je de onderlinge relatie tussen DOMEIN en BEDRIJF namen kunt leggen terwijl je een dergelijke mail analyseert (automatisch of handmatig).

Heb je vandaag Money-mules, morgen krijg je mail-mules. En meer malware, die vooral mail gaat sturen namens onschuldigen.

Vanzelfsprekend is het een goed idee, maar phishing en spam los je er niet mee op. Het wordt hooguit, voor degenen die het snappen en goed kijken, simpeler om te controleren of iets in de haak is of niet.

Laten we eens kijken hoe dit in andere protocollen is opgelost.
Bijvoorbeeld in Signal, wat WhatsApp gebruikt.

In whatsapp is het duidelijk wie jou een bericht stuurt (staat nummer in).
Alleen dat nummer kan het verzenden en de hele infra van certificaten zit erin.

1) check jij bij je vrienden dat certificaat ooit?
2) Hoeveel phishing is er via whatsapp? (tip: een hele hoop, met veel schade).

Conclusie: certificaten zijn goed, maar het is geen wapen. Het is misschien een bot mes.
Note. Ook DANE helpt, ook DKIM helpt.

Je?

Twee mogelijkheden:
1) Theorie: de ontvanger doet dat handmatig. Behalve jij en ik doet geen enkele Henk en geen enkele Ingrid dat. Valt dus af.
2) Praktijk: DMARC doet dat automatisch. Echter maar half, want als SPF klopt mag alles in de mail vervalst zijn en worden DKIM signatures genegeerd.

Of ken en gebruik jij soms een betere automatische oplossing dan DMARC? Met alleen DKIM bereik je namelijk niet wat jij lijkt te suggereren.

En beantwoord nou eens mijn vraag, die ik probeer te verduidelijken: ik krijg een e-mail van ashley.nivers@gmail.com met een geldige DKIM signature die niet is verzonden vanuit een gmail.com account, maar een leek ziet dat nergens aan. Wat heb ik daar in vredesnaam aan? Dat wil zeggen: hoe helpt DKIM mij (en vooral: Henk en Ingrid) vaststellen dat deze mail NIET is verzonden vanuit een gmail account, en dus zeker niet door ashley.nivers@gmail.com?

Ik herhaal (advies: lees dit nou eens en leer ervan): Wat zeer veel ICT'ers (inclusief TS), maar ook veel anderen, niet lijken te (willen) snappen: de m.i. belangrijkste eis aan elke authenticatiemethode is niet dat Alice kan aantonen dat zij Alice is, maar dat Mallory (of wie dan ook, anders dan Alice) niet kan aantonen dat zij of hij Alice is. Want zo'n mogelijkheid is precies waar identiteitsfrauders altijd naar op zoek zijn.

Aanvulling: het omgekeerde van "niet" is niet altijd "wel" (en/of vice versa). Vergelijk het met een Covid-19 sneltest: bij een positieve uitslag is de kans zeer groot dat je besmettelijk bent. Bij een negatieve uitslag weet je niks zeker.

Ik heb bij escrow toch voornamelijk visioenen van politieagenten die alles wat je zegt in de gaten houden. Voor bedrijven kan het nuttig zijn voor de continuïteit als een werknemer ziek is. Maar we hebben het hier natuurlijk vooral over burgers die deze escrow op hun identiteitskaarten en paspoorten terug zien.

Verder is het heel leuk om een ongeopende e-mail op malware te kunnen scannen, ware het niet dat deze scansoftware waarschijnlijk bedrijfsgeheim is en zelf een veelvoud aan fouten en kwetsbaarheden bevat.

Ook zullen criminelen net zo lang 'innoveren' tot ze een manier ontdekken om buiten de escrow om berichten uit te wisselen. Dus het heeft allemaal helemaal geen enkele zin.

Het is beter als dat het nu is zonder escrow.

Anoniem 20:49

Je knipt het belangrijkste deel van de reactie weg en gaat weer door met dezelfde misvatting. Ik geef het op.

Nou nee. Jij herhaalt steeds dat als de ontvanger niet weet welk BEDRIJF bij een getoond afzender-DOMEIN hoort, die ontvanger dan eenvoudig gefopt kan worden. Ja duh...

Mijn punt is: als de ontvanger wel weet welk BEDRIJF bij een afzender-DOMEIN hoort (iets dat simpelweg noodzakelijk is om niet belazerd te worden, zelfs met alle toeters en bellen zoals SPF, DKIM, DMARC, ARC, S/MIME, PGP signatures en whatever), zijn phishingmails met een geldige DKIM signature eenvoudig te maken, terwijl deze geen enkele zekerheid bieden dat het getoonde afzender-DOMEIN daadwerkelijk het verzendende domein is.

Dat is wat ik jou duidelijk probeer te maken: aan alleen DKIM heb je niks. Zonder redelijke tegenreactie geef ook ik het op.

Tja. Elk voordeel heeft zijn nadeel.
Ook ik snap dat de criminelen zullen innoveren. Als dat hetgeen is waardoor je zelf geen verbetering wil doorvoeren, wat betekent dat dan? Ben je dan niet al automatisch slachtoffer van die criminelen?

Ongeopende (encrypted) mail op malware scannen is echt geen bedrijfsgeheim hoor. De scanners kan je gewoon kopen.
De decryptie in die scanstraat plaatsen is slechts een ontwerp dat iedereen kan verzinnen.
Software veilig maken is echt wel te doen. Software veilig implementeren en configureren, dat is ook heel goed te doen.
Al met al is dit probleem best op te lossen.

Dan blijf je nog bij het eerste puntje. Die visioenen van politieagenten. Ik begrijp wel dat je veel mensen dit negatieve visioen hebben. Eigenlijk een discussie tussen de fundamentalisten voor/tegen geheimhouding. Ik heb ook respect voor diegenen die deze discussie voeren. Ik zit hier te pragmatisch in.
Ik snap en erken ook het argument dat de criminelen inderdaad echt wel eigen encryptie hebben of kunnen ontwikkelen. Die pak je niet automatisch met sleutels in escrow. Die gaan om de escrow manieren heen werken.

Maar goed.
Je kent de discussie over verzwakken van encryptie. Daar ben ik tegenstander van. Ik kan dat niet tegenhouden. Ook niet met het argument dat het algoritme dan ook zwakker is voor misbruik door criminelen.
Als ik ergens een alternatief mag aanreiken, dan liever encryptiesleutels in escrow. In ieder geval kan ik dan dezelfde sleutel gebruiken in de verschillende apparaten die ik heb. En de opsporingsdienst kan opsporen. Ik heb dan in ieder geval mezelf tegen criminelen beschermd. Ik heb nu eenmaal meer vertrouwen in de overheid dan in criminelen. Wetende dat niets perfect is.

Overigens bescherm ik ook graag mijn privacy. Dat doe ik zo goed ik kan, maar......
Ook hier. Niets is perfect en mijn leven kunnen leven is belangrijker dan mijn privacy met zekerheid beschermen.

Los van de verdere zijpaden
Met formele ondertekening van emails is heel veel spam, phisinh en malwareinjectie te voorkomen.
Zoals iemand anders zei: "ook dit werkt niet perfect (mailmules)". Op deze manier draai je in ieder geval eerst de kraan dicht en daarna kunnen opsporingsinstanties de nog overblijvende spammers, phishers en malware injectors opsporen.

En toen was er BIMI: zie https://tweakers.net/nieuws/184334/gmail-gaat-bedrijfslogos-bij-geauthenticeerde-mailafzenders-tonen.html en de verduidelijkende bijdrage van LeonM (in https://tweakers.net/nieuws/184334/gmail-gaat-bedrijfslogos-bij-geauthenticeerde-mailafzenders-tonen.html?showReaction=16324990#r_16324990).

Dat zal ongeveer hetzelfde zijn als het 'gouden' vinkje dat GMail een paar jaar geleden geïntroduceerd heeft. Dat was ook voor bedrijven die aan speciale eisen voldeden. DMARC plus een registratie bij GMail. Zo'n bedrijfsloge is natuurlijk een sutk duidelijker dan een vinkje in gele kleur.