Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Bedrijven en Nederlandse overheid starten 'coalitie voor veilig e-mailen'

Door , 87 reacties

Een groot aantal overheidsinstellingen en bedrijven in Nederland gaan samenwerken voor veilige e-mail. De coalitie gaat het gebruik van veilige standaarden afspreken, met als doel om zaken zoals phishing en het onderscheppen van mail te voorkomen.

De organisatie wordt de Veilige E-Mail Coalitie genoemd, en is opgericht met ondersteuning van het Ministerie van Economische Zaken, zo wordt gemeld op de overheidswebsite Forum Standaardisatie. Een groot aantal organisaties heeft zich aangesloten bij de coalitie, te weten: PostNL, KPN, Betaalvereniging Nederland, DDMA, Thuiswinkel.org, VNO-NCW, MKB-Nederland, Stichting Zeker-OnLine, Dutch Datacenter Association, Stichting DINL, Xs4all, Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (Rijks-CIO), Fraudehelpdesk, Nederland ICT en de Belastingdienst. Het is overigens mogelijk voor andere partijen om zich bij het verbond aan te sluiten.

Volgens de Veilige E-Mail Coalitie gaan de organisaties gezamenlijk bepalen welke beveiligingsstandaarden nodig zijn voor veilig e-mailverkeer. Dit moet voorkomen dat er gevoelige informatie wordt gestolen door middel van phishing, of dat e-mailverkeer wordt onderschept. Er zal onderling kennis worden gedeeld, maar de organisatie meldt niet met welke technieken zij voor betere beveiliging gaan zorgen.

Vorig jaar kwam het Nationaal Beraad met het besluit dat overheidsinstellingen de standaarden dane en starttls moeten toepassen in hun e-mailapplicaties. Destijds had slechts een klein deel van de overheids-e-mailservers ondersteuning voor beide beveiligingsstandaarden. Het belang van het invoeren van dergelijke beveiliging voor e-mail wordt ingegeven door de toename van hacks op overheidssystemen en de gevoelige inhoud die overheidsmail kan bevatten.

Reacties (87)

Wijzig sortering
DKIM, SPF & DMARC?...
Een quickscan en een scorecard van deze technieken door verschillende domeinen kun je opvragen op de volgende website:
https://www.phishingscorecard.com/

Kijk maar eens op die website bij overheidsdomeinen en ziekenhuisdomeinen hoe weinig deze technieken helaas nog worden toegepast.

Als je gebruik gaat maken van DKIM, SPF & Dmarc moet je deze wel regelmatig monitoren, hiervoor gebruik ik dmarcian
Mochten er nog mensen vragen en of opmerkingen met betrekking tot dmarcian of de Phishing Scorecard, Dan hoor ik het graag :)
Een opmerking: SPF check lijkt niet corredct te werken; SPF voor een domein wordt door b.v. kitterman, mxtoolbox, Google & EOP (Microsoft) als valide afgehandeld, maar geeft een rood kruis in Phising Scorecard.
Wij zitten achter een Barracuda, zodoende lijkt dit mij veilig genoeg.

Of niet?
Ben wel benieuwd waarom je linkt naar een commerciele site, terwijl er al een zeer uitgebreide en goede nederlandse officiele site is: https://internet.nl
Een veel eenvoudigere methode om je e-mail te testen is via de mail-tester. Stuur simpelweg een mailtje naar het opgegeven e-mailadres en hij laat exact zien wat er allemaal mis is met de afzender daarvan. Dan hoef je ook niet handmatig te gaan zoeken naar je DKIM code.
DKIM:

Doet niks op het gebied van phising maar alleen garanderen dat het bericht in transit niet is aangepast tussen de 2 servers en in de praktijk zit daar vaak ook nog een hop extra voor of achter waardoor ook daar mitm mogelijk is

SPF:

Goed protocol alleen bescherm het alleen de envelop from en niet de header from.
Spoofing en phising zijn dus gewoon mogelijk

DMARC:
Dit is de grootste blunder van allemaal. Dit kost nederlandse bedrijven veel geld om in te richten omdat bijvoorbeeld de nederlandse bank dit verplicht. Maar ook dit protocol voegt 0 toe omdat het alleen maar rapportage doet en een policy afdwingt die al in het SPF of DKIM uitgevoerd worden. Ook dit protocol diet niks met header from waardoor phising nog steeds makkelijk mogelijk is.

Als we veilige email willen moet er een nieuwe standard komen want het enige wat momelteel veilig is zijn smime en PGP maar daar snapt Jan modal niks van.
Inderdaad zijn er zat veilige verificatie methodes voor email afkomst. Door deze allen te ondersteunen en mail te versturen via tls is het voor een mail applicatie gewoon heel duidelijk dat de mail legitiem is.

Mail applicaties moeten gewoon duidelijker laten zien dat de mail versleuteld is verstuurd en of het mail adres niet gespoofed is. Vergelijkbaar met hoe het wordt getoond in de url balk van een browser.
Ik kijk in mijn spamfolder en zie bv:
From: "Amazon.de" <supporthilfe923@baubetreuung-moench.de>
Subject: Kundenschutz - Information Ihres Kundenkontos
Spamassassing weet het volgende vertellen:
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low
trust
Maar ze gebruiken verificatie methodes, het bericht zelf moet wel legitiem zijn.....

Vertrouwen op DKIM/DMARC/SPF/whatever is volledige onzinnig, het gaat voorbij aan fenomeen dat gebruikers misbruikt kunnen worden, in bovenstaande geval staat er wellicht ergens een pc mail te versturen die onderdeel van een bot net is of zijn er asmtp credentials gelekt, of een webform dat lek is, of .....

De inhoud is een image in de correcte opmaak van amazon.de met een link naar gehackte URL, die verder dus ook volledig valide is (en kan zijn voorzien van https), maar duidelijk niet amazon gerelateerd is.
Het gaat hem juist er om dat als er no-reply@overheid.nl staat dat je zeker weet dat de mail van overheid.nl is.

Als een phisher roverheid.nl registreerd en hiermee phishing mails verstuurd dan is het inderdaad mogelijk dat het niet als spam wordt gezien, het is dan aan de gebruiker om naar het mail adres te kijken, deze moet dan ook duidelijk zichtbaar zijn met bijvoorbeeld een indicator als deze gespoofed lijkt te zijn.

Als de smtp server login uitlekt of wordt gehacked is het een grove fout dit is even erg of zelfs erger als het lekken van een ftp login.

En als er door een fout in een formulier een mail verstuurd kan worden naar een willekeurige mailadres dan is er ook behoorlijk wat mis...

[Reactie gewijzigd door seapip op 2 februari 2017 20:09]

Zulke mails kom ik ook tegen maar dan gewoon in m'n Spamfilter zoals het hoort. Als ik het IP dan natrek zie ik vaak dat het een IP is dat gelinkt is aan een partij die aan VPS verhuur doet in Oekraïne of Roemenië. Vervolgens gaat het van 1 IP over op het volgende IP, ook met loginpogingen. Ze huren dus vaak een hele bups aan IP's of VPS servers. Daar kun je amper tegenop met blacklists. Domeinregistraties zijn ook geautomatiseerd. Dan is het inderdaad van belang dat het herkenbaar kan worden dat een mail van roverheid.nl dus niet gelijk is aan een mail van overheid.nl. Dat kun je doen voor grotere partijen die te verifiëren zijn maar dat is niet te doen voor kleinere partijen. Dan komt het certificaat om de hoek kijken om mails te ondertekenen, maar daar is zover ik weet helaas nog geen letsencrypt variant van en het bijbehorende bedrag betalen is voor consumenten sowieso een grens en voor bedrijven loopt het snel op voor iets dat niet verplicht is helaas.
Ik zie in mijn Thunderbird de controle van de DKIM.
Die wordt door de plug-in gecheckt en wat er verder in de header staat doet er niet toe.
Het is bijzonder jammer dat niet alle email clients een controle header hebben, zoals het slotje in de browser.
Dat er bijna geen ontwikkeling is op dat gebied.

Heb ook getest met digitaal ondertekenen met een certificaat, maar dat kan ik aan een gewone buurman niet uitleggen, hoe je daar mee om moet gaan.
Ik heb dan zelf een gratis certificaat waarvan alleen de email gecheckt is.
Het systeem geeft het niet aan, hoe zwaar het certificaat is.
Dit systeem kan ook wel een Forse verbetering ondergaan.

Misbruik is overmacht, dat kan ook met een beveiligde website gebeuren.
Mensen die hun wachtwoord op de monitor plakken kom je overal tegen.

Als email clients en providers niet actief beveiligingen in gaan bouwen haal je de fouten er ook nooit uit. Maar op dit moment gebeurt er veel te weinig.

Van de overheid moet je het ook niet hebben.
Die geven op alle fronten het verkeerde voorbeeld.
Zo erger ik me b.v dat de website overheid.nl een simpel certificaat heeft zonder naam naast het slotje. Alleen een slotje zegt namelijk niets.
Is mailen met IPv6 eigenlijk veiliger dan IPv4 ?

[Reactie gewijzigd door walkstyle op 2 februari 2017 19:04]

Nee, het gebruikt enkel een andere manier van adressering van de servers. De daadwerkelijke mail gaat nog steeds op dezelfde manier over het internet.
Er is wel degelijk een verschil tussen IPv4 en IPv6 en encryptie. Zie bijvoorbeeld http://www.cu.ipv6tf.org/pdf/ipv6_ssl.pdf
Ha, geweldig om een 20 jaar oud document te lezen over ipv6 en te zien dat het volledig achtehaalt is.

Alhoewel de opname van beveiliging in het protocol een pre kan zijn is het duidelijk dat de voorgestelde ciphers nu volledig achterhaalt en onveilig zijn. Een star gedefineert protocol is inherent onveilg maakt op lange termijn (doc geeft overigens aan de er op het moment van schrijven nog geen key exchange mechanisme was afgesproken en dus alle encryptie toepassingen lastig te verifieeeren zijn), gelukkig staat de IPv6 implementatie nog altijd in de kinderschoenen (tot vreugde van per mensen die nu nog een leuke hoeveelheid ipv4 adressen in beheer hebben: $$$).

De introductie van VPN (in al zijn vormen) biedt een gedeelte van beveiliging en de oa SSL RFCs zijn intussen ook geupdate en voldoen voor de meeste toepassingen prima, maar zijn helaas net als IPv6 nog steeds geen gemeengoed in vele gevallen (bv DNSSEC/DANE zou wonderen doen)
Dat is een document uit 1997, neem aan dat dat niet meer courant is. En elk goed cryptosysteem heeft pluggable cyphers zodat je gewoon kan overschakelen als er een onveilig wordt. Inderdaad geldt dat voor alle cyphers en hashes uit dat document :)
IPv6 had mandatory IPSEC.
IPSEC zelf heeft upgrades ondergaan vwb. de geaccepteerde MAC's en Encrypties. Daarnaast is IPSEC protocol (UDP, SCTP, TCP, GRE...) agnostisch dus alle aspecten van het gebruikte protocol blijven in tact, dat is bij SSL (alleen voor TCP) niet het geval.

IPSEC (Tunnel Mode) = VPN....
IPSEC is de kinderschoenen al ontgroeid, alleen de NL / EU ISP's (op een enkeling na) proberen uit alle macht om nog klein te blijven...
Ik geef je een +1 omdat je wel een vrij pijnlijk punt aansnijdt omtrent IPv6. Men heeft ooit bedacht om encryptie in het protocol te verwerken; maar de daadwerkelijke uitvoering is optioneel, waardoor het uiteindelijk waardeloos is geworden.

E-mail versturen blijft in alle gevallen lastig. IPv4 omdat er vaak per provider een blokkade wordt ingesteld (denk aan hostingboeren, bepaalde ranges van consumentenlijnen, etc.), IPv6 omdat "bijzondere" eisen worden gesteld door de ontvangende partij. Google is hierin erg, eh, restrictief (zie ook orbit_ph op 2017-02-02 19:55) en het in één keer 'juist' doen is vrij lastig.

Dus nee, met IPv6 e-mailen is niet veiliger ten opzichte van IPv4. Nog even los van de hoeveelheid mailservers die überhaupt op IPv6 bereikbaar zijn...
Je kunt klikken op het gedeelte dat je quote en dus ook de link kopiëren: orbit_ph in 'nieuws: Bedrijven en Nederlandse overheid starten 'coalitie voor...
Nee dat maakt als het goed is in de praktijk geen verschil. Het wordt alleen minder gebruikt.

Hou er rekening mee dat zelf mail versturen met een eigen server al snel kan worden gezien als spam omdat het IP adres dan nog nieuw is voor de email diensten en deze dus minder kunnen inschatten of het spam is omdat er nog geen eerdere informatie beschikbaar is over eerdere mail van het IP adres.

[Reactie gewijzigd door seapip op 2 februari 2017 19:30]

Dat geldt in de praktijk alleen als je bulk verstuurt ;) 100 mails per dag bijvoorbeeld heeft amper invloed.
Als je geen authenticatie toepast, DMARC+DKIM dan loop je bij Google al een risico.

Deze hebben het specifiek als requirement in de Postmaster Guidelines staan.
https://support.google.com/a/answer/81126?hl=en

Verder als techniek maakt het protocol wat je gebruikt voor het transport van de mail niet uit.
DMARC is niet een opzichzelfstaand techniek. Het vormt een extra beschermlaag met behulp van DKIM+SPF. Dus als je DMARC compatibel bent, heb je reeds DKIM en SPF.

Het is niet zozeer dat DMARC aangeraden wordt, het gaat erom dat er alignment is met het Envelope sender domein, d= domein en het From header domein.
De spammers zijn de eerste die dat soort technieken implementeren en vervolgens met typosquatting, toevoegen van leestekens en IDN gelijkenissen de slachtoffers alsnog weten te strikken.
En daarom is een technische oplossing niet de juiste.

Het best werkt een emailsysteem waarbij per email gewoon van een digitale postzegel voorzien moet worden, die écht geld kost. Bijvoorbeeld één cent per verzonden email. Dat haalt het hele economische model van spam en phishing onderuit, want miljoenen mails versturen kost dan serieus geld.

En ook op zakelijk nivo zou het helpen tegen de "email-als-chatbox met reply to all" vergezeld gaat van een rekening. Door de kosten relatief laag te houden is een gerichte marketing actie naar een paar duizend 'bekende contacten' nog steeds in een marketing budget te passen terwijl ongelimiteerd spammen gewoon de hoofdprijs kost.

Tussenliggende email servers kunnen uit de opbrengsten weer (fractioneel) betaald worden om de benodigde infrastructuur op te tuigen.
Tijd voor een goude ouwe uit de jaren 90 :)

Your post advocates a

( ) technical ( ) legislative (X) market-based ( ) vigilante

approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)

( ) Spammers can easily use it to harvest email addresses
(X) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
(X) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
(X) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business

Specifically, your plan fails to account for

( ) Laws expressly prohibiting it
(X) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
(X) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
(X) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
(X) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook

and the following philosophical objections may also apply:

(X) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
(X) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
(X) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough

Furthermore, this is what I think about you:

(X) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!
Voorstel PostNL: Print uit, stop in verzegelde enveloppe en stuur via PostNL.
Dan moet die wel erg goed dichtgeplakt zitten anders kan die toch nog onderschept worden ;-)
Dat in combinatie met SSL/TLS met de juiste ciphers. Eventueel nog S/MIME of PGP.
Hier nog een leuke en zéér simpele tool om de kwaliteit van je uitgaande e-mail te checken:
https://www.mail-tester.com/
Nee S/MIME. Mail alleen leesbaar voor zender en ontvanger.

DKIM en SPF zijn halve wassen neuzen.
Door S/MIME zal een spammer eerst kennis moeten maken met ALz'n afnemers door een uitwisseling van mail die alleen signed voor uitwisseling van adressen.

Anonieme BULK mail as we know it kan niet meer, maar dat zal gevolgen hebben voor nieuwsbrieven etc.
(Of een organisatie moet die per stuk aan anfnemers verzenden)....
Ik heb al een tijdje een DKIM plugin voor Thunderbird.
Echter bij veel (nieuws)brieven is het nog steeds wazig, omdat die door derden verstuurt worden.
Dan is de DKIM ook van de derde.
Dan heb je nog instanties waarvan bij iedere mail de DKIM helemaal niet deugd.
Degene die me in bijzonder opvalt is de nieuwsbrief van de NS.
In mijn beleving gaat het allemaal veel te traag. Er gaan jaren voorbij, zonder noemenswaardige verbeteringen.
Klopt. Het nare is dat DKIM de return-path authenticeert. Dit is de afzender in het "MAIL FROM" SMTP commando. Elke MUI laat echter de afzender die vermeld wordt in de "From" header zien indien die aanwezig is. Daardoor mist het zijn doel volledig. Als ik een domeinnaam heb met DKIM-sleutel die ik zelf heb en niet gebruik, en een SPF-header -all, en de DMARC policy op reject zet, dan nog kan een derde partij mail sturen die van mijn domein afkomstig lijkt te zijn en die niet als gespoofd wordt aangemerkt, maar juist als geauthenticeerd, alleen maar omdat de return-path, die niet aan de gebruiker getoond wordt, niet van mijn domeinnaam is.

Er is bij dergelijke technieken veel te veel rekening gehouden met bestaande infrastructuur zoals nieuwsbrieven en mailinglijsten. Een goede authenticatie zou zich richten op hoe de gebruiker het ervaart, niet hoe het technisch in elkaar steekt.
Dat klopt toch niet helemaal? De e-mail wordt normaal getekend met de sleutel in de DNS-record. Het komt erop neer dat de spammer/hacker controle zou moeten hebben over jouw DNS-server.
Nee hoor, dat hoeft niet. Ten minste, als netjes een eigen return-path opgeven die in hun eigen beheer is, en ze van dat domein wel de DKIM-sleutel hebben.

Ik heb hier meerdere nieuwsbrieven in mijn Thunderbird die als DKIM gevalideerd worden waarbij de DKIM signature gevalideerd is met een ander domein dan wat er als afzender verschijnt, namelijk de return-path.
Als dat bedrijf de sender heeft staan in de DNS-record (als geverifieerde domeinnaam), dan kan dat toch gewoon?... Dit doen we op de zaak ook met zaken die verzonden worden door derden, zoals YMLP bijvoorbeeld. Kan je mij eens een concreet voorbeeld geven? Bedoel je trouwens met return-path de recursive DNS?
Zoals hierboven al aangegeven. DKIM is onafhankelijk van zowel het Envelope sender domein (5322.from) als het From header domein.

Voor DKIM gebruik je het 'd=' domein, het signature domein. Dat staat compleet los van alle andere headers
Complete nonsens dus. Dat is wat ik bedoelde te zeggen: voor wie is dit nu ontworpen? Die mogelijkheid zou er niet eens moeten zijn. Waarom moet DMARC daaraan te pas komen?

DKIM zou niet onafhankelijk moeten zijn. DKIM-validate zou per definitie moeten falen als ofwel het envelope sender domain als de From header domein niet overeen komen.


In mijn zoektocht naar de bronnen (tijdje geleden dat ik me hierin verdiept had), vond ik het volgende juweeltje ook nog:
Date: Thu, 8 Aug 2013 21:44:28 -0700 (PDT)
From: Barack Obama <barack@whitehouse.gov>
From: Random Spammer <rndmspmr_098435@yahoo.com>
Reply-To: Random Spammer <rndmspmr_098435@yahoo.com>
Subject: Awarded a Pulizer for "DKIM is Harmful"
To: "Joseph Shmoe" <joe.shmoe@gmail.com>
Bron: http://www.zdnet.com/arti...ss-or-just-disappointing/


Ik heb het zelf niet geprobeerd overigens, maar ze beweren daar dat je meerdere From-headers kan doorgeven, en aangezien er ten minsten eentje overeenkomt en de From-header ondertekend is (wat dus alleen aangeeft dat de signature de integriteit van het veld bevestigd, niet dat de From-header daadwerkelijk hoort bij de afzender), er geen alarmbellen afgaan, terwijl je mailclient waarschijnlijk alleen de eerste afzender laat zien. Mogelijk is het FUD, maar gebaseerd op mijn ervaring met dergelijke maatregelen zou het me absoluut niet verbazen als het echt zo werkt...
DKIM icm DMARC zit op de RFC 5322.from, SPF zit op de RFC 5321.MailFrom.

DMARC leunt op een SPF of DKIM pass om te valideren, alleen als beide technieken een fail produceren faalt DMARC.

Alleen als de 3e partij jou private DKIM key gebruikt voor signing komt deze door de DMARC validatie.

DMARC zit altijd op het zichtbare domein wat de ontvanger in de email zit.

De oude mailman lijsten waar je naar verwijst zijn voornamelijk een product van de mensen die nu grijs haar hebben en lange baarden.

Ik heb met eigen ogen gezien dat juist deze garde problemen heeft met een DMARC reject policy (M3AAWG en IETF meetings).

Met betrekking tot email nieuwsbrieven: binnen Nederland sturen de ESP's conform de Technische Richtlijnen van de DDMA DMARC compliant mail.

[edit]
ivm correctheid, nav opmerking Aurora
Als er sprake is van DMARC icm DKIM en SPF heb ik het altijd over DKIM op de RFC 5322.from. Zie het als gevolg dat ik er dagelijks mee bezig ben (DMARC).

[Reactie gewijzigd door orbit_ph op 2 februari 2017 22:21]

Sorry, maar je hebt maar deels gelijk. DKIM is totaal onafhankelijk van zowel het Envelope sender domein (5322.from) als het From header domein.

DKIM gebruikt het 'd=' domein, het signature domein. Dat staat compleet los van alle andere headers. Met dit domein onderteken je de email. En als je het goed doet, onderteken je de mail met het hetzelfde domein die je gebruikt in de andere headers.

Vuistregel in email deliverability is dat de Envelope sender en d= domein aligned moet zijn met het From header domein. Dit is gelijk 1 van de eisen als je DMARC wilt implementeren.
Ik heb hier een aantal nieuwsbrieven in mijn mailbox die verstuurd zijn met Zoho Campaigns. De afzender hiervan, de from-header dus, is From: Bedrijf <info@bedrijf.nl>, maar de DKIM-signature is gevalideerd op zcsend.net, waarbij het return-path dus in de vorm is van bounce...@zcsend.net

Dit wordt gewoon gevalideerd. Waarom? Als ik de bron van het bericht er niet bij pakt dan zie ik alleen maar info@bedrijf.nl als afzender staan, dus de DKIM-validatie geeft mij de indruk dat dit daadwerkelijk ondertekend is met de DKIM-sleutel van bedrijf.nl, maar dat is dus niet het geval.

Er is namelijk zoiets briljants als ADSP: Author Domain Signing Practices (RFC 5617).

Het vervelende is dat er dus een pleister bovenop DKIM is geplakt om deze strategie mogelijk te maken, en die vereist de aanwezigheid van een _adsp._domainkey.bedrijf.nl. Is die niet aanwezig dan wordt maar aangenomen dat het wel goed zal zitten. 8)7 Dat betekent dus dat een ieder die DKIM goed geconfigureerd heeft zonder op de hoogte te zijn van ADSP alsnog gespooft kan worden.

Ik kan hier echt weinig begrip voor opbrengen. DKIM is een redelijk idee, maar op deze manier worden de poten er direct weer onder weggezaagd. Ik heb ook mails verstuurd via Amazon SES, daarbij werd je als gebruiker geacht netjes je DNS-configuratie aan te passen om de DKIM-signature goed te krijgen. Dat is wat mij betreft de enige acceptabele manier - het wordt zo pleister op pleister of procedure op policy, en door de wirwar aan oplossingen wordt het alleen maar ondoorzichtiger.
Ik ben nog steeds niet mee vrees ik. Dan moet die _adsp._domainkey.bedrijf.nl record toch aangemaakt worden in de DNS-server van bedrijf.nl? Dus... de hacker/spammer moet toegang hebben tot de DNS-server van dat bedrijf?
Nee. Als dat record niet bestaat is de default policy dat het wel goed is.
Dat klopt toch niet? Dat is toch afhankelijk van hoe de beheerder van de DNS-server zijn eigen SPF record heeft aangemaakt en welke policy die hanteert? Als die p=none daarin zet in plaats van p=quarantine of p=reject, dan is dat toch logisch dat die alsnog geaccepteerd wordt door de server van de ontvanger? p=quarantine / p=reject zou ervoor moeten zorgen dat die e-mail geflagged wordt in jouw mailbox, denk ik.

[Reactie gewijzigd door helonaut op 9 februari 2017 15:25]

Ik heb het over DKIM, niet over SPF.

In de link naar RFC 5617 die ik hierboven ook al zette, staat het volgende Appendix A2:
A.2. Domain Exists, ADSP Does Not Exist

A mail message contains this From: header line:

From: alice@bbb.example (Old-fashioned Alice)

The ADSP lookup first identifies the Author Address alice@bbb.example
and the Author Domain bbb.example. It does an MX DNS query for
bbb.example and gets back record (3). Since that query didn't return
an error, it then proceeds to a TXT DNS query for
_adsp._domainkey.bbb.example, which returns NXDOMAIN. Since the
domain exists but there is no ADSP record, ADSP returns the default
unknown result: messages may or may not have an author domain
signature.
May or may not have a signature dus. Het is allemaal wel prima, zoek het maar uit. En dat terwijl je DKIM-record dus wel gewoon bestaat.

Hoe graag ik ook zou willen dat het niét klopt, ik heb in de praktijk ervaren dat het wel werkt. Een defaut._domainkey record leid tot afwijzing bij afwezigheid van een DKIM ADSP-header, maar zodra je die toevoegt wordt hij weer klakkeloos geaccepteerd.
OK tnx voor de verduidelijking, dus het komt erop neer dat de implementatie van de verwijzing naar de key niet correct gebeurd is. Dus alsof er eigenlijk geen key is en dus geen domain sig... En daarop wordt hij geaccepteerd.

Dat wist ik niet. Ik ging inderdaad steeds uit van een werkende, goed geïmplementeerde casus. Maar had geen rekening gehouden met eventuele "fouten" van de kant van de afzender. Dat is inderdaad interessant... Dat zou inderdaad eigenlijk geweigerd moeten worden? Straf.
Dat is gewoon luiheid van de nieuwsbrief verstuurder door geen extra DKIM key aan te maken.
Onze nieuwsbrief wordt ook via een externe partij verzonden, zelfs een shared SMTP-server. Zolang je afzendadres maar jouw domeinnaam heeft en de externe SMTP-servers in je DNS-record opgenomen zijn zou dat moeten lukken. Via deze website kan je alles (driedubbel) checken: https://www.mail-tester.com
Waarom mailen? Dat gaan we never ever meer veilig krijgen. Veel te veel historische baggage.


mijnoverheid.nl heeft een prima beveiligde berichtenbox. Als al deze bedrijven gewoon de consument de optie geven om alle communicatie via dit platform te laten verlopen zijn we toch klaar?
Omdat SMTP/mail een federated infra is. En hoe moet ik overigens weten dat er een bericht in die mijnoverheid.nl berichtenbox zit? Moet ik dat gaan pollen? Kan ik dat automatiseren? Is dat dan veilig? Hoe archiveer ik het voor eigen offline gebruik?

De mentaliteit die je hier geeft betekent een einde van het open netwerk wat we nu internet noemen. De fragmentatie/clustering is al jaren duidelijk zichtbaar met de opkomst van het app(licatie) voor specifieke (gedeeltelijk gesloten) platforms. Waren we na begin 2000 eindelijk af van specifieke implementaties (bv bankieren vereiste IE 5.x met java) en kon alles in een webbrowser gebaseerd op open standaarden. Sterven nu de OSen af bij bosjes bij gebrek aan support van de leveranciers van specifieke diensten.
Dus ik moet mijn email maar toevertrouwen aan de overheid ? Neen dank je, ik gebruik veel liever een partij als xs4all.nl. Wat mij betreft een prima adres die ik al jaren gebruik via imap en ik heb geen belangstelling voor Het.Draakje12345689@mijn.overheid.nl via pop of webmail.

Want als iedere Nederlander via mijn.overheid.nl moet mailen, dan loop je al gauw tegen beperkingen aan als Jan deVries.

Trouwens: mijn.overheid, mijn.ing, mijn.groenteboer. Kan het na dat jaren 90 'gepersonaliseerde' internet wat minder met mijn.whatever ?
email imap Het.Draakje12345689@mijn.overheid.nl pop
Je denkt teveel in legacy technologie. Als je een secure messaging service wilt, zal je dit allemaal achter je moeten laten.
"de organisatie meldt niet met welke technieken zij voor betere beveiliging gaan zorgen."

Als ik naar de gelinkte bron doorklik, staat daar gelijk een infographic over DKIM, SPF, DMARC, en starttls. De PDF die daar staat is niet meer bereikbaar, dus alleen afgaande op het plaatje lijken me dat de technieken waarmee ze dat voor elkaar willen boxen ;)
Het gaat om de standaarden van de Pas toe of Leg uit lijst.

https://www.forumstandaar...mein/internet-beveiliging

Daarbij moet ik de kanttekening plaatsen dat DMARC nog niet op de lijst met verplichtte standaarden staat omdat het traject bij de IETF nog niet afgerond is.
De coalitie heeft nog een lange weg te gaan.
Nog niet zo lang geleden heb ik bedrijven waar ik als prive persoon veel contact mee heb de vraag gesteld of ze plannen hebben om hun e-mail uitingen (nieuwsbrieven en aanverwant) digitaal te ondertekenen.
PWN, Nuon, ABNAMRO, Conrad, HCC, Bol, en nog een handvol.
Geen van hen stond te juichen, sterker nog, er is een collective knee-jerk reaction waarbij met gestrekte knieen een buigende beweging wordt gemaakt zodat het hoofd weldadig diep in het zand kan worden gestoken.

Het is allemaal moeilijker dan 'de beweging ter instanthouding van de soort' zeg maar. Een aantal geeft zelfs aan dat een s/mime bestand of ander type key door klanten kan worden gezien als een gevaarlijk attachment.
Speelt natuurlijk ook in mee dat dit soort bedrijven de verspreiding van nieuwsbrieven en dergelijke hebben uitbesteed aan derde partijen, die soms wel, en soms niet het domein van het bedrijf zelf gebruiken.
@Skriptkiddie maakt een belangrijk punt: S/MIME en PGP.. daar snapt Jan Modaal niets van.
Daar heeft hij gelijk in. Het beveiligen van informatie moet bij de eindpunten liggen. De transport lagen die ertussen liggen hebben geen andere functie dan juist die. Transporteren.
Maar ja, als die beveiliging niet wordt begrepen, en dus niet wordt toegepast, dan kom je geen steek verder.

Next best thing is je mail applicatie. Als je beveiliging kunt 'democratiseren' zodat je geen diepgaand technische kennis nodig hebt, heb je gewonnen.
Kijk je vervolgens naar de capabilities van mail clients op de diverse platformen, (met name mobiele apparaten) wordt het mij enigszins droef te moede.
Als "Pretty Easy Privacy" eenmaal uit het vaporware stadium is, wordt het misschien nog weleens wat.
Ik weet niet of het door het "jaren 90 filter" van @Dorank komt; Hij is (X) Technical, hoe hard je ook roept dat het "easy" is.

Maar goed.. Ik kan WIRE (secure chat) BoxCryptor (encrypted storage), PGP (enigmail), SMIME (mobiel) gebruiken wat ik wil, maar ik denk dat we het er wel over eens kunnen zijn dat those "in the know" over beveiliging helaas nog een druppel op een gloeiende plaat vertegenwoordigt.

Ik vind het overigens opmerkelijk dat bits of freedom niet een warm plekje in de coalitie heeft gekregen.

Hoe dan ook: Trek je paarse pij maar weer aan, we hebben nog steeds een boel aan evangelisatie te doen !

Dank voor deze zinvolle en leerzame discussie !

Leo
Leuk allemaal en het zal vast wel werken tussen bedrijven of overheden onderling. Maar zodra de burger gemaild moet worden (en dan bedoel ik niet de gemiddelde tweaker) zal TLS of andere beveiliging niet aan de orde zijn bij de desktopclient of de mobiele mail-app. Dus dan maar iedereen zijn mail via webclient laten lezen?
Dat hele smtp is gewoon een rot protocol. Dat zou vervangen moeten worden ipv steeds maar weer dingen (beveiliging) tegen aan te plakken.
Ik ken maar weinig mail clients die geen TLS ondersteunen. Vaak gebeurd de detectie zelfs automatisch.
Ik ken geen MUAs/MTAs die TLS afdwingen. De term Opportunistic TLS is al gevallen. Een MitM kan bv simpel het starttls commando uit de EHLO laten verdwijnen in SMTP of in de IMAP capabilities.
SMTP is een prima transport protocol, op de envelope staat:
-afzender a
-bestemming b
Vervolgens kan je aan de binnenkant van de envelope prima een mechanisme verzinnen dat:
-een echtheidskenmerk heeft
-een detectie van aanpassingen door derden geeft
-eventueel end to end encryptie toevoegt.

Dit is allemaal al meer dan 10 jaar in RFCs omschreven. Helaas is er niemand die het gebruik van (specifieke RFC) implementaties bevorderd.
Ik ben zelf met deze technieken begonnen toen ik merkte dat Gmail e-mails van mijn private SMTP-server begon te weigeren omdat ik geen correcte DNS-record had. Dus de gemiddelde burger was technisch gezien vóór mijn private server beveiligd en ik reken mezelf bij de techneuten. Op alle andere punten die je maakt, heeft Dorank reeds correct geantwoord.
Klinkt als een bureaucratisch zootje met veel te veel partijen waar geen ene reet van terecht gaat komen.
Daar zou ik mijn geld ook opzetten. PostNL, KPN en overheidsinstanties, leuke reünie, waar een hoop koffie gedronken zal worden.
Dan moet ik je in het kader van PostNL teleurstellen.

We staan daar inmiddels op een DMARC policy van 50% reject, deze gaat binnenkort naar 100% en is het complete domein PostNL.nl beveiligd.
Zover ik kan zien staat het domein postnl.nl volledig op een 100% 'reject' policy :)
Ik schrok eerst even, dan zou er dus iets gebeurd zijn waar ik niets van af weet ;)

Binnen de DMARC policy p=reject staat nog een pct=50, hierdoor 50% van de mail als reject, de overige 50% als p=quarantine (indien DMARC fail op SPF & DKIM).

Stiekem even wat linkjes:
https://www.dmarcian-eu.com/dmarc-inspector/postnl.nl
https://www.dnswatch.info...l&type=TXT&submit=Resolve
Sorry voor de schrik, zag dat ik inderdaad een foutje maakte :) Ik deed een lookup op post.nl in plaats van postnl.nl.
Misschien in combinatie met PGP voor het encrypten en signen van emails?
Er zijn nogal wat protocol standaarden die verouderd zijn. Het afdwingen van TLS/STARTLS gaat in de praktijk niet aan de serverkant. Opportunistic TLS is ook niet echt veilig: https://en.m.wikipedia.org/wiki/Opportunistic_TLS.
Tja, dat is het nadeel van een dergelijk federated protocol. Afdwingen kun je zelf niet maken. Als Google/Gmail en Microsoft/Outlook een goede standaard omarmen en afdwingen (en dus mail weigeren die het niet implementeert) dan komen we ergens. Dan kan je als beheerder van kleinere mailservers rustig meevaren op die ontwikkeling, en is het ook makkelijk aan je gebruikers uit te leggen als ze mail niet krijgen (want op gmail had je het ook niet gekregen).
Veilig emailen bestaat niet. Email is altijd te allen tijde te wijzigen, te wissen, of zo traag te versturen dat het geen zin heeft om email te gebruiken. Dit heeft te maken o.a. met hoe email technisch werkt. Zo zet ieder ontvangt tussen-station gegevens in de email om aan te geven dat de email er geweest is, of informatie over of het spam is, of andere informatie over wat de email bevat.

En, ook kan het te maken hebben met de technische capaciteiten van de ontvangers en verstuurders van de email. Bijvoorbeeld omdat een email niet op het scherm past, en daarom in kleinere stukken moet worden getoond of bijvoorbeeld :-) te vervangen door :)

Dit soort dingen wordt geregeld in RFC 2822 en de andere standaards die over email gaan.
Dus ja, je kan een veilig berichten-systeem opzetten. Maar, als het bericht niet veranderd kan worden, heet het geen email.

[Reactie gewijzigd door Wody op 2 februari 2017 19:17]

Dat valt in de praktijk best mee. Die tussenstations zijn echt geen limiterende factor. Dat heeft meer te maken met het ontwerp en de gebruikte hard-software.
Dit heeft te maken o.a. met hoe email technisch werkt. Zo zet ieder ontvangt tussen-station gegevens in de email om aan te geven dat de email er geweest is, of informatie over of het spam is, of andere informatie over wat de email bevat.
Er is echter geen enkele technische reden om via tussen stations te gaan (mail relays). SMTP kan prima end to end plaatsvinden.
Maar, als het bericht niet veranderd kan worden, heet het geen email.
Waarom zou dat geen email zijn? Wat is overigens het bericht? De oorsponkelijke body? Wellicht inclusief headers? En zijn die veranderd als ze volledig encapsulated worden doorgezet in een nieuwe envelope?

Op dit item kan niet meer gereageerd worden.


Nintendo Switch Google Pixel XL 2 LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*