Gmail gaat bedrijfslogo's bij geauthenticeerde mailafzenders tonen

Gmail gaat binnenkort bedrijfslogo's bij afzenders tonen als Google de afzender kan authenticeren. Zo moet een gebruiker bijvoorbeeld duidelijk kunnen herkennen dat een mail daadwerkelijk van een bank komt wanneer het logo van de bank bij de afzender staat.

Voor het tonen van de bedrijfslogo's gaat Gmail Brand Indicators for Message Identification gebruiken. Binnen deze BIMI-standaard wordt het logo van een bedrijf pas getoond als de mailprovider kan bevestigen dat het bedrijf daadwerkelijk de instantie is die de mail verstuurt en het dus niet een kwaadwillende is die een bedrijf probeert te imiteren.

BIMI doet dit door bedrijven hun e-mails te laten authenticeren met Domain-based Message Authentication, Reporting and Conformance, of dmarc. Bedrijven en organisaties moeten hiervoor hun mails authenticeren met Sender Policy Framework, ook wel bekend als SPF, of met Domain Keys Identified Mail, ook wel bekend als DKIM. Dan kunnen ze dmarc inzetten. Daarna kunnen ze Google voorzien van hun gevalideerde logo's met een Verified Mark Certificate.

Zodra bedrijven of organisaties aan deze voorwaarden voldoen en alle antimisbruikchecks van Google doorstaan, gaat Gmail het bedrijfslogo tonen op de plek waar nu avatars verschijnen. In de smartphoneapp zien gebruikers het logo dus al in de inbox; in de webversie moeten gebruikers eerst doorklikken naar een mail.

Gmail-gebruikers hoeven niks te doen om de bedrijfslogo's te zien. Google zegt de functie in de komende weken te willen implementeren in Gmail. Deze maildienst is daarmee niet de eerste die BIMI ondersteunt; Yahoo-mail doet dit nu al.

Het Bank of America-logo dat dankzij BIMI binnenkort in Gmail wordt getoond

Reacties (147)

[LeonM]

Er lijkt hier in de reacties veel verwarring over BIMI.

Je kan niet zomaar een willekeurig logo kiezen om te tonen in iemand's mailbox. Dit zou juist phishing bevorderen.

Voor BIMI moet je een Verified Mark certificate kopen bij een certificate authority die dit aanbied (momenteel alleen DigiCert en Entrust). De verstrekker van het VM certificate controleert (onder andere) bij jouw lokale trademark office of jouw organisatie inderdaad de trademark heeft of het logo. Je artwork (logo) moet dus gedeponeerd zijn bij het trademark bureau.

Gezien de hoeveelheid mensenwerk wat erbij betrokken is voor het validatie process, zijn VM certificates nog erg duur. DigiCert rekent bijvoorbeelt 1500 dollar voor een VM cert.

Een VM certificate is een x509 certificaat zoals je gebruikt voor webservers, maar met een extension geactiveerd waarin de trademark informatie (inclusief het logo zelf) zit verwerkt. ​
Via een DNS record publiceer je de BIMI ondersteuning van jouw domain, een via HTTPS (met wederom een geldig certificaat) moet je dan ook hetzelfde logo hosten voor mailclients.

BIMI is in het leven geroepen om de adoption rate van DMARC te vergroten. Je domain moet DMARC (in quarantine of reject modus) hebben geactiveerd om BIMI te kunnen gebruiken.

Momenteel zijn er een aantal domains die BIMI hebben geimplementeerd met een geldig certificaat. Zoals bijvoorbeeld CNN BIMI validator voor cnn.com.

Ik heb over de huidige staat van BIMI geschreven hier: the current state of BIMI

edit: om het wellicht nog duidelijker te maken: je kan BIMI zien als verified accounts, maar dan voor email. Omdat er geen centrale eigenaar is van email (zoals bijvoorbeeld wel bij twitter het geval is) moet het vertrouwen komen uit een certificate authority (net als met HTTPS).

[Reactie gewijzigd door LeonM op 23 juli 2024 17:16]

[Anoniem: 1576590]

Dus bij https hebben we het EV-certificaat weggegooid met het badwater, en nu gaan we zoiets nabouwen in e-mail?

BTW ik zag An email has more than one sender address op mailhardener en werd blij, want ik dacht (te snel) ze adresseren het (DMARC-) probleem dat een e-mail meer dan één RFC5322.From afzender kan hebben - maar nee (geen kritiek hoor, maar misschien een idee voor een aanvulling).

Nb. destijds was dit er waarschijnlijk de oorzaak van dat protonmail een phishingmail doorliet aan Bellingcat (met in RFC5322.From zowel een protonmail.ch als een mail.de afzender).

Later is aan OpenDMARC (destijds kennelijk gebruikt door protonmail) een instelling "RejectMultiValueFrom" toegevoegd, maar die werkt kennelijk nog niet zoals gedocumenteerd.

[Reactie gewijzigd door Anoniem: 1576590 op 23 juli 2024 17:16]

[Bart ®]

Maar als ik mijn moeder nu een mailtje stuur, ziet ze daar mijn foto bij staan. Die komt uit mijn Google-profiel. Als ik die profielfoto vervang door een logo van Microsoft, denkt mijn moeder dat ze een mail van Microsoft ontvangt. Of gaat Google checken dat ik niet zelf op die profielfoto sta, maar dat het een logo van Microsoft is? En wordt vervolgens mijn profielfoto niet weergegeven omdat ik geen rechten heb om dat logo te gebruiken?

[LeonM]

Dat is geen BIMI, profielfotos werken alleen binnen Gmail.

Bovendien toont Gmail alleen profielfotos van je contacten. Profielfotos van vreemden worden niet getoond, precies vanwege de gevoeligheid tot phishing.

[Sebazzz]

Profielfotos van vreemden worden niet getoond, precies vanwege de gevoeligheid tot phishing.

Dat is grappig, dat is bij Outlook.com niet. Ik heb iets gekocht bij iemand van V&A, en bij zijn e-mailtje zag ik zijn foto.

[faim]

Weet niet of dit recentelijk is gewijzigd, maar bij Gmail zag je (voorheen) ook gewoon profielfoto’s van niet-contacten.

[Berlinetta]

Ik zie ze nog steeds

[davidov2008]

Ik ook hoor. Ik dacht dat er aan het logo nog een speciaal certificaat of ander uiterlijk verschil zou zitten maar niks.

Iedereen met Google account die mij wat stuurt zie ik profiel foto van incl sommige bedrijven. Zelfde bij Hotmail /outlook.

Dus zonder extra visuele maatregel lijkt me dit wel heel makkelijk voor fraude. Enige is profiel foto aanpassen, dat je daar de rechten niet voor hebt of dat ie na tijdje offline gehaald wordt zal oplichters een ons wegen.

"werkt alleen binnen Gmail"? Het gaat immers nu ook om Gmail gebruik op web of app. Denk dat bijna niemand oude mail software gebruikt met gmail.

[Mangu429]

Wat maakt het uit of het BIMI is? Een logo is een logo. Mensen gaan niet uitzoeken waar dat vandaan komt.

[loki504]

En sinds wanneer heb jij fraudeurs in je contacten lijsten staan?

[ejabberd]

Sinds die contacten hun mailbox kan zijn gekraakt.

[loki504]

Dan praat je over een hele specifieke gerichte aanval. Dat kost teveel tijd en moeite voor de fraudeurs. Massa bericht sturen zonder logo is vele malen makkelijker en uiteindelijk efficiënter.

[ejabberd]

Als men een bedrijf of organisatie miljoenen wil aftroggelen met gijzelsoftware, dan is het een kleine moeite om je legitiem voor te doen als een van uw contacten om betrouwbaar over te komen.

[loki504]

En hoeve miljoenen organisaties werken met Gmail? Als ze het al bij zakelijke mail gaan toepassen.

Dit is gedaan voor consumenten. En met voordoen bedoel je op een of andere manier in je contacten komen. In de hoop dat die ene toe hapt? Dan is een massa mail/bericht naar duizenden mensen veel interessanter voor een fraudeur.

[Gamebuster]

Naast "kraken" zie ik ook wel potentie om een contact toegevoegd te krijgen via een andere app die daar toegang toe heeft. Er is vast wel een app waarmee je makkelijk iemand kan toevoegen als contact (incl. plaatje).

Bij zakelijke mail kan dit zo makkelijk zijn als bijv. voordoen als potentiele klant, "ik heb mijn contactgegevens bijgevoegd" en bij klikken contactgegevens kaartje wordt malafide e-mail adres + plaatje toegevoegd.

[Boraxx]

BIMI werkt ook enkel bij Yahoo! En Gmail.
Het werkt niet bij Microsoft Office 365 of Outlook.com

Microsoft gebruikt namelijk haar eigen concurerende "standaard"

[Bart ®]

Helder, dankjewel .

[paltenburg]

Ja maar in het voorbeeld van het artikel staat het logo op de plek van de profielfoto. Dus is daar niet snel verwarring tussen?

[loki504]

Misschien van mensen die bevriend zijn met/herkennen? Want er is in mijn mail box 1 bedrijf waar ik een logo/foto van zie. En voor de rest alleen een letter.

/Edit. Mijn vrouw ook. Maar die zit ook in mijn contacten.

[Reactie gewijzigd door loki504 op 23 juli 2024 17:16]

[GrooV]

Het lijkt eerder op de zelfde ellende als die we hadden bij EV certs, ben blij dat we daar vanaf zijn.

Het geeft alleen maar schijnveiligheid

[Boraxx]

@LeonM wellicht kan je de andere grote gratis email speler, Microsoft, meenemen in je artikel.

Hoe zie je een standaard als BIMI als niet elke grote speler deze omarmt?

Waarom betaalt een bedrijf 1500 EUR per jaar als dit enkel een mogelijk extra vertrouwen geeft bij minder dan 50% van de zakelijke mail?

[Reactie gewijzigd door Boraxx op 23 juli 2024 17:16]

[LeonM]

Microsoft heeft, voor zover bekend bij ons bekend, aangegeven dat zij *niet* voornemens zijn om BIMI te gaan ondersteunen. Bron: https://bimigroup.org/bimi-adoption-october-2020/

En ja, 1500 euro is een hoop geld, en een barrière voor BIMI. Het is ook maar de vraag of BIMI door zal breken als geaccepteerde techniek. Het is momenteel nog een experiment.

[Simkin]

Nmw is een certificaat voorlopig nog optioneel?

Consult with a trusted authority to issue a Verified Mark Certificate (VMC) for your sender domain. Currently, this is optional, but if your sender reputation is excellent and still the BIMI logo not appearing, then this is worth trying. Once the certificate is issued, you should add that as a part of your BIMI TXT record.

Bron: https://netcorecloud.com/tutorials/bimi/

[LeonM]

Technisch gezien optioneel, maar zonder het certificaat zal iedereen dus het logo van je bank kunnen gebruiken. Dus het is vrijwel zeker dat voor de publieke email services je een geldig certificaat zou moeten hebben, anders wordt het logo niet getoond.

[Simkin]

Ik vraag me af in hoeverre mijn custom niet gecertificeerde logo kan/mag lijken op een gecertificeerde. Zolang mijn domain/ip reputatie in orde is (weinig bounces/spam alerts genereer) denk ik dat mijn spoof logo wel getoond zal worden, of mis ik iets?

[LeonM]

Je logo zal niet getoond worden zonder VM cert, ongeacht reputatie.

Het geeft simpelweg teveel risico voor de e-mailprovider aan de ontvangende kant. Als gmail (of andere partij) een logo zal tonen welke misbruikt wordt voor phishing, dan zal de gebruiker dus nooit meer het logo vertrouwen, en is alles voor niks geweest.

De echte vraag is: als jouw trademark bureau (in Nederland is dit de BOIP) jou een logo toekend dat sterk lijkt op een logo van een buitenlands bedrijf (bijvoorbeeld: bank of america), heeft de Certificate Authority (die de VM cert uitgeeft) dan nog steeds recht/plicht om jou VM cert te weigeren, of in te trekken?

[MeMoRy]

, zijn VM certificates nog erg duur. DigiCert rekent bijvoorbeelt 1500 dollar voor een VM cert.

Voor bedrijven (voor wie dit bedoeld is) is eenmalig 1500 helemaal niet duur. Verwaarloosbaar zelfs in perspectief van de andere kosten die aan commerciele emaildistributie zitten.

[bart.koppers]

1500 niet veel? Er zijn ook kleinere bedrijven (zzp/mkb) - bedrag is niet niks. Plus je merkregistratie.

Valt op dat mailen steeds lastiger gemaakt wordt door dit soort (niet-gestandaardiseerde, lees RFC) toevoegingen.

[MeMoRy]

Je logo tonen bij een email is optioneel. C.q. "gewoon mailen" kan gewoon.
Dit is (volgen mij) ook niet echt bedoeld voor kleine bedrijven. Maar voor bijvoorbeeld banken e.d. die grote kans hebben om gespoofd te worden.

Over RFC's gesproken: veel RFCs (of andere standaarden) zijn pas gemaakt na ervaring in het veld, bijv als iets wat allang bestond als standaard binnen een bedrijf. Google werkt ook gewoon mee aan RFCs. Dus dat het nu nog geen standaard is, betekent niet dat het in de toekomst geen standaard wordt.

[bart.koppers]

Snap ik ook wel dat standaardiseren zo werkt.
Gaat mij erom dat er allerlei “eigen” zaken aangehangen worden die het (aankomen) van mail verder (gaan) bemoeilijken. Of surrogaat-gevoel van veiligheid introduceren.

Draai al tientallen jaren eigen mailserver en dat wordt meer en meer gewoon onmogelijk gemaakt zo.
En ik spam niemand he!

Nou begrijp ik heus dat niemand op spam en spoofing zit te wachten, maar de huidige werkwijze en steeds complexer maken dwingt iedereen steeds meer en meer richting grote aanbieders.
Die behalve dit soort fratsen ook jouw mail-inhoud lezen, en bepalen of het spam (of ongewenst) is.
(Die (spam)controle staat daarmee al trouwens op gespannen voet met briefgeheim en AVG.)

[Mic2000]

Dus mogelijk kunnen ze met BIMI het filteren van spam verbeteren als meer en meer internetproviders en bedrijven een BIMI aanschaffen?

[Scriptkid]

Grootste probleem is dat men hier toch weer SPF mee neemt in DMARC, ipv Alleen DKIM, (helaas heeft DMARC DNS issue flaws waardoor je gedwongen wordt SPF als failback te gebruiken)

SPF is met de cloud een protocol dat niet langer voldoet als je geen macro`s toevoegd in je SPF record, Steeds meer en meer partijen hebben exact het zelfde SPF record nl include de grote clouds , dat is precies wat SPF niet is daar verwacht je alleen een paar eigen servers.

DKIM daar in tegen is uniek per signer en identificeert dus wel de echte verzender.

[LeonM]

helaas heeft DMARC DNS issue flaws

Welke flaws bedoel je hier?

[Scriptkid]

het leunt op DNS, en die hoeft maar een hik te hebben ,

Ik zie 2% van het traffic van heel veel klanten hier last van heeft,

[Speleding]

Je kan niet zomaar een willekeurig logo kiezen om te tonen in iemand's mailbox

Ik heb BIMI toegevoegd aan ons domein, zonder validate o.i.d., en die wordt getoond in de mailbox in Fastmail. Middagje werk om alles helemaal goed te krijgen, het luistert nogal nauw (SPF + DKIM en DMARC nodig, en de SVG heeft een specifiek formaat) maar verder niets bijzonders gedaan. Dat controleren van een certificaat gebeurt blijkbaar alleen in Gmail.

[fschuurman68]

Het logo moet geregistreerd staan bij een US of EU beeldmerk registratie bureau. Met dat bewijs dat jouw bedrijf de eigenaar is, kun je een certificaat krijgen van je logo. Dit wordt dan getoond als de rechtmatige eigenaar. Net als een DigiNotar hack zal er iets te fixen zijn, maar dat wordt wel moeilijk in het begin.

Wat @leonm zegt dus

[Reactie gewijzigd door fschuurman68 op 23 juli 2024 17:16]

[3raser]

Maar als ik nu een willekeurige Google Account maak en zelf een profielfoto kies met het logo van de bank, dan heb je toch hetzelfde resultaat?

[kroegtijger]

Toevallig dat ik laatst nog even met BIMI heb zitten spelen en vast heb geimplementeerd in de hoop dat het snel zou worden doorgevoerd, maar tot nu toe moest je nog steeds eerst bij het geselecteerde groepje gelukkige bedrijven horen om daadwerkelijk je logo te kunnen laten tonen.

MXToolbox heeft inmiddels ook al de check ervoor geimplementeerd, en toont reeds netjes de preview van de afbeeldingen:
https://mxtoolbox.com/Sup...funcarrun.eu&run=toolpage

[mrwiggs]

Dus als ik het Bank of America logo als profielfoto instel voor m’n Google account trappen er straks meer mensen in mijn phishing mails..

[Reactie gewijzigd door mrwiggs op 23 juli 2024 17:16]

[LeonM]

Nee, je moet een Verified Mark certificate kopen om BIMI te activeren.

De verstrekker van het VM certificate controleert (onder andere) bij jouw lokale trademark office of jouw organisatie inderdaad de trademark heeft of het logo.

Needless to say is een VM certificate best prijzig, gezien de hoeveelheid mensenwerk wat erbij betrokken is voor de validatie process. DigiCert rekent bijvoorbeelt 1500 dollar voor een VM cert.

[Mangu429]

Mensen die in phishing mail trappen zien een logo en gaan niet controleren of er een certificaat aan hangt.

[foobar79]

Dat hoeft ook niet want de gebruiker hoeft alleen de plek van het logo te controleren.
Het logo wat google laat zien staat namelijk bij de verzender, zoals je in aan het screenshot kan zien, en er is geen manier om daar zelf een willekeurig logo te plaatsen als verzender met slechte intenties.
Uiteraard kan je logos in de email zelf plaatsen maar dit is, relatief gezien, een eenvoudige optische check die makkelijk uit te leggen en controleren is voor mensen.

[B64]

Je mist het punt. Mensen die in een phishing mail trappen doen dat waarschijnlijk ook als er helemaal geen logo is. Lang niet alle bedrijven zullen een BIMI certificaat hebben, ook op langere termijn niet, dus is het niet heel vreemd als het logo ontbreekt. Als er dus wel een logo staat, al of niet bonafide, zijn ze in hun idee gesterkt dat het klopt.

Voor jou is een optische check misschien eenvoudig en makkelijk uit te leggen, maar vergeet niet dat er een heleboel gebruikers zijn voor wie computers en email bepaald geen gesneden koek zijn. Mijn schoonmoeder van 80 hoef ik dit niet te proberen uit te leggen hoor...

[foobar79]

Je mist het punt. Mensen die in een phishing mail trappen doen dat waarschijnlijk ook als er helemaal geen logo is.
Lang niet alle bedrijven zullen een BIMI certificaat hebben, ook op langere termijn niet, dus is het niet heel vreemd als het logo ontbreekt.

Met deze instelling kom je nooit verder.
Hoe prominenter deze functionaliteit aanwezig is hoe meer bedrijven het zullen gaan adopteren en hoe meer mensen zullen begrijpen dat dat logo daadwerkelijk iets betekend.
Het wordt dus wel degelijk makkelijker voor veel mensen om echt van nep te onderscheiden, misschien niet nog niet voor iedereen maar dat is een kwestie van tijd.
Ik verwacht namelijk dat vroeg of laat google alles zonder certificaat bij default gaat flaggen als onbetrouwbaar en naar de spam box verplaatst.
Net zoals https door google hard gepushed is door sites zonder https lagere search rankings te geven.

Wat mij betreft is het in ieder geval een stuk beter dan niets doen en een stap in de goede richting.

[bart.koppers]

“Watch out what you wish for”

Je kan ook doorschieten en drempels opwerpen die hiermee partijen (Gmail/Google en anderen) tot centers of the universe maken omdat je er een duur plaatje aan hangt (letterlijk en figuurlijk).

Verdienmodel en deugcontrole zoveel?

[Anoniem: 1322]

Je kunt geen logo presenteren zonder Verified Mark certificaat. Je krijgt geen certificaat tenzij dat logo ingeschreven staat en daarbij worden vele controles uitgevoerd of jij het copyright van het logo hebt.

Mensen gaan dus niet zomaar logo's zien (in ieder geval niet door deze techniek).

[LeonM]

Het logo wordt dus NIET getoond als het certificaat niet klopt. Je mailprovider/client doet deze controle dus voor je, je hoeft dit niet zelf te doen.

[Jeroenneman]

Niet echt geschikt voor het MKB dus.

[LeonM]

Nee, maar voor MKB voegt het ook weinig toe, een zeer klein deel van de mail providers ondersteund momenteel BIMI. Echter, voor bedrijven die fraudegevoelig zijn (banken, payment providers, social media platforms, etc) is dit een waardevolle toevoeging.

[Christoxz]

Vreemd dat ze niet gewoon een verificatie icoon bij toevoegen. Wat inprincipe al mogelijk is met mail, genaamd S/MIME.

[HKLM_]

S/MIME is helaas zwaar ondergewaardeerd in email ik zou wel willen dat dat nog breder opgepakt gaat worden!

Maar zolang SPF,DKIM,DMARC al te moeilijk is voor sommige beheerders…

[Reactie gewijzigd door HKLM_ op 23 juli 2024 17:16]

[Anoniem: 1322]

S/MIME is top maar in de praktijk gewoon te complex om te implementeren en te beheren. Ik zou graag zien dat mensen dit omarmen maar gezien de leeftijd van deze standaard denk ik niet dat dit nog gaat gebeuren.

[raro007]

Dus voor het gemaak sla je de eerste zin over?
Nou hier lees dit eerst: Gmail gaat binnenkort bedrijfslogo's bij afzenders tonen als Google de afzender kan authenticeren

[FrozenPK]

En bij personen kan je de naam en de profielfoto zien, beide in te stellen

[Sandor_Clegane]

Dat meende ik mij ook te herinneren, daarom vond ik het wel creatief gevonden.

[Deralte]

Maar je kan toch nog steeds een profielfoto instellen als “particulier”… dat zien andere mensen toch ook. Als je dan een mail stuurt trappen er idd mss meer mensen in.

[kodak]

Het probleem wat @mrwiggs lijkt te tonen is dat niet duidelijk is wat de toegevoegde waarde is en gebruikers niet kunnen zien wanneer ze die logo's kunnen vertrouwen. Dus is er aanzienlijke kans dat criminelen zelf creatief logos gaan gebruiken alsof het te vertrouwen is.

Google suggereert alsof een logo zorgt voor vertrouwen, maar dat werkt niet zomaar alleen in het voordeel.

[Sandor_Clegane]

lol. Nice.

[MatthijsZ]

Eh, misschien een domme vraag:

Maar als ik rabobank-klantenservice.nl registreer en daar de hele rambam (BIMI, SPF) voor instel, dan kan ik er gewoon een Rabobank logo bijzetten?

Dat komt dan straks super betrouwbaar over

[LeonM]

Nee, je moet bewijzen dat je de eigenaar bent van het logo via het trademark bureau, en die is bovendien gekoppeld aan het domain (rabobank.nl), waar jij ook geen eigenaar van bent.

[MatthijsZ]

Aha, ik vermoede al dat er ergens een centrale schakel moest zijn, dat niet alles technisch opgelost kan worden. Maar werd niet duidelijk uit artikel. Dank

[M4RTiN]

Als jij zover bent dat jij de hele rambam goed hebt ingesteld is jouw fysieke adres ook bij de juiste instanties bekend. Ik denk dat dat de reden is. Dus dat criminele activiteiten makkelijk aan een bedrijf/persoon te linken zijn en dus niet interessant voor een crimineel.

Dit is mijn guess tenminste...

[mmjjb]

Slechte zet. Gebruikers gaan straks wellicht meer op het logo af dan de controle van het domein. Ideaal voor phishing emails.

[Reactie gewijzigd door mmjjb op 23 juli 2024 17:16]

[Munchie]

Maar dit is toch juist precies het doel? Door middel van deze dmarc wordt toch juist de betrouwbaarheid van de afzender bevestigd en kan een gebruiker emails met het bedrijfslogo vertrouwen.

Controleren van het domein is onbetrouwbaar, als ik even wat afzenders uit mijn spam map erbij pak:
[e-mail]
[e-mail]
[e-mail]

[citegrene]

dmarc werkt toch ook prima met blokkker.nl
of blokker.tv

[Reactie gewijzigd door citegrene op 23 juli 2024 17:16]

[Munchie]

DMARC voorkomt ook domein spoofing:

DMARC is always used with these two email authentication methods or checks:

- Sender Policy Framework (SPF) lets the domain owner authorize IP addresses that are allowed to send email for the domain. Receiving servers can verify that messages appearing to come from a specific domain are sent from servers allowed by the domain owner.
- Domain Keys Identified Mail (DKIM) adds a digital signature to every sent message. Receiving servers use the signature to verify messages are authentic, and weren't forged or changed during transit.

https://support.google.co...-messages-dmarc-alignment

[djiwie]

Als jij blokkker.nl hebt (met drie k's!) valt dat niet zo op en hoef je helemaal niet te spoofen. Zeker niet als Gmail er een logootje bij gaat zetten. Dmarc, dkim en spf helpen daar alle drie niet tegen!

[dok33]

Dmarc, DKIM en SPF zorgen er voor dat Google dat logo er niet bij gaat zetten, dus helpen er juist prima tegen

Want jij kan niet bewijzen met je blokkker.nl dat je eigenaar bent van het geregistreerde logo van Blokker.

Die komt dus niet bij jouw mails...

[djiwie]

Ja ik zag dat het logo nog een losse registratie is inderdaad. Dan moet je Blokkker nog registreren als merk en dat zal wel wat lastiger zijn dan DKIM/SPF/DMARC

[citegrene]

ik spoof toch ook helemaal geen domein in de voorbeelden, de domeinnamen kunnen wel legitiem zijn maar erg lijken op het orgineel.

[Reactie gewijzigd door citegrene op 23 juli 2024 17:16]

[Munchie]

Dan moet je ook nog hun Verified Mark Certificate (VMC) doorlopen, en dus je (trademark) logo verifiëren. En dit in combinatie met een verdacht domein.

[Scriptkid]

Niet helemaal,

zoals ik jaren geleden al blogs over schreef geld dit nog steeds ,

https://www.tech-savvy.nl...ionalization-eai-attacks/

[dragonlords1]

scamtelegraaf.nl, blokkerscam.nl en scamns.nl kunnen evengoed geldige spf, dkim en dmarc records hebben en vervolgens een logo opgeven.

De vraag is hoe goed googles anti-misbruikchecks zijn.

[JackBol]

We wordt gechecked of je de rechten van het logo bezit. Je kan dus niet zomaar een favicon mee sturen.

[svenk91]

En hoe moeilijk zal het zijn om een logo dat lijkt op die van Blokker ergens in de US, of een random bananen republiek, te gaan registreren? Criminelen zullen wat extra hoepels door moeten springen, maar veilig is het nog steeds niet.

[dok33]

Een logo registreren bij een merkenbureau is minder makkelijk dan je denkt, denk ik.
En duur.

[Scriptkid]

crypto encrypted bedrijven betalen massaal 300.000-500.000 euro,

Daar kan je vast wel wat mensen voor omkopen in bepaalde landen

[dok33]

Alleen gaat het niet om "bepaalde landen" (waarmee je vast landen bedoeld waar het minder nauw genomen wordt met de regels en beveiliging). Het gaat om het EU Merkenbureau, en het US MerkenBureau. Ik zal niet zeggen dat het onmogelijk is, maar lastiger dan in een bananenrepubliek. Als die uberhaupt al aan merkbescherming doen...

[DarkForce]

Slechte zet. Gebruikers gaan straks wellicht meer op het logo af dan de controle van het domein. Ideaal voor phishing emails.

Vertel, hoe ga jij die DMARC maar ook een aantal andere checks (SPF, DKIM) d.m.v. phising omzeilen? Deze zaken worden bepaald door de server en zijn niet 1.2.3. even te omzeilen.

Denk niet dat het zomaar even mogelijk zal worden om een Rabobank logo te tonen als jij domeinnaam mijnrabobank.nl op je server hebt draaien.

[Reactie gewijzigd door DarkForce op 23 juli 2024 17:16]

[citegrene]

Heb even gekeken naar bimi, het is dus mogelijk zelf de svg logo te hosten

[djiwie]

Waarom zou dat niet kunnen, ervan uitgaande dat je een valide SPF record hebt en DKIM hebt geconfigureerd?

[dok33]

Omdat jij niet het Rabobank logo hebt geregistreerd bij het EU Merkenbureau

[Scriptkid]

de beste truck is dan ook om een simple medewerker zijn account te compromisen en van daaruit de batch mail weg te sturen met allen toeters en bellen er op aan.

SPF, DMARC, DKIM, SMTP STS, DANE, BIMI,

Alles is ok en valide en gaat netjes naar je klanten ( eh targets). die dan er vol intrappen omdat alles 100% klopt.

[dok33]

Dat is een andere aanvalsvector, en slaat niet op het mijnrabobank.nl domein als 'echt' doen overkomen.

Dus lijkt me niet relevant voor de discussie in dit deel van de thread.

[Jantjo]

Was ook een van de eerste dingen waar ik aan dacht toen ik dit nieuws item zag...

[HoppyF]

Mooi zo.
Kan dit ook met niet-Gmail clients bv Exim?
Niet iedereen wil/kan Gmail gebruiken maar wil wel graag weten of de afzender betrouwbaar is.

[JeroenED]

Lijkt mij eerder een front-end feature waarbij een lijst van geverifieerde afzenders hun logo krijgen. Dus als outlook of roundcube of rainloop soortgelijke feature implementeren heb je dit. Verificatie kun je doen adhv dkim-keys of andere zaken als pgp-signature.

[Dorank]

Exim is een MTA en heeft niets met de weergave in de MUA van doen.

[HoppyF]

Klopt, maar ik bedoelde dus of het ook zonder Gmail cliënt kan werken als je een eigen server gebruikt die op Exim draait en je daar met een cliënt gebruik van maakt.
Bv de mail cliënt die op een iPad staat en IMAP gebruikt.

[terabyte]

Het bedrijfslogo misschien (nog) niet, maar je kunt wel SPF policy checken.
Ik heb op mijn eigen (postfix) mailserver SPF en DKIM en DMARC ingesteld

[The Zep Man]

En haalt je mailserver 100%?

[DarkForce]

TLS 1.3 (de rest droppen en laten afhandelen via een fallback), SPF, DKIM, DMARC.TLSA en ja... je haalt 100% zelfs ondanks dat de fallback TLSv1.1/TLSv1.2 ondersteuning biedt.

Waarom via een fallback? Sja, juist om aan die 100% score te voldoen omdat sommige toko's te beroerd zijn om TLS 1.3 te ondersteunen

[Reactie gewijzigd door DarkForce op 23 juli 2024 17:16]

[mrmrmr]

Email klanten van zowel Google als Microsoft halen geen 100%.

Amerikaanse partijen zoals Google en Microsoft ondersteunen geen DNSSEC en DANE. Die zijn erg belangrijk om in de basis authenticiteit van internetverbindingen nagenoeg te garanderen.

@terabyte TLS 1.3 kun je gerust aan laten staan. Microsoft heeft nog steeds geen TLS 1.3 in schannel voor email, maar je hebt wel nog TLS 1.2 om op terug te vallen en daar werkt Microsoft wel mee.

Voor iedereen die bij Amerikaanse partijen zit: gebruik betrouwbare EU aanbieders!

[Scriptkid]

Waarom moet je complexe DNSSec of DANE doen als je gewoon simple SMTP STS kunt doen ?

[mrmrmr]

Het is een hardnekkig misverstand dat de twee hetzelfde doen, dat beeld klopt niet. STS heeft geen certificaat/signature en het gaat er van uit dat er databases van verzenders worden aangelegd bij het eerste contact. Dat vind ik niet simpel, het heeft haken en ogen en het is onvoldoende veilig.

DNSSEC werkt tegen MitM DNS aanvallen. DANE verbindt het STARTTLS certificaat met DNS, waardoor er een gelinkte beveiligingketting ontstaat. DANE biedt MitM security.

Gelukkig zijn er DNSSEC aanbieders in Nederland. Je hoeft het niet zelf te doen. DANE is een kwestie van toevoegen aan DNS bij certificaatwijziging, met een overlap. Het is feitelijk tamelijk simpel uit te voeren.

Overigens gaat dit pas werken als de DNSSEC/DANE controles ook daadwerkelijk worden uitgevoerd. Cryptografisch stelt het weinig voor, maar het is een kip en ei kwestie.

DANE is de missing link voor SMTP beveiliging.

Ik denk dat het geen toeval is dat juist bedrijven uit de VS zo lang wachten met DNSSEC. In onze streken is het veel meer geaccepteerd.

[Scriptkid]

weet niet waar je dat vandaan haalt maar STS doe exact het zelfde als DANE alleen dan via een HTTP call ipv een DNS call ??

Geen database voor nodig , de HTTP plain text file beschrijft welke certs er gebruikt mogen worden voor TLS

[mrmrmr]

Dan heb je opportunistische TLS terug bij STS, bij DNS (DNSSEC) niet zoals ik beschreef. Een MiTM aanvaller kan zelf HTTP, DNS onderscheppen, certificaten vervangen en nog meer truuks toepassen. Dat kan niet zo makkelijk als er sprake is van het cryptografisch vastklinken van het certificaat van de mail server via DNS (DNSSEC). DANE werkt voor zowel HTTPS als SMTP+STARTTLS.

[Scriptkid]

als hij https mimt kan kan hij ook je dnssec mimt spoofen, zelfde principe , Bijde zijn gebouwd om MIMT tegen te gaan.

je STS verteld je net als DANE welke certificaten van welke authority er vertrouwed zijn om te gebruiken voor SMTP,

Denk dat je in de war bent met hsts

[Reactie gewijzigd door Scriptkid op 23 juli 2024 17:16]

[mrmrmr]

Je verwart DANE met STS denk ik, het is omgekeerd. DNSSEC kun je niet spoofen, dat is gekoppeld aan root certificaten aanwezig op clients via signatures op certificaten.

anker: root certificaat
DNSSEC: DNS geauthenticeerd via root en tld certificaten
DANE: gesigneerd door DNSSEC
service: SMTP, HTTPS, POP3, etc. aangeduid met een (tcp) poort

Het mooie van dit systeem is dat je veel services op die manier kunt beschermen. Omdat alles via een beveiligde ketting gaat mag je ervan uit gaan dat het klopt. Absolute zekerheid bestaat natuurlijk niet, certificaathouders en ook certificate authorities kunnen beveiligingslekken vertonen.

STS zegt niets over welke certificaten of authority (CA), dat doet DANE wel, want die gebruikt cryptografie waarmee het certificaat die de mail server of web server gebruikt controleerd wordt. Zodoende kan een aanvaller niet even zijn eigen certificaat gebruiken. Met het CAA record kun je nog eens bevestigen wie de certificaat leverancier is (de CA).

De zwakheid zit hem vooral in de toepassing, er is implementatie nodig van zowel de server als de client zijde. De client moet controleren of DNSSEC/DANE responses kloppen en er geen downgrade aanval wordt gebruikt.

Zo ziet STS er uit:
_mta-sts TXT v=STSv1; id=2020010101;

https://mta-sts.example.org/.well-known/mta-sts.txt bevat:
version: STSv1
mode: testing
mx: mail.example.org
max_age: 604800

Geen cryptografie.

Zo ziet DANE er uit voor SMTP (mail.example.org:25)
_25._tcp.mail TLSA 3 0 1 70984c34e69270419b221bd102b069c1ad7358b7e873b6e30535df0419527488
En voor HTTPS (www.example.org:443)
_443._tcp.www TLSA 3 0 1 70984c34e69270419b221bd102b069c1ad7358b7e873b6e30535df0419527488

Er is een cryptografische koppeling met het certificaat dat de mail en web server gebruiken.

[Reactie gewijzigd door mrmrmr op 23 juli 2024 17:16]

[Scriptkid]

nee daarvoor vertrouw je op de CA lists die publicly trusted zijn dat is nu juist het hele voordeel,

Je STS record geeft aan welke certs domains vertrouwed zijn en samen gebruiken we alleen trusted root cert chains.

Als jij deze certs en chains niet meer kan vertrouwen dan is het net ze lek als bij DANE waar je de zelfde cert chain niet meer kan vertrouwen.

DANE start geen TLS sessie dus moet cert opnemen in de DNS chain, SMTP heeft al StartTLS dus het encrypte en vertrouwen laat SMTP TLS over aan StartTLS, SMTP STS verteld start TLS alleen nog maar welke domains er vertrouwed mogen worden en dus indirect welke certs er dor publieke vertrouwde CA`s afgegeven mogen zijn voor dat domein. Daar zit je trust stuk bij STS.

Meschien even anders naar het IETF doc kijken :
https://tools.ietf.org/id...-sts-12.html#introduction

SMTP STS is PKI authenticated en trusted mailflow.

Net als DANE PKI authenticated DNS is

[mrmrmr]

DANE is een toevoeging op de beveiliging van TLS. DNSSEC beschermt de contents van DNS verkeer.

Als MitM kun je gemakkelijk een ander certificaat aanvragen. Of DNS/HTTP queries afvangen of manipuleren.

Dat is een zwakheid in de CA structuur. DANE beschermd via DNSSEC zodat een aanvaller dat niet meer kan doen. Het certificaat is immers vastgeketend via het TLSA record.

De RFC waar je naar verwijst bespreekt een deel van de problemen in niet-heldere taal in secties 10.x, en het toont eveneens aan dat de auteurs geen oplossing hiervoor bieden en hier en daar wel noemen dat DNSSEC dat wel doet. Dat erkennen deze auteurs bijvoorbeeld in 10.2. Lees de hele 10 sectie maar eens nauwkeurig, het bevestigd wat ik eerder schreef. Ik heb wel een beetje moeite met de niet zo heldere verwoording.

"MTA-STS can thwart such [MitM] attacks only if the sender is able to previously obtain and cache a policy for the recipient domain, and only if the attacker is unable to obtain a valid certificate that complies with that policy"

Er dient dus voldaan te worden aan beide voorwaarden. De eerste is de database die ik eerder noemde (van bekende verzenders), en de tweede is dat de aanvaller slim genoeg is om een aanval te lanceren, maar op mysterieuze wijze niet weet hoe hij een certificaat kan aanvragen als MitM. Dat is een zeer onwaarschijnlijke combinatie. Letsencrypt bijvoorbeeld maakt het heel makkelijk certificaten aan te vragen in realtime.

Ik laat het verder hierbij. We kunnen de hele RFC wel uitspellen, maar dat verandert niet het feit dat DNSSEC+DANE met afstand de betrouwbaarste oplossing is.

[Scriptkid]

Maar daarin zit wel het key stuk, en zoals ik al aangaf zonder dat je hele DNSSEC implementatie hoeft te doen.

Dane vertouwed op dat DNS cert en de chain.

SMTP STS vertrouwd op het PKI stuk

hoe krijg jij een valided symantec cetificaat voor een domain wat jij niet beheerd, ???

Als je certificaten niet meer vertrouwed kunnen we het hele HTTPS ook wel gedag zeggen en zelfs bij Lets encrypt moet jij eerst domain ownership aan tonen voordat het cert word uitgegeven en zul je de lets encrypt servers dus via dns om de tuin moeten leiden.

[Reactie gewijzigd door Scriptkid op 23 juli 2024 17:16]

[terabyte]

Ik heb geforceerd TLS 1.3 vorig jaar uitgezet omdat mails verstuurd via Microsoft niet aankwamen..
En 100% ga ik niet halen want ik heb geen ipv6.

Dus geen 100% score zegt weinig over de kwaliteit van configuratie van mijn mailserver.

[The Zep Man]

Ik heb geforceerd TLS 1.3 vorig jaar uitgezet omdat mails verstuurd via Microsoft niet aankwamen..
En 100% ga ik niet halen want ik heb geen ipv6.

Dus geen 100% score zegt weinig over de kwaliteit van configuratie van mijn mailserver.

Je hoeft TLS 1.3 niet te forceren, enkel te ondersteunen. Met TLS 1.2+1.3 zit je goed.

Geen IPv6 is geen toekomstbestendigheid, dus ik snap wel dat ze dat meenemen en dat daardoor de score niet 100% is. Het zal in dagelijks gebruik geen invloed hebben, inderdaad.

[HoppyF]

Die van mij staat op 69%.
Kan dus beter.
Heeft zo te zien te maken met de twee mail servers, mijn eigen domein plus de backup server.
Wel een mooi overzicht wat er getoond wordt.

[mrbbs]

Alleen jammer dat Microsoft Office365 nog niet wil meedoen. Begin dit jaar meerdere malen aan de lijn gehangen maar ze willen er nog geen tijd in stoppen. Al zijn wij al klaar met de implementatie mocht het zover komen.

[raro007]

Het zou mooi zijn als Google Microsoft, Apple en proton mail samen werken op dit gebied

[fschuurman68]

Same here.

[mrmrmr]

Leg eens uit wat je dan hebt geimplementeerd, als je wilt.

[iKiddo]

Cool! Hopelijk een reden voor bedrijven om hun mail aan secure standaarden te laten voldoen.

[hErcuLEss]

Dit is toch al een tijdje zo. Bij mailtjes van bol.com en spotify staat er echt al weken of zelfs maanden het logo bij.