Ze zijn gek geworden.

Een website-certificaat kunt u prima vergelijken met een kopie van een paspoort. Bij gebruik van een https://-verbinding stuurt de server die kopie, ongevraagd, naar de browser.

Zoals ik al zo vaak heb gezegd: je hebt niets aan een kopie van een paspoort. Maar bij https:// gebeurt er iets bijzonders: met een wiskundige truc (asymmetrische cryptografie) bewijst de server over het originele paspoort te beschikken. Daardoor weet je zeker dat jouw browser een (versleutelde, niet te AutM'en) verbinding heeft met de website waarvan de domeinnaam in de adresbalk van de browser te zien is.

Sterker, als er duidelijker identificerende informatie in het originele paspoort (en dus ook de kopie) staat, is de domeinnaam geheel niet interessant meer.

Website-certificaten zijn er voor internetters, niet voor servers of hun beheerders. Browser-gebruikers zouden risicovolle echte- van nepwebsites moeten kunnen onderscheiden door, voor een website met een specifieke domeinnaam, gedetalleerde en zinvolle informatie over die website te zien te krijgen indien, in elk geval indien (en/of):

1) Zij die website (met de gebruikte browser) voor het eerst bezoeken;

2) Het certificaat is vernieuwd;

3) De website van eigenaar is veranderd;

4) De website van hostingprovider is veranderd;

5) De website van naar een server in een ander land is verplaatst.

Zorgvuldig beschreven en begrijpelijke identificerende infofmatie van de juridisch verantwoordelijke voor de website met de gegeven doneinnaam, dient paginavullend door de browser te worden weergegeven, vóórdat er überhaupt content (met potentiële browser-exploits) wordt opgehaald van de server.

Tevens dient de betrouwbaarheid van die informatie te worden weergegeven. Dat kan alleen als deze informatie digitaal is ondertekend, en je precies weet door welke partij de digitale handtekening is gezet.

Dit betekent géén verbod op DV (Domain Validated) en OV (Organization-) certificaten! Het betekent WÉL dat de internetter moet kunnen zien hoe betrouwbaar] de identiteit van de verantwoordelijke voor de website is vastgesteld (DV betekent anoniem, verantwoordelijke onbekend, vertrouwen betekent potentieel een enorm risico voor u - tenzij u heel zeker weet dat de domeinnaam exact de bedoelde is).

Hier zijn bij uitstek digitale certificaten voor bedoeld (wellicht moeten er uitbreidingen op plaatsvinden, maar dat kan met "extensions" waarin certificaten voorzien).

Naast dat browsers op de schop moeten, geldt dat ook voor certificaatverstrekkers en het CA/B forum. Die laatste is nu een zakkenvullende slager die diens eigen vlees keurt.

Certificaatuitgevers zullen door onafhankelijke beoordelaars geaudit moeten worden, waaruit hun (de certificaatuitgevers) betrouwbaarheid moet blijken. Die beoordelaars op hun beurt zullen door onafhankelijke derden, in opdracht van consumentenorganisaties en/of overheden, beoordeeld moeten worden.

Uitsluitend een domeinnaam zegt niets over de identiteit van de verantwoordelijke voor een website (en ook niet over het land waar die verantwoordelijke gevestigd is, noch waar de server staat, noch wie er allemaal mee kunnen kijken). Aan anonieme websites hebben surfers niets; als zij belazerd worden kunnen zij niemand aansprakelijk stellen.

Bovendien zijn veel domeinnamen voor mensen onmogelijk om uit elkaar te houden. Veel mensen weten niet dat zij domeinnamen moeten checken, en gegeven een domeinnaam, hoe je zou moeten vaststellen van wie deze is. Dit naast dat veel mensen het verschil niet begrijpen tussen:
• www.securlty.nl
• www-security.nl
• https-security.nl
• https.www-security.nl
• https-www-security.nl
• www.security.nl
kunnen criminelen daar met IDN's (International Domain Names) weer tig variaties op bedenken, zoals
• www.securîty.nl
• www.securíty.nl
• www.securìty.nl
• www.securïty.nl.
Naast populaire constructies zoals
• www.security.nl-e2ee.eu.org of combinaties van de bovenstaande, al dan niet met deze. Of een andere TLD, zoals
• www.security.ml
• www.security.nI
• www.security.nl.com etcetera.

Dit is een volstrekt KRANZINNIG plan - notabene in een tijd waarbij BURGERS met steeds grotere betrouwbaarheid online moeten authenticeren, o.a. i.v.m. leeftijdsverificatie en de voorgenomen eID's zoals EDIW/EUDIW. En ook bij DigiD sprake is van verschillende betrouwbaarheidsniveaus: laten we voor websites dan vooral betrouwbaarheidsniveau NUL introduceren - en niks anders (NOT).

Dit is SMEKEN om AitM (Attacker in the Middle) phishing- en identiteitsfraude-aanvallen (zie [3]).

Ik heb hier al vreselijk veel over geschreven, zie bijv.
[1] https://security.nl/posting/876502
[2] https://security.nl/posting/852814
[3] https://security.nl/posting/852763
[4] Onterecht door Let's Encrypt uitgegeven certs, waar de CA-doodstraf op hoort te staan: https://infosec.exchange/@ErikvanStraten/112914047006977222

ACME != lets encrypt....
Lets encrypt gebruikt het ACME protocol... Dat is echt anders.

ACME is een goed id..

Daarnaast certificaten zijn paspooryen bij een digitali identiteot aka privatekey...

Goed idee

Phishing is al 10+ jaar een opgelost probleem door de beschikbaarheid van phishing-resistente authenticatiemethodes. Dat hoeft dus geen belemmering te zijn om certificaat uitgifte efficiënter, betrouwbaarder en goedkoper te maken door het ACME protocol in te voeren.

Er staat nergens in het expertadvies dat er DV moet worden gebruikt. Sterker nog: er staat expliciet dat het advies gaat over het protocol wat wordt aangeraden voor uitgifte, verlengen en intrekken (niet voor validatie) en dat dat niet verward moet worden met de keus voor DV/OV/EV of CA. Je kan prima OV of EV gebruiken i.c.m. ACME, dat ondersteune alle grote leveranciers door middel van EAB (behalve Let's Encrypt natuurlijk).

Correctie (ik kan het hierboven niet meer aanpassen, 1 uur na de eerste submit): in de eerste sectie staat "AutM'en" waar ik "AitM'en" bedoelde.

Nb. eerder schreef ik "Kopie-ID: kap ermee!" (https://security.nl/posting/827137).

Weet je überhaubt wel hoe ACME Dehydrated werkt?
Al deze dingen die je hier boven aangehaald hebt kun je ook doen als je de certificaten met de hand aanvraagt.

Onjuist om meerdere redenen:

1) Bijna niemand gebruikt phishing-resistente authenticatiemethodes. Passkeys hebben nog veel te veel kinderziektes, en FIDO2 hardware keys zijn een ramp en veel te duur voor doorsnee gebruikers.

2) Phishing-resistente authenticatiemethodes zijn minder phishing-resistent dan gedacht, vooral i.r.t. websites waar snel veel te scoren valt voor cybercriminelen, zoals DeFi (Decentralised Finance, crypto-valuta) websites. Ik noem de link nog maar een keer: https://infosec.exchange/@ErikvanStraten/112914047006977222.

3) Potentiële slachtoffers worden naar nepwebsites gelokt waar zij op alternatieve wijze moeten authenticeren, zoals gebruikelijk bij een bankapp op een nieuwe smartphone. Zo zijn mensen gefopt met de melding dat zij opnieuw moesten authenticeren met een scan van hun paspoort en een selfie-filmpje voor o.a. bunq. Als slachtoffers dat deden, werd de de babk-app op de smartphone van de AitM gekoppeld aan de bankrekening van het slachtoffer (waarna de app van het slachtoffer werd ontkoppeld).

4) Sterker, EDIW/EUDIW komt eraan. Tenzij ik mij heel erg vergis, is daarmee authenticeren NIET phishing-resistant.

5) Het stikt van de websites waar mensen (nog) géén account op hebben, maar daar wél vertrouwelijke informatie mee moeten uitwisselen, op allerlei manieren moeten authenticeren en/of betalen. Weer een link die je duidelijk niet gevolgd hebt: https://security.nl/posting/876502. Of zie mijn eerdere postings over PGO's, zoals https://www.security.nl/posting/842899. Of zie bijv. mijn posting over bedrocksandals-nederland.com in https://www.security.nl/posting/851829 (ik heb, in de loop van de jaaaaren, al zóveel voorbeelden gegeven...).

Aanvulling 22:13: zie ook het plaatje onderin https://infosec.exchange/@ErikvanStraten/114032329847123742

Ik wil af van de 1FA afhankelijkheid van DNS-registraties en BGP.

Voor zover ik weet is het huidige ACME-protocol net zo kwetsbaar voor de onterechte heruitgifte van een certificaat aan een gekaapte domeinnaam, als de eerste uitgifte.

Ik kan mij wel een systeem van automatische verlenging voorstellen waarbij bewijs van het bezit van de private key van het vorige certificaat een vereiste is. Maar waarom zou je dan, in hemelsnaam, de levensduur van certificaten zo absurd willen inkorten?

Ofwel onterechte certificaatuitgifte en het kopiejatten van de private key vormen wél een significant risico. Maar waarom zie ik dan toegestaan worden dat websites vele jaren hetzelfde sleutelpaar blijven gebruiken, zoals tweakers.net eerder deed https://crt.sh/?spkisha256=78a29b6ffd6e8281a5f5e32442a246a589c9d5f73219b083fbe9eed5d898c9ad en Fastly nog steeds doet voor een deel van de sites die zij proxyen? En waarom vormt een private key in verkeerde handen niet onmiddellijk een risico dat met zo min mogelijk vertraging moet worden bestreden? En dus het vervangen van OCSP (stapling) door CRL's één van de stomste dingen is die je kunt doen? Zie ook de eerste link in deze reactie (gehijackte DeFi websites).

Ofwel onterechte certificaatuitgifte en het kopiejatten van de private key vormen géén significant risico. Waarom zou men dan de levensduur van certificaten steeds verder inkorten, met als gevolg dat het automatiseren van het vernieuwen van certificaten een vereiste wordt, omdat het anders veel te vaak veel gedoe is?

Het hele plaatje zuigt. We gaan ook niet paspoorten slechts 3 maanden (of nog veel korter) geldig maken. Betrouwbare authenticatie *is* lastig en prijzig. Het is wensdenken dat authenticatie van websites betrouwbaarder wordt, voor bezoekers (die voor alle impersonatie-risico's opdraaien), door te automatiseren met protocollen zoals ACME.

Het is een ordinaire bezuinigingsmaatregel waarbij steeds meer online risico's op burgers, klanten en patiënten worden afgewenteld, waarbij de kloof in de samenleving tussen digitaal vaardigen en minder vaardigen niet kleiner, maar juist groter wordt.

Aanvulling, uit https://datatracker.ietf.org/doc/html/rfc8555, geschreven door de zakkenvullende slager die zelf diens vlees keurt (opmaak middels vet schuinschrift toegevoegd door mij):
Dat klopt steeds vaker, en dat is precies waarom phishing met nepwebsites een steeds groter probleem wordt!

Want: gegeven een (pseudonieme!) domeinnaam van een potentieel risicovolle (voor bezoekers) website met een DV-certificaat, kunnen bezoekers onmogelijk met voldoende betrouwbaarheid achterhalen wie zij voor de rechter kunnen slepen als zij door de eigenaar van die website worden beroofd. En ook de Politie staat machteloos als de server in bijv. Rusland of Hong Kong staat. Indien bijv. Google deze host, zal uit de lucht halen waarschijnlijk wel lukken, maar dan verkast de website naar een andere server en draait vrolijk verder. Zonder dat er iemand wordt gepakt, veroordeeld en gestraft.

En, tenzij ik mij enorm vergis, beschrijft RFC 8555 (ACME dus) het "DV-protocol" - zoals gebruikt door onder meer Let's Encrypt. Ook de redactie laat hier geen twijfel over bestaan:

Voorbeelden van een stroom aan totaal nietszeggende domeinnamen (van criminele websites) postte ik gisterochtend vroeg in https://security.nl/posting/876655. Nb. daaruit blijkt ook dat jouw virusscanner, "Google Safe Browsing" en/of jouw SafeOnWeb (of vergelijkbare) browserextensie jou niet gaan redden.

Een heel slecht idee. ACME zegt alleen iets over het feit dat de aanvrager in control is van DNS voor het betreffende domein. Het zegt *NIETS* over de legitimiteit van de aanvrager (dus ook niet of de website betrouwbaar is). Dit legitimeert de RA's alleen maar om helemaal geen controle meer uit te voeren over de aanvraag (de malafide aanvrager is natuurlijk altijd in control van zijn malafide domein). Door de actie van Google (en daarmee de rest van de browserfabrikanten) door in te zetten op DV is betere controle mbt de aanvrager weggevaagd, met een nog onbetrouwbaarder internet tot gevolg.

Ook is ACME beperkt tot server-side certificaten. Certificaten voor andere doeleinden (client authenticatie, signing, encryptie) zijn op deze manier niet aan te vragen omdat deze certificaten meestal niet domain-bound zijn.

Je beseft dat https://infosec.exchange gebruik maakt van Let's Encrypt Certificaten?

Ik respecteer je enthousiasme en schrijfwerk omtrent dit onderwerp maar je doet wel uitspraken die niet volledig gegrond zijn.

1) Dit is natuurlijk onjuist. Ik werk persoonlijk met veel gezondheidsorganisaties en verschillende gebruiken Yubikeys. Het werkt fantastisch simpel en gebruikers zijn er zeer tevreden over (vooral omdat het als een niet-technische sleutel aanvoelt).
We hebben al zeker 6 jaar geen phishing incidenten meer gehad (wel pogingen, uiteraard). Je kan verder prima deals maken zodat ze voor een prikkie te krijgen zijn (bulk). Maar wat betreft de prijs, je bent mogelijk niet bekend met het ouderwetse RSA SecurID apparaten. Die waren pas prijzig...

2) Je weet ook wel dat iedere actie helpt. Om dan Phishing-resistente authenticatiemethodes maar af te kraken is niet slim.
De meeste security maatregelen zijn niet zo effectief als initieel gedacht, zo werkt security wel vaker. Dat is geen reden om het niet te doen.

3) Ja, mensen blijven dom en zullen altijd in phishing blijven trappen, dat is niets nieuw. Wel verbeterd techniek continue en blijven we er gewoon aan werken, het is een oorlog met strijd onderweg. De beste methode is om de strijd uit de weg te gaan (blijven voorlopen op de rest).

Anyway, al deze zaken hebben helemaal niets met ACME te maken.

Bij de overheid hebben ze een probleem, er is 0 innovatie en niemand doet eigenlijk iets... Veel traditionele organisaties zitten ook vast in die sleur en dat is niet goed voor de beveiliging.
Als ik een server uitrol bij de overheid dan vraag ik hoe lang het cert geldig moet zijn. Dan is het antwoord altijd: Zo lang mogelijk, wij willen er geen onderhoud of omkijken naar hebben. Hier is het wildcard cert dat we overal voor gebruiken...
En precies na een 1-2 jaar belt men weer: kan je het certificaat komen vervangen?

Dit is een poging om dit slechte gedrag onmogelijk te maken. Niets mis mee.
Ik zit er ook niet op te wachten om iedere drie maanden certificaten lopen te vervangen maar daar draait het op uit als dit zo doorgaat. Misschien gaan beheerders dan ook wel een nadenken over hun oude ('enterprise hardware') zoals netscalers die alleen maar certificaten aankunnen die honderden euro's kosten...

Jazeker, en de bijpassende afweging heb ik gemaakt.

Een DV-certificaat is onwenselijk maar net acceptabel indien, en/en:

• Je bij het aanmaken van je account zeer grondig checkt dat het om exact de juiste domeinnaam gaat (rekening houdend met IDN's, en precies weten hoe je domeinnamen moet interpreteren);

• Je vervolgens, bij elke keer inloggen, opnieuw die exacte domeinnaam kent en checkt (zo niet dan https://security.nl/posting/768888). Ik hoef dat niet te doen, want mijn inloggegevens staan in KeePassDX en als ik in probeer te loggen verschijnt er een pop-up (te zien in https://infosec.exchange/@ErikvanStraten/113549056619471557), waarna KeePassDX uitsluitend een record vindt als de donrinnaam exact infosec.exchange luidt (of eindigt op .infosec.exchange);
Aanvulling 12:18: {
Je moet ook checken dat er sprake is van een https:// verbinding. Tenzij jouw browser "Waarschuwen bij http:// fatsoenlijk ondersteunt en je dat hebt aangezet (zoals ik in o.a. Firefox/Android). Zie "Veilig Inloggen" in https://security.nl/posting/840236;
}

• Ik niet op infosex.exchange klik op het moment dat die naam bovenaan staat als ik iemand op een andere Mastodon instance wil volgen (en die instance niet snapt van welke instance ik precies kwam);

• Ik niet in phishing mails trap zoals "uw account is geblokkeerd, log in op whatever.TLD om bezwaar aan te tekenen" (Nb. mijn account is wel eens geblokkeerd en gelimiteerd geweest, zo'n mail is niet meer onverwacht voor mij);

• Sowieso ben ik geen "VIP" met een account dat criminelen graag zouden willen pwnen. Want mijn volgers zullen het totaal ongeloofwaardig vinden als ik plotseling zou aanraden om in DOGEcoins of andere cryptojunk te investeren;

• Last but not least: er voor cybercriminelen onvoldoende te halen valt om middels BGP of DNS-hijacks onterecht een geldig DV-certificaat "te verlengen" voor een website.

Kortom, een voorbeel van een website met een laag risico voor mij waarvoor ik ook nog eens mitigerende maatregelen heb getroffen.

De grootste risico's die ik heb geïnventariseerd (en waar ik geen invloed op heb) zijn:

• Dat deze site "achter Fastly" zit, en dus DM's door wildvreemden (waaronder three-letter-agencies, middels FISA section 702) kunnen worden gelezen, gewijzigd of verwijderd;

• Dat beheerder Jerry toch minder aardig blijkt te zijn dan tot nu toe lijkt;

• Dat Jerry de hele handel verkoopt (bijv. voor een fortuin aan Musk);

• Of dat de mods zwichten voor de druk en/of hun eigen mening volgen, en mij permanent de mond snoeren vanwege mijn anti-Big-Tech, anti-Musk/Trump en/of anti-genocide toots (door velen antisemitisch genoemd - GFY).

Daarbij vind ik het volkomen begrijpelijk dat Jerry een "business to run" heeft. Doordat velen niet (regelmatig) doneren is zijn budget uitermate krap. Dan moet je wel net zo'n ongebruikelijke wereldverbeteraar zijn als ik, wil je er een OV- of EV-cert op zetten - dat ik met Firefox op mijn smartphone niet eens kan bekijken en dus geen verschil zie met een DV-cert van LE.

Je punt was?

Ik schreef:
nuf said punt

Omdat jij een hekel hebt aan certificaten enkel voor encryptie, betekend het niet dat ACME meteen de vuilnisbak in kan.
Er zijn meer CA's (dan hetgeen jij allemaal haat) die dat reeds toepassen.
PKIoverheid / "Staat der Nederlanden EV Root CA is overgeheveld naar Logius die het KPN en Digidentity laat doen.
Ik kan mij zo voorstellen dat zij heel graag ACME als standaard protocol wil hebben, zeken nu beperkte lifespan de trend gaat worden.

Je bent weer eens te hard aan het herhalen; copy/pasten...
Heb je ook een link die wèl werkt?

Dank @Majortom voor de support.

Nog even i.r.t. https://security.nl/posting/768888, check:
• https://circleci.com
• https://crt.sh/?q=circleci.com
• https://www.checkjelinkje.nl/check/#u=aHR0cHM6Ly9jaXJjbGVjaS5jb20=

• https://circle-ci.com
• https://crt.sh/?q=circle-ci.com
• https://www.checkjelinkje.nl/check/#u=aHR0cHM6Ly9jaXJjbGUtY2kuY29t

Welke van de twee is de echte site?

(Tip voor dit specifieke geval, your mileage may vary:
• https://www.virustotal.com/gui/domain/circleci.com
• https://www.virustotal.com/gui/domain/circle-ci.com
)

Nog meer drek vind je als je naar historische IP-adressen van die laatste kijkt, zoals https://www.virustotal.com/gui/ip-address/58.64.137.69/relations.

Ook zie ik steeds vaker "_bimi" subdomains (door de underscore officieel géén geldige domeinnamen, misbruikt voor DNS TXT records), uit https://www.virustotal.com/gui/ip-address/176.113.115.140/relations:

En uit https://www.virustotal.com/gui/ip-address/34.118.89.236/relations (trouwens een "Google Cloud Hosting" server in Polen met daarop, begin december, meer dan 100 criminele websites, die steeds van server verkassen):
(of alle genoemde DNS records nog bestaan heb ik niet gecheckt).

Voor de certs van bijv. "blacksaltys" zie https://crt.sh/?q=blacksaltys.com.

M.b.t. BIMI zie bijv. "Politie implementeert standaard die geverifieerde logo's in e-mailclients toont" boven https://security.nl/posting/845574, maar lees ook https://www.theregister.com/2023/06/09/google_bimi_email_authentication/.

    KAP MET FLUTAUTHENTICATIE!
 

Website-certificaten "enkel voor encryptie" hebben nog nooit bestaan.

Bovendien wordt, vanaf TLS v1.3, de verbinding eerst versleuteld vóórdat de server het website-certificaat naar de browser stuurt. Uitsluitend ter authenticatie. De public key in het certificaat mág niet eens voor versleuteling worden gebruikt (uitsluitend voor de verificatie van digitale handtekeningen).

En omdat je mij nooit gelooft, mijn posts niet leest of acuut vergeet, is het zinloos dat ik het volgende herhaal uit een post van mij hierboven (uit de ACME RFC, nu met de nadruk ietsje anders, speciaal voor jou) en is dit tegen beter weten in (het laat andere lezers wel zien wat voor een onkundige noob jij bent):
Prima, maar volstrekt niets in DV-certs helpt tegen nepwebsites. En dat op het moment dat steeds anoniemere websites één van de grootste problemen op het hedendaagse internet vormen, terwijl internetters worden verplicht om steeds "betrouwbaarder" te authenticeren - wat onmogelijk is als de verifieerder onbetrouwbaar is en criminelen daarmee blijven wegkomen. Wel erg ingewikkeld allemaal voor jou, hè.

Bij mij werkt die link gewoon. Er zijn soms DNS-providers (Quad9 meen ik recentelijk) die https://infosec.exchange blokkeren omdat daar soms in detail kwetsbaarheden worden beschreven. Maar dit gaat jou waarschijnlijk boven jouw pet.

Aanvulling 13:56: als er bereikbaarheidsproblemen zijn met een website, vul dan de domeinnaam in op https://isc.sans.edu/tools/dnslookup.html. Op dit moment lijkt alles OK, maar ook hier wordt niet elke DNS provider gecheckt. Bovendien: mogelijk is de vergeetachtige Anoniem vergeten dat zhij, als resolver, een Raspberry Pi met agressieve blocklist draait.

Als tijdelijke fix (bij bereikbaarheidsproblemen) kunnen mensen (die de -niet geringe- risico's begrijpen) aan hun hosts file toevoegen:

Als je dat eng vindt, de volgende regel (vervang "infosec.exchange" door elke gewenste domeinnaam) geeft ook altijd een hilarisch resultaat:

In aanvulling op mijn alter ego, ik schrijf dit al jaren (bijv. in https://security.nl/posting/564452) maar ben steeds meer gaan inzien (door veel onderzoek te doen, o.a. middels VirusTotal) dat uitsluitend een domeinnaam helemaal niets hoeft te zegen over wie verantwoordelijk is voor een website.

Cybercriminelen maken hier dankbaar misbruik van, terwijl Google en andere Big Tech dit model enorm stimuleren omdat zij vet meeverdienen aan cybercrime.

Niet voor niets vliegen de nieuwe TLD's ons om de oren, en moet je als authentieke web-presentie-willer steeds meer moeite doen om een passende, ongebruikte, domeinnaam te scoren.

En als het lukt om een geschikte doch gebruikte domeinnaam -voor minder dan grof geld- te registreren (waarvan er steeds minder zijn), kom je steeds vaker achter dat deze op allerlei blocklists staat en/of door veel virusscanners wordt als foute boel wordt gevlagd (Google Safe Browsing zie ik zelden nog, logisch gezien het volgende).

Enkele voorbeelden van verse "Google Cloud Hosting" servers met criminele websites (vooral bedoeld voor Canadese slachtoffers):

1) (DE) https://www.virustotal.com/gui/ip-address/34.32.81.38/relations

2) (DE) https://www.virustotal.com/gui/ip-address/34.141.2.186/relations

3) (US) https://www.virustotal.com/gui/ip-address/34.170.119.0/relations

4) (DE) https://www.virustotal.com/gui/ip-address/34.107.63.107/relations

(Ik heb enkele website-certs gecheckt, allen Let's Encrypt).

Niet alleen kan het Google (en Let's Encrypt en de DNS-boeren) geen bal schelen, het is hun verdienmodel (LE wordt natuurlijk betaald door Big Tech).

En Trump, Musk et al. zijn de laatste die hier wat tegen gaan doen (Sundar Pichai liep, ondanks huidskleur, ook op Trumps inaugupartijtje rond).

Helaas ben ik (samen met een paar anderen) een roepende in de woestijn, tegengewerkt door Anoniemen die meeprofiteren van dit model (of volstrekt naïef zijn). Bizar.

In de lange rants lijkt te worden genegeerd dat ACME prima kan met OV certificaten. En ik mag hopen dat je al weet dat OV verplicht gaat zijn in de BIO2.

Nog maar een keer dan, uit https://security.nl/abuse/876952:
Het ACME protocol is gebaseerd op (potentieel volstrekt anonieme) domeinnamen. Er wordt op géén enkele wijze geverifieerd of de aanvrager van een eerste of een te vervangen certificaat de authentieke eigenaar is van de betreffende website.

Het is niets meer en niets minder dan DV: DomeinValidatie.

Bovendien, voor de huidige OV-certificaten worden, vooral door cowboy-CA's, brakke online "authenticatie"-checks uitgevoerd waarbij impersonatie een eitje is.

Het helpt geen zier als belastingdienst.nl een ijzersterk certificaat van Quo Vadis heeft, en mensen niet weten, en in de meeste mobiele browsers überhaupt niet kunnen zien, dat bijvoorbeeld

• belastingdienst-afhandelen·com (*)

niet van de Belastingdienst is.

(*) Veel meer voorbeelden gaf ik in https://security.nl/posting/874752 - en dat is nog maar een microtopje van een GIGANTISCHE ijsberg.

Ik blijf het herhalen: het World Wide Web wordt er niet significant veiliger op als niet het hele systeem op de schop gaat en we niet onmiddellijk stoppen met toestaan dat commerciële partijen, met Google voorop, de lakens uitdelen.

Zo'n lange post en je hebt werkelijk geen idee waar je het over hebt.
Een certificaat doet niets anders dan het verkeer van een website versleutelen zodat je weet dat het niet onderschept kan worden door malafide partijen. Het ACME protocol is een erg zinnig protocol om je certificaten te vernieuwen, scheelt veel werk en misconfiguratie. Hoe de kans op een MITM aanval groter wordt door het ACME protocol te gebruiken voor de installatie van een nieuw certificaat mag je me uitleggen.

Een certificaat werkt op vertrouwen: dat wil dus zeggen dat jij (jouw browser) de uitgever van dat certificaat vertrouwd. Voor de overheid is dat op dit moment volgens mij alleen KPN. Maar iedere "trusted root" is in principe voldoende. Je vertrouwd er dan op dat het verkeer niet gelezen kan worden door iemand anders dan de overheid.

De rest van je verhaal is echt een klok-klepel verhaal en slaat gewoon nergens op, ik kan er niet eens zinnig op in gaan.

Voor wat betreft Let's encrypt heb ik nog wel een opmerking: meer dan 75% van de websites wereldwijd draait op een certificaat van Let's encrypt. Dat is een risico, want daarmee is die uitgever een prime doelwit voor inlichtingendiensten. Als je het root (private) certifcaat van Let's encrypt hebt kun je zonder veel moeite meelezen met het verkeer van het merendeel van de websites. Dat single point of failure is wel een risico.

Erik,

Je wekt de indruk dat je je eraan stoort dat het PKI-systeem niet feilloos is. Dat valt te begrijpen.

Maar je moet die irritatie niet verwarren met waar het hier over gaat:

ACME is een methode om het aanvragen en vervangen van certificaten te automatiseren. We kennen dit van Let's Encrypt, maar ACME wordt ook door andere CA's gebruikt en niet alleen in combinatie met HTTP- en DNS-challenges; een 'key authorization' kan bijvoorbeeld ook.

Met ACME los je niet alle tekortkomingen van het PKI-systeem op, maar je kunt er wel een paar dingen mee verbeteren. Je kunt certificaten veel gemakkelijker rollen (verversen) bijvoorbeeld. Dat voorkomt dat je dit vergeet, of dat je eens per jaar weer een dag druk bent, wat vooral handig is voor grote organisaties. Je kunt ook de levensduur van een certificaat verkorten, wat bepaalde veiligheidsvoordelen heeft, zonder dat het certificaat-beheer significant meer werkt oplevert.

En dat is het.

Dit advies gaat alleen over de vraag: als je (in je organisatie) certificaat-beheer doet (voor DV-certificaten), doe het dan met behulp van ACME.

Niet meer, niet minder.

Al je mooie argumenten en voorbeelden ten spijt.

stopt met lezen en gaat niet herhalen wat ik al schreef

lees mijn regel hierboven