gvd? .nl?
verklaar je nader

Gewoon vragen wanneer je gemeente overstapt op de 'berichtenbox' van de overheid. Dan is de communicatie ook beveiligd.

Mijn gemeente is daar ook op aangesloten. Bij de berichtenbox wordt er niets verstuurt en kun je zelf via HTTPS inloggen om bij de brieven van de gemeente te komen.

Omdat misschien 99,9999% van de wereld niet eens weet wat pgp is?

Dus waarom iets duurs neer zetten als niemand het echt gebruikt?

Omdat misschien 99,9999% van de wereld niet eens weet wat pgp is?

Dus waarom iets duurs neer zetten als niemand het echt gebruikt?

De berichtenbox is natuurlijk een onwenselijk, minder veilig, overbodig en omslachtig alternatief voor beveiligde e-mail.


De reden dat niemand dit gebruikt is nu juist dat beleidsmakers bij bedrijven en overheden te dom zijn om het te begrijpen (terwijl het concept zeer simpel is) en het daarom niet aanbieden. En dat zijn nu juist de contacten waarbij beveiligde communicatie belangrijk is. Als zij het zouden aanbieden met een duidelijke handleiding, dan zou ook iedereen het gebruiken. Dus het is niet echt een kip ei verhaal maar meer onkunde. Sterker nog waarschijnlijk gebruiken ze intern al asymmetrische versleuteling zonder dat ze het weten: S/MIME. Alleen werkt dat met certificaten dus de gedachte van TS is helemaal niet gek. Bovendien kost het niets en zelfs als luie ITers voor de gemakkelijkste implementatie kiezen is het een fractie van aanbestedingen die echt nergens op slaan. Alleen al daarom zou dit best als een alternatief aangeboden kunnen worden.

Bovendien is een web of trust veel veiliger dan bv een eenzijdige berichtenbox.

Doe iets goed of doe iets niet. Half werk is ook maar prutswerk.

Erg jammer dat een techniek die ervoor kan zorgen dat miljoenen burgers op een uniforme manier veilig met bedrijven en overheden kunnen communiceren, niet van de grond komt door een gebrek aan inzicht bij enkele leidinggevenden.

Nu moet communicatie met elk bedrijf of overheidsinstelling via een eigen aparte portal. Elke portal betekend apart inloggen, paswoorden onderhouden, en elk hun eigen security flaws en incidenten. Het registreren van een pub key en mailadres door deze bedrijven en overheden zou in een klap een einde kunne maken aan een enorme chaos en berg datalekken. Bovendien blijft ontvangen post daarmee in eigen beheer, zoals dat bij de brieven ook was. Bij berichtenboxen kan een afzenden een bericht terugtrekken en bewijs dan achteraf maar eens dat je dat wel ontvangen hebt. Omgekeerd kunnen ze wel registreren of jij het bericht gelezen hebt en hoe laat op welke datum dat was en vanaf welke lokatie.

Ergens is het onbegrijpelijk: het is 2015, bedrijfsleven en overheid kunnen niets anders roepen dan "digitalisering!", er rijden zelfs al auto's zelfstandig rond, maar we mailen nog steeds op de manier hoe ze dat in de jaren 80 deden...

Een aantal nadelen (deze lijsten zijn niet compleet):

Problemen van PGP/GnuPG:
1) Meestal onzeker dat een public key daadwerkelijk van de aangegeven persoon is. Vaak onveilige uitwisseling van public keys.
2) Geen goed systeem voor revocation.
3) Slechte ondersteuning in Outlook.
4) Deels amateuristische software.
5) Schaalt slecht.
6) De meeste mensen begrijpen er geen snars van waardoor private key niet wordt gebackupped en zoekraakt.
7) Bij kwijtgeraakte private key kun je ontvangen versleutelde mails niet meer decrypten.
8) Private key wordt meestal ontsleuteld op een mogelijk gecompromiteerde PC.
9) Met private key op veilig extern device kan een door jou gesigneerde mail een andere inhoud hebben dan jij ziet.
10) Indien meerdere medewerkers ontvangen versleutelde mail moeten kunnen openen, moet een private key worden gedeeld.
11) Onveilig bij webmail.
12) Voor doorzetters is het relatief eenvoudig om zich voor te doen als iemand anders.
13) Onduidelijk of het e-mail header "Date:" veld wordt meegenomen in de signature (replay attacks).
14) Third party time-stamping van de signature wordt zelden gebruikt.
15) Naast spoofing zijn signature-strip aanvallen mogelijk. Weten ontvangers dat zij alle unsigned mail van jou moeten negeren? Ook als "jij" erbij schrijft dat je tijdelijk problemen hebt met jouw sofware of sleutels?
16) Complexe software waar regelmatig security issues in worden gevonden.
17) Vaak veel te lang ondersteuning voor onveilig verklaarde algoritimes en sleutellengtes.
18) Versleutelde mails kunnen pas op endpoint op malware en/of spam worden gecontroleerd.
19) De meeste mensen kennen de risico's niet waardoor een vals gevoel van veiligheid (authenticiteit, integriteit en vertrouwelijkheid) bestaat.
20) Sommige mailservers wijzigen platte-tekst berichten o.a. door lange regels in te korten of door vooraan regels die met From beginnen een > (groter dan teken) te zetten - waardoor digitale handtekeningen niet meer kloppen (zie ook punt 15).
(21) Als een digitale handtekening aanwezig is, maar niet automatisch wordt gecontroleerd, kan dit een vals gevoel van veiligheid geven. Voorbeeld: onderaan https://lists.gnupg.org/pipermail/gnupg-announce/2015q4/000380.html staat de suggestie dat de digitale handtekening gevonden kan worden in https://lists.gnupg.org/pipermail/attachments/20151010/e192e4e4/attachment.sig - maar die URL werkt niet. Overigens kon ik eerstgenoemde pagina in Firefox ook al niet openen (Error code: ssl_error_no_cypher_overlap) doordat de site, die een HSTS header meestuurt, slechts 3 cipher suites ondersteunt: 2x DHE met zwakke DH sleutels en 3DES (zie https://www.ssllabs.com/ssltest/analyze.html?d=lists.gnupg.org). Dit is een site van mensen die toch beter zouden moeten weten; bij mij wekt dit geen vertrouwen.
22) Omdat het zo lastig is om public keys van vreemden te vinden, bestaan keyservers. De bedoeling is dat je daar keys kunt downloaden waarbij je, "natuurlijk" (helaas doet bijna niemand dat), nog wel moet controleren of zo'n key daadwerkelijk van de persoon is die je bedoelt. Want als je zo'n key via het (ongeauthenticeerde en onversleutelde) hkp protocol ophaalt, kan deze "onderweg" vervalst worden (zie http://seclists.org/oss-sec/2014/q4/285). En, zoals Werner Koch in zijn response daarop schrijft (http://seclists.org/oss-sec/2014/q4/290): "But do not trust any keyserver! Use your own way to validate the key".
Nu liggen MitM attacks niet zo heel erg voor de hand, maar niets belet malloten, geheime diensten of criminelen om gespoofte public keys op jouw naam te publiceren. Dit overkwam in elk geval Jürgen Schmidt, redacteur van het Duitse blad c't, zie http://www.heise.de/ct/ausgabe/2015-6-Gefaelschte-PGP-Keys-im-Umlauf-2549724.html. Hij ontving mails die hij niet kon decrypten - doordat afzenders public keys gebruiken die niet van hem zijn - maar wel op zijn naam staan (de 4 valse sleutels zie je nog steeds bovenaan in https://pgp.mit.edu/pks/lookup?search=ju%40heisec.de&op=index - ook al ben jij de echte Jürgen Schmidt van Heise.de, jij kunt die nepsleutels niet verwijderen).

Problemen van S/MIME:
A) Onduidelijk of een certificaat daadwerkelijk van de aangegeven persoon is. Vaak brakke tot geen identiteitsvalidatie door "trusted third parties" die dat vertrouwen niet waard zijn.
B) Onduidelijk of revocation werkt.
C) Nauwelijks gebruikt door non-Microsoft gebruikers.
D) De meeste mensen begrijpen er geen snars van waardoor private key niet wordt gebackupped en zoekraakt.
E) Private key wordt meestal ontsleuteld op een mogelijk gecompromiteerde PC.
F) Met private key op veilig extern device kan een door jou gesigneerde mail een andere inhoud hebben dan jij ziet.
G) Indien meerdere medewerkers ontvangen versleutelde mail moeten kunnen openen, moet een private key worden gedeeld.
H) Onveilig bij webmail.
I) Vaak relatief korte levensduur van certificaten.
J) Voor doorzetters is het relatief eenvoudig om zich voor te doen als iemand anders.
K) Onduidelijk of het e-mail header "Date:" veld wordt meegenomen in de signature (replay attacks).
L) Third party time-stamping van de signature wordt zelden gebruikt.
M) Naast spoofing zijn signature-strip aanvallen mogelijk. Weten ontvangers dat zij alle unsigned mail van jou moeten negeren? Ook als "jij" erbij schrijft dat je tijdelijk problemen hebt met jouw sofware of sleutels?
N) Complexe software waar regelmatig security issues in worden gevonden.
O) Vaak veel te lang ondersteuning voor onveilig verklaarde algoritimes en sleutellengtes.
P) Versleutelde mails kunnen pas op endpoint op malware en/of spam worden gecontroleerd.
Q) De meeste mensen kennen de risico's niet waardoor een vals gevoel van veiligheid (authenticiteit, integriteit en vertrouwelijkheid) bestaat.

Aanvullingen 16-11-2015, 10:13 beschamende typfout gecorrigeerd (veiligheit - oops). Punten 20 en 21 toegevoegd.
Aanvullingen 19-11-2015, 21:59: punt 22 toegevoegd (over keyservers).

Wat zou je dan wel aanraden? En waarom zou de NSA 'moeite hebben' met PGP?

==== edit: ik vond het ook vreemd dat een (mijn) notaris zich beroept op 'u geeft toch zelf toestemming voor email communicatie met ons kantoor'? I.p.v. wij gebruiken xxxx voor uw privacy bescherming.

@ Erik

Deze lijst met nadelen bevat hoofdzakelijk gebruikersproblemen en implementatieproblemen die wegvallen bij het juist toepassen van de software en bij het juist opbouwen van het web of trust. Het is een solide systeem wat daardoor onvermijdelijk complex is in gebruik. Mallware infecties, het kwijtraken van sleutels of sleutels met een eeuwige geldigheid, etc zijn gebruikersproblemen die elk digitaal apparaat kunnen treffen. Een goede frontend (ontwikkeld door marktleiders) en duidelijke handleiding kan de meeste problemen oplossen. Outlook intergratie en keyservers bestaan al overigens en alles wat overblijft wordt snel opgelost als het grootschalig geaccepteerd zou worden.

Het enige probleem is dat grootschalig gebruik van asymmetrische emailencryptie ervoor kan zorgen dat inlichtingendiensten minder zicht hebben op dreigingen. Ze zouden dan bv alle email moet kraken of op alle endpoints bv hun kostbare zero days toepassen, iets dat op de enorme schaal van email onmogelijk is. Daarom zullen deze diensten het gebruik ervan logischerwijs zoveel mogelijk tegenwerken, in plaats van er juist aan bijdragen.

Echter, daar is een oplossing voor:

Met een aanpassing in PGP zou een bericht met 2 public keys versleuteld kunnen worden waardoor afgetapte e-mail alleen gelezen kan worden door de ontvanger van het bericht en door de houder van de 2e private key, wat een inlichtingendienst kan zijn. Nederlanders kunnen dan de public key van de AIVD toevoegen, Amerikanen die van de NSA, Duitsers die van de BND, etc, etc. Zo kunnen inlichtingendiensten e-mail verkeer van hun eigen bevolking lezen en weet je als burger dat jouw e-mail alleen gelezen kan worden door de inlichtingendienst van jouw land. Bevriende diensten kunnen dan bij elkaar verzoeken indienen voor onversleutelde mails van burgers uit een ander land. Verhuis je naar een ander land, verwijder je de oude key en voeg je de key van een nieuwe inlichtingendienst toe. Mensen die deze key dan bewust niet toevoegen kunnen dan ook betrouwbaarder als verdacht aangemerkt worden.

Op die manier hoeven burgers minimaal aan privacy in te leveren, krijgen criminelen en datagraaiers geen vat meer op communicatie van burgers, kunnen datalekken op grote schaal voorkomen worden en hebben relevante inlichtingendiensten toch een handvat om aan de benodigde informatie te komen.

Tot het zover is blijft het een soort Betamax cassette die bijna niemand kan afspelen.

Voor communicatie tussen overheid en gebruikers: de Berichtenbox?

Je schrijft dat alsof ik stel dat de NSA moeite zou hebben met PGP, maar dat schrijf ik nergens.

Iets duur, zoals een gratis produkt als PGP ? Moet de overheid alleen veilige communicatie bieden, wanneer de wereld weet wat PGP is ?

Op bedrijfsniveau lijkt mij die dubbele sleutel een goed idee. Maar op natie niveau niet. Je zou dit namelijk ook willen doen om criminelen en terroristen te pakken, maar die zullen het systeem met 2 sleutels natuurlijk niet gebruiken. Dan blijft over dat je een overheid creëert als big brother voor email en dat willen we toch niet?
Hoeveel Betamax graaiers zijn er zoals Google? Ik dacht dat het merendeel van de dreigingen daar niet vanaf komt.

Hoezo deze vraag, is de NSA de enige bedreiging voor je privacy wereldwijd ofzo ? Alles wat de NSA kan kraken, dat is irrelevant ? Of moet je ook nadenken over de vraag wat nou eigenlijk de dreigingen zijn, en bijbehorende actoren, waartegen je je wilt beschermen ? Moet je maatregelen nemen die criminelen buiten de deur houden, indien diezelfde maatregelen niet effectief zullen zijn tegen de NSA ?

@ Erik

Je hebt gelijk dat we hiermee gedeeltelijk een big brother gaan tolereren. Maar doen we dat nu niet ook al door alles in plain text te mailen? Zonder medewerking van inlichtingendiensten kunnen we een grootschalige implementatie van PGP wel vergeten omdat bedrijven die dit op eigen houtje gaan aanbieden een vloedgolf aan geavanceerde cyberaanvallen over zich afroepen waardoor niemand durft. Door bepaalde diensten met een sleutel toegang te geven tot onze communicatie is het overbodig om in te breken (en dus ook de deur open te zetten voor kwaadwillende derden) en het is overbodig om achterdeurtjes in versleuteling in te bouwen (welke uiteindelijk ook door derden gevonden worden).

Uiteraard zullen kwaadwillende doelwitten van inlichtingendiensten deze sleutel niet gebruiken, maar daarmee vallen ze erg op tussen de massa en kunnen deze diensten besluiten alles uit de kast te halen om om deze specifieke versleuteling heen te werken of hun brute force resources efficiënter inzetten. In de huidige situatie met PGP is er voor hen namelijk het risico dat ze veel tijd en energie verspillen aan versleutelde berichten welke achteraf niets blijken voor te stellen. Een loose-loose situatie dus.

Voor burgers is er het voordeel dat commerciele data graaiers buitenspel gezet kunnen worden (Betamax app voor Google gebruiken ipv hun webmail), alleen de broodnodige diensten bij hun data kunnen en dat ze altijd een keuze hebben tot opt out. Dit laatste is belangrijk indien een democratie omklapt naar een dictatuur waarbij de overheidsdiensten misbruikt worden om mensen te onderdrukken.

Dus ergens toch een win-win situatie. Als dit bij email succesvol blijkt kan men ook aan een implementatie van bv Whatsapp gaan denken. Het lijkt me in elk geval beter dan de huidige situatie waarbij men niet verder komt als achterdeurtjes en decryptiebevelen. Alleen als we blijven treuzelen tot elke kwaadwillende beschikt over onuitputtelijke rekenkracht dan heeft het weinig zin en blijven we waarschijnlijk in de situatie hangen waar we in de jaren 80 mee begonnen.

Mailservers kunnen ook gewoon over ssl babbelen. Dan heb je netjes een versleutelde verbinding maar zowel de ontvanger als verzender moeten dan een Certificaat geinstalleerd hebben en goed voor ssl geconfigureerd zijn.

Het wordt tijd dat dit opgenomen gaat worden in de email specificaties als een verplichting, dat zijn we al weer een stap verder. Moeilijk doen met pgp lijkt me niet echt een optie, zeker niet voor de gemiddelde gebruiker.

Overigens als mailservers over ssl babbelen moeten de clients dat uiteraard ook doen, dus geen onbeveiligde pop verbinden e.d. meer.

Foutje bedankt; de post van 13:48 moet gericht zijn aan Dick5*9...

Maar het doet natuurlijk niet af aan het idee; een acceptabel compromis voor zowel onschuldige burgers als hongerige inlichtingendiensten. Blijf je als een van deze diensten je kop in het zand steken, heb je kans dat een soort versleuteling waar je geen grip op hebt, straks toch doorbreekt. En als je als bezorgde burger niet een beetje water bij de wijn wil doen loop je het risico dat goede versleuteling onbereikbaar blijft waardoor je risico loopt op veel meer dan een vorm vrijwillige massasurveilance door je eigen veiligheidsdiensten.

Om terug te komen op het onderwerp van de topicstarter: niet moeilijk doen en verzoeken om gevoelige stukken per post af te handelen en als men gevoelige informatie toch blijven mailen, ze op alle risico's wijzen en aangeven dat zij aansprakelijk zijn voor alle schade en leed dat hierdoor veroorzaakt kan worden.

Inderdaad SSL/TLS maakt het weer een stukje veiliger en ik begrijp dat Google dat gebruik bij email ook stimuleert. Maar PGP gaat verder en verzorgt persoon tot persoon (end-to-end) encryptie. Ik heb dat vaak nodig bij vertrouwelijke documenten.
Zelf gebruik ik 7ZIP archieven met een wachtzin van 5 willekeurige woorden. Die zijn gemakkelijk mondeling over te brengen. Het lezen uit het archief werkt gewoon onder de file verkenner van windows 8+. Enige nadeel dat ik zie, is dat ik 7ZIP nog niet genoemd heb zien worden in NSA documenten. Maar van de 3-poot: algoritme, sleutel, implementatie is bij 7ZIP alleen de laatste voor mij een mogelijk zwak punt.

PS. mijn eerdere post die NSA noemt was iets te cryptisch, voor de discussie hier had het weggelaten kunnen worden.

Je kunt niet afdwingen dat degene waarmee je communiceert een door jouw gekozen en door de andere partij niet
gewenste methode van communicatie gebruikt. Je gaat het niet voor elkaar krijgen dat de andere partij PGP gaat
installeren en beheren omdat jij dat toevallig wilt. Of de andere partij een rechtbank is maakt niet uit.
Je had nog een punt gehad als je gezegd had "ik wil een veiliger methode gebruiken" en dan bijvoorbeeld een aanbod om die
berichtenbox te gebruiken geaccepteerd had, maar door ze PGP op te dringen heb je jezelf buitenspel gezet.

Zorg dat je dan in elk geval "AES-256" versleuteling gebruikt i.p.v. "ZipCrypto" want die laatste is lek.

Echter, over de AES-256 versleuteling van 7Zip heb ik ook zorgen:
- Je kunt (per ongeluk) bestanden onversleuteld toevoegen aan een ZIP file die 1 of meer versleutelde bestanden bevat
- Hetzelfde wachtwoord geldt voor elk van de versleutelde bestanden
- Bestandsnamen worden niet versleuteld wat, in combinatie met het vorige punt, het risico op known-plain-text-attacks vergroot, met name als te versleutelen bestanden niet worden voorafgegaan door random padding met een random lengte (of dat laatste zo is, weet ik niet).
- Voor zover ik weet is er nooit een serieuze code-review van de crypto code van 7Zip uitgevoerd en gepubliceerd
- Bij 7z versleutelde bestanden kun je ook bestandsnamen versleutelen, maar bij een korte blik op de sourcecode leek het daarbij eerder om obfuscatie dan versleutelen te gaan (ik kan dit laatste echter best fout hebben).

Globaal mee eens, maar de lijst is al heel wat korter dan bij PGP
:-)
De code review is 1 reden dat ik implementatie noemde als mogelijk zwak punt. Andere reden is dat de hash code van de binaries niet gepubliceerd wordt.
De punten 'Onversleuteld' en 'het zelfde wachtwoord' zijn goed om te weten maar zijn zo goed als geen punt van aandacht als je het als puur verzendmechanisme gebruikt, dus niet als archief van allerlei na te voegen en bij te werken files.
Bij AES mag je toch wel wat plain text kennen? Misschien niet als er nog eens een AES zwakheid gevonden wordt. Je zou ZIP in ZIP kunnen doen om de file namen te encrypten.

Nu het toch over details gaat, ik vind jouw oorspronkelijke punt 18 dat ook voor ZIP geldt, "Versleutelde mails kunnen pas op endpoint op malware en/of spam worden gecontroleerd" juist een sterk punt. De IT afdeling moet de endpoints dan goed veilig uitrusten en dat betekent dat reizigers onderweg en thuiswerkers ook goed bediend worden.

We kunnen natuurlijk kort en lang discussiëren over veilige communicatie met de overheid, maar zolang Henk en Ingrid niet begrijpen hoe het werkt zal elk implementatie traject als een loden ballon doodvallen. De enige oplossing is de ouderwetsche brief met postzegel (en bijkomend briefgeheim).

Volgens mij begrijp je het niet zo goed. De helft die wel PGP kennen hebben het ook geleerd. Overigens gaat ons belastinggeld ook naar bullshit op dus dan mogen ze wel een keer een lesje Veiligheid en encryptie geven!

Het valt me wel op dat de crime inlichtingen diensten wel gebruik maakt van PGP waarom niet lokale bureaus en rechtbanken?

Als jouw Henk en Ingrid maatgevend worden als basis voor begrip hebben we een veel breder probleem.
Fictieve Henk en Ingrid begrijpen namelijk wel meer niet en mogen desondanks zonder ook maar enige vorm van begeleiding met de vingertjes aan allerlei rode knopjes zitten.

Klopt helemaal... Maar toen de belastingdienst onlangs aankondigde dat de blauwe envelop zou verdwijnen was de website te klein om alle commentaren op te vangen van mensen die zich afvroegen hoe Opa Henk en Oma Ingrid nu hun belastingen zouden moeten doen?!?

Met andere woorden: als de belastingdienst van brief naar beveiligde berichtenbox wil dan is dat fout, maar als een rechtbank niet met PGP mailt dan is dat ook fout?

M.b.t. 7-Zip:
Ik wil hier graag op reageren maar ik heb het momenteel erg druk, deze hou je van me tegoed - in een andere thread. Want hoewel je met de rechtbank/gemeente een shared wachwoord zou kunnen afspreken en met 7-Zip versleutelde bijlagen zou kunnen uitwisselen, ligt dat niet zo voor de hand.

Dat is wishfull thinking. Bijv. Kaspersky Mail Anti-Virus kan de extensies van bestandsnamen van potentieel gevaarlijke bijlagen hernoemen om te voorkomen dat ontvangers in bijlagen met bestandsnamen trappen als:
of
waarbij natuurlijk een Adobe PDF icoontje getoond wordt.

Voorbeeld: als je Kaspersky antivirus gebruikt, zou je de Outlook plugin van Mail Anti-Virus op clients kunnen aanzetten. Helaas wordt werken met e-mail dan vreselijk traag (openen van e-mails duurt minstens 5 seconden en vaak veel meer, en bij ontvangen van mail lijkt Outlook enkele seconden te bevriezen). Alleen met ingeschakelde Outlook plugin kan Kaspersky de extensie van bovengenoemde bijlagen in Outlook wijzigen (in bijv. _scr) waardoor deze niet meer uitvoerbaar zijn. Dit lijkt een prima compromis om de beveiliging op endpoints te vergroten, met als prijs wat langer wachten.

Maar helaas: deze virusscanner is niet in staat om, in het geval van een bestand met een bovengenoemde naam+extensie - als bijlage bij een mail opgenomen in bijv. een met ZipEncrypt versleutelde "factuur.zip", te voorkomen dat een gebruiker dat het .scr bestand kan uitvoeren (de gebruiker moet daarbij wel enkele Windows waarschuwingen in de wind slaan, maar die zijn te cryptisch voor veel gebruikers). Daarmee lijk deze Outlook plugin zinloos bij versleutelde mail. Het zou mij niet verbazen als dit ook voor andere anti-virus oplossingen geldt, maar daar heb ik geen recente ervaringen mee.

Goede spam/AV oplossingen op mailservers checken overigens wel bestandsnaam-extensies in versleutelde zipfiles (bestandsnamen zijn niet versleuteld in .zip) en kunnen zo mails met malware blokkeren of in quarantaine zetten (een jaar of 12 geleden werden er malwaremails gespammed met een versleutelde zip-bijlage en het wachtwoord in een plaatje in de body van de mail; al snel wisten goede spamfilters dit soort mails te herkennen - niet door OCR, maar door naar bestandsnamen en evt. CRC's van bekende malwarefiles te kijken).

Je valt dan terug op file antivirus. Detectie van verse malware door virusscanners is ronduit slecht. Bovendien, als een gebruiker, na enkele dagen z'n PC niet te hebben gebruikt, de PC aanzet en mail gaat lezen, is de virusscanner op dat moment vaak nog niet bijgewerkt met de laatste definities.

Een server die 24x7 aanstaat zal over het algemeen wel actuele virusdefinities gebruiken, en het is verstandig om hier een ander merk scanner te gebruiken dan op de endpoints; de detectiekans van malware neemt daardoor toe. Ook op de server kun je natuurlijk al potentieel kwaadaardige bijlagen blokkeren en hernoemen, zodat je bijv. die zenuwslopende Kaspersky Outlook plugin niet hoeft aan te zetten op clients.

Of het Kaspersky endpoint spamfilter zijn werk doet op het moment dat de body van een e-mail is ontsleuteld (bijv. waarschuwen bij herkende spam met daarin bijv. links naar phishing en/of kwaadaardige websites), vraag ik mij af - ik heb dit niet getest. Spamfilters op mailservers zijn vaak zeer goed in staat om spam, content-based, te herkennen en eruit te vissen. Enige vertaging bij ontvangst door een server is natuurlijk minder hinderlijk dan dat je bij het openen van elke mail in je MUA moet wachten op een spam-check (bovendien staat die spam dan al in jouw inbox).

Kortom, versleuteling maakt detectie van malware en phishing lastiger. Het uitsluitend checken op de client betekent dat je dat op minder plaatsen, en vooral minder effectief (blokkeren/hernoemen van potentieel kwaadaardige extensies) kunt doen dan bij onversleutelde mail. Een redelijk betrouwbare (up-to-date) endpoint check is bij reizigers, en zeker bij thuiswerkers met eigen PC, lastiger af te dwingen dan bij gebruikers op werkplekken binnen een bedrijf. En: zodra versleutelde mail meer gemeengoed wordt, zullen spammers en andere cybercriminelen hier bovenop springen en zal het aantal slachtoffers toenemen.

Het endpoint probleem is inderdaad een probleem, maar goed als je dit als beheerder afschrikt, dan zou ik maar vast in huilen uitbarsten voor als IPv6 met IOT gemeengoed wordt. Dan heb je nog een vele grotere nachtmerrie.

Het antivirus endpoint update probleem: stel je AV pakket zo in dat de firewall van de machine (of de proxy server in je netwerk) alle overige verkeer voor die machine zal blokkeren totdat de endpoint AV ge-update is. Of maak gebruik van terminals en virtuele werkplekken, dan is je 'client' altijd up to date.

Het probleem met spammers is juist een oplossing: zij moeten nu niet alleen je mailadres weten (wat ze nu in bulk uitproberen) maar ook je public key om je een leesbaar mailtje te sturen. Die key heeft als het goed is alleen jouw web of trust in bezit. Alleen mensen die jou of je werknemers kennen kunnen dus succesvol spammen.

Er bestaan trouwens Exchange alternatieven voor Linux; dan zou je met een beetje handigheid PGP zelfs transparant kunnen maken naar je users.

Klinkt leuk, maar als je wel eens presentaties buiten je pand met jouw laptop gegeven hebt, weet je dat dit ongewenste maatregelen zijn.

En voor de oorspronkelijke doelgroep (thuisgebruikers die vertrouwelijke informatie via e-mail met gemeente/rechtbank willen uitwisselen) helemaal niet realistisch.

Overigens ben ik niet "tegen" versleutelde en/of ondertekende mail, maar denk dat invoering ervan voor "Jan met de pet" niet realistisch is.

Tot nu toe is het gebruikelijk om public keys op keyservers te publiceren (het is de vraag of keyservers een goed idee zijn, zie mijn bijdrage van 15-11-2015, 11:59, punt 22 - toegevoegd 19-11-2015, 21:59). Ook worden public keys vaak op de website van de betreffende gebruiker gepubliceerd. Ik begrijp dat jij beiden afraadt?

Je kunt, als organisatie, inderdaad alle uitgaande mail ondertekenen met een organisatie-brede digitale handtekening. En versleutelde mail van derden (die de organisatie-brede public key gebruiken) ontvangen en centraal decrypten. Echter, als zo'n "Exchange alternatief" niet over de public key van de bedoelde ontvanger beschikt (d.w.z. een public key die met zekerheid van een specifiek persoon of andere organisatie is) kan uitgaande mail niet worden versleuteld, en kan de handtekening van inkomende mail niet worden gecontroleerd. Het is dus zeker geen oplossing voor e-mail-communicatie tussen burgers en rechtbanken/gemeentes.