SIDN: afhankelijkheid van klein aantal partijen voor tls-certificaten is risico

De afhankelijkheid van een klein aantal partijen voor tls-certificaten is een risico voor Nederland, meent domeinuitgever SIDN. Vrijwel alle certificaten komen van vier Amerikaanse certificaatautoriteiten.

Een grotere verscheidenheid aan partijen uit diverse landen zou wenselijk zijn, zegt SIDN. "Welke problemen treden er bijvoorbeeld op wanneer Let’s Encrypt wordt getroffen door een DigiNotar-achtig incident of het uitgiftesysteem van Let’s Encrypt voor langere tijd niet beschikbaar is?" vraagt onderzoeker Maarten Wullink zich af. Met een DigiNotar-achtig incident verwijst hij naar de hack bij DigiNotar in 2011. Daarbij verklaarden browsers certificaten van veel overheidsdiensten in een klap ongeldig, iets dat veel problemen veroorzaakte. Hoe SIDN die verscheidenheid wil bewerkstelligen, is vooralsnog onbekend.

In Nederland is Let's Encrypt marktleider volgens SIDN; 71 procent van de certificaten is van die organisatie. Dat komt vooral doordat het gratis is en verlenging automatisch gaat, waardoor het voor veel sites een aantrekkelijke partij is om een certificaat af te nemen. Sectigo, cPanel en DigiCert zijn de andere grote partijen. De enige Nederlandse partij in het rijtje is Trust Provider, dat 0,4 procent van de markt in handen heeft.

Reacties (94)

[CAPSLOCK2000]

De oplossing heet DANE.
Dat kunnen we gebruiken als aanvulling op of vervanging van de meeste "gewone" certificaten.
DANE is een onafhankelijk en gedistribueerd systeem zonder SPOF of afhankelijkheid van een enkele organisatie.

DANE publiceert (een fingerprint van) je TLS-certificaten in DNS.
Op het moment dat je een website (of andere dienst) probeert te bezoeken dan vraagt je browser niet alleen het IP-adres op van die site, maar ook welk TLS-certificaat er verwacht kan worden.
Je hebt dan geen CA meer nodig* om aan te geven welke certificaten "echt" zijn, als beheerder publiceer je dat zelf. Er is dus ook geen centraal punt waar het voor iedereen stuk kan gaan.
Nou ja, als DNS uitvalt dan werkt DANE ook niet meer, maar dan ligt heel internet er uit en werken traditionele certificaten ook niet meer.

Je kan DANE wel niet gebruiken om de identiteit van de eigenaar van een certificaat vast te stellen, maar dat is ook zo bij LetsEncrypt en gewone DV-certificaten die door 90% van de wereld gebruikt worden.

* Maar het kan wel. Je kan ieder certificaat gebruiken voor DANE, het maakt niet uit of het nu self-signed, LetsEncrypt of een traditioneel CA-certificaat is.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 16:09]

[lenwar]

Ik heb me er verder niet op ingelezen, maar is dit niet gevoeliger voor DNS-spoofing?

Als ik als MITM het DNS-verkeer afvang (even uit te gaan dat er geen DoH/etc gebruikt wordt), dan kan ik toch alsnog iemand zonder dat hij het merkt naar mijn malafide server sturen, en dat hij dan zelfs nog een geldige https-verbinding ziet (want mijn DANE-record komt overeen met mijn malafide server)?

Met ondertekende certificaten moet de hacker daadwerkelijk controle hebben over de NS-records van het te spoofen domein.

Of zit ik er nu helemaal naast?

[jk-5]

Je hebt inderdaad een goed punt, maar dit is opgelost met DNSSEC. DANE werkt alleen voor zones die met dnssec ondertekend zijn, en daarmee is dit risico dus uitgesloten

[ProperChaos]

En voor DNSSEC ben je weer afhankelijk van organisaties die de root servers en de TLDs onderhouden...

[jk-5]

Maar dat ben je sowieso al als je een domeinnaam koopt, dus daar verandert niks aan met de invoering van DANE voor SSL-certificaten

[lenwar]

DNSSEC is de controle tussen de DNS server (waar de client mee praat) en de same server (waar de DNS Server mee praat)

Maar als ik die malafide DNS server beheer, ga ik toch niets doen met DNSSEC? Ik stuur gewoon het antwoord terug naar mijn malafide webserver.

[jk-5]

Ja dat is dus precies het punt, als je niks gaat doen met DNSSEC dan wordt DANE niet toegestaan. De client applicatie moet expliciet weten dat DNSSEC is gevalideerd, met bijvoorbeeld de dnssec flag in een dns request/response icm een trusted validating dns resolver of een lokale validating resolver zoals systemd resolved kan doen.

[Reactie gewijzigd door jk-5 op 22 juli 2024 16:09]

[Tozz]

En dat impliceert dat DANE de eerstkomende 20 jaar kansloos is.

KPN en Ziggo doen geen DNSSEC omdat ze de helpdeskload niet aan kunnen doordat er teveel domeinen zijn die invalide DNSSEC hebben. Dat betekent dat voor het gros van het Nederlandse publiek DANE ook niet zou werken momenteel.

Routertjes van mensen thuis doen ook geen DNSSEC over het algemeen.

[CAPSLOCK2000]

KPN en Ziggo doen geen DNSSEC omdat ze de helpdeskload niet aan kunnen doordat er teveel domeinen zijn die invalide DNSSEC hebben.

Dat is overigens totale onzin. Ik verzorg DNS voor tienduizenden mensen en het is jaren geleden dat ik een klacht heb gehad over DNSSEC. In mijn logs zie ik af en toe wel een melding langs komen maar dat is geen probleem, overal gaat wel eens iets stuk. Als het maar een beetje belangrijk is wordt het snel gerepareerd. Ik zie veel meer sites met verlopen/ongeldige SSL-certificaten dan DNSSEC problemen. Voor de beeldvorming, meer dan de helft van de .nl domeinen heeft DNSSEC. Als er veel problemen waren dan had ik het wel gemerkt.

Er is tegenwoordig toezicht op het gebruik van DNS. Als je in .nl bijvoorbeeld een fout maakt krijg je al snel een melding van SIDN.

Routertjes van mensen thuis doen ook geen DNSSEC over het algemeen.

Geen probleem, DNSSEC doe je op de client, niet op de router. De OS- en/of browser-bouwers kunnen het zelfstandig oppakken zonder dat je router iets hoeft te doen.
Als de DNS-resolver in je router het ook kan is dat mooi meegenomen maar het is absoluut niet nodig.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 16:09]

[Tozz]

Mag je onzin vinden, het is wel de reden dat Ziggo en KPN het niet implementeren.

Niet verlengde SSL certificaten geeft een enigzins duidelijke melding in de browser. Niet werkende DNSSEC zorgt ervoor dat het lijkt alsof je Internet niet werkt.

Geen probleem, DNSSEC doe je op de client, niet op de router.

Veel routers geven DHCP leases uit met het router IP als DNS server. Als die geen DNSSEC praat dan heb je geen validatie. Het klopt niet dat alleen de client validatie hoeft te doen. De hele chain met resolvers moet DNSSEC valideren.

Het zal vast zo zijn dat de client theoretisch zelf nog apart DNSSEC validatie kan doen, maar nu is er geen client die dat doet. bv. standaard Windows of Linux machines doen geen DNSSEC validatie in de resolver library. Die vertrouwen daarvoor (terecht) op de DNS server die ze hebben toegewezen gekregen.

[CAPSLOCK2000]

Mag je onzin vinden, het is wel de reden dat Ziggo en KPN het niet implementeren.

XS4all en Google doen het wel, dus die reden klopt gewoon niet (meer).

Niet verlengde SSL certificaten geeft een enigzins duidelijke melding in de browser. Niet werkende DNSSEC zorgt ervoor dat het lijkt alsof je Internet niet werkt.

Het is een voordeel en een nadeel. Het nadeel is dat mensen steevast op het knopje "toch doorgaan" klikken. Er wordt overigens wel gewerkt aan een beter feedback mechanisme voor DNS, want ook op andere punten schiet dat nog wel eens te kort.

Het klopt niet dat alleen de client validatie hoeft te doen. De hele chain met resolvers moet DNSSEC valideren.

Dit wordt een wellus-nietus verhaal maar het klopt niet. De tussenliggende systemen hoeven niet vertrouwd te worden. Je kan aan het einde van de keten (dus op de client of resolver zelf) alle benodigde informatie opvragen en zelf controleren.
De tussenliggende servers moeten de DNSSEC-informatie uiteraard wel doorgeven, maar ze hoeven er zelf niks mee te doen.

Het zal vast zo zijn dat de client theoretisch zelf nog apart DNSSEC validatie kan doen, maar nu is er geen client die dat doet. bv. standaard Windows of Linux machines doen geen DNSSEC validatie in de resolver library.

Dat klopt, we zijn nog niet klaar met de invoering. Mijn punt is vooral dat je aan het einde (waar dat ook ligt) alles kan controleren zonder de tussenliggende servers te hoeven vertrouwen.

Die vertrouwen daarvoor (terecht) op de DNS server die ze hebben toegewezen gekregen.

Dat "terecht" ben ik het niet zo mee eens, want dan moet je nog steeds de communicatie tussen jouwe client en de DNS-resolver beveiligen. Het mooie van DNSSEC is juist dat je dat soort systemen niet hoeft te vertrouwen want je kan ze controleren.

[Tozz]

Jammer dat je zoveel onwaarheden verkondigd.

KPN en Ziggo doen GEEN DNSSEC. Daarmee het merendeel van de Nederlandse internetters niet. Want die gebruiken gewoon de DNS servers van KPN/Ziggo en doen zelf geen validatie. Ik ken geen DNS resolver library die zelf validatie doet.

Dat XS4ALL en Google het wel doen doet er niets aan af dat de 2 grootste ISPs in ons land geen validatie doet.

Dit wordt een wellus-nietus verhaal maar het klopt niet. De tussenliggende systemen hoeven niet vertrouwd te worden. Je kan aan het einde van de keten (dus op de client of resolver zelf) alle benodigde informatie opvragen en zelf controleren.

Een client *kan* het misschien doen, maar geen enkele client doet het ook daadwerkelijk. DNSSEC validatie vergt namelijk wat meer dan wat UDP requests afvuren. Bovendien, als een DNS client library wel DNSSEC validatie doet maar de resolver waar hij gebruik van maakt niet en het ook niet doorgeeft dan kom je alsnog niet verder.

De praktijk is heel simpel: De 2 grootste ISPs van het land doen geen DNSSEC. Standaard clients (Windows/Linux/Mac) doen geen DNSSEC validatie op eigen houtje. Doet de resolver (die de client krijgt vanuit DHCP) geen DNSSEC, dan doet de client geen DNSSEC. Zo simpel is het. Niet meer en niet minder.

Dat het allemaal anders kan voor iemand die uberhaupt weet wat DNSSEC is.. Dat is prachtig, maar je moet uit gaan van de gemiddelde situatie. En in de gemiddelde situatie wordt er nu gewoon voor >90% van het Nederlandse volk geen DNSSEC gedaan.

[CAPSLOCK2000]

Jammer dat je zoveel onwaarheden verkondigd.

KPN en Ziggo doen GEEN DNSSEC. Daarmee het merendeel van de Nederlandse internetters niet.
Want die gebruiken gewoon de DNS servers van KPN/Ziggo en doen zelf geen validatie.

Volgens mij hebben we een misverstand want dat is precies wat ik zeg.

Ik ken geen DNS resolver library die zelf validatie doet.

getdns en libunbound kunnen het, zie bv: https://getdnsapi.net/dox...00791234d2c9d6dc5202d1b18

Dat XS4ALL en Google het wel doen doet er niets aan af dat de 2 grootste ISPs in ons land geen validatie doet.

We hadden over de vraag of het kan, niet of ze het doen.

Een client *kan* het misschien doen, maar geen enkele client doet het ook daadwerkelijk

Misschien dat ik hier wat onduidelijk ben geweest, maar veel moderne systemen draaien lokaal een resolver en daar kun je dus eenvoudig DNSSEC doen voor je hele systeem. Er is dan geen onbeveiligd pad tussen resolver en applicatie. Het is nog mooier als applicaties het direct doen, maar dat is inderdaad extreem zeldzaam.

Bovendien, als een DNS client library wel DNSSEC validatie doet maar de resolver waar hij gebruik van maakt niet en het ook niet doorgeeft dan kom je alsnog niet verder.

Tja, als je de kabel doorknipt kom je ook niet verder. DNSSEC kan niet op magische wijze voorbij firewalls of andere systemen die informatie tegen houden. Geen enkel beveiligingssysteem kan informatie door een blokkade heen toveren, dat is niet het doel.
Maar met DNSSEC weet je in ieder geval dat er informatie wordt tegengehouden en dat je de informatie die je wel krijgt dus niet mag vertrouwen en alle implementaties die ik ken blokkeren de verbinding dan.

De praktijk is heel simpel: De 2 grootste ISPs van het land doen geen DNSSEC. Standaard clients (Windows/Linux/Mac) doen geen DNSSEC validatie op eigen houtje. Doet de resolver (die de client krijgt vanuit DHCP) geen DNSSEC, dan doet de client geen DNSSEC. Zo simpel is het. Niet meer en niet minder.

Dat het allemaal anders kan voor iemand die uberhaupt weet wat DNSSEC is.. Dat is prachtig, maar je moet uit gaan van de gemiddelde situatie. En in de gemiddelde situatie wordt er nu gewoon voor >90% van het Nederlandse volk geen DNSSEC gedaan.

Ik weet niet wat je probeert te zeggen. Wil je het hebben over de theoretische werking van het systeem of over wat de gemiddelde consument in praktijk doet?

Dat de twee grootste ISPs geen DNSSEC doen is duidelijk. Jij beweerde dat het zo is omdat het te veel gedoe zou opleveren voor de helpdesk. Ik laat zien dat die angst onterecht is omdat andere grote DNS-aanbieders het wel doen en de belasting voor hun helpdesk dus blijkbaar acceptabel is.

[lenwar]

Helder
Het kwartje is gevallen. Bedankt voor de uitleg.

[CAPSLOCK2000]

Als het goed is controleer je DNSSEC (ook) op de client.
Je kan DNSSEC-informatie wel strippen, maar niet verbergen dat je het hebt gestript.
Als jouw malafide DNS-server een vals of incompleet antwoord geeft zal mijn client (of de ACME-server) dat antwoord als vals herkennen en weigeren.

[lenwar]

Het kwartje is gevallen. Bedankt voor de uitleg.

[CAPSLOCK2000]

Als je geen DNSSEC gebruikt dan klopt dat, maar zonder DNSSEC kun je ook niet op je gewone certificaten vertrouwen. DV, OV en LetsEncrypt certificaten zijn namelijk allemaal afhankelijk van een betrouwbaar DNS-systeem.
Pas als je naar EV toe gaat krijg je controles die niet te misleiden zijn door DNS te onderschappen.

[lenwar]

Dat klopt.

Maar als mijn malafide DNS server geen DNSSEC gebruikt, maakt de hele DNSSEC infrastruur niets meer uit. De verkenner en/of een besturingssysteem doen niets met DNSSEC.

Maar ook zonder DNSSEC weet je in elk geval zeker dat het certificaat is ondertekend door een CA die jouw verkenner vertrouwd. Of die CA dat had mogen doen is natuurlijk dan niet gecontroleerd.

[CAPSLOCK2000]

Maar als mijn malafide DNS server geen DNSSEC gebruikt, maakt de hele DNSSEC infrastruur niets meer uit.

Nee hoor, ik zie dan gewoon dat jouw antwoorden malafide zijn en weiger ze.

De verkenner en/of een besturingssysteem doen niets met DNSSEC.

Dat ligt aan jouw OS.

Maar ook zonder DNSSEC weet je in elk geval zeker dat het certificaat is ondertekend door een CA die jouw verkenner vertrouwd. Of die CA dat had mogen doen is natuurlijk dan niet gecontroleerd.

Dat klopt en in sommige gevallen is dat inderdaad nuttig. In praktijk heb je er alleen niet heel veel aan. Mensen controleren toch niet of ze wel op de site.com zijn gekomen, of dat ze op s1te.com zitten. Het hele idee van een certificaat gebruiken om de identiteit of echtheid van een site te controleren heeft weinig zin meer. Die certificaten zijn er om je communicatie met de webserver te beveiligen tegen afluisteren, meer niet. Wat dat betreft zouden we wat mij betreft ook over kunnen gaan op self-signed certificaten, maar dat zou verstorend zijn voor iedereen die (om goede of slechte redenen) wel nog gebruik maakt van een gewone CA.

[Tozz]

Dat is wel heel erg theoretisch. Je bedoelt dan neem ik aan dat een aanvaller de DNS van bv. een DV uitgever moet kunnen poisonen om zo een DV uitgeleverd te krijgen die niet uitgeleverd had mogen worden, en dat de aanvaller dan hetzelfde trucje moet uithalen bij een bezoeker van de website met het foutief uitgegeven certificaat?

Theoretisch kan het, in praktijk lijkt me dat onmogelijk.

[CAPSLOCK2000]

Ja, dat klopt. Het wordt een stuk haalbaarder als je de bezoeker kan MITM'en omdat je de (onbevoegde) beheerder van het WIFI-netwerk bent.
Wat ook "helpt" is dat DNS typisch over UDP loopt en dus eenvoudig te spoofen is. Als je kan voorspellen wanneer een bepaalde DNS-resolver om een bepaald antwoord kan vragen (en dat kan je als je een ACME-verzoek doet), dan kun je zo'n server flooden met vervalste antwoorden. Er is wel een beetje beveiliging tegen maar die is nogal minimaal en met brute force te doorbreken.
DNSSEC beschermt daar tegen.

[Mushroomician]

Nog nooit eerder van gehoord. Dit is toch geweldig? What's the catch? Waarom ondersteund Chrome dit niet maar FF wel?

[CAPSLOCK2000]

De catch is dat je DNSSEC nodig hebt en dit nog niet standaard aan staat in onze besturingssystemen. Onze ISPs zouden ons 90% op weg kunnen helpen door DNSSEC aan te zetten op hun resolvers, maar dat wordt alleen door kleine ISPs gedaan die zich op kwaliteit richten (XS4All enzo). Ziggo en KPN doen niks dat niet noodzakelijk is om de kosten zo laag mogelijk te houden.

[Mushroomician]

Ach, ze zijn er mee bezig:

Telfort: "Bij Telfort gebruiken we nu standaard DNSSEC om jou nog veiliger te laten internetten."
Ook Telfort: "We gaan straks samen met KPN, dus bij KPN komt deze beveiliging er ook bij. De technische voorbereiding voor DNSSEC is voor Telfort-klanten iets sneller klaar dan voor KPN-klanten. Doe er je voordeel mee! Zo zorgen we er samen voor dat het internet zo veilig mogelijk blijft."

Bron: https://forum.telfort.nl/...internet-met-dnssec-85090

[CAPSLOCK2000]

Dat is erg goed nieuws! Fijn om te horen, het is ook gewoon zonde om het niet te doen.

[ACM]

't Levert natuurlijk wel een interessant kip-en-ei probleem op als je DANE wilt combineren met DNS over HTTPS zoals diverse browsers nu aan het pushen zijn

[CAPSLOCK2000]

't Levert natuurlijk wel een interessant kip-en-ei probleem op als je DANE wilt combineren met DNS over HTTPS zoals diverse browsers nu aan het pushen zijn

Zonder DANE is ook lastig. DoH servers worden namelijk meestal via een URL geconfigureerd. Voor je daar gebruik van kan maken zal je toch de hostname uit die URL moeten resolven.
Je zou ze ook op IP-adres kunnen configureren maar dan wordt het weer lastig om controleerbare SSL-certificaten te gebruiken.

Ik ben eerlijk gezegd niet zo'n fan van DoH, er zijn te veel rauwe randjes waar ze niet goed over na hebben gedacht. Voor de duidelijkheid: ik ben niet tégen DoH, in een hoop gevallen is het beter dan wat er was, maar ik ben geen fan.

[WhatsappHack]

Comodo en Sectigo is een en ‘t zelfde bedrijf en cPanel’s certificaten zijn ook gewoon uitgegeven door Sectigo (tenzij je handmatig LE hebt ingeschakeld). Dus die kunnen allemaal eigenlijk ook op een hoop in de statistieken (tezamen met CF).

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 16:09]

[Mattashii]

Sectigo is daarnaast ook een brits bedrijf (ingeschreven in UK, en valt onder UK recht). Zie https://sectigo.com/legal.

Ik weet niet waarom ze dat bij SIDN fout hebben gedaan, maar dat is toch een grove 15-25% van de certificaten.

[Reactie gewijzigd door Mattashii op 22 juli 2024 16:09]

[foxofinfinety]

https://sectigo.com/about

About Sectigo

• ...
• Headquartered in Roseland, NJ USA
• ...

Ze hebben wel regionale kantoren in Engeland en Canada maar het is een Amerikaans bedrijf.

[Mattashii]

Ha, dat wist ik niet. Al hun CA-gerelateerde documenten hebben namelijk een adres in Salford, Greater Manchester, GB, en de privacy statement heeft "Sectigo, Inc" als naam voor zijn adres in de US (de about-pagina heeft wel Sectigo Limited).

[- peter -]

Het hele protocol van letsencrypt is wel open. Dus mocht er iets aan de hand zijn kan je, mits er een andere aanbieder is, gemakkelijk overschakelen.

[The Zep Man]

Zijn er dan andere aanbieders die hetzelfde protocol geïmplementeerd hebben?

[ProperChaos]

Er is inderdaad een andere aanbieder van gratis geautomatiseerde certificaten via ACME: https://www.buypass.com/ssl/products/acme

Hier ook nog een leuk artikel over hoe je een backup CA kunt gebruiken: https://scotthelme.co.uk/...ckup-ca-for-lets-encrypt/

[Reactie gewijzigd door ProperChaos op 22 juli 2024 16:09]

[The Zep Man]

Dit is interessant. Eigenlijk is het niet kritisch waar een gratis certificaat vandaan komt, zolang de root CA maar op de lijst van vertrouwde CA's staat in browsers/besturingssystemen. Er is prima wat te scripten dat wanneer Let's Encrypt (herhaaldelijk) niet correct reageert dat simpelweg een andere aanbieder geprobeerd wordt.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:09]

[D11]

Eigenlijk is het niet kritisch waar een gratis certificaat vandaan komt

.

Ik heb zelf toch graag een betrouwbare partij, het liefst eentje die niet in handen is van een overheidsorganisatie.

[Bardman1]

.

[Reactie gewijzigd door Bardman1 op 22 juli 2024 16:09]

[Patriot]

Heb je zijn reactie wel goed gelezen, of vind je overheden inderdaad betrouwbaar in deze?

[svenslootweg]

Het maakt in de praktijk eigenlijk geen bal uit waar je je certificaat vandaan haalt, en of ze nou betrouwbaar zijn of niet. De baseline is dat iedere CA een certificaat voor ieder domein uit kan geven, ongeacht waar de legitieme eigenaar van dat domein zijn certificaat vandaan heeft gehaald.

Oftewel: als Van De Vrachtwagen Gevallen BV een erkende CA is, dan kunnen ze toch wel een vals certificaat voor je domein uitgeven, of jij je certificaat nu bij Let's Encrypt hebt gehaald of bij Van De Vrachtwagen Gevallen BV.

[smartbit]

Buypass wordt klaarblijkelijk ook door Certmanager ondersteunt, zie deze thread & issue 1375. Zeker het proberen waard, leuk vrijdag project.

[lenwar]

Volgens Wikipedia zijn het er op het moment van schrijven acht:
https://en.wikipedia.org/...t_offer_ACME_certificates

[smartbit]

Het wikipedia lema beschrijft niet welke gratis is en welke niet. Enig idee?

[markjanssen]

Buypass.com heb ik zelf getest/gebruikt, en is gratis.

[CAPSLOCK2000]

Ik weet van Digicert en Sectigo dat ze er mee bezig zijn, al lijken die implementaties nog experimenteel en beperkt te zijn.

[Bor]

Het gaat hier niet zo zeer alleen om een open protocol maar meer om de effecten bij een compromise van de certificaat uitgever. Jij bekijkt het nu vanuit het perspecief als afnemer van (gratis) certificaat diensten. Daar is zijn grotere risico's.

[svenslootweg]

Als een CA gehackt is, kunnen ze sowieso certificaten uitgeven voor ieder domein. Hoeveel legitieme certificaten ze uitgegeven hebben, is daarvoor volkomen irrelevant.

Het hebben van meerdere CAs is dan ook eigenlijk alleen maar wenselijk vanuit availability-perspectief; vanuit beveiligings-perspectief wil je er eigenlijk juist zo min mogelijk hebben, want iedere erkende CA is een extra single point of failure.

[basix]

Voor het publieke domein mis ik PKI Overheid als Root in dit artikel.

[Blokker_1999]

Daar kan niemand, buiten de overheid, certificaten kopen. Er zijn enorm veel CAs die niet de markt bedienen, enkel zichzelf en dus ook niet helpen bij de outage van 1 van de weinige grote CAs die er overblijven.

[mrdemc]

Ook buiten de overheid worden PKIOverheid certificaten gebruikt. Het gaat voornamelijk om diensten die betrekking hebben op overheidstaken.
Dus bijv. DigiD, maar ook persoonlijke certificaten voor beschermde beroepen. Maar ook partijen die communiceren met overheidsdiensten kunnen of moeten hiervan gebruik maken.
https://certificaat.kpn.com/pkioverheidcertificaten/

[Reactie gewijzigd door mrdemc op 22 juli 2024 16:09]

[rbr320]

Dat klopt, maar het aanvragen van die pkioverheid certificaten loopt nog steeds via de overheidsinstantie waar de commerciële partij mee moet communiceren

[mrdemc]

Als je met commerciële partijen de Trust Service Providers bedoelt dan klopt dat. Logius heeft het beheer van de certificaten maar de aanvraag kan via verschillende commerciële partijen zoals KPN maar in totaal zijn dit 5 verschillende partijen. Met Logius heb je als afnemer geen contact.

[Reactie gewijzigd door mrdemc op 22 juli 2024 16:09]

[lenwar]

Het is een hele kleine PKI (en die niet publiekelijk beschikbaar is voor iedereen). Of had je liever gehad dat alle PKIs die in je verkenners staan in een lijstje werden gezet?

Dit zijn de meestgebruikte certificaatverstrekkers voor .nl-domeinen.
https://stats.sidnlabs.nl...s-certificaatautoriteiten

[kwakzalver]

Onze overheid is ook geen 'vertrouwde' Root certificaat provider (die Microsoft een paar ton betaald om als vertrouwd te worden beschouwd.)

Heeft zijn voor- en nadelen.
Maar het certificaat moet nadrukkelijk handmatig worden geïnstalleerd.

Bron: https://www.pkioverheid.nl

[SleutelMan]

Erhm, dat geldt alleen voor de Private Root CA - G1 en de testroot (beide nogal logisch).

De G2, G3 en EV Root CA's zijn wel degelijk publiekelijk vertrouwd (zie ook bijv. https://crt.sh/?caid=5962)

[MikeN]

Uh, wat is je bron? Dat ze op een pagina hun certificaten hebben staan betekent niet dat ze niet trusted zijn.

Ter info, in ieder geval de volgende zitten gewoon in Windows en Mac OS:

Staat der Nederlanden EV Root CA
Staat der Nederlanden Root CA - G2
Staat der Nederlanden Root CA - G3

Zie o.a. https://ccadb-public.secu...ACertificateReportForMSFT

[wifikabelhuren]

Waarom kan er niet een algemeen certificaat komen als toch iedereen maar gratis zonder verificatie een certificaat kan aanvragen. (heb er geen verstand van hoor)

[Reactie gewijzigd door wifikabelhuren op 22 juli 2024 16:09]

[WhatsappHack]

Zonder verificatie kan niet, dan krijg je een self-signed certificaat; en die worden niet vertrouwd door browsers, telefoons, et cetera tenzij je deze handmatig als vertrouwd markeert.

[CAPSLOCK2000]

De belangrijkste functie van een certificaat is zorgen dat je verbinding niet wordt afgeluisterd.
Het controleren van je identiteit is in praktijk een stuk minder belangrijk. Dat hebben we dus al grotendeels laten varen. Beschermen tegen afluisteren/onderscheppen/manipuleren is wel nog belangrijk.

Daarom is het belangrijk dat iedereen een uniek certificaat heeft.
Anders is het alsof je iedereen dezelfde huissleutel geeft, dan kan iedereen overal zomaar naar binnen.

[lenwar]

Er is zeker wel verificatie.
Er wordt geverifieerd, dat de aanvrager uberhaupt iets te maken heeft met de domeinnaam. Dus in het geval van DNS-spoofing, kan je bestemming niet ondertekend zijn. (tenzij de 'hacker' ook toegang heeft tot je domein natuurlijk)

[The Zep Man]

"Welke problemen treden er bijvoorbeeld op wanneer Let’s Encrypt wordt getroffen door een Diginotar-achtig incident of het uitgiftesysteem van Let’s Encrypt voor langere tijd niet beschikbaar is?"

Een aantal sites zullen even niet beschikbaar zijn totdat er een nieuw certificaat van een andere aanbieder geïnstalleerd wordt.

Kom verder maar op met (gratis) alternatieven voor Let's Encrypt. Wel graag 100% compatibel met certbot.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:09]

[Bor]

Een aantal sites zullen even niet beschikbaar zijn totdat er een nieuw certificaat van een andere aanbieder geïnstalleerd wordt.

Je focussed hier alleen op het laatste deel van de zin. Het grotere gevaar zit waarschijnlijk in het eerste deel; bij Diginotar zagen we een certificaat ten onrechte uitgegeven worden voor *.google.com met alle mogelijke gevolgen van dien.

[lenwar]

Er zijn op het moment van schrijven acht bedrijven die het ACME(v2) protocol ondersteunen:
https://en.wikipedia.org/...t_offer_ACME_certificates

Welke er gratis van zijn weet ik zo 1-2-3 niet.

Een aantal sites zullen even niet beschikbaar zijn totdat er een nieuw certificaat van een andere aanbieder geïnstalleerd wordt.

Afhankelijk van de site of andere dienst die afhankelijk is van SSL-certificaten, kan dit natuurlijk desastreuze gevolgen hebben voor bedrijfsvoering. Als een site er een halve dag uit ligt, kan dat gigantisch veel geld kosten.

[Ondermertje]

SIDN als gesloten monopolist die een met een BV security diensten is gaan leveren is een directe bedreiging voor onze samenleving.

Daar hoor je niemand over.

Bovendien die "onderzoeker" heeft geen enkele achtergrond in informatie beveiliging.

Dit is onderdeel van FUD marketing waar SIDN al een tijdje mee wegkomt.

Met betrekking tot Cpanel, dat is geen CA, je kunt default (voormalige comodo) certificaten gratis gebruiken OF Let's encrypt, aangezien lang voordat CPANEL er zelf mee kwam er (gratis) integratie modules waren van derden voor Let's Encrypt is leeuwendeel van CPANEL hosters gewoon hierbij gebleven.

[Ventieldopje]

Dat vond ik ook al zo gek. cPanel is geen CA inderdaad en er staat ook duidelijk bij in WHM bij de AutoSSL providers: cPanel (powered by Sectigo).

Dus al die resultaten kun je bij Sectico optellen Het zelfde geldt volgens mij voor Comodo. Leuk dat de SSL infrastructuur helemaal door Cloudfare geregeld wordt maar de CA is gewoon Comodo.

[Reactie gewijzigd door Ventieldopje op 22 juli 2024 16:09]

[Jester-NL]

En Comodo heet tegenwoordig Sectigo.. en staat dus vier keer in de lijst

[Ventieldopje]

Ook dat inderdaad, al zijn ze nog in transitie dus dat is ze vergeven

[webfreakz.nl]

Hoe zit het met de veiligheidsdiensten van de VS die d.m.v een Patriot Act (of vergelijkbaar) bij een Thawte, Comodo, Verisign, LetsEncrypt kopieën kan aanvragen van de private keys van root certificates?

[.oisyn]

Die partijen hebben typisch geen kopie van je private key. Je maakt lokaal een private key en een certificate signing request waar de bijbehorende public key in staat, die wordt ondertekend door de CA als alle gegevens kloppen.

In het resulterende certificaat wat je terugkrijgt staat dus je identiteit (typisch hostname en wat aanvullende informatie) en de pubkey, waarmee iemand kan verifieren dat het verkeer dat van jouw afkomt komt ook echt van jou is. En bovendien staat er een digitale handtekening van de CA onder, waarmee de CA dus garant staat voor die identitiet. De CA heeft bovendien ook zelf een certificaat dat weer wordt vertrouwd door je OS (of dat certificaat is ook weer ondertekend door een andere CA, etc, tot je bij een trusted root certificate uitkomt)

[Reactie gewijzigd door .oisyn op 22 juli 2024 16:09]

[webfreakz.nl]

Mijn zorg was inderdaad niet het uitlekken van mijn private key. Maar zouden ze met de private key van een root CA niet MITM attacks kunnen uitvoeren? Beetje zoals Iran e.d. doen met het afluisteren van al het internet verkeer..?

[.oisyn]

Oh zo. Ja, met zo'n kopie zouden ze elk gewenst certificaat gewoon kunnen ondertekenen als ze dat willen, dat klopt. En dan kunnen ze dus met zo'n gegenereerd certificaat een MitM attack uitvoeren.

[Tozz]

Daarvoor zou je nog certificate pinning kunnen gebruiken. Dat doet bijvoorbeeld de Rabobank in hun Apps.

[lenwar]

Kunnen ze dat? (heb je daar een bron van?) Ik heb er nooit van gehoord.
Maar al zouden ze dat doen. Wat schieten ze er mee op? Dan kan de staat namens die bedrijven certificaten uitdelen? De beheerder van de root-certicaten kan niet meekijken met al het versleutelde verkeer.

[tweaknico]

Als het goed is verlaten private keys NOOIT de server via het acme protocol.
Een CA die een private key voor je aanmaakt zou je moeten mijden..., dat HOORT lokaal te gebeuren.

de CSR bevan jouw public key, het ondertekenen daarvan is voldoende als tijdens connectie een geheimpje gedeeld wordt dat met jouw private key is ondertekent. het certificataa geeft de mogelijkheid om te controleren.

Met die private keys van de root certificaten kunnen wel anderen ondertekent worden.
Zoals bij diginotar ook is gebeurt. Zodra dat bekend wordt is dat het einde van de CA.
Tot die tijd is er vrij spel.

[Reactie gewijzigd door tweaknico op 22 juli 2024 16:09]

[CAPSLOCK2000]

Om dat te voorkomen is er Certificate Transparency. Dat is een logboek waarin de CA's alle certificaten publiceren die ze uitgeven, althans dat beloven ze.

Als er een certificaat gevonden wordt dat niet op de lijst staat (en er zijn tools om automatische controles te doen) dan is onmiddellijk duidelijk dat er iets niet in de haak is en het is duidelijk welke CA z'n private keys heeft laten lekken/misbruiken.

Als dat gebeurt dan heb je als CA heel veel uit te leggen. Uit concurrentie-overwegingen en om de markt te beschermen houden de CA's elkaar als havikken in de gaten.

[Blokker_1999]

Maar wat heb je aan vele aanbieders? Het moment dat het misloopt is het bij beheerders alsnog alle hens aan dek om certificaten te veranderen, configs aan te passen, ... . Daarnaast is het niet eenvoudig om als CA op te staan en te beginnen. Het duurt jaren voordat je eigen root CA vertrouwd zal worden. Al die tijd ben je afhankelijk van een andere partij die hopelijk niet gehacked zal worden.

[CAPSLOCK2000]

Maar wat heb je aan vele aanbieders?

Dat niet het halve land plat gaat door een fout bij een van de weinige aanbieders.
Een paar weken geleden was (een van) de OCSP-servers van Digicert stuk en binnen onze organisatie deed geen enkele website het meer. Dat was nogal pijnlijk en grotendeels buiten onze macht.

[tweaknico]

Dat zou een grond kunnen zijn om aanspraak op de garantie te doen...
falen van de CA waardoor het certificaat niet werkt.

[CAPSLOCK2000]

Die garantie is flinter dun. Met wat geluk krijg je de prijs van het certificaat vergoed. Dat weegt natuurlijk niet op tegen een dag geen zaken kunnen doen. Je garantie opeisen is waarschijnlijk duurder in werktijd dan wat je terug kan krijgen.

[tweaknico]

Toch is die garantie de meerwaarde die veel CA's claimen.
En je hebt vermoedelijk de enige grond te pakken waarop je nog iets kan opeisen.
(garantie dekt geen tonnen, maar wel enkele honderden/duizenden? euro's).

Een e-mail kan voldoende zijn....

[lenwar]

Per individuele site heb je er inderdaad niet zoveel aan. Maar stel dat Letsencrypt ineens niet meer wordt vertrouwd, dan doet dus blijkbaar ineens 71% van de .nl-websites het niet meer. Dat heeft best wel wat impact op alles-en-nogwat. Als alles een beetje verdeeld zou zijn (dus dat elke certificaatverstrekker maximaal 5% van de markt heeft), dan is de algemene impact kleiner. Het is vervelend als die ene dienst het niet doet, maar de rest doet het dan wel.

[wifikabelhuren]

Een geruststelling is dan wel als het niet meer werkt: je bent dan niet de enige met ongeldige certificaten.