Beveiligingsteam Chrome zegt vertrouwen in TLS-certificaten van Entrust op

Het beveiligingsteam van Google Chrome heeft het vertrouwen in de TLS-certificaten van Entrust opgezegd. Het team meent een patroon bij de certificaatautoriteit te ontwaren waaruit moet blijken dat er al jaren niet aan bepaalde kwaliteitseisen wordt voldaan.

Het vermeende patroon heeft het vertrouwen in de certificaatautoriteit naar verluidt geschaad en daarom voert het beveiligingsteam binnenkort enkele wijzigingen door. Het team zal een update voor Google Chrome uitbrengen waarmee bepaalde TLS-certificaten van Entrust vanaf 1 november 2024 niet meer automatisch zullen worden vertrouwd door de browser.

Deze wijzigingen zitten in Google Chrome 127 vervat. Gebruikers die vanaf 1 november 2024 een website met een TLS-certificaat van de certificaatautoriteit bezoeken, krijgen een beveiligingswaarschuwing te zien. Entrust heeft op het moment van schrijven nog niet gereageerd op de maatregel.

Reacties (90)

[Vinez Initez]

Certificeringsautoriteiten (CAs) vervullen een bevoorrechte en vertrouwde rol op het internet die ten grondslag ligt aan versleutelde verbindingen tussen browsers en websites. Met deze verantwoordelijkheid komt de verwachting om te voldoen aan redelijke en consensusgedreven beveiligings- en nalevingsverwachtingen, waaronder die gedefinieerd door de CA/Browser TLS Baseline Requirements.

Gedurende de afgelopen zes jaar heeft het Chrome Security Team een patroon van nalevingsfouten, niet nagekomen verbeteringsbeloften en het ontbreken van tastbare, meetbare vooruitgang in reactie op openbaar gemaakte incidentrapporten waargenomen. Wanneer deze factoren in hun geheel worden beschouwd en afgezet tegen het inherente risico dat elke publiek-vertrouwde CA vormt voor het internetecosysteem, is het Chrome Security Team van mening dat het voortgezette vertrouwen van Chrome in Entrust niet langer gerechtvaardigd is.

Lijst met incidenten:
https://bugzilla.mozilla....advanced&list_id=17064895

[willieverhoef]

Blijf een vreemde zaak. We moeten een certificaat vertrouwen. Maar tegelijkertijd moeten we ook in dit geval google vertrouwen dat het eerlijk is. Blijft jammer dat dit stukje dus commercieel geregeld is zonder toezicht of een instantie die onafhankelijk een CA beoordeeld. Als grootste browser kun je een CA maken en breken.

[laurxp]

Nee, dat is niet hoe het werkt.

CA's moeten zich houden aan de regels van het CA/Browser Forum om in de Trust Store te kunnen komen. Dat is een organisatie die praktisch een "who's who" van het internet is: Amazon, Mozilla, Apple, Cisco, Microsoft, ..., en inderdaad ook Google.

Google kan niet arbitrair kiezen om een willekeurige partij er uit te gooien, dat zou voor een enorme rechtszaak zorgen. De enige reden dat Entrust nu de sjaak is, is omdat ze een hele waslijst aan incidenten hebben gehad waarbij ze in strijd met de branche-regels hebben gehandeld. In dit geval is het Google die het nekschot geeft, maar in zowel de openbare mailing lists van Google én Mozilla is het héél duidelijk dat de gehele industrie zijn vertrouwen in Entrust heeft opgegeven, en van mening is dat er geen verbetering te verwachten is.

CAs kunnen niet ongestraft de gestelde gedragsregels overtreden. Ze bestaan letterlijk om vertrouwen te verkopen - als ze niet te vertrouwen zijn, hebben ze geen bestaansrecht. Zulke partijen in de Trust Store houden is een ondermijning van de veiligheid van het internet.

[EnigmA-X]

Google kan niet arbitrair kiezen om een willekeurige partij er uit te gooien, dat zou voor een enorme rechtszaak zorgen.

Wellicht niet uit de generieke CA/B trust store, maar wel uit hun eigen Chrome Trust store:

A Chrome Root Program Participant’s failure to follow the minimum requirements defined in this policy may result in the corresponding CA certificate’s removal from the Chrome Root Store, limitations on Chrome's acceptance of the certificates they issue, or other technical or policy restrictions.

https://www.chromium.org/...-security/root-ca-policy/

De minimale requirements voor chrome root program participants omvatten onder andere de CA/Browser forum requirements maar er moet OOK voldaan worden aan andere requirements die Chrome specifiek heeft vastgelegd. En die andere requirements zijn reden om Entrust uit de Chrome Trust store te verwijderen.

Google kiest dus wel arbitrair om Entrust uit hun root program te halen, in de zin dat het eigenmachtig is (op basis van de zelfgestelde requirements die hierboven gelinkt staan).

Als dit niet arbitrair zou mogen, is het alleen mogelijk na een oordeel van het CA/Browser Forum, maar daar is hier (zover ik kan zien) absoluut geen sprake van.

Samengevat:

- CA's moeten zich aan meer confirmeren dan in het CA/Browser forum is vastgelegd om getrust te blijven binnen Chrome
- Chrome mag op basis van eigen requirements CA's verwijderen

Voor de duidelijkheid: ik begrijp en accepteer de beslissing die het Chrome team hier maakt. Desondanks is het wel zo dat Chrome de mogelijkheid heeft zelf te beslissen welke CA wel/niet te accepteren. Op zichzelf is dat geen probleem, maar wel minimaal bedenkelijk bij zo'n groot marktaandeel/populariteit op de browsermarkt. Er zijn situaties denkbaar (bijvoorbeeld concurrenten) waarin je die niet zou willen lijkt mij. Belangrijkste: als Chrome dit besluit maakt, maakt het dit besluit voor het marktaandeel aan gebruikers dat ze hebben. Significant dus.

[Reactie gewijzigd door EnigmA-X op 22 juli 2024 15:49]

[Florimon]

Belangrijkste: als Chrome dit besluit maakt, maakt het dit besluit voor het marktaandeel aan gebruikers dat ze hebben. Significant dus.

Maar dat is dan ook Google's volste recht toch? Het is ook niet alsof ze hun gebruikers hiermee benadelen want die kunnen wanneer ze toch willens en wetens het risico willen nemen om een site te bezoeken met een Entrust certificate, gewoon een andere browser inatelleren / gebruiken.

[CAPSLOCK2000]

Blijf een vreemde zaak. We moeten een certificaat vertrouwen. Maar tegelijkertijd moeten we ook in dit geval google vertrouwen dat het eerlijk is. Blijft jammer dat dit stukje dus commercieel geregeld is zonder toezicht of een instantie die onafhankelijk een CA beoordeeld. Als grootste browser kun je een CA maken en breken.

Vertrouwen op internet hangt als een lange ketting aan elkaar.
Vertrouwen kan niet vanuit het niets ontstaan. Je zal ergens iets of iemand in vertrouwen moeten nemen als anker waar je rest aan vast kan maken. In praktijk is dat vooral de maker van je besturingssysteem en je browser, voor de meeste mensen is dat dus het trio Microsoft, Google & Apple.
Die certificaten zijn een andere manier om vertrouwen te ankeren. Maar om dat vertrouwen te controleren heb je software nodig en een lijstje met vertrouwde certificaten. Die software zit typisch in je OS en/of browser en je krijgt ook een kant-en-klaar lijstje met vertrouwde certificaten van CA's mee.

De belangrijkste boodschap is dat je vooral heel erg veel vertrouwen moet hebben in de maker van je OS. Al het andere staat of valt bij de betrouwbaarheid van het OS. Ik heb geen vertrouwen in Microsoft, Google & Apple. Of, beter gezegd, ik heb niet het vertrouwen dat die bedrijven mijn belang op de eerste plek hebben staan. Als puntje bij paaltje komt en er moeilijke keuzes gemaakt moeten worden dan wint het grote geld het van de belangen van de eindgebruiker.

[T-men]

True !

Maar wie vertrouw je dan wel ?

Overheden... ? Nah... die hebben ook belangen, dus die ook niet.
'De community' dan ? Daar is veel te weinig controle. De wolf in schaapskleren kan daar grote brokken maken.
Zelf maar een lijstje bijhouden ? Dat is geen doen. Daarvoor zijn er veel te veel partijen in de markt. Het is voor een expert (of een groep daarvan) al moeilijk, laat staan een argeloze gebruiker.

Ik ben het met je eens: het trio Microsoft, Google & Apple is niet ideaal. Maar een beter optie is er niet.

[autostatic]

Niet helemaal, is iets complexer dan dat. Sterker nog, Entrust had hier best een sterke stem in. En de reactie van Google is begrijpelijk, vooral als je die naast de reacties vanuit Mozilla legt, die zijn vergelijkbaar.

[EnigmA-X]

Wat bedoel je met "Entrust had hier best een sterke stem in"?

De reacties van Mozilla zijn niet vergelijkbaar, de bevindingen wel. Het grote verschil is dat Mozilla (zover ik kan vinden) helemaal nog geen besluit heeft genomen om Entrust wel/niet uit de trusted store te gooien?

[autostatic]

Entrust heeft mede het beleid van het CA/Browser Forum bepaald, zie bijvoorbeeld
https://cabforum.org/about/leadership/

Mozilla heeft nog geen beslissing genomen nee.

En heb de termen reacties en bevindingen door elkaar gehaald, bedankt voor het aangeven.

[EnigmA-X]

Zover ik kan zien, staat nergens dat het Chrome team Entrust "distrust" op basis van wat in CA/Browser Forum vastgesteld is?

De beslissing wordt gemaakt op basis van de Chrome Root Program Policy, zoals hier ook staat: https://security.googlebl...certificate-security.html

Het lijkt mij niet dat Entrust een stem heeft in de Chrome Root Program Policy.

[Reactie gewijzigd door EnigmA-X op 22 juli 2024 15:49]

[i-chat]

[...]en als CA kun je bij toezichthouders klagen over oneerlijke handelspraktijken

als Google ook maar één keer onterecht zulke claims maakt lopen z het risico op enorm schadevergoedingsclms en torenhoge antitrust boetes

[EnigmA-X]

With great power comes great responsibility.
Dat geldt overigens ook voor de grotere CA's.

[dinoballz]

Google heeft ook al eigenhandig besloten certificaten nog maar 90 dagen te erkennen ipv de nu geldende 13 maanden. Als ik niet beter wist zou ik zeggen dat ze een beetje Cyberpunk megacorp achtige trekjes krijgen.

[ibmpc]

Zijn certificaten die kort geldig zijn niet juist veiliger? Voor mijn always-on VPN naar huis gebruik ik certificaten die 24 uur geldig zijn, maar ik wil misschien wel naar certificaten die maar een uur geldig zijn. Dat is veel makkelijker te implementeren dan Conditional Access op een VPN server thuis.

[Ulysses]

Tot op zekere hoogte volg ik jouw specifieke logica. Maar bij het dagelijks of meermaals overhoop halen van infrastructuur die een wat langere uptime en dus maintenance windows met langere intervals heeft, zou ik toch wel tevreden blijven met de 3 maanden geldigheid. Zoals die ik nu via Let's Encrypt meestal instel op webprojecten e.d. - Dit voldoet dan meteen aan een volgende veiligheidsmaatregel van dat het niet al te vluchtig uitgegeven kan worden met dezelfde gegevens wat absoluut misbruik op geautomatiseerde wijze weer dwarsboomt. Hoewel het vernieuwen natuurlijk automatisch gaat daarna idealiter, heb ik ook een systeempje dat ik elke keer handmatig een zetje moet geven voor die weer 'bij' is... maar als die verloopt dan is er dus wat mis met mij persoonlijk haha ;-)
Veel langere geldigheid zie ik echter ook niet als toegevoegde waarde voor eindpunten inderdaad. Zowel te korte als te lange vernieuwingsintervals hebben security nadelen in mijn optiek dus.

[ibmpc]

Intune verlengt de certificaten nu iedere dag. Volgens mij is er geen downtime aangezien de certificaten al enkele uren vantevoren kunnen worden verlengd. Ik wil dat dus terugbrengen naar ieder uur. Zo'n always-on VPN verbindt zo snel, dat je daar volgens mij geen last van hoeft te hebben.

[fenrirs]

ik zie dat nu bij de SAP infrastructuur. Ongeveer elke dag wordt er van certificaten gewisseld. Het aantal mails hierover gaat inmiddels direct door naar een archive. Begrijpelijk, maar heel vervelend, bijna spam.
Ik zie niet in hoe een veilig certificaat dat een jaar geldig is ineens veiliger wordt als je het vaker wisselt, zeker niet als het van dezelfde partij af komt

[aikebah]

Het gaat dan ook niet zozeer om het certificaat, maar om de daarbij behorende prive-sleutel die in veel van dergelijke automatische processen ook mee vervangen wordt met de certificaat-wissel.

Mocht de prive-sleutel onverhoopt lekken, dan kan de crimineel die slechts max 90 dagen gebruiken voor een kloon-site icm DNS-hack, daarna is er een nieuw certificaat waar een nieuwe prive-sleutel hoort zodat de crimineel eerst weer op pad moet om de nieuwe prive-sleutel te verkrijgen voor ie verder kan met zijn louche zaak.

[fenrirs]

dat is waar, maar net als bij veel bedrijven waar je elke maand je ww moet wijzigen, mensen worden lui en overschillig. Bij geautomatiseerde processen is dat anders natuurlijk.

[lilmonkey]

Vandaar ook dat de richtlijn van NIST inmiddels al weer behoorlijk wat jaartjes is dat gebruikers periodiek vragen een nieuw wachtwoord in te stellen de veiligheid juist verslechterd. Natuurlijk wel als er sprake is van een (vermoedelijk) lek.

Dat is echter niet te vergelijken met de situatie hier, zoals je zelf ook al opmerkt, en daarmee dus irrelevant in deze discussie.

[TheMak]

Maar je hebt toch ook weer een sleutel nodig om de komende jaren die certificaten op te vragen?

[aikebah]

Voor opvragen van die certificaten heb je geen sleutel nodig.

Certificaat-aanvraag is populair gezegd: 'he hallo CA, dit is mijn publieke sleutel, zou jij even willen verklaren dat die bij mijn domein hoort door je handtekening eronder te zetten'.
Bij een CA zoals Let's Encrypt in de HTTP validatiesmaak antwoord de CA dan met 'als jij echt dat domein controleert, zet dan deze waarde even op je website onder deze door mij bepaalde URL. Als ik die kan vinden zet ik mijn handtekening dat die publieke sleutel bij jouw domein hoort'

[laurxp]

Heel simpel: er zullen dingen mis gaan met certificaten. Dat is niet een vraag óf, maar wannéér.

Entrust heeft een aantal keer door administratieve fouten certificaten uitgegeven die later weer ingetrokken moesten worden. Volgens de geldende regels moet dat bij administratieve fouten binnen 5 dagen gebeuren. Entrust weigert dit te doen, omdat het "niet serieus" was, en ze grote klanten hebben die in een "freeze" zitten tussen mid-november en mid-januari en daarom liever niks aan willen passen. Bij deze bedrijven is het vervangen van een certificaat een handmatig proces dat weken kan duren, met een handjevol tickets en twee dozijn mensen die er een plasje over moeten doen.

Dat is geen enkel probleem als je een certificaat hebt dat een jaar geldig is. Je zet het gewoon in de agenda, begint een maand of twee van tevoren, en wacht tot het allemaal door de pijplijn komt. Maar wat als er een keer een serieus beveiligingsincident is, en de sleutels (en dus certificaten) acuut moeten worden vervangen? Volgens de regels moet dat binnen 24 uur gebeuren, dat gaat zo'n bedrijf nooit lukken! Moeten we twee of drie maanden lang een gapend gat in de beveiliging van het internet laten, omdat een handjevol bedrijven incompetent is?

Door de certificaten een kortere geldigheid te geven, dwing je een gestroomlijnt vervangingsproces af. Een certificaat dat 90 dagen geldig is, vervang je na +- 60 dagen. Niemand zit er op te wachten om dat iedere twee maanden handmatig te hoeven doen, dus zorg je er voor dat je het proces zo veel mogelijk automatiseert. En als het volledig automatisch gaat, is dat vervangen binnen 24 uur ineens een fluitje van een cent. Dát is waarom kortere certificaten veiliger zijn.

[ibmpc]

Waarom gaan je certificaten naar je archief? Moet je die perse bewaren?

Intune rolt gewoon elke dag een nieuw certificaat uit naar mijn endpoint, maar ik wil dat verkorten naar ieder uur. Als gebruiker zie ik daar volgens mij niets van, of ik let gewoon niet goed op.

[fenrirs]

Alleen de notificaties gaan naar het archief. Liever zou ik hebben dat ze gewoon een mail sturen als er iets MIS is ipv een wolkbreuk aan mails die niet uit te zetten is

[supersnathan94]

13 maanden is ook wel een eeuwigheid en is om meerdere redenen niet zo handig.

1 daarvan is maintenance. Kans is groot dat als ze maar eens per 13 maanden verlengd hoeven te worden je dit gewoon met het handje doet. Iemand die drie keer op rij die verlenging doet (en dat in zijn agenda scheduled) kan dus dik drie jaar ff tussendoor zo’n certificaat verlengen. Totdat deze persoon na 3 jaar weg gaat (wat bij externen bijvoorbeeld erg lang is en vaak vanuit de opdrachtgever wordt gezien als een hard eindpunt, tenzij …). Dan is er dus een kans dat het bij jaar 4 ineens vergeten wordt en de hele boel een tijdje plat ligt.

I kid you not. Verlengen van SSL certificaten is iets wat bij ieder bedrijf wel eens of meerdere keren fout gaat omdat het zo lang gewoon werkt.

Als je ieder kwartaal zoiets moet doen (of liever nog iedere maand) dan ga je dat direct automatiseren.

Gelukkig hebben eigenlijk alle cloud providers hier al een oplossing voor waardoor het automatisch gebeurd en je je er niet druk over hoeft te maken. Scheelt heel veel downtime, want een verlenging doorvoeren met de hand nadat de boel verlopen is kan soms heel lang duren afhankelijk van het type certificaat.

[Abysmax]

Thanks Chatgpt.

[kodak]

Hoe Google problemen met certificaatautoriteiten als te ernstig ziet om vertrouwen op te zeggen is hier niet duidelijker mee geworden.

Zo werden ongeveer 2 jaar geleden bekend dat meerdere platformcertificaten gebruikt werden om malware met zeer hoge rechten te ondertekenen als vertrouwd. In plaats van duidelijke oplossingen werd door Google genoegen genomen met een bewering dat er maatregelen waren genomen. Geen duidelijk intrekken van certificaten, geen duidelijkheid hoe miljoenen gebruikers dan wel beschermd zijn.

Nu maakt een certificaatautoriteit veel kleine fouten die niet duidelijk een te groot risico vormen en dan trekt men wel het vertrouwen in.

[autostatic]

Dit is ook ongeveer de redenering die Entrust zelf hanteert. Maar het gaat niet om de risico's die deze verkeerd uitgegeven certs zouden kunnen vormen, die zijn er namelijk niet. Het gaat om de risico's die een CA met zich meebrengt die zich niet aan afspraken houdt, die moeite heeft met transparant communiceren, die niet goed uit kan leggen hoe belangrijke processen geborgd zijn en niet uit kan leggen hoe ze dit in de toekomst willen voorkomen.

[Reactie gewijzigd door autostatic op 22 juli 2024 15:49]

[kodak]

De CA staat aan de top van alle onderliggende certificaten. Als daar iets mis gaat dan geeft dat risico voor de certificaten. Het gaat daar dus wel degelijk om. Dat is waarom er duidelijkheid nodig is, niet alleen van een CA maar ook van Google. Dat Google het vertrouwen niet zomaar blijft behouden moet ergens uit blijken. Google laat vooral blijken waarom en wanneer het geen vertrouwen meer heeft. Dat is absoluut niet genoeg.

[Guru Evi]

Ik denk dat meer en meer grote bedrijven die nog steeds certificaten "verkopen" langzaam aan uitgehold aan het worden zijn en dus meer en meer gaan doen om klanten te winnen die misschien niet zo ethisch verantwoord zijn. Entrust was ooit deel van Nortel, dus een heel oud bedrijf dat al lang niet meer meekan.

Bijna iedereen gebruikt tegenwoordig de "gratis" certificaten van Let's Encrypt, ik denk dat we teveel vertrouwen in 1 emmertje steken, maar het ACME protocol laat iedereen een CA opzetten. Ik denk dat moest er dienstverlening zijn van de grote CAs naast certificaatjes verkopen (vb een CA die oude Java versies en andere libraries gaat patchen voor ACME of nieuwere TLS ondersteuning) dat er een markt is voor zulke platformen maar anders denk ik dat er nog meer zullen vallen in de volgende paar jaren.

[Reactie gewijzigd door Guru Evi op 22 juli 2024 15:49]

[Jeoh]

Iedereen kon altijd al een CA opzetten, het probleem was om voldoende vertrouwd te worden door Mozilla / Google / Apple / Microsoft om toegevoegd te worden aan hun Root CA Stores. Daar heeft ACME niets mee te maken en niets aan veranderd.

[The Zep Man]

Daar heeft ACME niets mee te maken en niets aan veranderd.

Klopt. ACME is om geautomatiseerd certificaten aan te vragen en toe te wijzen. Dat op zich zegt niets over de betrouwbaarheid van een certificaataanbieder.

Als Let's Encrypt dergelijke problemen had dan werd die ook wel geweerd door partijen zoals Google.

[MrFax]

Let's Encrypt is dan ook toch alleen verantwoordelijk voor domain trust. Organisation validation kan niet geautomatiseerd. Je moet namelijk bijv. bij een ing.nl ervanuit kunnen gaan dat het domeinnaam niet om een of andere manier gekaapt is en dan een nieuwe certificaat aanvraagt heeft. Je moet dus kunnen bewijzen dat het ook echt om de ING Bank gaat, lijkt me? Toch merk ik dat OV's en EV's niet meer het bedrijf laten zien direct in de URL (https://www.troyhunt.com/...on-certificates-are-dead/).

Ik vind dat toch bijzonder. Want domeinkaping is echt niet onmogelijk om uit te voeren. Ik vind dat een grote stap terug in phishingbeveiliging.

[Reactie gewijzigd door MrFax op 22 juli 2024 15:49]

[laurxp]

Bedrijfsnamen zijn niet uniek. Iedere grapjas kan een bedrijf dat "ING Bank" heet opzetten in een land als Vanuatu en daarvoor een OV/EV aanvragen.

Het hele "kijk naar de groene bedrijfsnaam" is daarmee in één klap volstrekt waardeloos. Sure, je zit op de website van een ING Bank, maar zit je wel op de website van de echte ING Bank?

[MrFax]

Maar hoe kom je er dan achter of je wel echt op ing.nl van ING BANK N.V. bent? Waarom is dit expliciet verifieren bijna onmogelijk voor de normale gebruiker?

ING gebruikt namelijk wel gewoon een EV "ING BANK N.V. [NL]" en je ziet dat er dan ook nog expliciet NL bij staat.

Het leuke is, dat ING zelf ook Entrust gebruikt, en daarmee Chrome-gebruikers straks hun bankzaken niet meer kunnen regelen. Dat zie ik nu toevallig

[Reactie gewijzigd door MrFax op 22 juli 2024 15:49]

[laurxp]

Je kijkt naar de domeinnaam. ing.nl is altijd ing.nl als je TLS gebruikt, want je krijgt alleen een certificaat na domein-validatie. EV voegt daar niks aan toe, en omdat gebruikers in de praktijk alleen keken naar de groene balk en de domeinnaam zelf negeerden, was EV dus eigenlijk minder veilig dan niet-EV.

ING gebruikt namelijk wel gewoon een EV "ING BANK N.V. [NL]" en je ziet dat er dan ook nog expliciet NL bij staat.

Voornamelijk traditie. Op tech-gebied doen banken wat veilig lijkt, niet wat veilig is. Bedrijven als Google, Amazon, en Microsoft gebruiken geen EV, en zijn minstens net zulke kritische infrastructuur.

Dat expliciete "NL" erachter is vrij zinloos bij multinationals. De website van de internationale tak heeft dat ook, maar dat is dus waar je terecht komt als klant in Frankrijk of Italië.

Daarnaast zijn bedrijfsnamen binnen een land óók niet uniek. Denk bijvoorbeeld aan Ajax brandblussers & Ajax de voetbalclub, of Apple het computermerk en Apple de platenmaatschappij van de Beatles. Zolang verwarring onwaarschijnlijk is ("moron in a hurry"), is overlap niet direct een probleem. Máár, dat is niet te zien in je EV-balkje! Als daar "AJAX N.V." staat, ben je dan bij de brandblussers of bij de voetbalclub? Je kan het alleen zien aan de inhoud van de website zelf, maar dan is het dus al te laat.

[MrFax]

Mijn punt is dat je niet zeker kan zijn van dat een domein niet volledig gekaapt is. Bij een EV heb je ook noge een adres. Bij een EV wordt naar dat adres een brief gestuurd voor verificatie.

Dat is enige sure-fire way om echt 100% zeker te zijn dat ing.nl ook echt de ING bank is en het domein ongekaapt is gebleven.

Want het is natuurlijk heel makkelijk voor een publieke WiFi om een DNS aan te passen en je om te leiden naar een ander ip adres. Maar dit kan dan weer worden voorkomen door geforceerd altijd 1.1.1.1 of 8.8.8.8 als DNS resolver te gebruiken, en lokale DNS resolvers te blokkeren.

Toch is het fijn om te zien of je wel echt op de servers van ING ben belandt.

[Reactie gewijzigd door MrFax op 22 juli 2024 15:49]

[supersnathan94]

[q] Als daar "AJAX N.V." staat, ben je dan bij de brandblussers of bij de voetbalclub?[\]

Of bij de allesreiniger fabrikant
Of bij de security/beveiliging
Of het softwarebedrijf uit Amsterdam
Of …

offtopic:
ajax brandblussers is een mooie. Die hebben namelijk toestemming van de club om het logo van ajax zelf te gebruiken omdat de zoon van de oprichter daar jarenlang als keeper heeft gespeeld. Dus de verwarring is makkelijk te maken

[Guru Evi]

Ik bedoelde dat het gemakkelijker dan ooit is om een interne CA op te zetten en te vertrouwen voor intern gebruik. Met ACME is zowel de server als de cliënt een paar instructies in Docker of de cloud waar je vroeger zelfs voor interne CA management graag/beter een product kocht van de grote CAs.

[JapyDooge]

Een Microsoft CA opzetten is hooguit een tiental klikjes al sinds Windows NT, en ik kan mij niet voorstellen dat dat op *nix veel moeilijker is, lang voor ACME.

[Guru Evi]

En dan moet je nog steeds een certificaat genereren, een CSR naar de CA beheerder, laten ondertekenen en terugsturen, allemaal manueel met openssl instructies. Het is een lomp systeem, vooral als je niet wilt dat iedereen je sleutels ziet, dus moet je een ticketje insturen, wachten etc en automatiseren was niet echt beschikbaar. Veel CA hadden een platform waar je dus wel mee kon automatiseren of self service maar het was niet gestandaardiseerd en vele systemen hadden zelfs geen API.

[JapyDooge]

Ik kan niet spreken over hoe het onder *nix werkt historisch, maar ook hier, onder Windows met een Microsoft CA; enkele klikjes en je hebt een certificaat. Dit was nooit moelijk en is al decenia niet veranderd.

Edit: Ook het concept van een signing request is al vele jaren hetzelfde; daar hoef je geen sleutels voor te laten zien.

[Reactie gewijzigd door JapyDooge op 22 juli 2024 15:49]

[Guru Evi]

Opnieuw, enkele klikjes (nadat het opgezet is) is geen automatisatie. Daarnaast werkt Microsoft CA enkel met Microsoft producten, als je Apache (zelfs op Windows) of Linux draait krijg je geen CA integratie of je moet al je certificaten handmatig exporteren en importeren elk jaar, laat staan om dit te doen elke maand of 3 maanden zoals momenteel aanbevolen wordt.

Daarnaast is Microsoft CA een product die je moest aankopen. En je gaat toch geen CSR van gelijk iemand aanvaarden of mensen zelf hun certificaat laten ondertekenen met je AD certificaat, teveel werk als je spreekt over een domein met 10-20k machines. Daarmee dat ongeveer nergens de Windows "client" een ondertekend certificaat heeft, zelfs niet intern. Met ACME zie ik daar nu verandering in komen.

[Reactie gewijzigd door Guru Evi op 22 juli 2024 15:49]

[CAPSLOCK2000]

Bijna iedereen gebruikt tegenwoordig de "gratis" certificaten van Let's Encrypt, ik denk dat we teveel vertrouwen in 1 emmertje steken, maar het ACME protocol laat iedereen een CA opzetten.

Een andere interessante oplossing is DANE/TLSA. Wikipedia: DNS-based Authentication of Named Entities

Daarbij gebruik je helemaal geen (openbare) CA maar publiceer je in DNS welke certificaten je gebruikt. Je browser (of andere applicatie) kan die informatie vergelijken met het certificaat dat die site gebruikt en zo controleren of dit het juiste certificaat nodig is.

Je hebt geen CA meer nodig, het kost niks en je kan je SSL-certificaten zo snel veranderen als je je DNS kan updaten. Het lastige punt is dat je wel toegang tot DNS nodig hebt om die informatie te publiceren. Dat zal op sommige plekken wat gedoe opleveren, maar niks fundamenteels.

Ik denk dat moest er dienstverlening zijn van de grote CAs naast certificaatjes verkopen (vb een CA die oude Java versies en andere libraries gaat patchen voor ACME of nieuwere TLS ondersteuning) dat er een markt is voor zulke platformen maar anders denk ik dat er nog meer zullen vallen in de volgende paar jaren.

Ik denk dat ze persoonsidentificatie gaan doen. Nu willen sites als Facebook en Google dat je een kopie van je ID-kaart stuurt om jezelf te identificeren. Dat mag eigenlijk niet van de wet maar ze doen het toch en je moet er maar op vertrouwen dat ze niks anders met die data doen en het niet onnodig lang bewaren. Dat vertrouwen heb ik niet. Dan liever een onafhankelijk bedrijf dat niks anders doet dan identiteiten controleren dat onmiddelijk failliet gaat als ze gekke dingen zouden doen omdat ze geen andere bron van inkomen hebben.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 15:49]

[Triblade_8472]

Nee, het zijn juist de grote jongens als Google die het probleem (deels) veroorzaken.

Neem de groene balk nou. Dat was bedoeld als duidelijk tegen dat het een extra gecontroleerd (EV) certificaat was. Maar Google vind 't nodig dit niet meer te doen. En wat is dan nog de daadwerkelijke waarde voor de eindklant?

Waarom zou je nog dure Certs halen?

[laurxp]

EVs hebben geen toegevoegde waarde, want bedrijfsnamen zijn niet uniek. Hierdoor kan iedere scammer een bedrijf opzetten met de naam van hun doelwit, en daar een EV voor aanvragen.

[Tozz]

Tja, ze kunnen 't nooit goed doen. Een phishing site kon ook een OV of EV certificaat aanvragen op een willekeurig domein als hoempapa.com. Als daar een phishing site op stond van de ABN AMRO dan denken veel mensen 'Hey groene adresbalk! Is veilig!'

En zie daar de reden waarom die groene balk is verwijderd. Dat is niet omdat Google dat leuk vond, maar omdat er misbruik van werd gemaakt.

[Blokker_1999]

Een EV cert haal je niet zomaar en als dat ten onrechte wordt uitgegeven door een CA dan is dat een deuk in het vertrouwen van die CA. Daarom ook dat het een EV cert is dat niet goedkoop is en ook voor jouw een hoop administratie oplevert.

Ja, een phishing site kan een DV cert gebruiken. Maar als ik vroeger naar de site van mijn bank surfte, dan was het eerste wat ik deed naar die adresbalk kijken om na te gaan of daar de juiste informatie stond van het EV certificaat. Nu moet ik daar een stuk meer werk voor verzetten. En terwijl we mensen dus meer en meer in phishing zien trappen zou een snelle identificatie van de eigenaar van een EV cert er net voor kunnen zorgen dat sommige mensen niet opgelicht worden.

[Yggdrasil]

Toch is juist herhaaldelijk aangetoond dat EV certificaten niet de garanties boden die mensen ervan verwachttenen, dat normale gebruikers ze helemaal niet correct interpreteerden en dat het vooral marketing van de CA's zelf was die ze maar al te graag verkochten. Een bekend artikel erover is https://www.troyhunt.com/...on-certificates-are-dead/
Ik ga ze niet missen.

[Triblade_8472]

En sinds het door Google afgeschafte systeem is het allemaal beter geworden?

Niet echt.

Sterker nog, ik vraag mij af of het niet erger geworden is. Tijd voor een onderzoek of het geholpen heeft!

Maar het boeit niet of de balk groen is, ik zou wél graag een methode hebben die duidelijk aan een gebruiker kan tonen dat de eigenaar extra geverifieerd is. En daarmee, of als extra functie wellicht, contact met de uitgever kan opgeven bij misbruik! Dat zou actief kunnen bijdragen aan betrouwbaarheid.

[dasiro]

het feit dat het zo simpel is om gratis certificaatjes te genereren holt het principe van CA's uit. Voordien moest je een CA betalen om een certificaat te krijgen, waardoor er een money-trail was, maar de drijfveer om alles geëncrypteerd te laten verlopen zorgt er tegelijk voor dat ik hen als CA niet meer even serieus neem als vroeger het bij betalende CA's het geval was.

[cariolive23]

Wat is dan de waarde van een money trail?

[dasiro]

"follow the money" en "money makes the world go round". Een gratis certificaat, domeinhost en mailadres via een publieke hotspot aanmaken lukt je quasi volledig anoniem, maar een bankrekening waar het geld vandaan komt is dat niet en zelfs al is het een gestolen CC, uiteindelijk gaan criminelen nog altijd willen profiteren van hun misdaad en dat is het moment dat je ze kan vinden/pakken.

[Groningerkoek]

Alleen koop je een pakket met CC's anoniem online en is er dus geen enkele link tussen de daadwerkelijke persoon en de CC. Tevens moet je wel extreem dom zijn wil je zo'n CC langer gebruiken en ben je minimaal zwakbegaafd als je die CC dan ook nog gaat gebruiken voor dingen die herleidbaar naar jou zijn.

[cariolive23]

Okay, en wat dan als ik op jouw naam, of die van een willekeurig ander persoon die er in stinkt, een bankrekening open? Je kunt zelfs kant&klare bankrekeningen op andermans naam kopen, dan hebben andere criminelen deze al voor je geopend.

Helaas stelt dit vrij weinig voor en is daarmee jouw money trail volkomen waardeloos. Het is geen spoor, maar een dwaalspoor.

ps. wij doen regelmatig klussen in deze hoek van fraude

[Oebele Drijfhout]

Misleidende flauwekul. Een certificaat garandeert de validatie. De validatie vindt plaats wanneer je bewijst bij de autoriteit wie je bent. De methode van validatie moet daarom passen bij het doel van het certificaat. Voor validatie van een certificaat voor bv. een webserver is geld dus niet relevant, wel een DNS record of een token dat je kunt serveren op het aangevraagde adres.

[rjd22]

Dit kan nog steeds maar zijn gewoon ander soort certificaten. Een domein certificaat is gewoon validatie dat de verbinding tussen jouw en het domein gevalideerd en geencrypt is. Dit is voor de meeste websites voldoende.

Dan heb je ook nog organisatie (ev) certificaten waar naast het domein ook de organisatie gevalideerd wordt. Dit is vooral voor dingen die veel vertrouwen nodig hebben zoals banken en overheids instanties heel belangrijk. Deze zijn vaak ook een heel stuk duurder dan domein certificaten en dienen een belangrijk doel.

Dat domein certificaten geld kosten was eigenlijk een beetje raar en zorgte ervoor dat niemand ze gebruikten wat internet verkeer afluisteren (bijvoorbeeld door mitm wifi netwerken) heel makkelijk maakte. Om de veiligheid van het internet te verhogen zijn deze toegankelijker gemaakt met een veel veiliger internet als resultaat.

[The Realone]

Kleine aanpassing, de organisatie validatie certs zijn OVs, vandaar de O in de afkorting. EVs zijn OVs met een aantal extra verificatie stappen (Extended). Eigenlijk zijn EVs de enige juiste stap na DVs als het aankomt op zekerheid. Wat duurder, maar ook niet schrikbarend.

[SleutelMan]

Vergeleken tussen "gratis" en EV zit er nog wel een gat. Maar ook de grotere commerciele CA's rekenen inderdaad 200 euro per jaar voor een DV certificaat. EV kan dan overigens nog wel fors duurder zijn hoor, tot makkelijk wel 1400 dollar per jaar (!)

[The Realone]

Mijn punt was dat er eigenlijk geen goede reden is om voor een OV te gaan. Het is een redelijk halfbakken verificatie en een single domain EV is al voor minder dan €200 te krijgen.

[SleutelMan]

EV zelf is in een browser context eigenlijk ook overbodig. Er is eerder al een onderzoek aangehaald hierboven geloof ik waarin onderzoek is gedaan naar geen TLS, DV, OV of EV (toen de groene balk nog wel bestond). Zelfs al zien mensen de groene balk, hoe weet je dan of het wel de juiste partij is die die website zou moeten beheren? Bekende merken zitten vaak onder een andere organisatienaam, of zijn het partijen (betalingsverwerkers) die niemand kent. Dan ben je nog heel erg van interpretatie afhankelijk van de eindgebruiker en die klikt toch wel.

Waar OV/EV wel werkt is in een Machine-to-machine situatie, immers: je kunt de server configeren om alleen certificaten met bepaalde juiste kenmerken te accepteren voor TLS verbindingen.

[BugBoy]

HTTPS geeft enkel aan dat jij de website bezoekt die bij dat domein hoort en dat je verkeer met die website beveiligd verstuurd wordt. Het protocol zelf is nooit bedoeld om aan te geven dat de inhoud ook veilig is. Let's Encrypt heeft het internet wel degelijk veiliger gemaakt, omdat het (vrijwel) iedereen in staat stelt om gratis een beveiligde verbinding aan te bieden. Een website zonder HTTPS is bijna ondenkbaar tegenwoordig.

Een ander voordeel van ACME is dat je het ook kan automatiseren. Kost een keer werk om het op te zetten, maar daarna ververs je certificaten veel sneller en is er geen handwerk meer nodig en vergeet je het ook niet. Dat maakt websites ook betrouwbaarder.

Overigens zijn er Extended Validation (EV) certificaten waarbij er ook extra controles zijn. Dit zie je vooral bij grote bedrijven terug en bij financiële instellingen. Bij een EV certificaat weet je ook zeker welk bedrijf er achter het certificaat zit.

[air2]

Maar daar heb je de ev certificaten voor. Die bied lets encrypt natuurlijk niet aan.

Een betaald gewoon certificaat bied echt niet meer dan een certificaat van lets encrypt, namelijk dat je aantoont dat het domein ook echt klopt en dat er dus geen man in de middle plaatsvind.

Het zegt niet dat het domein ook betrouwbaar is of dat het behoort tot een bepaalde persoon oid

[sniek]

Een beetje een drogreden als je het mij vraagt. Als jij claimed dat een 20 euro certificaat beter is dan ACME louter en alleen om het feit dat ervoor betaald is, gaat er iets niet helemaal goed. De money trail, zeker op internet, is waardeloos.

[Blokker_1999]

Dan begrijp je wat mij betreft het verschil tussen DV en EV niet.

Een DV, oftewel domain verified, certificaat is NOOIT bedoeld geweest om de eigenaar van het certificaat aan te duiden. Zelfs als je er enkele Euro of Dollar voor betaald staat er in het certificaat geen enkele bit aan informatie over de eigenaar van dat certificaat. Je browser gaat bijvoorbeeld gewoon aangeven dat er geen eigenaar in het certificaat staat. En dat klopt ook. Want DV is daar niet voor bedoeld. En follow the money? Neen. Ja, het kan zijn dat er een geldspoor te volgen is, maar voor criminelen die een certificaat nodig hebben is het kinderlijk eenvoudig om bijv. virtuele creditcards te krijgen om mee te betalen die uiteindelijk met cash ergens worden opgeladen. Of wat dacht je van muilezels, oplichting, ... zovele manieren om dat betaald te krijgen zonder een spoor dat naar jouw verwijst.

Wil je weten wie de eigenaar van een certificaat is? Dan moet je voor EV gaan, oftewel extended validation. Dat soort certificaten kost geld, vereist een hoop papierwerk, bij vele CAs mag je ook nog eens langs een notaris om je papierwerk te laten ondertekenen door een externe partij. En dan krijg je in ruil een certificaat dat wel bevestigd wie de eigenaar van dat certificaat is.

Uiteindelijk moet je kijken naar het doel van een certificaat. De vele DV certificaten, die je vandaag gratis en vroeger voor een appel en een ei te krijgen zijn dienen enkel om ervoor te zorgen dat er tussen jouw en de webserver niemand kan meeluisteren. Wie die server is en of je die wel kunt vertrouwen, dat weet je nooit met zo een certificaat. Wil je daar zekerheid over, dan moet je een EV certificaat gebruiken. Dat is bedoeld om niet alleen de verbinding te beveiligen, maar ook de identiteit te bevestigen.

Dus neen, gratis CAs hollen het principe helemaal niet uit.

[Hieronymuski]

Dat soort certificaten kost geld, vereist een hoop papierwerk, bij vele CAs mag je ook nog eens langs een notaris om je papierwerk te laten ondertekenen door een externe partij.

Wanneer heb je dit voor 't laatst aangevraagd? Toen ik dat een paar jaar geleden voor 't laatst deed, was een correctie KvK registratie, een bestaand kantoor en telefoonnummer en geldige WHOIS gegevens voldoende om zo'n ding aan te vragen. Zij checken dit allemaal, maar 't enige wat jij daar van merkt zijn telefoontjes naar 't bedrijf

En de "hoop" papierwerk zijn een paar vinkjes online.

[autostatic]

Het team zal een update voor Google Chrome uitbrengen waarmee bepaalde tls-certificaten van Entrust vanaf 1 november 2024 niet meer automatisch zullen worden vertrouwd door de browser.

Dit heeft wat meer uitleg nodig denk ik. Na 31 oktober zullen certificaten die na 31 oktober zijn uitgegeven door Entrust niet meer vertrouwd worden. Vraag je een Entrust cert aan op zeg 30 oktober 2024 met een geldigheid van een jaar dan zou deze in principe tot en met 30 oktober 2025 vertrouwd moeten blijven worden.

[4tro]

Nee hoor, als Google de stekker eruit trekt door het root CA van entrust uit de trust store te halen, worden per direct alle certificaten die daar mee gesigned zijn niet meer vertrouwd... Of ze nou nog wel of niet geldig meer zijn

[autostatic]

Bron: https://security.googlebl...certificate-security.html

Upcoming change in Chrome 127 and higher:

TLS server authentication certificates validating to the following Entrust roots whose earliest Signed Certificate Timestamp (SCT) is dated after October 31, 2024, will no longer be trusted by default.
...
TLS server authentication certificates validating to the above set of roots whose earliest SCT is on or before October 31, 2024, will be unaffected by this change.

[4tro]

Het staat er een beetje ambigu, zijn het de roots met een datum na October 2024, of de certificaten die erdoor gesigned zijn

[autostatic]

De certificaten die erdoor gesigned zijn. Deze worden straks gevalideerd aan de hand van de SCT (Signed Certificate Timestamp). Na de grace period worden de roots waarschijnlijk wel verwijderd tenzij Entrust voor die tijd weer toegelaten wordt. Zie ik zelf zo snel niet gebeuren, waarschijnlijker is dat ze een andere certificatenleverancier overnemen en op die manier hun "business continuity" kunnen blijven garanderen.

[The Zep Man]

Entrust heeft op het moment van schrijven nog niet gereageerd op de maatregel.

Stilte als certificaatautoriteit op dit soort momenten is zelfvernietiging. Vertrouwen komt te voet en gaat te paard, zeker in een markt waar er alternatieven zijn. Je PR op orde hebben kan inhouden dat je op de achtergrond alles op orde hebt of er niets van bakt. Je PR niet op orde hebben is sowieso een rode vlag.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:49]

[kamerplant]

Dit bedrijf is nu sowieso voorbij, ongeacht de reactie die men zou geven.
Ik ben benieuwd in hoeverre de andere browsers volgen, Firefox, Microsoft en Apple.

[autostatic]

TLS-certificaten vormen maar een klein deel van de omzet van Entrust. De verantwoordelijke afdeling zal hoogstwaarschijnlijk opgedoekt worden maar Entrust als geheel zal niet omvallen.

[Paul]

Reageren kost tijd, onderbouwd reageren nog veel meer, en die blog-post is pas een dag oud.

Ik heb geen idee of Entrust al eerder op de hoogte was, maar op dit soort zaken heb ik liever een onderbouwde reactie dan een snelle reactie

[autostatic]

Entrust was al maanden op de hoogte, ze zijn eind maart al gewaarschuwd. Maar doordat ze in de dagen daarna weer in de fout zijn gegaan is het vertrouwen opgezegd. Daarnaast speelt er mee dat er al een heel voortraject was, loopt vanaf 2020.

[autostatic]

Een van de redenen waarom Google certs van Entrust straks niet meer gaat vertrouwen was de trage respons vanuit Entrust. Ook op het PR-vlak lijkt zich dit te herhalen. Dit heeft denk ik te maken met een gevoel van urgentie welke ontbreekt en de angst dat een te snelle reactie misschien te emotioneel over zou kunnen komen en klanten af zou kunnen schrikken.

[Reactie gewijzigd door autostatic op 22 juli 2024 15:49]

[Accretion]

Binnen Windows zijn ze nog wel vertrouwd, dus op Firefox worden ze wel als veilig aangegeven?

[autostatic]

Mozilla heeft nog geen beslissing genomen of ze Entrust certs blijven vertrouwen of niet dus op FF zullen Entrust certs die na 31 oktober zullen worden uitgegeven vooralsnog blijven werken. Maar zal me niet verbazen als Mozilla deze certs straks ook niet meer vertrouwt. En daarnaast, wat doet dit nieuws met de reputatie van Entrust als CA?

[Reactie gewijzigd door autostatic op 22 juli 2024 15:49]

[Blokker_1999]

Ook in Chrome worden ze vandaag nog vertrouwd. Je moet voorlopig zelf actie ondernemen als je hen niet wenst te vertrouwen.

[The Zep Man]

Binnen Windows zijn ze nog wel vertrouwd, dus op Firefox worden ze wel als veilig aangegeven?

Firefox gebruikt eigen certificate stores, ook onder Windows.

[dbzokphp]

In theorie als de DANE adoption wereldwijd een geaccepteerde standaard (en geïntegreerd) zou zijn, zouden we in theorie geen certificate authorities meer nodig hebben. Hopelijk komen we ooit op dat punt.

[Yggdrasil]

Dat gaat echt niet gebeuren. De uptake is dermate langzaam dat het me niks verbaasd als DANE gebruik uitsteft.

[KvanG]

Hoeveel websites worden hierdoor getroffen?

[autostatic]

Dat gaat in de tienduizenden lopen denk ik. De shitstorm van maart resulteerde al in een lijst van 25000 certs die herroepen moesten worden. En dat was over een periode van een half jaar.

Maar sitebeheerders hebben in principe nog tot 31 oktober 2025 de tijd om een andere CA te zoeken. Tenzij Entrust al voor 31 oktober van dit jaar de verantwoordelijke afdeling opdoekt en er vanaf dat moment geen nieuwe certs meer aangevraagd kunnen worden.

[Reactie gewijzigd door autostatic op 22 juli 2024 15:49]

[FrostyPeet]

Dat hele CA systeem is al "krom" in het ontwerp. Je hangt ergens een ankterpunt op, wat iedereen vertrouwt, en alles wat er onder hangt is ook automatisch vertrouwt, tenzij je het niet-vertrouwt. Vervolgens moet je dus allemaal stappen zetten om dat niet-vertrouwde te verwijderen uit allerlei "kluisjes".

Vervolgens zijn er tig CA's, die een deal sluiten met browser-, os- en app ontwikkelaars. Komt er een heel systeem van certificaat niveau X kopen bij aanbieder Y om in pakket Z iets te kunnen ondertekenen/versleutelen.

Het moet toch mogelijk zijn om iets beters op te zetten in een blockchain o.i.d.?

[supersnathan94]

Ah blockchain. Ik zat te wachten op een reactie die daarmee zou komen.

Blockchain zou een gigantische hit in performance geven als we dat gaan gebruiken. Iedere website moet dan immers een cert op de chain gaan gooien en bij iedere wijziging weer opnieuw een transactie inschieten die mogelijk binnen nu en ergens een keer wordt verwerkt.

Met de hoeveelheid certificaten die in omloop zijn wordt dat een onbegonnen exercitie.
Bitcoin heeft zelfs met het lightning network de capaciteit gewoonweg niet om dat aan te kunnen laat staan alle miljarden reads per uur van iedere web gebruiker die een cert opvraagt ter validatie.

Nee dit is 1 van die dingen waar je notarisatie nog gewoon bij een partij wil hebben liggen die dat centraal doet en valideert.

[ISaFeeliN]

"Het team meent een patroon bij de certificaatautoriteit te ontwaren waaruit moet blijken dat er al jaren niet aan bepaalde kwaliteitseisen wordt voldaan"

.. toont wel weer aan hoe slecht dat mechanisme werkt. Dat zou toch wel wat strenger mogen zijn, niet?