Let's Encrypt (en andere DV-cert-boeren) bieden schijnveiligheid. Internetters mogen het helemaal zelf uitzoeken of een domeinnaam wel of niet van een bedoelde organisatie is, en daar bestaat geen eenduidige procedure voor.

Erger, DV-boeren faciliteren cybercrime doordat zij, met enorme oogkleppen op, certificaten blijven uitgeven aan duidelijk voor phishing bedoelde domeinnamen, zoals login.mlcrosoft.support (zie [1]) en microsofloffice365.com ([2]; ik ken nog véél meer voorbeelden).

[1] https://crt.sh/?q=login.mlcrosoft.support
[2] https://crt.sh/?q=microsofloffice365.com (al 24x, hardleers?)

Speelgoedcertificaten zijn het. Webbrowsers zouden internetters moeten waarschuwen bij DV-certs, maar in plaats daarvan hebben ze EV-certs in de ban gedaan.

Phishing is mogelijk het grootste cyberrisico op internet, en we doen er niks aan dat structureel helpt.

Hiervoor is de FIDO2 WebAuthn standaard ontwikkeld. Die voorkomt nagenoeg alle vormen van phishing.

aka.ms bijvoorbeeld?
youtu.be misschien?

Domeinen waarvan jij denkt dat het duidelijk phishing domeinen zijn, blijken in de praktijk relatief vaak door de betreffende organisatie te zijn aangevraagd.

Daarnaast kunnen organisaties zelf heel goed (laten) controleren of voor dergelijke domeinen certificaten zijn aagevraagd. Dat doen ze ook niet.

Als laatste blijken er gewoon organisaties te zijn in land X waarvan de naam overeenkomt met een organisatie in land Y. Wie beslist dan of organisatie.X uitgegeven mag worden als organisatie.Y al bestaat?

Peter

Letsencrypt is een @#$@#$ bedrijfje, zelfs als je een dry-run doet geven ze je hostname aan google.

euh... dat is zo'n beetje iedere grootte CA op dit moment via Certificate Transparency logs. Want het is voor alles en iedereen zichtbaar, inclusief Google.

Dus ik weet niet waar jij je precies druk om maakt.

Hoera een certificering voor je certificering zodat je een certificaat kan aanvragen..
Blij dat het voor ze gefixed is minder blij dat we weer DNS troep erbij krijgen.

Het lijkt erop dat op deze site vooral cybercriminelen reageren die, met eenvoudig te pareren argumenten (maar daar moet ik dan wel elke keer tijd voor hebben en de moeite voor willen nemen) willen dat er niks verandert, en als er wat verandert, dat dit zoveel mogelijk in hun voordeel is.

Nee, de FIDO2 WebAuthn standaard is niet ontwikkeld om aan te tonen dat een website van een bedoelde organisatie is, en bovendien voorkomt een FIDO2 hardware key -afhankelijk van de definitie van phishing- in veel meer gevallen dan wordt gesuggereerd niet dat slachtoffers vertrouwelijke informatie met onbedoelde partijen delen of dat zij op andere wijze in een val trappen waardoor phishing alsnog mogelijk is.

Daarnaast ondersteunen (nog) maar heel weinig websites WebAuthn en zijn hardware keys gedrochten van dingen voor doorsnee internetters (want het is bezopen dat je minstens 2 keys moet hebben om account-lockout te voorkomen bij verlies of defectraken van één daarvan, en ook nog eens dat je er zelf om moet denken om ze "gesynchroniseerd" te houden - wat zuigt als het advies luidt om altijd één exemplaar in een kluis te bewaren).

M.b.t. authenticatie van websites, in de volgende situaties heb je NIETS aan jouw FIDO2 hardware key (of passkey):

1) Websites waarop je geen account hebt maar vanwege de aangeboden informatie, links en downloads, wilt weten of die website authentiek is - in de zin van "wie is de eigenaar" en is dat een mij bekende en daardoor vertrouwde partij (bijvoorbeeld omdat die partij een bepaalde reputatie heeft opgebouwd);

2) Websites waarop je nog geen account hebt maar wel wilt aanmaken. Zoals voor een PGO (zie [3] en de verwijzingen daarin; zowel https://vitaalbank.nl/ als https://mijnpgo.org/ (anderen heb ik niet gecheckt) gebruiken Let's Encrypt certs en zijn dus, als je niet de exacte domeinnaam kent, niet te onderscheiden van identieke websites met afwijkende domeinnamen.

3) Zodra jouw paspoort op jouw smartphone staat [4], willekeurige websites die willen dat jij authenticeert zonder dat jij weet bij wie je dat doet noch of zij, met jouw identificatie, niet als AitM (Attacker in the Middle) met jouw identiteit op een heel andere website (en wellicht voor een heel ander doel) als zijnde jou authenticeren. Bijvoorbeeld zo een lening op jouw naam afsluiten en cashen. Overigens heb ik medewerkers van de Wallet-ID en IRMA aangeraden ([5], "Plus" artikel) om, naast de identificerende gegevens die met een private key op de client worden ondertekend, tevens het https certificaat van de vragende website op te nemen en op te sturen. Bij een AitM-aanval (via een "evil proxy") kan de feitelijke RP (Relying Party, effectief de identiteit validerende site) zien dat de browser (of andere app) niet hun certificaat onder ogen had. Een mogelijk "nadeel" hiervan zijn problemen door "legitieme" TLS inspectie.

4) Een nepwebsite met (licht) afwijkende domeinnaam die je laat inloggen met WebAuthn en meldt dat er iets mis gaat, en vervolgens vermeldt dat er iets mis lijkt met jouw hardware/passkey en je daarom op alternatieve wijze moet inloggen.Nb. dit heeft alleen zin als die alternatieve inlogmanier ook mogelijk is op de echte inlogpagina, maar heel vaak is dat het geval.

5) Als jouw client device gecompromitteerd is.

[3] https://security.nl/posting/778360

[4] https://tweakers.net/nieuws/204604/irma-ontwikkelaar-sidn-neemt-deel-aan-eu-pilot-voor-digitale-identiteitswallet.html?showReaction=18254976#r_18254976

[5] https://tweakers.net/nieuws/204138/nederland-krijgt-een-paspoort-voor-op-internet-hoe-gaat-dat-werken.html?showReaction=18259126#r_18259126

Aanvankelijk hadden https servercertificaten twee doelen:
a) Authenticatie van de website én de eigenaar;
b) Veilig transporteren van de symmetrische sessiesleutel via de, nog onversleutelde, verbinding.

Doel b) is (al jaren geleden) komen te vervallen sinds forward secrecy wordt gebruikt (via de Diffie-Hellman key agreement methode). De public key in moderne https servercertificaten mag niet eens meer gebruikt worden voor versleuteling, maar uitsluitend nog voor het valideren van digitale handtekeningen. Daarmee hebben moderne https servercertificaten niets meer te maken met de versleutelde verbinding tussen browser en webserver, maar dienen uitsluitend ter authenticatie van de server. Dat we daarbij authenticatie van de eigenaar achterwege menen te kunnen laten, is een blunder van jewelste - cybercriminelen lachen zich rot.

Je zwamt.
https://www.virustotal.com/gui/domain/login.mlcrosoft.support
https://www.virustotal.com/gui/domain/microsofloffice365.com
Ook recent: findappledevice.info,
www-xiaomi.com etc. etc.
Zie https://github.com/mitchellkrogza/Phishing.Database/blob/master/phishing-domains-NEW-today.txt (een klein deel daarvan zijn gecompromitteerde websites, dus domeinnamen die niet door cybercriminelen zijn geregistreerd).

DRY-RUN <<<<<<< dat betekend er hoort helemaal niets ergens opgeslagen te worden.

En sinds wanneer moet er voor een log entry ergens, een dns request worden uitgevoerd?

Het was goed geweest als ze gewoon certificaten in 2 delen hadden opgedeeld zoals eerst het geval was, waar het geregistreerde bedrijf zo'n groen textje kreeg voor de domein naam.

Dan had je gewone certificaten die iedereen kon aanmaken, en certificaten waarvoor je een background check moest doorlopen.

Ik zou graag iets in die vorm zien terugkomen.

Compromitering gaat door, ook al denk je weer terug veilig te zijn.
Al te goed is de certificeringsgek.

Er bestaan zelfs/nog steeds 3 verschillende soorten https servercertificaten:

1) DV (Domain Validated)
2) OV (Organization Validated)
3) EV (Extended Validation)

Maar met die verschillen schiet je niks op als browsers geen onderscheid meer laten zien.

Met Firefox onder Android kan ik nog net zien wie de uitgever is van een certificaat, maar niet aan welke organisatie het certificaat is afgegeven (ook niet als dat in het certificaat is opgenomen).

"Google safe browsing" blokkeerde vanmiddag hxxps://realest0022-secondary.z13.web.core.windows[.]net/ niet, en zojuist nog steeds niet (lekker betrouwbaar). Bovenin de pagina zie ik een felblauwe balk met witte wolkjes en "OneDrive". Daaronder:

En daaronder een veld om je e-mailadres in te vullen en een "Next" knop. Ik heb een niet bestaand mail adres bij outlook.com ingevuld en "Next" gedrukt, waarna de "Next" knop vervangen werd door een wachtwoordveld en een "Sign In" knop. Een onzin-wachtwoord leidde binnen 1 seconde tot de melding "Wrong password! Please try again". Dit is dus waarschijnlijk een "evil proxy" die mogelijk ook met TOTP 2FA codes kan omgaan (zie https://www.security.nl/posting/778668/TOTP+Authenticators+drama).

Case in point: toen ik met Firefox voor Android op het slotje drukte en vervolgens op > rechts van "Connection is secure", zag ik: "Verified by: Microsoft Corporation". Ik ben niet verbaasd dat sommigen (velen?) die een e-mail met een link naar zo'n "OneDrive" pagina ontvangen, hier intrappen (no thanks, Microsoft).

Onder iOS 15.x weet Firefox niets meer te melden dan "de verbinding is beveiligd" als je op het slotje drukt, en Safari vertelt je zo mogelijk nog minder.

Waarom zou je als organisatie nog moeilijk doen en veel geld uitgeven aan OV of EV certs?

We zitten, qua betrouwbaarheid van het internet, in een neerwaartse spiraal - en bijna niemand lijkt zich daar wat van aan te trekken. We digitaliseren steeds verder op drijfzand.

Heel mooi verhaal van Let's Encrypt. Ik zie echter legio voor beelden dat er Let's Encrypt certificaten aangevraagd worden voor domeinnamen die een CAA record hebben waar de naam Let's Encrypt niet in voorkomt...Dus Let's Encrypt lapt de regels aan zijn laars of negeert de DNS standaard CAA.

@erik Even los van het in het artikel beschreven issue met MITM kwetsbaarheden bij een initiele aanvraag, ik begrijp niet waarom je blijft ageren tegen DV tls-cerificaat verstrekkers. Een tls-certificaat is eigenlijk niets meer dan één van de componenten die wordt gebruikt een een versleutelde verbinding tussen een browser en een webserver op te zetten. (net als een webserver,browser software, dns server etc). De DV certificaat leveranciers verkopen geen identificatiemiddel, ze verkopen een stukje code dat momenteel noodzakelijk is om een tls verbinding tussen browser en server op te kunnen zetten.

Dezelfde kritiek die je hebt op de certificaat leveranciers zou je daarom ook kunnen hebben op de domain verkopers en webhosters, die werken net zo goed mee aan het faciliteren van cyber-crime door zomaar iedereen een domeinnaam of webserver te geven zonder de naam te koppelen aan een legitieme organisatie.

De zwarte piet bij de certificaat leveranciers neerleggen is te vergelijken met het aanvallen van een drukkerij omdat ze zomaar in opdracht van een willekeurige persoon enveloppen of visitekaartjes afdrukken met een bedrijfsnaam zonder te controleren of de opdrachtgever wel gemachtigd is om te handelen namens een bedrijf met die bedrijfsnaam. Of zelf de copyshop omdat je hun systemen kunt gebruiken om vals briefpapier te printen.

Ook al zou het verschil tussen EV en DV certificaten nog te zien zijn in browsers, dan nog controleren de meeste mensen niet op wiens naam een EV certificaat is uitgegeven. De reden dat Chrome gestopt is met visueel onderscheid tussen EV en DV certtificaten is:
"Through our own research as well as a survey of prior academic work, the Chrome Security UX team has determined that the EV UI does not protect users as intended. Users do not appear to make secure choices (such as not entering password or credit card information) when the UI is altered or removed, as would be necessary for EV UI to provide meaningful protection."

Zelfs al zou de identiteit van een organisatie goed worden gecontroleerd en weergegeven in de browser dan nog zouden er phishing sites zijn omdat gebruikers die identiteit toch niet goed controleren.

In the old days was het zo dat je voor een .nl registratie (en vergelijkbare eisen bij een aantal andere tld's) een kvk nummer moest hebben, dat maakte het in ieder geval iets omslachtiger en kostbaarder voor cyber criminelen (maar die waren er toen ook gewoon veel minder) een malafide .nl website op te zetten. Ik ben blij dat dat niet meer zo is want dat was een behoorlijke belemmering geweest voor de groei van het internet.

Het echte probleem ligt in het feit dat veel mensen waarde hechten aan tls-certificaten als bewijs dat een website onder controle staat van een organisatienaam die zich op die website presenteert terwijl bij geen enkel certificaat, ook EV niet, zo is.

Ik denk dat het probleem van welke website er wel of niet vertrouwd kan worden niet eenvoudig op te lossen is. Het komt uiteindelijk neer op een goede controle door de bezoeker en dat gaat in veel gevallen niet goed. Er zijn ook nog steeds mensen die hun bankpas en pincode afgeven aan iemand die aanbelt en zegt namens de bank te komen.

Of heb jij hier wellicht een briljant idee voor? Ik denk dat we het wel eens zijn dat daar behoefte aan is.

Je hebt geen certificaat nodig voor een versleutelde TLS verbinding!

Uit https://wiki.openssl.org/index.php/Diffie_Hellman#Diffie-Hellman_in_SSL.2FTLS:

Bij de gebruikelijke Ephemeral Diffie-Hellman worden de de DH-parameters door de server ondertekend met diens private key. De client, die als het goed is dezelfde parameters gebruikt, checkt die digitale handtekening aan de hand van de public key in het servercertificaat en vergelijkt de parameters. Als daar een verschil tussen bestaat, is er sprake van een AitM.

Bij Anonymous Diffie-Hellman heb je geen https servercertificaat nodig.

Het eerste probleem
Anonymous Diffie-Hellman (geen certificaat) is prima als er geen AitM (Attacker in the Middle) tussen jouw browser en de server zit en DNS betrouwbaar is (de DNS-records niet gehacked zijn en de communicatie tussen de DNS-server en jouw browser niet gemanipuleerd wordt).

Bij een DV-certificaat vertrouw je erop dat, tijdens certificaat-uitgifte, er geen AitM tussen de certificaat-provider en de server zat en dat DNS betrouwbaar was (de DNS-records niet gehacked waren en de communicatie tussen de DNS-server en de certificaat-provider niet gemanipuleerd werd).

Een DV-certificaat is dus nauwelijks een verbetering t.o.v. geen certificaat, en dit gaat in de praktijk ook daadwerkelijk fout. Voorbeelden (waarbij Let's Encrypt certificaten voor specifieke domeinnamen aan cybercriminelen voor heel andere servers werden verstrekt):

• BGP-hijack: https://arstechnica.com/information-technology/2022/09/how-3-hours-of-inaction-from-amazon-cost-cryptocurrency-holders-235000/. Nb. zo'n aanval is steeds moeilijker naarmate het langer duurt voordat de cybercrimineel z'n (onterecht afgegeven) certificaat verkrijgt. "Dankzij" het bloedsnelle Let's Encrypt is dit geen probleem voor de aanvallers.

• Primary DNS-records hacked: https://www.mandiant.com/resources/blog/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.

• Subdomain takeover attacks: https://0xpatrik.com/subdomain-takeover-impact/

• Bij de voorbeelden van "Domain Shadowing attacks (https://unit42.paloaltonetworks.com/domain-shadowing/) kon ik geen Let's Encrypt of andere DV certs vinden, maar het zou mij verbazen als die niet gebruikt worden bij dit soort aanvallen.

Probleem twee
De meeste phishing-sites gebruiken DV-certificaten. Je krijgt ze onmiddellijk, niemand checkt of de domeinnaam duidelijk bedoeld is voor phishing, ze zijn gratis (geen money-trail) en het is "no questions asked"; er komt geen organisatienaam in het certificaat waarvan je moet bewijzen dat jij namens die organisatie geautoriseerd bent om dat certificaat aan te vragen. Perfect voor cybercriminelen.

Probleem drie
Gebruikers kunnen onmogelijk weten of een domeinnaam in de adresbalk van hun browser van de organisatie is die de pagina zegt te zijn (de link genoemd in https://www.virustotal.com/gui/url/bdf3e928b4ad185b713d25a58348fa79d3a7aaa596c244c03f1783bd4bc6a3d5/details is nog steeds live, en suggereert een OneDrive pagina te zijn).

Doordat webbrowsers geen onderscheid meer laten zien tussen de verschillende soorten certificaten, weten gebruikers van geen enkele site (ook niet van digid.nl, hun bank of cryptovalutaboer) hoe zeker het is dat je echt verbinding hebt met de in de adresbalk vermelde domeinnaam (zie probleem 1: het kan om een nepsite gaan). Bovendien kun je in steeds minder browsers certificaten bekijken en last but not least gebruiken steeds meer sites, waarbij de authenticiteit cruciaal is, ook DV-certificaten.

Tegelijkertijd wil de EU dat wij ons paspoorten digitaliseren op onze smartphones zodat wij ons wel "betrouwbaar" kunnen authenticeren - op websites waarvan we geen idee hebben van wie zij zijn.

Webhosters hoeven niet te weten welke fout-klinkende domeinnamen naar hun servers wijzen en ook horen zij, vanwege privacy, niet op de servers van hun klanten rond te neuzen.

Het kan mij persoonlijk niet schelen of DNS-boeren danwel certificaatverstrekkers controleren, maar zoals je zelf zegt deden certificaatverstrekkers dat van oudsher. Zij vervulden, en bij OV/EV certificaten vervullen zij nog steeds, een soort notarisrol die de aanvrager authenticeert. Ook zitten zij, via het CAB-forum, met de browserboeren aan tafel. En als een certificaatboer zich misdraagt (onterecht certificaten uitgeeft aan criminelen), kunnen de rootcerts uit browsers worden geschrapt.

Verstandige gebruikers letten daar wel op. En die verstandige gebruikers bestaan (ik ben er één van). Belangrijker is dat ik nu niet meer fatsoenlijk aan iedereen, die het wil horen, kan uitleggen waar ze op moeten letten, want het verschil tussen nep en echt is flinterdun geworden sinds browsers EV-gegevens niet meer tonen.

Kul. Het is niet 100% onmogelijk maar wel extreem veel moeilijker voor cybercriminelen om een EV-cert voor een gegeven domeinnaam te kopen, dan een DV-cert te verkrijgen.

Als je weet dat een partij Sywert van Lienden of "WC Eend" heet, wil dat niet zeggen dat die partij betrouwbaar is. Maar dat probleem bestaat al sinds mensenheugenis. Wel is het zo dat als je de naam van een partij kent en zeker weet dat je met die partij (en niet met een identiteitsfraudeur) te maken hebt, je bijv. naar reputatie kunt kijken. De risico's tussen "face to face" zakendoen met een partij zijn dan vergelijkbaar met zakendoen via een website met een geauthenticeerde partij.

We kunnen het aantal internet-fraude-slachtoffers, net als het aantal verkeersdoden, waarschijnlijk nooit op nul krijgen - maar wel lager. En bij een kleiner aantal slachtoffers zijn vangnetten (zoals grotendeels vergoeden van de schade via een fonds of evt. verzekeringen met betaalbare premies) wellicht ook acceptabeler.