internet providers zijn zelf ook niet onschuldig hoor...

Het is niet zo eenvoudig omdat er geen duidelijke definitie van spam is en ook geen wetgeving dat dit "niet mag".
Je bent dus afhankelijk van wat die hoster zelf voor voorwaarden heeft, en voor bepaalde hosters is nou eenmaal het verdienmodel (wat ze ook adverteren) "klachten over misbruik negeren wij!". (bulletproof hosting)

Ik merk dat de spam die ik tegenwoordig krijg vaak afkomstig is van mailinglist bedrijven waar je klant kunt worden en een nieuwsbrief kunt laten mailen naar een lijst van adressen die je geupload hebt.
Dit zijn dan uiteraard hit-and-run klanten, er komen klachten bij het mailinglist bedrijf en dan worden deze klanten eraf gegooid maar er zijn tegenwoordig zo veel van die bedrijven dat ze een dag later weer ergens anders zitten.
En dit soort diensten (mailinglist outsourcing) verbieden of alleen toelaten als er goede klant validatie gedaan wordt dat staat vast niet op de agenda van de wetgever...

Dat kan twee verschillende oorzaken hebben: je spamfilter doet het niet goed voor een nieuw type spam of dat er daadwerkelijk meer spam is. Veel providers weigeren spam al voordat het wordt geaccepteerd via een blacklist. Die spam zie je dus nooit. Als er een nieuw botnet is, of een nieuw type spam kan het een tijd duren voordat de DNSBL's ze ook detecteren. Er was daadwerkelijk een nieuw type botnetspam de laatste maand.

De verplichting van certificaten is een goed idee, maar het helpt met name tegen botnet spam. Bovendien duurt het jaren voordat zoiets zou kunnen worden ingevoerd. Het is een goed idee omdat zo alle mail versleuteld wordt, en niet zozeer vanwege de authenticatie. Microsoft bijvoorbeeld doet niet aan DNSSEC en DANE. Ze blijven liever prutsen met andere methoden, misschien onder druk van 3-letter organisaties in de VS.

Eén type spam gebruikt sinds heel lang geleden een aan het domein gekoppeld certificaat. Dat soort spam probeert zich voor te doen als legitiem. Ze gebruikte al DKIM en SPF lang voordat het salonfahig werd. Ze kregen zodoende een positieve score in spam filters destijds. Dit spamtype kenmerkt zich door het verzamelen van persoonsgegevens via zogenaamde win-acties en het gebruik van veel verschillende wisselende IP reeksen. Spamhaus noemt het vanwege dat laatste snowshoe spam.
De domeinen die hierbij gebruikt worden zijn van de spammers zelf, ze kunnen dus zelf certificaten hiervoor maken. Dat is een belangrijke reden waarom certificaten het spamprobleem niet volledig zullen oplossen.

Er is een wettelijk kader we hebben niet voor niks het ACM (voormalige OPTA)
https://www.acm.nl/nl/onderwerpen/telecommunicatie/internet/veelgestelde-vragen-over-spam

Die bestaan reeds maar er is geen tijdindicatie waar men altijd aan moet voldoen dit verschilt per land.

Dus wat je hier zegt is dat er wel een wettelijkkader is maar deze niet effectief is. Ok dan waarom de eerdere beantwoording dat er een wettelijk kade moet komen.

Daarnaast het artikel ontbreekt een goede bronvermelding er is geen citaat van Jornt van der Wiel te vinden terug te lezen bij Kaspersky zelf enkel wat rtlnieuws neer heeft gezet. Nu wil ik de beste Jornt best geloven dat wij ergens plek 5 staan bij de door Kaspersky waargenomen spam over hun services. We stonden vorige jaar op de 6de plek bij hun en de strategische belangen van de nederlandse ligging qua datacenters wordt enkel belangrijker met de dag. Ook waarom Meta en Microsoft graag hun eigen DC hier hebben staan.

Geen idee echter wat we aan de informatie hebben behalve dat het weer leuk persbericht voor ze geeft.

Beheerders lezen fabrikant advisories niet fabrikanten blogs om te weten wat er speelt en ze kijken naar de threatlandscape. Als we alle artikelen zouden moeten geloven dan stond nederland zowel in de top 3 bij sommige fabrikanten en tegelijk bij andere niet eens in de top 10. Net zo nutteloos als de berichten dat een antivirus product nu in de top 3 staat van meeste veilige product. Het zegt niks zonder de relevante data erachter en crosschecks.

Niet eens mee. Hoofdoorzaken zijn naiviteit en kennisgebrek. Als iedere eindgebruiker snapt dat ze geen prijs hebben gewonnen of dat hun bank niet vraagt om gegevens in mail dan hadden we deze hele ellende niet gehad. Dan waren de criminelen al jaren gestopt met spammen gezien het ze dan meer kost dan opleverd.

https://www.troyhunt.com/extended-validation-certificates-are-really-really-dead/
Hier een artikel van een pseudo deskundige

Dat heet het struisvogel syndroom iets waar meer mensen last van schijnen te hebben die denken ergens verstand van te hebben zonder zelfreflectie vervolgens antwoorden negeren omdat deze niet overeenkomen met hun wereldje. Misschien ken je ook wel iemand in je buurt.

Of spamassassin op de mailserver vaar jou mailbox op gehost word is eindelijk weer eens geupdate. 80% van al het verkeer op onze mailservers zijn spam of phishing berichten. Maar die worden netjes door spamassassin herkend en verwijderd.

Het aantal spamberichten is vrij stabiel 1-5 per week.

Wie zegt dat de in Nederland staan?

Eigenaar van de hardware?
Eigenaar van het IP adres?
Eigenaar van het OS?
Wat al er een cloud mail server wordt gebruikt, bijvoorbeeld google, sendgrid?
Hoe weet je wie de eigenaar is?
Wat als er meerdere sites op de server draaien?

Ik mis nog wat onderbouwing en zie voornamelijk aannames.

Klopt. Een xertificaat, zoals meerdere keren je al gemeld is, lost niets op, nog afgezien dit voor gebruikers ook nog eens heel complex is.

Dat is niet de eigenschap van een web server certificaat. Je communicatie is encrypted, maar het zegt niets van wie de server of het web server certificaat is. Je aanname van een mail certificaat en een web server certificaat gaat al in de basis verkeerd.

Je gebruikt de verkeerde techniek voor je oplossing.
Extreme vergelijking: Trump die tornado's wou nuken. Of disinfect/licht gebruiken om in het lichaam tegen covid.

Tja... Als je niet wilt begrijpen wat nu eigenlijk een certificaat is of hoe dit gebruikt wordt en dan ook nog eens deze opmerking.

Misschien moet je toch maar eens de moeite nemen, om dat artikel waarnaar de link verwijst te gaan lezen, dan zal je jezelf realiseren, dat je een boel onzin hebt zitten schrijven. En zoek een hobby is mijn raad.
https://www.rtlnieuws.nl/tech/artikel/5265075/nederland-spam-spammen-onderzoek-kaspersky-anti-virus-mail

Absoluut een goed punt om te benoemen maar ik zal hem even aanvullen met het trainen van de Bayesian classifier als het tweede punt. En dat laatste doen de meeste bedrijven helaas niet laat staan dat ze snappen hoe ze dat moeten doen met sa-learn als het geen Ham, Spam foldertjes zijn.

Gevolg gezien meeste klanten zich ook niet aan mail ettiquete houden geen nette onderwerp gebruiken, handtekening vergeten inclusief afmeld link bij nieuwsbrief en correcte spelling achterwege laten dat de classifier die fouten steeds minder hoge score gaat geven want tja al die vreselijke fouten die bots maken maken je gebruikers ook maar die hebben vaak een negatieve score.


Als je als particulier echter veel spam krijgt eerste wat je beste kan doen is checken of je in een gelekte lijst staat.
https://haveibeenpwned.com/

Verder gebruik maken ten alle tijden van plus adressing of temporary mail domains als het eenmalige inschrijvingen betreft met geen gevoelige informatie.

Daarnaast blokkeren van tld's die je niet nodig hebt.
Geen contact met mensen en bedrijven op een .info? dan *@*.info in je blacklist.
Hier handige link omtrent spam trends. https://www.spamhaus.org/statistics/tlds/

En allerbelangrijkste regel als het spam lijkt open nooit het bericht tenzij je scripts uit hebt html uit staat en image loading ook. Want moment dat jij die mail aanklikt kan de spammer een signaal krijgen via tracking pixel dat er iets gelezen is en dat maakt je een aantrekkelijker target voor volgende spam campagne of doorverkoop van data.

Ik snap soms echt niet hoe mensen het voor mekaar krijgen om hun hele box vol spam te krijgen elke dag.
Ik ontvang gemiddeld 400 berichten per dag en ongeveer 10 per maand daarvan zijn spam en ook geclassificeerd as such.

Je reactie heeft interessante punten, maar het is Kaspersky die het over het wettelijke kader in Nederland heeft en niet ik.

Troy Hunt voorspeld in 2018 dat het einde van certificering aangebroken is althans hij heeft het over EV certificering, en nu bijna 2022 gebruiken websites nog steeds certificaten om de betrouwbaarheid te garanderen. Wat is dus je argument.
Hier bijvoorbeeld een ander mening van andere deskundigen:
https://www.leaderssl.nl/articles/233-het-verschil-tussen-ov-en-ev-ssl-certificaten

En de reactie op het artikel van RTL, is nogal kinderachtig, het strookt duidelijk niet met je eigen vooroordeel, dus ga je het artikel over Kaspersky ongeloofwaardig noemen.

Daarbij komt, dat tot op heden geen enkele reactie duidelijk heeft gemaakt, waarom e-mail certificering niet kan. Pseudo deskundige reacties, die vooral het kenmerk van selectief kersen pikken hebben.
https://comodosslstore.com/resources/how-an-email-certificate-works/
Het is een feit, dat e-mail certificaten wereldwijd door professionele certificaat aanbieders voor bedrijven en particulieren worden aangeboden.

Wat een vreselijke gruwelijke narigheid toch allemaal.

Door uw soort AOL mensen zit ik nog steeds regelmatig op allemaal koekiemeldingen OK te klikken, als ik even snel wat zoek.

Beseft u zich dat ongemak ook?

Misschien voortaan eerst checken dat je zelf weet waar je over praat voordat je iemand de les leest?

Een X.509 certificaat koppelt een public key aan identificerende gegevens middels een digitale handtekening (https://en.wikipedia.org/wiki/X.509).

Simpel gesteld kun je een certificaat vergelijken met een kopie van een identiteitsbewijs, waarbij de verzender bewijst dat zij of hij over het origineel beschikt. Dat zou kunnen als die kopie een onlosmakelijke (niet te vervangen) public key bevat, en het origineel de bijpassende private key. Dan kan de ontvanger een willekeurige tekst (of getal) naar keuze versleutelen met de public key (bijvoorbeeld "ozewiezewoze") en naar de tegenpartij sturen. Alleen de bezitter van de private key kan dat ontsleutelen en terugmelden: het geheime versleutelde woord was "ozewiezewoze". Nb. in de praktijk is dit proces ingewikkelder om MitM (Malicious in the Middle) aanvallen onmogelijk te maken.

Nadat een TTP (Trusted Third Party), op meer of minder grondige wijze, heeft vastgesteld dat de certificaataanvrager geautoriseerd is om dat certificaat aan te vragen namens de rechtmatige eigenaar van de identificerende gegevens in dat certificaat (en evt. heeft bewezen over de private key te beschikken die past bij de public key in dat certificaat), zet de TTP er een digitale handtekening onder. Als jouw browser of OS die TTP vertrouwt, wordt ook zo'n certificaat vertrouwd, en weet je van wie het is.

Overigens hoeft niet elk X.509 certifificaat een domeinnaam te bevatten, denk aan document- en/of code signing certificaten.

Een https servercertificaat bevat op z'n minst een domeinnaam (zoals www.security.nl). Zo'n certificaat kan aanvullende identificerende gegevens bevatten, zoals bedrijfsnaam, vestigingsland etc.

Een MIME certificaat bevat op z'n minst een e-mail adres als identificerend gegeven. Ook dit kan worden aangevuld met identificerende gegevens zoals volledige naam, telefoonnummer, woonadres of bedrijfsnaam.

Al vele jaren wordt, bij TLS-verbindingen, gebruik gemaakt van Forward Secrecy. In dat geval is het enige doel van een TLS servercertificaat (plus private key op de server) de authenticatie van die server.

Voordat gebruik gemaakt werd van Forward Secrecy, werd de public key in het servercertificaat tevens gebruikt om de door de client gegenereerde symmetrische sessiesleutel (bijvoorbeeld AES) versleuteld (met de public key uit het certificaat) naar de server te sturen, maar daar heb je de identificerende gegevens in het certificaat niet voor nodig (de public key volstaat).

Het nadeel van dat oude systeem is dat als bijv. de NSA of een crimineel jouw versleutelde TLS verkeer opslaat, en later ooit de private key van de server in handen krijgt, al dat versleutelde opgeslagen netwerkverkeer kan ontsleutelen (met de private key ontsleutel je het netwerkpakket met daarin de symmetrische sessiesleutel, en met die laatste kun je het sessieverkeer ontsleutelen).

Bij Forward Secrecy (middels het gebruikelijke Diffie-Hellman protocol) wordt, vereenvoudigd, voor elke sessie een tijdelijk asymmetrisch sleutelpaar gegenereerd waarmee de symmetrische sleutel wordt versleuteld voor transport. Het enige doel van het servercertificaat is dan nog authenticatie van de server - d.w.z. zonder dat MitM aanvallen mogelijk zijn.

De client identificeert de server aan de hand van de identificerende gegevens in het certificaat, waarna authenticatie van de server plaatsvindt doordat die server, middels een cryptografische berekening, bewijst over de bijpassende private key te beschikken (als de bijpassende private key niet gelekt is en de TTP betrouwbaar is, weet de client zeker dat het om de bedoelde server gaat).

Onzin. Het verschil is dat een MIME certificaat ten minste een e-mail adres bevat als "subject", en een https server certificaat ten minste een domeinnaam. Beide horen wereldwijd uniek te zijn. En ook als dat niet zo zou zijn (MitM direct op de verbinding, DNS-attack of een BGP-hijack), is er hooguit een beschikbaarheidprobleem: zolang een MitM niet over de bijpassende private key beschikt, zijn authenticiteit en/of vertrouwelijkheid behoorlijk goed gewaarborgd en zal er (normaal gesproken) een foutmelding worden getoond.

Het grootste probleem met certificaten zijn niet die certificaten zelf; je kunt er uitstekend mee aantonen (aan een ontvanger) dat jij bent wie je zegt dat jij bent. Het grootste probleem met certificaten is dat fraudeurs certificaten kunnen verkrijgen die (meer of minder) afwijken van jouw certificaat en het daarmee, in de praktijk, lukt om ontvangers ervan overtuigen dat het jouw (web server-, code/doc-signing of MIME-) certificaat is.

Bijvoorbeeld omdat ontvangers zich niet realiseren (of niet zien) dat security.ni niet hetzelfde is als security.nl, of dat bijv. erik.van.straten@bekende-mail-provider een ander kan zijn dan straten.van.erik@bekende-mail-provider - en sowieso een ander persoon kan zijn dan ik (er zijn meer mensen die zo heten, en ook als je niet zo heet kun je meestal wel een gratis e-mail account aanmaken met de naam van een ander, of naam die er op lijkt).

Aanvullende identificerende gegevens in een certificaat kunnen helpen, maar als ontvangers daar niet naar kijken (of software inzage in certificaten onmogelijk maakt, zoals Firefox onder Android), schiet je daar niets mee op. Integendeel, certificaten kunnen zo al snel een vals gevoel van veiligheid (lees: authenticiteit en/of vertrouwelijkheid) geven.

Gelukig krijg ik geen spam, behalve van mijn.overheid.nl en engie.nl.

Waarom? Ik gebruik geen gmail, hotmail of facebook, ik betaal voor mijn "postbus".

Dat kan dus niet, bijvoorbeeld de authenticiteit van een website zoals Security.nl wordt gegarandeerd door het rootcertificaat dat op onze computer staat, die deze eenvoudig uitgelegd, vergelijkt met publieke sleutel op de server van de website. In dit geval is dat DigiCert. en als dat klopt krijg je het slotje in de adresbalk.
Met een email certificaat gebeurt dat ook, dus namen veranderen of i.d zal nooit tot een geldige authenticatie leiden.

Dat bezoekers niet kijken of het slotje er wel is, dat is logisch, want dan ben je tijdens het rondsurfen nog wel even bezig, maar ten aanzien van email kan de authenticiteit gemakkelijk worden vastgesteld, door een melding in de webpagina (webmail) of in Thunderbird en Microsoft Outlook zoals dat al mogelijk is.
Voor wie het in kleine kring wil proberen, kan ik XCA ( X.509 certificates) aanbevelen, die o.a. ook gratis in de Microsoft store aangeboden word.

Wat jij maar niet wilt snappen is dat namen zodanig veranderd kunnen worden dat de gebruikers niet zien dat ze veranderd zijn, of zich niet realiseren dat ze niet naar hetzelfde bedrijf verwijzen.
Bijvoorbeeld in het voorbeeld wat Erik gaf: op veel computers lijkt een i heel erg op een l vooral als je een hoog resolutie scherm hebt of niet (meer) zulke beste ogen.
Dus je kunt heel makkelijk denken "oh dat is security.nl" als er security.ni staat en dus misleid worden.

Bovendien is er nog een 2e laag van problemen: veel bedrijven beperken zich niet tot 1 domeinnaam op internet, en je hebt dus niets aan het vergelijken van die domeinnaam. Als je mail krijgt van ING dan kan het best zijn dat dit niet komt van mailadres@ing.nl maar dat ze daar een apart domeintje @ingmail.nl voor hebben aangemaakt. Hoe moet je nou weten of ingmail.nl wel of niet van ING is? Ik kan zometeen dat domein registreren en jou mail sturen met een hoop certificaat toeters en bellen, en dan weet je zeker dat dit van ingmail.nl komt maar wat zegt dat dan verder?

Er zou dan eerst een register moeten komen wat automatisch door mailprogramma's doorzocht kan worden en wat de gebruiker vertelt "ja hoor als je mail krijgt van ingmail.nl dan is dat van de ING bank die je denkt dat het is".

Zonder zo'n soort extra lookup zijn certificaten totaal nutteloos want iedereen kan ze aanvragen voor eigen domein.

Dat kan best wel zijn maar als jij mij een mail stuurt die met een certificaat encrypted en ondertekend is, en mij mail programma zegt "ja deze mail is gestuurd door waterlelie" dan weet ik toch nog steeds niet wie hem gestuurd heeft?
Idem als er staat "deze mail is gestuurd door ING". Dat kan toch net zo goed ing.me zijn, een heel ander bedrijf?
En denk nou niet "banken in Nederland gebruiken toch geen .me domein??" want dat doen banken in Nederland WEL.
Bijvoorbeeld "tikkie.me" is een door een Nederlandse bank gebruikt domein. Debiel, ik weet het, maar ze doen het wel.

Dus een certificaat checken is niet zo simpel als jij denkt, wie het uitgeeft zegt niks.

Ja, maar je leest nog steeds niet wat ik schrijf.

Nogmaals, het probleem is als volgt. Stel ik wil toegang tot jouw security.nl account en op de een of andere manier heb ik jouw e-mail adres achterhaald. Dan zou ik bijvoorbeeld de domeinnaam security.ni, security.nl.mailservices.com of xn--securty-cza.nl kunnen registreren (er bestaan meer trucs).

Nb. de meeste browsers laten die laatste domeinnaam zien als security.nl met een meer of minder onopvallend schuin streepje op de i (je zult maar slechtziend zijn), iets dat ik in deze tekst niet kan laten zien omdat dit forum dat blokkeert (onder andere in https://www.verisign.com/en_US/channel-resources/domain-registry-products/idn/idn-conversion-tool/index.xhtml kun je dit zichtbaar maken).

Vervolgens huur of hack ik een webserver en koppel diens IP-adres aan genoemde domeinnaam. Daar kan ik vervolgens probleemloos een https server certificaat voor verkrijgen (Let's Encrypt is gratis, snel en letterlijk no questions asked). Daarna kopieer ik de website van security.nl daarnaartoe (of gebruik een tool zoals modlishka, evilginx etc). Ik installeer er ook een mailserver op, en maak er een account op aan genaamd redactie@ of iets dergelijks. Ook voor dat e-mail account kan ik vervolgens probleemloos een MIME certificaat verkrijgen (zelfs gratis als ik me niet vergis).

Klopt, maar ik verander helemaal niks; ik kan eenvoudig een geldig certificaat verkrijgen voor redactie@ een domeinnaam die lijkt op security.nl.

Daarmee stuur ik jou een mail waarin bijvoorbeeld staat dat er veel mislukte inlogpogingen op jouw account zijn gedaan, met het verzoek om jouw wachtwoord te wijzigen in een langere versie die niet voorkomt in bekende dictionaries (zoals gepubliceerd door haveibeenpwned.com) en vraag jou op de link in de mail te klikken (die direct of via een URL-shortener etc. verwijst naar de valse domeinnaam). Zodra jij daarop klikt en "inlogt", weet ik jouw wachtwoord.

Dit is geen probleem met de certificaten zelf, maar vooral met ontvangers (in dit geval jij) die niet in alle gevallen de domeinnaam checken of zich niet realiseren dat security.nl.mailservices.com niets met security.nl te maken hoeft te hebben.

Ook DNS-registrars en certificaatuitgevers valt iets te verwijten, namelijk dat zij phishers bedienen. Aan de andere kant kan dat lastig zijn: is ervaringen-met-abn-amro.nl een phishing site of niet?

Naast dat de meeste mensen geen idee hebben wat het nut en doel is van certificaten (notabene zelfs regelmatige bezoekers van deze site snappen er duidelijk niets van) weten de meesten niet dat je zo'n ding kunt inspecteren, noch wat al die informatie betekent. Het uiteindelijk grootste en m.i. deels onoplosbare probleem blijft echter dat:
1) mensen domeinnamen niet grondig checken, en als zij dat wel doen,
2) niet weten dat de gecheckte domeinnaam niet van de gesuggereerde organisatie is.

In Nederland ken ik dit fenomeen niet, maar in China had (heb?) je winkels waarop stond dat zij een officiële Apple winkel waren. Wat als jij op vakantie jouw pinpas in een geldautomaat stopt, jouw pincode invoert en in beeld "Muchas Gracias" verschijnt, er geen geld uitkomt en jij ook jouw pinpas niet terugkrijgt? M.a.w. hoe weet je dat iets niet fake is?

Bijv. in https://github.com/mitchellkrogza/Phishing.Database (klik "view code") kun je lijsten vinden met o.a. recente en aktieve phishing links. Dat zijn er veel. Oftewel, phishing werkt. Mensen zijn goed van vertrouwen en de pakkans is bijna nul.

E-mail adressen vergroten dat probleem omdat je dan zowel van de domeinnaam moet weten dat deze van de juiste organisatie is, en bij mail-providers als gmail.com en outlook.com moet je de exacte spelling van de accountnaam controleren en kennen (ongeacht welke "real life" naam daar door de afzender bij vermeld wordt).

Certificaten lossen dit probleem niet op. Want hoewel zij wel bewijzen dat X is wie hij zegt dat hij is, bewijzen zij niet dat lijkt-op-X iemand anders is dan X.

Je probeert je stelling dat iemand onzin schrijft te onderschrijven met een artikel over Kaspersky over spam. Kaspersky is geen spamdeskundige. Ja, ze weten wel wat over malware (voor het technische deel), maar spam hebben ze nooit begrepen. Daarnaast herken ik de in het artikel geponeerde stellingen totaal niet en komt de term misinformatie bij mij op. Dat is niets nieuws, Kaspersky heeft een lange geschiedenis van het mixen van feiten met slecht onderbouwde meningen, die vooral weerspiegelen hoe in Rusland zaken worden geregeld.

Je maakt mij niet wijs dat je werkzaam bent in IT security. Je kennis bestaat uit wikipedia en google searches. Een klein beetje kennis is gevaarlijk en het is dan een slecht idee om iemand anders de les proberen te lezen.

En wat als ik de volgende domeinnamen nu eens ter beschikking heb om te mailen en een https website neer te zeggen?
secur1ty.nl?
securlty.nl
mysecurity.nl
security.eu
security.sec
security.co.uk

Hoe zit een normale gebruiker nu precies het verschil tussen een goede of slechte website/email?

Dat is niet mijn ervaring. Ik heb al vele jaren een eigen persoonlijk domein, en voor elke webwinkel of andere plek waar ik een e-mailadres moet afgeven maak ik een uniek adres aan. Ik heb werkelijk nog nooit spam ontvangen op een van die unieke adressen. Ik krijg eigenlijk alleen maar heel af en toe spam op het info-adres dat ik nergens voor gebruik.

Los daarvan: aan je vet gemaakte kopjes is te zien dat je op de hoogte bent van bb-codes. Waarom maak je dan de url in je post niet klikbaar met de url-tag?

Het email adres van security.nl is "redactie@security.nl". Laten we nu eens aannemen, dat die dit mailadres met een email certificaat hebben beveiligd, en dit certificaat aan het rootcertificaat van "DigCert hebben verbonden. Dat rootcertificaat van DigiCert staat al alle computers.

Als ik de email wil ontvangen met Thunderbird, zal ik het rootcertificaat vermoedelijk handmatig in het certificatenbeheer van Thunderbird moeten opnemen. Voor het ontvangen van Gmail via de browser, zal ik een betaal account moeten afsluiten, want de gratis Gmail accounts laten geen authenticatie middels een certificaat toe.

Als Security.nl nu een email stuurt vanaf de computer in hun bedrijf, dan zal degene die de email schrijft, eerst op de mailserver inloggen, en de email als die klaar is naar mij sturen. Automatisch wordt dan het bericht ondertekend, en de publieke sleutel van het certificaat meegestuurd, en als ik deze mail ontvang, zal mijn emailclient (Thunderbird) de aanwezigheid van de publieke sleutel van "redactie@security.nl" detecteren, en kijken of er een match is met een rootcertificaat, en als dat zo is, zal er een melding daarover in Thunderbird verschijnen, en als ik daar op klik, krijg ik de melding dat deze email afkomstig is van "redactie@security.nl".

En iedere verzender van een email met als afzender "redactie@security.nl" of zoals je wilt "redactie@securIty.nl" dat niet van die mailserver is verzonden, en of niet correct is geschreven wordt als vals aangemerkt. Hierbij maakt het niks uit, of de redacteur vanaf zijn huis werkt, of in het bedrijf zelf, als hij of zij inlogt op de mailserver van Security.nl, dan staat vast, dat die email daarvan af is verzonden.

Ja dat gedeelte van het probleem is simpel. Dat lost DKIM+DMARC nu al op, als je een fatsoenlijke mail provider hebt die deze protocollen checked.
Maar wat nu als jij ineens een mail binnen krijgt van redactie@security.ni of van redactie@security.eu of whatever en jij zit niet op te letten en je denkt "dat komt van de redactie van...".
Daar helpt een certificaat dan niks tegen. Net zoals DKIM+DMARC daar niet tegen helpt.

Om die reden werkt het alleen goed als het op kleine schaal gebruikt wordt voor bepaalde repeterende vertrouwelijke communicatie tussen twee security bewuste partijen.
Als "de hele wereld er mee werkt" dan functioneert het niet meer.

@waterlelie: je leest nog steeds niet wat ik schrijf.

Bovendien:
Er zijn 2 plaatsen waar e-mails ondertekend kunnen worden (bijv. met een private key passend bij de public key in een MIME certificaat):
1) in de mail client, dus op persoonlijke titel
of/en
2) door de uitgaande mailserver van de organisatie.

Als ik het domein securIty.nl registreer en daar een mailserver op zet, is dat mijn domein en kan ik er geldige certificaten voor krijgen (type 1 en 2), die jouw mail-programma niet als vals zal vlaggen, want dat zijn ze niet. Ook SPF, DKIM, DMARC, ARC en whatever helpen niet: ik ben dan de enige echte "redactie@securIty.nl" en mijn mails worden daadwerkelijk verzonden vanaf de mailserver met domeinnaam "securIty.nl".

Als de echte security.nl van type 2 gebruik maakt, en ik hack een account van één van de medewerkers van security.nl, zullen mijn mails via dat account door de mailserver van security.nl worden ondertekend. Waarschijnlijk krijg ik niet de private key van die medewerker (noch van de server) te pakken, dus kan ik mij niet als die persoon voordoen (de mails zullen niet ondertekend zijn met diens private key) - maar wel als het generieke "redactie" of "no-reply", met signature type 2.

Exact dat laatste scenario beschreef ik eerder in https://security.nl/posting/733117 voor het onlangs gehackte e-mail account bij de gemeente Ede:

Daaronder (in https://security.nl/posting/733127) reageerde je daarop met:
Sja...

Het is dat ik niet rancuneus ben en geloof dat je het beste wilt, maar als je niet luistert naar ervaren oude rotten kom je er niet.

Daarom werk ik met een white-list die alle gekende mailadressen omvat. De whitelist bevat automatisch de mailadressen die in mijn adresboek staan en adressen waar ik al eerder iets heen gestuurd heb.

Mail die niet in de whilelist staat komt niet in mijn in-box, maar in een 'quarantaine box'. Deze mail controleer ik extra en indien de afzender goedgekeurd is, wordt hij aan de whitelist toegevoegd.

Weer een variant van Cunningham's law . Hoe dommer de vragen(steller), des te beter en uitgebreider de antwoorden .

Applaus voor je geduld - ik heb een stuk minder vaak zin om parels voor de zwijnen te gooien.

Ja maar dat werkt alleen maar voor mensen die gemiddeld met een beperkt kringetje communiceren, en die zorgvuldig zijn bij het invoeren van nieuwe personen/adressen in dat kringetje.
Voor het "algemene probleem" is dat niet echt een oplossing, want als je veel nieuwe adressen moet checken dan verslapt op een gegeven moment de controle (zeker als je onder tijdsdruk staat) en als je al niet helemaal weet waarop je moet controleren (wat voor de meeste mensen zal gelden) dan werkt het ook niet erg goed.
Plus dat je er van afhankelijk bent dat de verzenders van mail aan jou hun anti-spoofing (DMARC/DKIM/SPF) goed hebben ingeregeld EN dat jouw mailsysteem deze zaken controleert en flagged.

@Briolet: wellicht handig voor jou, en misschien heb je ooit eerder een e-mail van iemand bij security.nl gehad. Maar wat als dat niet zo is en je ziet de mail in jouw "quarantaine box", is het dan 100% uitgesloten dat je daar intrapt? En wat als het account van een bekende afzender gehacked is en de phishing mail in jouw inbox belandt? Als je er maar genoeg aan gewend bent dat mails in jouw inbox betrouwbaar zijn, kan zo'n "quarantaine box" averechts werken (net als spamfilters die zelden spam en phishing mails doorlaten).

Bovendien is zo'n systeem m.i. niet werkbaar voor organisaties die voortdurend e-mails van wisselende afzenders ontvangen (gemeenten van burgers, personeelszaken van sollicitanten, advocaten en andere dienstverleners van potentieel nieuwe klanten, administraties van nieuwe leveranciers, wetenschappers van onbekende collega's en ga zo maar door).

En sowieso hebben doorsnee mensen (en het MKB) niet de kennis en middelen om zoiets op te zetten en te onderhouden - nog los van de vraag hoe vaak zij in hun spambox kijken en waarschijnlijk boos worden als een belangrijke/beloofde mail van een nieuwe afzender (waar ze bijv. net mee hebben gebeld) niet in hun inbox verschijnt.

Wat je hier zegt, is dat je een geldige domeinnaam registreert, dat lijkt op die van "redactie@security.nl", maar één letter verschilt, "redactie@securlty.nl" daaraan een geldig certificaat zeg maar bij DigiCert koopt, net als Security in dit theoretische voorbeeld ook heeft gedaan. en dan een email aan mij zou sturen, en deze ondertekend met het certificaat dat je daarvoor dus bij DigiCert hebt gekocht, en daarvan de publieke sleutel meestuurt, dan zal ik als ontvanger het verschil in de naam niet opmerken. Dat is inderdaad meer dan reëel, en laat hoe spijtig ik het ook vind, voorlopig certificering als ultieme beveiliging van email afvallen.

@waterlelie: ik heb met veel respect jouw reactie van 17:42 gelezen!

In specifieke sectoren hebben versleuteling en ondertekening van e-mails (nog) wel zin. Helaas zal het massaal inzetten van MIME certificaten nauwelijks bescherming bieden tegen phishing (en mogelijk zelfs averechts werken).

Desalniettemin dank voor jouw inzet! Laat je niet uit het veld slaan; ook ik heb "briljante" ideeën gehad die achteraf toch niet zo goed waren als ik aanvankelijk dacht. Het is een leerproces...

Wat wel kan helpen tegen phishing, is aan potentiële slachtoffers uitleggen waar zij op moeten letten. Een aantal tips:

Ik laat wel eens, naast elkaar op één scherm, 2 screenshots van een webbrowser zien, één met een phishing site en de andere met de echte site. De meeste mensen aan wie ik vraag wat de echte en wat de fake site is, kijken niet naar de URL-balken, maar zoeken verschillen in de pagina's zelf.

Als ik uitleg dat (en waarom) ze naar de domeinnamen moeten kijken, vragen de meesten (terecht): hoe weet ik wat de juiste domeinnaam is? En dat is een lastige vraag met ingewikkelde antwoorden.

Het helpt als je zorgt dat je jouw belangrijkste inlogpagina's in favorieten (ook bekend als bookmarks, snelkoppelingen of shortcuts) hebt opgenomen. Als je op een link in een e-mail (of appje, SMS of getoond op een mogelijk onbetrouwbare website) hebt geklikt (of een QR-code hebt gescand) waarna een schijnbaar bekende inlogpagina opent, sluit die dan en heropen de (echte) pagina via de favoriet daarvoor.

Als je geen favoriet hebt voor een site die je wilt bezoeken (waar je de exacte domeinnaam van kent), vooral als je het (open) WiFi netwerk van een ander gebruikt: tik dan altijd https:// voor de domeinnaam van de site waar je naar toe wilt (tik niet ing.nl maar tik https://ing.nl). Dan dwing je elke browser om niet (eerst of als tweede) http:// te proberen, waarbij de verbinding gekaapt kan worden en je naar een andere https site gestuurd kunt worden.

Terzijde:

Sowieso is het gebruik van favorieten altijd veiliger dan sites opzoeken door hun domeinnaam in een zoekmachine in te tikken - mits de URL's in je favorieten allemaal beginnen met https://.

Als de browser het uitzetten van IDN (International Domain Names) ondersteunt, zet dat dan uit. In Nederland gebruiken we zelden of nooit IDN's. Uitzetten kan wel een nadeel zijn als je soms of vaak buitenlandse sites bezoekt met domeinnamen met allerlei leestekens op letters of andere schriften zoals Cyrillisch.

Als je support voor IDN'd uitzet, betekent dit dat je Punycode aanzet. Punycode bestaat uitsluitend uit Amerikaanse ASCII letters die worden ondersteund door DNS (DNS kan niks met letters met diakritische tekens, zoals é, ê, è of ï, maar ook een heel stel andere Unicode karakters (letters, symbolen etc.) waarvan ik de meeste niet kan laten zien op dit forum, zoals een i met een schuin streepje in plaats van het puntje op de I).

Punycode domeinnamen beginnen altijd met xn-- en zijn dus goed te herkennen. Voor de duidelijkheid, bij het volgende voorbeeld gaat het om dezelfde domeinnaam:


Om te weten of jouw browser IDN's ondersteunt (toont) kun je de bovenstaande IDN (sécurité.nl) naar de URL balk van jouw browser kopiëren (en er voor de veiligheid https:// voor zetten) en op Enter drukken (op dit moment bestaat die site niet, dus krijg je een foutmelding). Als daarna in de URL-balk nog steeds sécurité.nl te zien is, ondersteunt de browser IDN's; als dit veranderd is in xn--scurit-bvaf.nl, ondersteunt de browser geen IDN's (en toont dus de Punycode variant). In dat laatste geval zijn phishing sites die van internationale lijkt-op-letters gebruikmaken, eenvoudig te herkennen doordat de domeinnaam met xn-- begint, zeer ongebruikelijk bij sites bestemd voor Nederlandse bezoekers (vooral als de domeinnaam eindigt met .nl).

Als je, bijv. na het klikken op een link (of scannen van een QR-code) op een onbekende site uitkomt waarop je gegevens moet invullen, is het verstandig om eerst de domeinnaam via het klembord te Googlen (een andere zoekmachine gebruiken kan natuurlijk ook). Als de zoekmachine een spelfout vermoedt (voorbeeld: mediamartk.nl) of je sowieso weinig hits hebt, gaat het waarschijnlijk om een fake site.

Je kunt, in elk geval met Google, de zoekopdracht beginnen met site: (zoals site:securlty.nl) om te kijken welke pagina's (en subdomeinen) van die site Google geïnventariseerd heeft; in tegenstelling tot echte sites hebben phishingsites zelden veel pagina's. En als ze meerdere pagina's hebben, zijn dat vaak andere phishingpagina's, of pagina's met ongerelateerde (of schijnbaar willekeurige) teksten.

Als je een domeinnaam intikt, check dan eerst op spelfouten. Bijvoorbeeld mediamartk.nl is ooit een phishingsite geweest.

Goede oplossingen zijn helaas schaars. Vooral ouderen vertrouwen hun medemens. Helaas is dat vertrouwen online (en telefonisch) te vaak onterecht (alhoewel steeds meer hufters ook gewoon aanbellen, bijv. om je doorgeknipte pinpas op te halen). Meer dan onze best, om hen te beschermen, kunnen we niet doen.