Is hier toevallig ook bewijs voor?
Om een certificaat te kunnen stelen moet je in het servernetwerk of op de server zelf zitten. (En niet iedereen kan dat.)
En om een gestolen certificaat te kunnen gebruiken moet je tussen de gebruiker en de server gaan zitten.
Deze combinaties lijken mij nogal zeer zeldzaam, hoe vaak gebeurt dit nou echt?

En wat van de certificate revocation mechanismen OCSP stapling & CRL's, zijn die dan niet langer nodig?
Want als het voldoende is om de certificaten van kortere duur te maken, dan lijkt mij het intrekken overbodig geworden.

Laatste vraag: als je het netjes doet en een EV of OV certificaat hebt, is er dan elke 50 dagen identificatie nodig?
Of is identificatie eenmalig en is de rest via DV vernieuwing? (Dat lijkt mij kwetsbaar.)

Dit is niet in het belang van consumenten. Integendeel, dit maak het internet onveiliger. Steeds vaker trappen mensen in geraffineerde phishing. Consumenten zijn niet vertegenwoordigd in het CA/B forum.

Certificaten bestaan om de identiteit van entiteiten vast te kunnen stellen. De betrouwbaarheid van dat proces is gesloopt in in de afgelopen jaren (bewust ook in webbrowsers, in plaats van dat certificaten beter leesbaar zijn gemaakt en relevante informatie aan internetters wordt getoond). Criminelen maken hier op steeds grotere schaal dankbaar misbruik van.

Een certificaat zelf zegt niets direct over de betrouwbaarheid van een bezitter (van de bijpassende private key), maar naarmate deze méér bruikbare identificerende gegevens bevat, wél indirect. Want als je belazerd wordt, weet je tegen wie je aangifte kunt doen. Noorzakelijkerwijs betrouwbare (voor de consument) websites van webshops, banken, zorginstellingen en overheden zijn, voor de meeste mensen, niet meer te onderscheiden van nepversies.

Big Tech verdient vet aan de verhuur van hosting, domeinnamen en CDN's - ook en misschien wel vooral van cybercriminelen. Dat is precies de reden waarom zij niet willen dat internetters onderscheid kunnen maken tussen authentieke- en nepwebsites; dat zou hun winsten doen dalen.

Een domeinnaam zegt potentieel niets over de identiteit van de huidige huurder, of is zelfs ordinair misleidend. Van wie is https://nefkens-opel.nl op dit moment en waarom?

Zie ook https://crt.sh/?q=nefkens-opel.nl.

Ongetwijfeld gaan (anonieme) dwazen hieronder opnieuw roepen dat certificaten nodig zijn om https-verbindingen te versleutelen, en/of dat het goed is dat er anonieme websites bestaan.

Heel lang geleden hadden htpps-certificaten een dubbelfunctie (authenticatie en veilig uitwisselen van een encryptiesleutel voor de https-sessie). Risico: als een veiligheidsdienst de private key opeist, kunnen alle eerder opgenomen (versleutelde) sessies worden ontsleuteld.

Om die reden is "forward secrecy" geïntroduceerd: sindsdien hebben certificaten niets meer te maken met versleuteling (ze mogen uitsluitend voor de verificatie van digitale handtekeningen worden gebruikt, zodat je weet wie heeft ondertekend).

Sterker, bij TLS v1.3 wordt éérst de verbinding versleuteld, pas daarna stuurt de server het certificaat (via de versleutelde verbinding) naar de browser - die vervolgens met een wiskundige truc vaststelt dat de server beschikt over de private key, passend bij de public key in het certificaat. Daarmee is de server geauthenticeerd, d.w.z. een AitM (Attacker in the Middle) tussen de browser en de server wordt daarmee zo goed als uitgesloten. Maar dit is puur techniek: van wie dat certificaat is, staat in elk -voor mensen- bruikbaar certificaat - en niet in DV (Domain Validated) certificaten.

In de risico's die internetters lopen is big tech niet geïnteresseerd, wel in hun winst. Dat er anonieme websites bestaan is geen probleem als u hen maar fatsoenlijk kunt onderscheiden van niet-anonieme websites, maar dat kan niet meer. Opzettelijk.

U bent het product.

Aanvulling: zojuist heb ik in https://infosec.exchange/@ErikvanStraten/114341136538405187 een drietal toots gepost waarin ik, ook voor leken, laat zien waar je op moet letten - voor zover dat helpt tegen phishing.

Het hele afluisteren van unencrypted traffic was al best zeldzaam . Toch moest iedereen naar TLS (en SSH).

Ik heb niet gezocht naar cijfers - maar dit soort "global policies" zijn gewoon statistische gegevens.

Op de honderden miljoenen certificaten - voor hoeveel of hoe weinig zeg JIJ "laat die maar lekker gejat blijven, het zijn er weinig genoeg" .

Inderdaad kan "normaal gesproken" niet iedereen bij de server certificaten .
Echter - kijkend naar de "achtergrond ruis" van foute systeembeheerders die backdoors achterlaten, of een kamikaze actie doen - dan kun je er beslist van uitgaan dat er, naast de "echte" hackers van buiten, ook een percentage is van "foute insiders" die een certificaat meenemen.

Of - veel eerder - naar buiten brengen omdat ze lokaal aan het developen zijn en de test container "moeten" voorzien van "het" certificaat . En dat soms verliezen .

Weet je van zo'n verlies , of semi-verlies zoals een dev die het cert "ergens" had ?
Lang niet altijd , zeker als misbruik of niet gebeurt, of niet betrapt wordt.

Het is analoog aan het roteren van passwords - je kunt lang discussieren over de noodzakelijke frequentie ervan, en een "gegarandeerd nooit gelekt password" HOEFT niet gewijzigd te worden. Maar ja, "gegarandeerd nooit gelekt" , hoe langer het in gebruik is, des te groter de kans dat het toch eens gelekt, gezien is. En zeker voor noodzakelijke last-resort passwords , gedeeld met mensen die inmiddels niet meer de 'need to know' hebben . Zelfs als ze zonder ruzie weggegaan zijn.

Voor het overgrote zijn 'trusted insiders' inderdaad trusted, en zelfs als ze met frictie weggaan zijn er niet veel die een kamikaze actie doen op de voormalige werkomgeving. Maar de gevallen waarin het wel misgaat wil je die impact toch proberen te voorkomen - en dus heb je al dat soort "uit dienst" beleid, en een refresh met een bepaalde frequentie.


Het zal denk ik wel blijven. Of misschien verschuiven als 'premium feature' . LetsEncrypt wilde ervan af.
Als je WEET dat een certificate compromised is, wil je het graag heel acuut intrekken , en kunnen 47 dagen nog best lang zijn.

Als je WEET dat iemand boos weggaat , ga je ook niet wachten op de 30 dagen of 6 maanden of 1 jaar password refresh .


Geen idee , maar een ruime maand levensduur is nogal kort als er handmatige acties in het geheel zitten.
De push is heel duidelijk naar "automatiseren" .

Heb jij laatst nog belastingaangifte gedaan? (In de Chrome browser)
Ik moet drie maal klikken om certificaatgegevens te zien te krijgen. En dan zie ik ENKEL de organisatienaam!
Voor land & regio gegevens moet je in een andere tab het juiste veld aanklikken en dan in een tekstveld kijken.
Sterker nog, het eerste landsnaam dat ik tegenkom is "Ierland", waar de CA zit. Dat zal vragen oproepen.
Verder mist er nog een hoop extra contactgegevens en identificatiegegevens. Geen KVK, geen security email, etc...

Veel andere kritieke websites zijn in een net zo trieste staat, google gebruikt zelfs DV certificaten!

1+1=2, Erik van Straten is een hele goede kerel en ander fake news, inderdaad... ;-)

Ook met forward secrecy is AiTM inderdaad nog steeds een risico als je geen certificaat controleert. DV certificaten bestaan in mijn ogen puur enkel om dit soort aanvallen tegen te gaan. (Gebruik zelf ook Lets Encrypt hiervoor)

Onnodige administratieve last voor veel bedrijven, vooral in de SaaS-sector. En dat alles voor een stukje schijnveiligheid, waarbij de certificaat-uitgifte bedrijven nog meer winst kunnen maken, met een minimale inspanning.

Ik vind het prima, vooralsnog genereer ik self signed met geldigheid 1970..2200.
Heb anders devices die onderling communicatie verliezen wanneer NTP server onbeschikbaar, deze klappen dan terug naar het jaar 1970 ipv dat ze de interne tijd oppakken.(hebber RTC aan boord).

Waarom verzin je dat winst maken ?
Waarom verzin je dat SAAS bedrijven cert updates met de hand doen ?

LE is GRATIS

Volgens Let's Encrypt is OCSP een privacy risico en daarom stoppen ze er dit jaar mee. Vanaf 7 mei zal er al geen OCSP adres meer in het certificaat staan.

OCSP is sowieso een probleem omdat de meeste browsers gewoon verder gaan als ze geen OSCP kunnen opvragen. Ik heb nu al 3 keer meegemaakt dat het OSCP van Let's Encryps op een blacklist kwam en mijn router dit daardoor blokkeerde.

Dat de browser daardoor geen OSCP meer kon controleren merkte ik alleen doordat ik hierover een mailtje kreeg van mijn router, het browsen van de websites kon gewoon doorgaan.
Hun OSCP adres komt blijkbaar vaker ten onrechte op een blacklist omdat het in certificaten stond voor dubieuze websites. Diegene die dergelijke blacklists samenstelt heeft blijkbaar niet in de gaten dat ze nu juist het tegenovergestelde bereiken.

Ze doen dit vooral om bedrijven crypto agile te maken voor de mogelijke post-quantum threat.

Dont shoot the messenger

Lets Encrypt wil el-cheapo doen en daarom alles wat data verbruikt opdoeken. OSCP kost veel data, moet je in de lucht houden enz enz. en je moet het bijhouden.. Gewoon zeggen dat het onveilig is (dat is het maken van certificaten voor iedereen die het wil ook) en voila, je hebt een dikke kostenpost weggebonjourd.

Het is net zo'n onzin als dat de supermarkten nu zouden zeggen, de THT datum van alle pakken melk doen we nu 1 dag... want voor de veiligheid immers.. je wil toch niet een pak zure melk hebben?

Droom verder, iemand betaalt daarvoor.

Uit https://mastodon.ar.al/@aral/114224434946164202:
Geen cent van mij, de vervuiler hoort te betalen.

Big Tech (Google voorop) heeft nooit zin gehad in OCSP.

Als browsers onvoorwaardelijk op OCSP zouden checken, zou de industrie veel beter haar best doen om de infrastructuur in de lucht en bereikbaar te houden.

OCSP-stapling is een prima oplossing voor het zogenaamde "privacy-probleem" veroorzaakt door OCSP.

Het hele web is echter verworden tot één gigantisch privacyprobleem; denk aan tig meeglurende derde partijen via JavaScript (bijna altijd Google), maar ook door "vrienden" zoals Cloudflare (zie bijv. https://infosec.exchange/@ErikvanStraten/114341162016914396).

"Kortlevende" certificaten leven nog steeds veel te lang. Op de dag dat Josh Aas aankondigde te stoppen met OCSP, gaf LE (Let's Encrypt) minstens 34 certificaten onterecht uit aan cybercriminelen (en dit was niet de eerste keer). Die criminelen hadden via een BGP-hijack het netwerkverkeer, bedoeld voor servers van [*.]dydx.exchange, omgeleid naar hun servers. Zie https://infosec.exchange/@ErikvanStraten/112914047006977222 en de twee opvolgende toots.

"Dankzij" LE konden zij, in een oogwenk, no questions asked, voor hen gratis (geen geldspoor), 34 certificate-requests onterecht door LE digitaal laten ondertekenen.

Van die 34 trok LE er, redelijk snel, 27 in (CRL's zijn gemiddeld al hartstikke traag; OCSP is instantaan). Trok LE niet alle onterecht uitgegeven certificaten in omdat ze nauwelijks personeel hebben? Immers, het moet zo weinig mogelijk kosten, alles is geautomatiseerd. Pay peanuts...

In de tijd van DigiNotar was het onterecht uitgeven van certificaten een doodzonde. Sinds certificatenslagers hun eigen vlees keuren, is daar geen sprake meer van.

Weer een snap-probleem bij jou.

poster : "ze maken de tijd korter zodat de certificaatboeren meer geld kunnen vragen"
tegenwerping : de certificaatboeren (zoals LE) krijgen nul dollars , dus worden niet rijker van frequentere cert updates.

Jouw commentaar : tang & varken.


Ik zou zo graag ook een DOGE hebben die de bezem door alle EU subsidies haalde.

Waarom is encryptie van verkeer nog ondergebracht bij certificaat goede? Waarom is TLSA ondertussen niet leidend voor encryptie van verkeer?

Encryptie gebeurt tussen de webserver en je browser. Om er zeker van te zijn dat je echt met de server verbonden bent, is er een bevestigd authentieke public key nodig. Er is een derde partij nodig daarvoor.

De bevestiging van authentiekheid gebeurt door middel van certificaten die door Certificate Authorities worden uitgeleverd. Zij bevestigen dat jij als server eigenaar het domein daadwerkelijk in handen hebt. Als je enkel wilt controleren dat je echt met het domein verbonden bent, dan is TLSA inderdaad voldoende.

Echter, de CA's hadden ook nog een andere functie: Bevestigen dat de organisatie of individu die het domein beheert authentiek is. Dit gebeurde via de zogenoemde OV en EV certificaten, die voor de "groene slotjes met naam" zorgden. Helaas zijn deze groene slotjes verdwenen en zijn voegen OV en EV certificaten nog maar weinig toe. Niemand kijkt er meer naar en het zit tegenwoordig achter 3 to 5 klikken verborgen. Zelfs Google doet er niet meer aan.

Het hele systeem van domeinveiligheid is gewoon kapot. Er is geen oplossing voor phishing of nepdomeinen, en het proces voor het koppelen van een identiteit aan een domein is gebrekkig. Je weet niet met wie je verbonden bent als je "google.nl" intypt, aangezien er geen enkele organisatie aan zit gekoppeld. Is het de echte google, of iemand anders die toevallig opviel dat Google zich niet had geregistreerd voor de .nl versie?" Je weet het gewoon niet!

Let's encrypt is niet relevant voor SaaS bedrijven, aangezien men met diverse certificaat autoriteiten te maken heeft. Bedrijven die met Certificaat autoriteiten werken moeten hiervoor flink betalen. Automatiseren van certificaat updates is vrij lastig & sowieso heb je met verificaties te maken, waarbij mensen betrokken zijn.

Dat kan anders worden uitgelegd dan hoe het echt werkt:

1) Op de webserver wordt een sleutelpaar gegenereerd. Wat je met de ene sleutel versleutelt, kan uitsluitend met de andere sleutel (uit het paar) worden ontsleuteld. Zie https://www.security.nl/posting/884482/Public+keys+voor+leken.

2) De certificaataanvrager genereert een "certificate request" met daarin de public key uit het sleutelpaar. Dat certificate request wordt ondertekend met de private key uit het sleutelpaar (daarmee wordt het bezit van de private key aangetoond).

3) De certificaataanvrager stuurt het "certificate request" naar een CSP (Certificate Service Provider) die meer of minder goed controleert of alles klopt in de aanvraag, enkele gegevens toevoegt en een er een "pre-certificate" van maakt.

4) Het pre-certificate wordt voorzien van digitale handtekeningen van andere certificaatuitgevers, waarna het als bruikbaar "leaf certificate" wordt geretourneerd naar de aanvrager.

Precies, in zoverre dat browsermakers medeschuldig zijn.

Erger nog, google.nl staat niet op de HSTS-preload lijst en verstuurt geen HSTS headers: https://hstspreload.org/?domain=google.nl#submission-form.

Daarom is het uitermate verstandig om jouw browser, indien deze dat ondersteunt, je zo in te stellen dat deze waarschuwt indien er (ook al is het maar héél eventjes) van een http-verbinding gebruik wordt gemaakt.

Beste mensen,

Erik heeft gelijk.
Het is alleen nog een beetje erger dan Erik aangeeft.

De doelstelling van verkorting levensduur certificaten is alleen maar dat elke website eigenaar alleen nog maar bij BigTech CA's (zoals LetsEncrypt) kan verkrijgen. Want
- dan zal de website eigenaar dat ook den
- en dan kan voor elke gebruiker het webverkeer worden gemonitored (niet wat u lees, wel welke website).
- en dan heeft BigTech geen tracking cookies meer nodig om u te bestoken met reclames.

voorbeeld: als ik de websites bezoek van Volkswagen, BMW en Mercedes, dan is een commercial van 1 van die drie naar ineens veel waardevoller geworden

Ondanks dat Google (en Mozilla en dus ook LetsEncrypt) geen OCSP wensen, de URL naar de validatieserver (OCSP format) is er nog steeds.
- Uitdaging 1 aan u : toon aan dat dit niet meer zo is.
- Uitdaging 2 aan u : toon aan dat die niet onmiddellijk kan worden ingevoegd.

Dat daardoor 'noodgedwongen' uw veiligheid op internet door BigTech is verkleind, dat is collateral damage voor BigTech.

Ik denk dat we dit hele proces moeten opsplitsen in 3 delen:

1. Beveiligen van de verbinding: We willen AitM aanvallen en afluistersessies voorkomen. Certificate Authorities zijn blijkbaar een zeer zwak punt hiervoor. Er zijn genoeg incidenten geweest om dit aan te tonen. En omdat er tegenwoordig geen praktisch verschil meer zit in EV/OV en DV certificaten, kunnen we het hele certificaat gebeuren hiervoor afschaffen. Het doel is om de verbinding veilig te houden, en (een opvolger van) TLSA waar de autoriteit van de server door DNS(Sec) word bevestigd is daarvoor voldoende. Bijkomend voordeel is dat CA's minder server kosten hebben. ;)

2. Domeinen aan organisaties koppelen: Voor de meeste hobby sites, kleine forums en blogs is stap 1 voldoende. Maar voor grotere of gevoelige websites wil je toch echt wel bevestigd hebben dat je op de juiste website zit. Denk aan zaken zoals overheid, zorg, financieel en populaire diensten, bijvoorbeeld sites als: belastingdienst.nl, google.com, youtube.com, x.com, overheid.nl, paypal.site, nos.nl, etc.
Voor deze diensten wil je een certificaat van echtheid hebben, met alle bijbehorende identificerende gegevens. Het moet duidelijk zijn dat de domeinnaam daadwerkelijk bij de dienst hoort die je verwacht. Dit certificaat moet duidelijk leesbaar beschikbaar zijn binnen een enkele klik en er moet een hint zijn dat er een certificaat beschikbaar is. (groen slotje?)

3. Zelf-erkende domeinen: Gebruikers zullen een aantal websites veel gebruiken. Ongeacht of deze websites een certificaat van echtheid hebben zal de gebruiker het domein vertrouwen. Om de risico van links naar namaaksites zo veel mogelijk weg te nemen moet het mogelijk zijn voor de gebruiker om zelf een website/domein als bekend te markeren. De gebruiker zou de site een naam en kleurtje kunnen geven welke dan in de URL-balk zichtbaar word. Hierdoor is het makkelijk te zien als je op een namaak site beland, want de verwachte naam en kleur ontbreekt dan. Als een website een certificaat heeft, kan deze getoond worden tijdens het geven van een naam en kleurtje zodat de gebruiker de bevestiging heeft dat hij de juiste website te pakken heeft.

Ik denk persoonlijk dat dit is hoe het opgelost moet worden.
Op deze manier worden CA's verlost van de taak om DV certificaten uit te delen.
Hierdoor kunnen ze zich focussen op het koppelen van organisatie aan domeinnamen.
(Dit beperkt trouwens ook de gevolgen van gelekte root certificaten.)

Met alle respect, maar die incidenten ken ik niet; je lijkt zaken door elkaar te halen.

De (TLS-) verbinding is zelden of nooit het probleem.

Bij ouderwetse https verbindingen (zonder foward secrecy) stuurde de server diens certificaat (over de nog onversleutelde verbinding) naar de browser, met daarin een public key bedoeld voor encryption. De browser genereerde een random symmetrische sessiesleutel, versleutelde die met de public key in het certificaat en stuurde het resultaat naar de server. Als uitsluitend die server de private key heeft (passend bij de public key in het certificaat), kan uitsluitend die server dat resultaat ontsleutelen. Daarmee kennen zowel de server als de browser de symmetrische sessiesleutel.

De browser verifieert dat de domeinnaam, getoond in de adresbalk van de browser, als geldig is opgenomen in het certificaat.

Het certificaat en sleutelpaar werden zowel gebruikt voor veilige uitwisseling van de symmetrische sessiesleutel, als voor authenticatie van de server.

De Diffie-Hellman key agreement vind ik wat lastig uit te leggen, maar stel je het volgende voor bij https met forward secrecy.

Bij elke nieuwe verbinding genereert de server een nieuw random asymmetrisch sleutelpaar en stuurt de publieke sleutel (over de nog onversleutelde verbinding) naar de browser. De browser genereert een random symmetrische sessiesleutel, versleutelt die met de verse public key van de server (bij TLS v1.3 heeft de browser het certificaat überhaupt nog niet ontvangen), en stuurt het resultaat naar de server (die op dat moment nog een AitM kan zijn). De server genereert (met diens private key behorend bij de public key in het certificaat) een digitale handtekening over "het resultaat" en stuurt zowel het certificaat als de digitale handtekening naar de browser. De browser verifieert, met de public key uit het certificaat, dat de digitale handtekening klopt, en dat de domeinnaam getoond in de adresbalk van de browser als geldig is opgenomen in het certificaat.

Het certificaat en bijbehorende sleutelpaar werd hier uitsluitend gebruikt voor authenticatie van de server.

Mijn punt is: behoudens te zwakke cryptografie of inplementatiefouten (bijv. een slechte random number generator) kom je hier, als AitM, niet tussen.

De techniek achter TLS en https is niet het probleem.

Het probleem is: over welke server hebben we het: de "echte", een niet-kwaadaardige MitM of een AitM?

Ik zie op z'n minst drie verschillende mogelijkheden.

Gelukkig komt dit relatief zelden voor (risico met kleine kans doch potentieel gigantische impact): onterecht uitgegeven certificaten. Zie https://infosec.exchange/@ErikvanStraten/112914047006977222.

Voorbeeld: https://nefkens-opel.nl is niet van een Opel garage van Nefkens.

Als een server van Cloudflare een certificaat (met bijbehorende private key) heeft van https://vvd.nl, en je opent die link, dan heeft jouw browser een niet-te-AitM'en verbinding met een server van Cloudflare.

Dat is niet de échte server van de VVD (los van dat die waarschijnlijk op een cloudserver van een andere Amerikaanse partij gehost wordt). En je hebt geen idee over de betrouwbaarheid van de verbinding tussen de Cloudflare server en de "echte" VVD-server.

Er gaat steeds meer internetverkeer via Cloudflare, en Cloudflare heeft toegang tot al dat netwerkverkeer - ontsleuteld wel te verstaan.

Je zou het terecht kunnen noemen dat Cloudflare een certificaat voor https://vvd.nl kan verkrijgen, maar Cloudflare is niet de VVD. Op z'n minst zou jouw browser hiervoor moeten waarschuwen. Cloudflare kan besluiten jou te blokkeren, andere informatie te laten zien of jouw account te kapen (indien jij dat hebt en inlogt).

Cloudflare weet van alle websites "achter hen" dat jij ze bezoekt, welke pagina's je bekijkt en welke gegevens jij opstuurt. Terwijl in de adresbalk van jouw browser allerlei domeinnamen staan (niet Cloudflare.com) met een hangslotje ervoor.

Als je het bovenstaande niet begrijpt heeft verdere discussie geen zin vrees ik.

Hier ben ik het volledig mee eens.

Ik doelde eigenlijk op dat *alle* beveiligde verbindingen een AitM risico oplopen zodra er ook maar één CA oeps doet. Want (algemeen gesproken) kan elke CA voor elk domein een certificaat uitgeven. Ik durf ervan uit te gaan dat de CIA/NSA/etc wel een of ander root CA in handen hebben en daarmee willekeurig verkeer zou kunnen onderscheppen. En jij bent het DigiNotar incident niet vergeten, toch?

De CA zit hier tussen het domein en de browser in, en vormen daarmee een kwetsbare schakel:

Ik wil de CA's uit het laatste deel van de schakel hebben, zodat de beveiliging niet van CA's afhangt:
Hierdoor zijn gelekte root certs een stuk minder risicovol, aangezien uitgegeven certificaten niet meer te misbruiken zijn voor een AitM aanval. Ik ga er wel van uit dat DNSSec te vertrouwen is in deze situatie. (maar als DNS compromised is, dan zijn certs ook zinloos, want die vraag je dan zó aan...)

In principe moet je dan veilig met de website kunnen verbinden zonder dat daar een CA voor nodig is.
Dit scheelt een hele hoop DV certificaten en ontlast CA's van de taak om servercertificaten uit te delen.
Hierdoor kunnen die CA's zich focussen op hun primaire functie: Organisaties verifiëren!
(met nieuw soort certificaat waar meer info in zit zoals bijvoorbeeld een omschrijving, KVK of kantooradres?)

Klopt (los van CAA). Maar hoe groot is dat risico? Vooral: hoe vaak gebeurt dat?

Lees nu eerst https://notes.valdikss.org.ru/jabber.ru-mitm/ (overigens één van de incidenten genoemd in https://infosec.exchange/@ErikvanStraten/112914050216821746).

Dat nog los van al het internetverkeer dat nu via of naar Amerikaanse Big Tech zoals Cloudflare, Fastly, Amazon, Google en Microsoft gaat. Met de FISA Section 702 wetgeving kunnen de Amerikaanse drie-letter veiligheidsdiensten overal meekijken (zonder certificaten nodig te hebben) en de betrokken partijen geheimhoudingsplicht opleggen. Ook als de servers in de EU staan.

Nee, maar zoals ik al schreef: hoe vaak gebeurt dat? En hoe goed doen we onze best om de frequentie van dat soort incidenten te minimaliseren en de detectiekans zo groot mogelijk te maken?

Overigens heeft Certificate Transparency veel verbeterd op dit punt, maar juist CT wordt gesloopt door steeds korter geldige certificaten (https://crt.sh kan de stortvloed nu al nauwelijks aan).

Ik geloof niet dat ik dit helemaal kan volgen, in elk geval mis ik routering (meestal BGP).

Dat kan niet. Zie "Oplossing voor probleem 2: certificaten" in https://security.nl/posting/884774.

M.i. ontkom je er niet aan om een derde partij te vertrouwen. Net als de overheid die af en toe ook onterecht paspoorten afgeeft.