Chrome gaat eigen 'rootstore' voor certificaten gebruiken

Google stapt af van het gebruik van rootcertificaatstores in Chrome. Het techbedrijf begint zijn eigen certificaatprogramma voor de browser. Dat gebeurt voor alle platforms, behalve voor Apples iOS.

Chrome maakte tot nu toe altijd gebruik van de rootstores van het onderliggende besturingssysteem waarop de browser is geïnstalleerd. Google wil in de toekomst echter gebruikmaken van een eigen rootstore, die het bedrijf zelf wil uitbaten. Het Chrome Root Program moet ervoor zorgen dat certificaten in de browser op ieder apparaat aan dezelfde eisen voldoen. Nu zit er soms verschil tussen de rootstores waarvan besturingssystemen gebruikmaken, waardoor certificaten op het ene besturingssysteem wel kunnen worden goedgekeurd, maar op een ander niet. Hoe groot dat probleem precies is, beschrijft Google overigens niet. "Het Chrome Root Program zorgt ervoor dat gebruikers een consistente ervaring hebben op verschillende platforms, dat ontwikkelaars een consistent begrip hebben van Chromes gedrag, en dat Chrome de security en privacy van gebruikers beter kan beschermen", zegt het bedrijf.

Certificaatautoriteiten kunnen hun certificaten zelf aanmelden bij het Chrome Root Program. Google heeft daarvoor een aantal eisen opgesteld, zoals dat de CA's alleen tls-certificaten uitgeven en dat ze bijvoorbeeld 'een algemene publieke discussie voeren' over zaken als audits. Het bedrijf zegt dat het CA's die niet aan die eisen voldoen, individueel kan beoordelen.

Het Root Program werkt op alle platforms behalve iOS. "Apples beleid verhindert de Chrome Root Store het op Chrome voor iOS te gebruiken", zegt Google. Het bedrijf zegt dat er al een aantal certificaatautoriteiten is uitgekozen die kunnen deelnemen aan het programma. Dat zijn CA's die nu al in de Common CA Certificate Database van Mozilla zijn opgenomen. Google schrijft verder niet welke tijdlijn het aanhoudt om te migreren naar zijn eigen rootstore. Het is daarom niet bekend in welke versie van Chrome die verandering wordt doorgevoerd of op welke termijn.

Reacties (108)

[joost00719]

Waarom?
De rootstore van het OS is toch juist hiervoor bedoelt? Ik snap dat je het consistent wilt hebben, maar dan vervalt de rootstore van het OS toch juist voor een deel?
Daarnaast is het niet eens consistent gezien het op IOS niet eens gaat werken.

[Anoniem: 1322]

De rootstore van het OS is toch juist hiervoor bedoelt? Ik snap dat je het consistent wilt hebben, maar dan vervalt de rootstore van het OS toch juist voor een deel?
Het lijkt mij dat je vanuit beveiligingsoogpunt helemaal niet wilt vertrouwen op het onderliggende platform (en daarbij de root store van het OS). Je hebt immers geen invloed op het OS en wanneer die bijvoorbeeld niet voldoen aan goede beveiligingseisen (of gehackt wordt), jouw browser dan dat automatisch ook niet meer doet.

Browsers worstelen hier dus al langer mee:
nieuws: DigiNotar-hackers blijken 531 certificaten te hebben vervalst
nieuws: Browsermakers geven nieuwe versies uit na DigiNotar-blunder
nieuws: Hackers genereerden zelf vervalst Google-certificaat - update
nieuws: 'Iran gebruikt Nederlands certificaat om Gmail te onderscheppen'
En ze voegen al sinds hun bestaan de beveiliging verder op door de zwakke punten van het certificaat systeem aan te passen:
nieuws: Google en Mozilla gaan geldigheid tls-certificaten beperken tot 398 d...

Anyway, het is begrijpelijk op alle fronten, goed en slecht. Google (en andere browsers) willen meer controle. De browser is voor veel mensen nu al een besturingssysteem want de meeste applicaties draaien er in. Daar moet je op kunnen vertrouwen en certificaat providers maken er vaak een zootje van:
nieuws: 'NSA maakte misbruik van lek DigiNotar'
https://www.security.nl/p...at+Kazachstaanse+overheid
nieuws: Google blokkeert alle ssl-certificaten van Chinese certificaatautoriteit

[kalikatief]

Als je niet kunt vertrouwen op het onderliggende OS, dan heb je wel grotere problemen. Is de telefoon geroot? Draai ik in een debugger? Etc.

Dit is waar je gewoon sterker zou moeten inspelen op het nut van de certificaten naar zowel de eindgebruiker alsmede de OS-makers.

Het hele doel van certificaten is het vaststellen van onderling vertrouwen. En ik vind het zeer zorgwekkend dat Google nu maar 100% in handen wil gaan nemen wat er te vertrouwen is. Ze hebben al een veel te grote machtspositie met browser, advertenties, zoeken en mailen.. en nu komt dit er nog een keer bovenop?

We mogen het straks wel Googlenet gaan noemen.

[Willem_D]

Firefox doet dit al jaren volgens mij:
https://blog.mozilla.org/...n-root-certificate-store/

[OruBLMsFrl]

Klopt en er valt voor beiden wat te zeggen. Helaas in een zakelijk beheer setting, zeker bij bring your own device, best onhandig als je wat interne servers van eigen certificaten voorziet. Moet je straks voor 4 browsers die root stores gaan ondersteunen, al die browsers per verschillend platform ook nog eens als je pech hebt (uitgezonderd iOS, wat nog wel via het OS gaat).

Dan is een device management oplossing (MDM) om het naar 3 verschillende OS'en laten pushen toch een heel stuk makkelijker. Windows, Android, iOS certificaat ondersteuning hangt ook standaard in een MDM. Maar een Firefox, Chrome, ?Brave?, ??Edge?? certificaat push je niet zo makkelijk omdat daar vaak geen standaard templates voor zijn helaas. Dus vandaag uitdaging met Firefox, morgen ook al met Chrome.

Vraag is dan wat Edge en andere chromium browsers als Brave gaan doen, zou een logische stap zijn als er een als Edge met een meer zakelijke focus dan juist wel nog de certificate store van het OS zou gebruiken.

[Jimbolino]

Daarom zijn self signed certificaten (vaak icm een zelfverzonnen dns suffix) ook niet aanbevolen.
Als je een eigen domeinnaam kunt kopen, kun je makkelijk een wildcard voor dat domein aanvragen (evt gratis via letsencrypt)
Vaak makkelijker dan het gedoe met self signed certificaten.

[mobrockers]

We hebben het hier niet over je thuisnetwerk. We hebben het hier over enterprise omgevingen waarbij de interne omgeving misschien niet eens aan het internet mag en dus geen let's encrypt kan gebruiken. Daarnaast zijn LE certificaten beperkt geldig en moet je om de 3 maanden verversen.

[Jimbolino]

Een server hoeft niet direct aan het internet te hangen om een een geldig ssl certificaat te kunnen gebruiken. Net zoals je updates installeert op je servers, kun je ook ssl certificaten automatisch laten installeren. Jaarlijks handmatig je certificaat vernieuwen, of iedere 2 maanden automatisch aanvragen, maakt voor het gebruik en installatie niet veel verschil...

[Rob Coops]

Andere browsers zijn hen voor gegaan en weer andere zullen hen volgen. Het grootste probleem is dat je als browser maker niet kunt vertrouwen op het OS in de zin dat ieder OS een net even ander beleid er op na houd en dat sommige OS'en minder snel bepaalde certificaten of certificaat autoriteiten vertrouwen dan wel weigeren. Het resultaat is dat verschillende Linux distro's met verschillende kernel versies en verschillende Windows versies met verschillende patches allemaal net even andere lijsten hebben met welke root's wel en niet veilig zijn.
Als je als bedrijf dan dingen wil testen of verbeteren laat staan ondersteunen dan moet je wel heel erg veel verschillende antwoorden klaar hebben op de reden waarom op een bepaald systeem het gedrag van jouw product anders is dan op het systeem er direct naast.

Om die reden is het verstandig om een standaard root store te gebruiken waar van je zeker weet dat wat er wel en niet in staat.

De enige andere manier om dit te doen zou zijn om een externe onafhankelijke partij te creeren die niet aan welke overheid dan ook toebehoort of onder welke overheids regelgeving dan ook valt. Op dat moment zou je die partij als source of truth kunnen gebruiken voor alle root stores maar zo'n partij kan niet bestaan en dus is de enige andere oplossing als je op alle OS'en een zelfde root store wil vinden is een eigen root store maken.

[Jerie]

We mogen het straks wel Googlenet gaan noemen.

Als Flutter web ooit de standaard wordt wel, ja.

De lijst met CAs wordt door een organisatie gecureerd. Als het OS dat anders doet dan de browser heb je twee attack surfaces. Het is net zoiets als je geld investeren deels in EUR en deels in USD. Er zijn voor- en nadelen. Het is lastig te zeggen dat de een beter is dan de ander.

Waarom mijn browser Hong Kong post office en allerlei vage bedrijven van ondemocratische landen voor zoete koek slikt blijft mij een raadsel. Terwijl het OS, tja dan installeer je toch willens en wetens een vage app. Ik zou best graag tijdens installatie een white/grey/blacklist van bedrijven en/of jurisdicties (en dus landen) willen zien van CAs.

[tweaknico]

Waarom mijn browser Hong Kong post office en allerlei vage bedrijven van ondemocratische landen voor zoete koek slikt blijft mWaarom mijn browser Hong Kong post office en allerlei vage bedrijven van ondemocratische landen voor zoete koek slikt blijft mij een raadsel. Terwijl het OS, tja dan installeer je toch willens en wetens een vage app. Ik zou best graag tijdens installatie een white/grey/blacklist van bedrijven en/of jurisdicties (en dus landen) willen zien van CAs.ij een raadsel. Terwijl het OS, tja dan installeer je toch willens en wetens een vage app. Ik zou best graag tijdens installatie een white/grey/blacklist van bedrijven en/of jurisdicties (en dus landen) willen zien van CAs.

De lijst van vertrouwde CA's wordt met name door netscape/firefox beheerders vastgesteld aan de hand van vooraf vastgestelde richtlijnen. Het zijn die vertrouwde certificated die vastleggen wat wel of niet betrouwbaar is.
Als allerlei applicatie eigen lijstjes er op na gaan houden betekent dat ook evenveel lijstjes tegen het licht houden om vast te stellen welke je wel of niet betrouwbaar vindt.
(Noot de certificaten kunnen zowel Codesigning als Web access ondersteunen... waarbij de eerste best een dingetje is).

Als iedereen de OS variant gebruikt als "betrouwbare lijst" dan hoeft je zelf ook slecht een lijst naast je eigen maatstaf te houden. (verwijder een aantal CA's uit de vertrouwde lijst en het aanvalsoppervlak wordt een stuk kleiner).

[janbaarda]

De nadruk ligt op uitbaten ...

[Zeerob]

Draai ik in een debugger?

https://www.scientificame...-chances-are-about-50-50/

Sorry, wel een beetje OT.

[WoutervOorschot]

De browser vertrouwd ook dat het OS niet een keylogger is. Als je het OS niet kunt vertrouwen kun je net zo goed niks doen (of chromeos pushen natuurlijk). Wat google wilt is dat ze een volledig OS naast Windows/mac hebben, dat ze mensen gewoon langer vasthouden in de browser, want daar verdienen ze geld mee.

Je hebt meer invloed op het OS dan op automatische updates van Chrome, dan moet je via tweakers meekrijgen dat Google opeens gaat kiezen wat er veilig is of niet.

[djwice]

De gebruiker krijgt een melding in de browser als een connectie een man-in-the-middle mogelijk maakt.

Door te vertrouwen op OS root-certificaten - bijvoorbeeld de interne CA van het bedrijf - werkt die meldfunctie niet meer.

En kan een IT-beheerder dus ongemerkt de communicatie van hr, bedrijfsarts en top managers/directie inzien, aanpassen en afluisteren. Dat lijkt me niet een gezonde situatie.

[Robbaman]

Maar zijn er niet ook juist geldige use cases voor het introduceren van een CA van het bedrijf? Bijvoorbeeld het beveiligen van je interne intranet mbv een company TLS certificaat?

[VHware]

Of client authenticatie dmv certificaat

[djwice]

Ik ken bedrijven die wél die interne CA gebruiken man-in-the-middle toepassingen voor externe sites, maar niet een CA gebruiken voor interne websites, die hosten ze onder http - dus ook afluisterbaar.

[Reactie gewijzigd door djwice op 23 juli 2024 15:48]

[EraYaN]

Maar het bedrijf beheert ook die interne servers, dus de gegevens hebben ze toch.

[djwice]

Ik ben dat steeds meer aan het onmogelijk maken, steeds meer verplaats ik naar geautomatiseerd beheer op immutable images zonder admin privileges, juist om te voorkomen dat er nog mensen met good or bad intent op de server kunnen komen.

Plain text wachtwoorden over het netwerk moet gewoon niet acceptabel meer zijn en admins die inloggen om wijzigingen te doen of logs te bekijken op productie machines is ook niet meer van deze tijd.
Evenals agents die wijzigingen kunnen maken en sudo of root rechten nodig hebben. Die kunnen alleen maar voor productie verstoringen zorgen en voor gaten waardoor mensen of systemen met bad intent binnen komen. Dus weg er mee.

[Reactie gewijzigd door djwice op 23 juli 2024 15:48]

[WoutervOorschot]

Certificaten in chrome kun je waarschijnlijk ook gewoon beheren, en certificaten binnen een bedrijf hebben vaak gewoon een valide reden. Google kan nu certificaten naar Chrome pushen waardoor zijzelf alles kunnen ontsleutelen terwijl het veilig lijkt.

Dat google dat zelf doet is niet heel waarschijnlijk, maar Chrome kan nu dus vatbaar zijn voor malware die certificaten in Chrome toevoegt, alleen maar meer aanvalsvectoren omdst Google graag controle heeft over wat een gebruiker doet.

[djwice]

Doordat bedrijven intern slecht omgaan met interne CA, zijn gebruikers al lang gewent om intern binnen het bedrijf die certificaat waarschuwingen weg te klikken, en de onveilige route te volgen van non-matching of niet gevalideerd, geen of verlopen certificaat.

Dat zorgt er voor dat een hacker niet eens een root certificaat hoeft toe te voegen om gebruikers door te laten gaan naar zijn creatie.

Vaak zijn de CA servers intern veel minder goed beveiligd dan je mag hopen, soms zweven zelfs de root keys rond. - Bedenk alles wat een publieke CA ooit een keer fout heeft gedaan, zal intern gewoon regelmatig voorkomen.

Daarom ben ik geen voorstander van het idee "valide reden" voor "interne CA"; het beheer is simpelweg vaak zo slecht op orde, dat het wellicht slimmer is om publieke IP-adressen en Certificaten te gebruiken voor interne services.

[oef!]

Van de andere kant is het zo dat het OS in principe irrelevanter wordt. Door de verschuiving van het gebruik van lokale applicaties naar web-applicaties zou je kunnen stellen dat browserbeveiliging belangrijker is, waarbij certificaatbeheer makkelijker is omdat browsers ook nog eens multi-platform zijn. Dat betekent overigens niet dat het OS niets meer aan certificaatbeheer hoeft te doen.

Van de ene kant is het vervelend dat Google bepaalt wie wel of niet vertrouwd wordt maar van de andere kant moet er dan wel een discussie gevoerd worden of het OS eigenlijk nog wel de goede plaats is voor (een aantal) certificaten. Er zijn ook andere wegen mogelijk waarin bijvoorbeeld Google, MS en Firefox samen besluiten wie te vertrouwen is en wie niet.

[GeroldM]

Hoe wil je dat anders doen dan?

In het PKI model moet er een CA op het systeem aanwezig zijn om te verifieren of het zojuist door jouw aangeschafte certificaat (of vers aangevraagde LetsEncrypt certificaat) uberhaupt te vertrouwen is.

Dat is de eerste schakel om (public) keys uit te wisselen tussn partijen die een beveiligde verbinding tussen 2 punten willen opzetten. Doe je dat niet, kan je net zo goed self-signed certificaten gaan gebruiken.

Iets dat Google op grote schaal wil doen, daar lijkt het tenslotte sterk op met deze "strategische" zet.

[Maanzaad]

Een bekend probleem is het gebruik van oude Android smartphones die geen security update meer krijgen. De certificaten store wordt dan niet bijgewerkt. De overheid heeft onlangs een paar keer het root certificaat gewijzigd. Gevolg, de gebruiker klaagt dat hij/zij een veiligheidswaarschuwing krijgt en niet de site kan bereiken. Leg aan zo iemand maar eens uit dat hij beter een nieuwe smartphone kan kopen, of anders zelf het root certificaat moet installeren.
Of natuurlijk bv Firefox gebruiken

[johnkeates]

Het lijkt mij juist andersom: de applicaties kunnen lekker opdonderen met hun certificaatstores; ik beheers mijn OS-store en ze moeten die maar gebruiken, wat ze zelf willen vertrouw ik juist niet.

[TijsZonderH]

Dit doet me persoonlijk ook erg lijken op een volgende stap om het volledige internet te consolideren zoals Google dat met andere stappen ook probeert (zoals het gesleutel aan de url-balk).

[djwice]

Dit richt zich meer op interne Certificaten. Vaak zijn er bij bedrijven interne certificaten in omloop, en soms ook voor externe websites.

(Kijk even naar je eigen office 365 certificaat als je op de interne VPN zit, is die van Microsoft?)

Dat zorgde er voor dat de IT-beheerder kan zien wat je in Word, Excel en Outlook doet.
Ook als dat strategisch of persoonlijk gevoelig is.

[Reactie gewijzigd door djwice op 23 juli 2024 15:48]

[franssie]

Klopt. En een lastige. Dat bedrijven (zeker met veel gevoelige info) dit doen om interne fraude op te kunnen sporen is vanuit hun positie nog te begrijpen. Maar als ze dit doen zonder het te communiceren naar het personeel is het dacht ik niet toegestaan.
Dat een IT beheerder 9extern?) kan meelezen wat jij in excel etc aan bedrijfsgevoelige informatie schrijft zou ik in mijn bedrijf niet willen hebben of toestaan. Hoeveel IT beheerders hebben er een VOG moeten aanvragen voor het werken met vertrouwelijke informatie? Ik hoop alle?

[djwice]

Wordt nog complexer; de IT-beheerders wonen en zijn fysiek niet in de EU en hebben geen EU paspoort. Via een interne juridische constructie hebben ze een mandaat om het beheer uit te voeren (en zelfs uit te besteden zonder daarvoor EU-besluitvormers van het bedrijf te betrekken of te informeren).

[Reactie gewijzigd door djwice op 23 juli 2024 15:48]

[franssie]

Dus via de Patriot Act zou een USA beheerder gedwongen kunnen worden om ... en google is een USA bedrijf. Nu heb ik natuurlijk niets te verbergen maar morgen wellicht wel als het googelen naar het beschermen van de ijsvogel verdacht wordt bevonden.

[djwice]

Jep. Oh nee, niet de ijsvogel!

[Eonfge]

Vergeet Google's DNS trucs ook niet. Google zou graag zien dat iedereen voortaan hun DNS server gebruikt, in plaats van decentrale DNS servers van providers. Ook handig in het ontzeilen van DNS gebaseerde adblockers zoals PiHole.

[Reactie gewijzigd door Eonfge op 23 juli 2024 15:48]

[alex3305]

Alleen al op Android is dit verschrikkelijk. Google voegt simpelweg z'n eigen DNS servers toe, ongeacht wat de DHCP server aangeeft. Uiteindelijk heb ik de Google DNS servers in de firewall van mijn modem maar geblokkeerd voor alle hosts muv mijn forwarding DNS server.

Edit voor de mensen die dit als tip willen toepassen. Vergeet naast 8.8.8.8 ook niet 8.8.4.4 mee te nemen. En uiteraard de Google IPv6 DNS servers, wanneer van toepassing.

[Reactie gewijzigd door alex3305 op 23 juli 2024 15:48]

[WeiserMaster]

In een IPv4 only netwerk kan je ook d.m.v. NAT alle DNS traffic doorsluizen naar je eigen DNS server.
Mocht de client eerst Google proberen i.p.v. de lokale DNS en daarbij wachten op een response voordat de volgende (lokale) DNS geprobeerd wordt, scheelt dat weer een timeout

Een configuratie voorbeeld in pfSense

[Jerie]

Met DoT/DoH (een andere techniek die Google pushed) kan dat dus niet.

[Dorank]

Alleen al op Android is dit verschrikkelijk. Google voegt simpelweg z'n eigen DNS servers toe, ongeacht wat de DHCP server aangeeft.

Hoe kan ik dit controleren? Ik gebruik interne DNS servers met DNS voor mijn interne netwerk. Dat werkt gewoon op mjin telefoon. Als een externe DNS server gebruikt zou worden dan zou mijn telefoon niet functioneren met de hostnames.

MAW ik geloof niets van je claim. Wat ik vind zijn claims dat Android Google DNS servers als secondary toevoegd indien er slechts 1 DNS server wordt uitgegeven door bv DHCP. Nog steeds fout, maar heel anders dan je claimt.

[alex3305]

Zoals ik al zei; Google voegt de DNS servers toe, ze worden niet vervangen. Lokale hostnames zullen dan ook gewoon resolven, aangezien de primaire DNS server deze verzoeken kan beantwoorden.

Op IPv4 niveau heb ik inderdaad alleen maar een primaire DNS server vanuit de DHCP. 8.8.8.8 wordt dan als secundaire DNS server toegevoegd. Verder heb ik nooit gekeken naar aanvullende DNS servers, maar dat maakt mij eigenlijk niets uit. Als mijn DHCP maar één DNS server heeft, dan moet het OS dit gewoon accepteren en er niet zelf mee gaan rommelen. Windows doet dit bijvoorbeeld ook op deze manier, en er zijn genoeg redenen om op een device maar een enkele DNS server te hebben.

Voor zover ik mij kan herinneren worden er op IPv6 echter wel altijd aanvullende Google DNS servers toegevoegd, ongeacht hoe dit vanuit SLAAC wordt ingeregeld. DHCPv6 wordt op Android (tot en met 10 in ieder geval) niet ondersteund.

[Fastjur]

Oh dit is een goeie tip. Ik heb zelf een adblocker DNS ingesteld op mn telefoon als simpele snelle manier om ads te blokken, ik zal eens even kijken of die effectiever werkt als ik de google DNS simpelweg blokker in mijn router.

[Sicco2]

dus je forward verkeer naar bijv 8.8.8.8 naar je lokale DNS server? idd aardig idee. ga ik ook eens mee spelen.

[Alex3]

Uitgaand verkeer forwarden? Welke router kan dat?

[McBacon]

Elke fatsoenlijke router die een beetje flexibel is met NAT (bijv. pfSense/OPNsense).

[Jerie]

Vergeet AMP en Flutter Web niet.

[Eonfge]

Nog twee technieken die spontaan mijn constipatie oplossen...

[zalazar]

Ja dat vind ik ook. Dit is ook handiger als je interne certificaten hebt.
Firefox heeft ook een eigen store maar daar kwam na verloop van tijd de mogelijkheid om "security.enterprise_roots.enabled" in te stellen.
Misschien dat zo'n optie er bij Chrome ook komt.

[Slonzo]

Maar met zo'n optie vervalt het hele punt van "we willen het zelf beheren voor consistentie en veiligheid". Als ik gewoon mijn eigen root cert kan toevoegen aan de rootstore van Chrome (net zoals ik dat kan in de rootstores van OS'en), dan is alles wat ik sign ook gewoon trusted. Dus naast de OS rootstore krijg je dan gewoon nog een extra attack vector om te misbruiken?

[Sebazzz]

Feit is natuurlijk wel dat je om een vertrouwde certificate authority toe te voegen je admin rechten moet hebben op Windows. Dat is mogelijk niet zo als je dat aan Chrome wilt toevoegen.

[Sircuri]

Gaan mensen dan hiermee de Windows domain Group Policy kunnen omzeilen? Zullen netwerk admins niet leuk gaan vinden denk ik.

[Remzi1993]

Dit gaat inderdaad een dingetje worden. Dit is bij Firefox ook zo. Ik vind dit niet echt veilig. Dit zou bijvoorbeeld kunnen betekenen dat iemand (bijvoorbeeld een kennis of vriend of gast tijdens een bezoek) bij je thuis zomaar een certificaat kan toevoegen zonder admin rechten.

Om zulke dingen toe te voegen of aan te passen zou er een extra barrière moeten zijn zoals bijvoorbeeld een wachtwoord of admin request.

[djwice]

Veel mensen werken thuis direct onder admin user, want Windows doet dat zo nu default.

Dus no difference, tóch?

[Remzi1993]

Uiteraard, echter als je gasten hebt kunnen die dus onopgemerkt certificaten toevoegen aan de Firefox en dus Chrome cert store zonder dat er een barrière is om dat te voorkomen of moeilijker te maken. En gasten thuis is een voorbeeld, kan ook een receptie bij een bedrijf zijn.

Als je eenmaal binnen bent als hacker zijnde kan je mits je veel tijd, geduld en kennis hebt bij nog meer dingen komen. Bijvoorbeeld door Social engineering en andere hacking methodieken.

[djwice]

Maar dat kunnen ze nu dus ook al aan je windows certificate store.

[Remzi1993]

Nee dus, omdat je adminrechten nodig hebt en dus een wachtwoord moet invoeren (dit kan je zo instellen bij Windows en bij Linux is het standaard dat je zonder sudo niks kan). Bij Firefox en Chrome kan dus iedereen een certificaat toevoegen zonder verificatie.

Bij bedrijven is dit dus een veiligheidsrisico en vooral als je bij een bedrijf werkt die dus met staatsgeheimen en/of bedrijfsgeheimen werkt die belangrijk zijn voor de nationale- en internationale veiligheid.

EDIT: Je kan de certificaten inzien zonder adminrechten, echter kan je die niet globaal (systemwide) veranderen/toevoegen/verwijderen. En je kan het zo instellen dat je een wachtwoord moet invoeren bij een User Account Control (UAC) popup, sterker nog systeembeheerders kunnen dit zelfs afdwingen. Dit kan dus niet bij Firefox en Chrome. Je kan Firefox echter wil dwingen om de systeem cert store te gebruiken en naar alle waarschijnlijkheid zal Google dezelfde implementatie volgen.

[Reactie gewijzigd door Remzi1993 op 23 juli 2024 15:48]

[djwice]

Je wisselt van een thuis situatie naar een bedrijfssituatie. Je kunt als beheerder prima regelen dat mensen zelf niets kunnen installeren en je kunt de file die certificaten beheert simpelweg zulke rechten geven dat hij alleen aan te passen is door een admin.

Tot nu toe heb ik geen interne beheerders gevonden die een webserver veilig genoeg configureren, waarom heb jij de illusie dat ze certificaten wél beter op orde hebben? Zelfs renewal gaat vaak niet goed.

[Reactie gewijzigd door djwice op 23 juli 2024 15:48]

[Remzi1993]

De thuissituatie was een voorbeeld, een voorbeeld die je ook met een situatie op kantoor kan verwisselen.

Wat betreft beheerders van servers hoort dat in een professionele setting op orde te zijn. Ik ben zelf web developer en heb in het verleden aantal servers onderhouden. Er waren inderdaad een aantal developers die nonchalant/slordig te werk gingen, daarom heb je altijd een developer/beheerder/collega die wel op de veiligheid let in organisaties en die dat op zich neemt.

Echter dit zijn allemaal bijzaken die je erbij haalt. Ik gaf alleen een voorbeeld thuis en een voorbeeldsituatie bij een bedrijf. De kern van het probleem is dat beheerders dus zelf moeten knutselen om het dicht te timmeren, terwijl de standaard veilig hoort te zijn (secure by design) nu is het echter storend voor bedrijven die veiligheid voorop stellen. Firefox heeft hier gelukkig een optie en de kans is groot dat Google hier ook over nadenkt.

[djwice]

Ben het met je eens dat beheer op orde moet zijn, en jij zal dat vast doen. Helaas is dat niet overal het geval. Off topic: je zou je websites nog kunnen voorzien van HSTS pre-load https://hstspreload.org/ en van DNS CAA. En je zou eventueel kunnen kijken of deze website https://observatory.mozilla.org/ nog wat tips geeft als je een website scant die je beheerd. En eventueel wat informatie over de backend uit de HTTP-headers verwijderen.
Als web developer zou je kunnen overwegen of de Google Light House test nog wat tips heeft voor verbetering en alle content op je eigen server hosten in plaats van scripts inladen vanaf 3rd party domains.

De kern is wellicht : hoe gaat EDGE dit doen?

Ik ben juist heel blij dat Google het los trekt van het OS, waarom? Ik weet nog dat ik HTTP/2 op windows IIS servers heel lang niet aan kon zetten omdat de HTTP-laag in het OS gebakken zat. Waardoor IIS servers jaren lang achter liepen qua performance en SPDY niet konden ondersteunen.
Als we de decryptie van de content aan de browser over laten, waarom zou je daarbuiten willen beheren welke sleutels hij moet vertrouwen?
Bedenk dat zeer binnenkort HTTP/3 om de hoek staat (je server gebruikt nu h/2 - de volwassen versie van SPDY), HTTP/3 is de volwassen versie van QUIC. Daarbij gaat de trust via UDP, daar zijn de meeste OS beheerders nog helemaal niet naar aan het kijken.
Ik vermoed dat we de trust store dus ook anders gaan inrichten.

Leuke mind consideration: Stel dat er meer IPv6 zijn dan domeinnamen. Stel dat IPv6 gezien kan worden als een representatie van een rijtje UTF-8 tekens. Wat zou jij dan voorstellen als opvolger van domeinnamen? En hoe zou jij dat systeem inrichten? Hebben we dan nog certificaten?

[Reactie gewijzigd door djwice op 23 juli 2024 15:48]

[Remzi1993]

Uiteraard zijn er voor- en nadelen. Mits ze dit op een goede manier implementeren ben ik er eigenlijk ook voor, alleen is dit wel weer vervelend voor beheerders, want die moeten hier ook weer op letten en apart een optie configureren.

HSTS heb ik ook aangezet voor een aantal websites in het verleden. En Google Lighthouse heb ik ook een aantal keren gebruikt. Ook GTmetrix en andere testtools.

Ik vond het een fijne discussie
Ik kan veel in je overwegingen vinden. We zullen zien hoe Google dit gaat aan pakken en gaat implementeren.

[Razwer]

Maar met zo'n optie vervalt het hele punt van "we willen het zelf beheren voor consistentie en veiligheid"

oneens. Default aan betekent dat "Jan Boerenlul" zonder technische kennis dit niet aan gaat zetten. En laat Ome Jan nu eens risico nummer 1 zijn voor malware infecties.
Bedrijfsmatig of hobbyist niveau kan je het aan zetten. Meestal zijn de mensen die het handmatig aan (willen) zetten ook bewust van de risicos.

[iceheart]

Meestal zijn de mensen die het handmatig aan (willen) zetten ook bewust van de risicos.

Net als al die volksstammen die windows update permanent de nek omdraaiden en nu, jaren later, nog steeds piepen over de windows 10 benadering?

Sure, er zijn er genoeg die daadwerkelijk weten wat ze doen, maar er zijn er honderdvoudig meer die ergens een onvolledige forumpost vinden, deze half begrijpen, en vervolgens in hun eigen implementatie nog eens tien maal harder vernaggelen.

Dat soort cargo cult anti-beveiliging in consumentenhanden leidt IMO vooral heel snel tot een krachtige praktijkdemonstratie van de gevolgen van Dunning-Krügersyndroom.

Nou goed, laten we hopen dat jij meer gelijk krijgt dan ik dan maar

[Reactie gewijzigd door iceheart op 23 juli 2024 15:48]

[Razwer]

Je hebt vast wel gehoord van de Darwin Awards. Zulke figuren heb je helaas altijd
Helaas is het voor technische beveiliging minder fataal.

[iceheart]

Zou allicht fijn zijn als we een ontzegging van de internet(verbindings)bevoegdheid zouden kunnen opleggen bij herhaaldelijk blunderen.

Soort van ontzegging van de rijbevoegdheid, maar dan voor de 21e eeuw. Schijnt ook best een leerzame ervaring te zijn voor de meesten

[cyclone]

Voor iedere zelfrespecterende Enterprise is dit een must have omdat men (nu het nog kan) https inspectie uitvoert met behulp van een met eigen PKI omgeving.
In het geval van een eigen root store (a la firefox) moet er dus een mogelijk zijn om deze PKI als thrusted Root CA toe te voegen (nu gebeurd dat vaak mbh GPO / AD omgeving).
Als dit niet mogelijk is dan prijst Chrome zich behoorlijk uit de enterprise markt.

[cnieuweboer]

Controle en consistentie. Als Google een bepaald certificaat niet meer vertrouwd willen ze niet afhankelijk zijn van Microsoft voor wanneer dat certificaat wordt ingetrokken op Windows, terwijl Chrome op Android dat certificaat al blokkeert.
Dat het op iOS niet werkt is niet een keuze van Google. Webbrowsers op iOS zijn alleen maar GUIs, Apple laat geen andere browser engine toe dan alleen hun eigen webkit versie.
En er zijn meer dingen op de wereld dan Chrome of Firefox, de OS certificatestore blijft nuttig voor alle andere app/games die ergens op in moeten loggen.

[willieverhoef]

Controle inderdaad, google WIL bepalen welke certificaten en leveranciers "vertrouwd" zijn. Nog een extra macht positie...

[NielsFL]

Ja, fijn is dit. Als je met een eigen root werkt is er dus weer een extra plek waar je dat moet installeren/updaten.

Welk probleem lost men precies op? Ik snap dat andere/oudere OS versies er een afwijkende rootstore op nahouden - maar in veel gevallen is dat ook een bewuste keuze van de gebruiker/IT-afdeling.

[walteij]

Fijn, dus als ik binnen het bedrijf een eigen PKI heb, moet ik er dus voor zorgen dat mijn ROOT en intermediate CA certificaten niet alleen in de Windows certificate store staan, maar ook die van Firefox en nu ook Google.

Gaan ze er dan ook voor zorgen dat ik als beheerder dit eenvoudig op al mijn (Azure) AD geregistreerde devices kan implementeren?

[turbojet80s]

Misschien kan je je gebruikers instrueren om Edge te gebruiken. Het gaat in dit artikel immers over Chrome en niet Chromium. Ik moet zeggen dat de laatste versie van Edge mij bijzonder goed bevalt.

[walteij]

Ik adviseer al mijn gebruikers al Edge, maar sommige mensen willen nu eenmaal de vrijheid om hun eigen browser te kiezen, ook binnen een bedrijf, waarbij management de oren laat hangen naar de mensen met een grote mond (ja, meerdere keren, bij meerdere bedrijven meegemaakt) en dit dus toe staat.

Probleem is ook nog eens dat Chrome standaard in %userprofile% wordt geïnstalleerd, zodat er geen elevated rechten nodig zijn om het te kunnen installeren. Ja, je kunt met policies dit dan wel weer tegenhouden, maar daarmee zorg je er alleen maar voor dat mensen nog meer omwegen gaan verzinnen (waarmee het systeem dus gecompromitteerd kan worden).
Het is dus kiezen tussen meerdere kwaden en de minst kwade is dan helaas om gewoon 4 verschillende browsers aan te bieden aan de medewerkers en deze up-to-date te houden.

Firefox is overigens net zo kwalijk met een eigen certificate store. Gelukkig zijn daar wel oplossingen voor gekomen. Via Group Policies kun je hier wel een en ander aansturen.
Maar er zullen dan dus ook nieuwe Chrome ADMX templates moeten gaan komen om de corporate PKi te ondersteunen in Chrome.

[DataGhost]

Voor enterprise lijkt het me fijn als een feature als "Trusted Path Execution" in Windows beschikbaar wordt, dan ben je direct van die geintjes van Chrome (e.a.) af. Daarmee mag je namelijk alleen maar executables uitvoeren in root-owned mappen (en trees) en wordt het starten van een programma keihard geweigerd als het in een user-writable path staat. Op die manier kan je alle normaal geïnstalleerde programma's nog gebruiken maar gaat dat niet vanuit je userprofile. Dan is ook de attack vector weg van malware die met user-rechten user-executables gebruikt, plaatst of wijzigt.

[Reactie gewijzigd door DataGhost op 23 juli 2024 15:48]

[walteij]

Ik denk dat je zoiets wel redelijk kunt aftikken met AppLocker, maar daar zul je dus wel de juiste rules voor moeten aanmaken.

Dat gezegd hebbende, met de standaard rules die ervoor zorgen dat Windows werkt, in combinatie met 2 path rules (C:\Program Files en C:\Program Files (x86) ) kom je wel een heel eind denk ik.

[Reactie gewijzigd door walteij op 23 juli 2024 15:48]

[GeroldM]

Als admin:
Windows + R
tiep: mmc
'Add snap-in' (heb een Engelse versie van Windows)
kies: certificates
kies: local user
ga door alle andere stappen van de wizard en sla deze nieuwe interface op met een naam die jou wat zegt.

Nu heb je toegang tot alle certificate stores op Windows. En kun je naar hartelust "spelen" met certificaten.

Herhaal bovenstaande, maar kies ipv local user nu system. Daarmee kun je de certificaten beheren die voor alle gebruikers op de computer waar je dit uitvoert. Zit je in een AD omgeving, dan is deze interface naar alle waarschijnlijkheid geblokt (vanwege policies), maar werkt uitstekend in een Workgroup omgeving.

Ben echter gewaarschuwd: de resulterende rommel die je nu kan maken, dat is je eigen dikke schuld.

[walteij]

Mooi verhaal, was me volledig bekend, maar dit heeft niets te maken met een corporate PKI en een bijbehorend root en issuing ca certificaat en hoe ik dit naar al mijn (Azure) AD registered devices distribueer.
Om nog maar te zwijgen over Chrome die deze bestaande structuur dus niet meer wil gebruiken.

[Reactie gewijzigd door walteij op 23 juli 2024 15:48]

[kijkje]

Misschien overstappen op Edge, ook chromium based en die gaan vast niet overstappen op de store van Google

[Reactie gewijzigd door kijkje op 23 juli 2024 15:48]

[mobrockers]

Vergeet niet Java, die gebruikt altijd al de Java trust store in plaats van de OS trust store..

[walteij]

Zullen we die beerput maar gewoon dicht laten .

[Nimja]

Het zou wel fijn zijn als ze bewijs aandragen van de verschillen tussen de OSen en welke problemen dat voor normale gebruikers oplevert.

Want op dit moment lijkt het meer op "Wij willen in de hand hebben wat er wel/niet goedgekeurd wordt" en dat is geen goede zaak.

[DarkJack]

Dat heeft Microsoft nu ook met hun eigen Microsoft Root Certificate Program, en Mozilla gebruik al lang hun eigen root certificate store, dus op zich is dit niet "nieuw", alleen is Google wel een gigantische speler qua invloed.

Zo lang dit maar overridable is voor bedrijven zoals het nu is bij FireFox (een simpele policy doet FF terug de OS root store gebruiken).

Maar de vraag is hoe dit in de toekomst zal uitspelen. Chromium Edge is stelselmatig marktaandeel aan het afsnoepen van Google Chrome, en Microsoft zal gegaraneerd hun eigen Root Certificate Program aanhouden hiervoor.

[Blokker_1999]

Microsoft maakt natuurlijk het OS en heeft daarom inderdaad wel iets te zeggen over de certstore. En het feit dat Mozilla zelf de certificaten beheert ipv de OS specifieke certstore te gebruiken is iets dat al niet door iedereen op applaus wordt ontvangen.

Imho wil je net iets dat zo centraal mogelijk in het OS beheerd wordt. Als systeembeheerder maakt dat het net eenvoudiger om certificaten te beheren en je eigen certificaten te installeren.

[MsG]

Het merendeel van reguliere gebruikers heeft natuurlijk geen 'systeembeheerder'. Het lijkt me voor het tegengaan van malware wel veiliger dat een browser het OS qua certificaten niet zomaar gebruikt. Zo zijn er ook virusscanners die aan certificaten sleutelen.

[Blokker_1999]

En die moeten nu dus ook weer op zoek naar andere manieren. Er is een goede reden waarom die "internet security" applicaties dat doen en dat is nog altijd een bewuste keuze om dat te doen (al begrijpen mensen vaak niet wat ze doen, dat is dan weer wel spijtig).

Het lijkt me voor malware net weer positief dat als er meer stores zijn, er meer manieren zijn om je mogelijks te gaan verbergen en net weer meer locaties die je vanuit veiligheidsoogpunt moet in het oog gaan houden.

[Razwer]

Imho wil je net iets dat zo centraal mogelijk in het OS beheerd wordt

Vanuit het Zero Touch principe wel ja, maar vanuit het Zero Trust principe juist niet. Het OS is over het algemeen het eerste doelwit. De cert store is over het algemeen niet (goed) beveiligd.

Overigens moet niet iedereen ineens roomser dan de paus willen zijn. Door de jaren heen is elke JRE applicatie verbannen naar een aparte keystore van de geinstalleerde JRE ipv het OS waardoor er al een split is voor veel applicaties. De cert store een eigen silo te maken voor de browser is vanuit security perspectief een heel goed idee. Dat dit vooral voor bedrijfsmatig gebruik mogelijk problematisch kan zijn is een andere discussie.

[Slonzo]

Ik begrijp het ook niet zo goed. Ik heb nog nooit problemen gehad met root certificates die al dan niet beschikbaar/blacklisted waren. Daarvoor hebben we toch CRL en OCSP? Het punt van Certificate Authorities is net dat ze al trusted zijn; waarom moeten ze nu nog door een extra hoepeltje springen zodat ome Google nogmaals kan bepalen of ze trusted zijn?

Verder heeft Google de vinger al in de pap op Android, dus dan hebben we het verder enkel over desktopplatformen?

[n4m3l355]

Op dit moment trek jij die conclusies vanuit het oogpunt dat Google automatisch iets kwalijks wilt doen. Nu is de credo "do no evil" misschien niet zoveel meer het geval, tegelijkertijd kan ik deze actie goed begrijpen gezien hoe vaak het misgaat met de verschillende certificaten servers. En het zou inderdaad Google netjes staan als ze wat dieper hierop ingingen, tegelijkertijd is het gemiddelde nieuws gehalte zowieso vrij sumier behalve dat Google iets wilt veranderen cq verbeteren.

[Yalopa]

Dus google gaat nu controle nemen over wat we technisch gezien als "trusted" zien en wat niet? Google gaat ook de criteria bepalen om trusted te mogen zijn? Volgens het artikel doen ze dit om de veiligheid en de privacy van hun gebruikers te beschermen, maar google is zowat de voorlaatste aan wie ik mijn privacy zou toevertrouwen...

Er is niets mis met het open systeem van PKI, wat door elke applicatie te benaderen valt. Ik zie gewoon weer veel dubbel werk, zeker in bedrijven waar een eigen PKI er voor zorgt dat eigen certificaten gebruikt kunnen worden.

[kalikatief]

Het grootste probleem IMHO is dat alle partijen certificaten een heel technisch verhaaltje maken dat een dozijn laagjes diep verborgen zit. Stop er als sector wat serieuze marketing push achter en laat de besturingssystemen eens een goede gebruiksvriendelijke UI ontwikkelen, dan los je het probleem op bij de bron: de gebruiker.

Het is absurd dat een paar bedrijven wereldwijd maar beslissen wat er te vertrouwen is op basis van geld uitwisselingen. Dit zou veel decentraler moeten worden opgezet.

[GeroldM]

Er is mij ooit eens een grafische voorstelling getoond van het aantal certificaat uitgevers (globaal) en of dat deze een dochter-onderneming zijn van een andere certificaat uitgever of niet.

Blijkt dat er maar een handjevol certificaat uitgevers zijn, met een hoop dochter ondernemingen, welke op huj beurt ook weer dochter-ondernemingen onder zich hebben. Het lijkt alsof je veel keuze hebt, maar is vooral een wassen neus. Als je die voorstelling geloofde.

[kalikatief]

Geen wonder, toch? Het is zo'n technisch zooitje dat alleen de partijen die er goud geld in zagen er in hebben geinversteerd waardoor het nu best vast ligt. Maar als er meer keuze zou zijn dan kun je ook mer opties krijgen.

Lets Encrypt mag dan niet 100% in de discussie passen als certificaatuitgever voor jan-en-alleman, maar het laat wel zien dat er mensen zijn die de markt willen openbreken en het systeem zoals wij het kennen innoveren.

Hoe beter de consument wordt voorgelicht en hoe transparanter het hele 'vertrouwen' verhaal wordt gemaakt, hoe beter. Maar ja, dat gaat nooit gebeuren want daar zien de politici en commercie het nut niet van in.

[Amiga3000]

Als het van Google komt is het niet open dat was vroeger wel zo.

[MadEgg]

Er is niets mis met het open systeem van PKI, wat door elke applicatie te benaderen valt. Ik zie gewoon weer veel dubbel werk, zeker in bedrijven waar een eigen PKI er voor zorgt dat eigen certificaten gebruikt kunnen worden.

Nou.... ik vind niet dat Google hier goed aan doet maar Java en Mozilla doen dit bijvoorbeeld ook. Het certificaatgebeuren stelt een zeer krappe en gevaarlijke bottleneck voor je privacy bij de beheerder van de certificate store. Daar vertrouw ik Google zeker niet meer in dan Microsoft. Maar wat mij betreft stappen we zo snel mogelijk af van de huidige PKI en gaan over naar DANE. Hierbij stel worden het beheer van het certificaat gekoppeld aan de bijbehorende DNS-zone die weer met DNSSEC beveiligd is. Geen dubieuze CA's meer die certificaten voor alles wat ze maar willen kunnen uitgeven.

[CAPSLOCK2000]

Het Root Program werkt op alle platforms behalve iOS. "Apples beleid verhindert de Chrome Root Store het op Chrome voor iOS te gebruiken", zegt Google. Het bedrijf zegt dat er al een aantal certificaatautoriteiten is uitgekozen die kunnen deelnemen aan het programma

Dat is wel illustratief voor de tijd waarin we leven. Twee molochen die vechten om macht en daarbij de privacy van hun gebruikers als wapen inzetten. Ergens klinkt het fijn dat de plannen van Google niet door gaan omdat Apple dat niet toestaat, maar uiteindelijk is dat het niet want ik wil zelf beslissen wat ik mag doen met mijn computers.
Het zijn middeleeuwse koningen die vooral bezig zijn met hun eigen profijt en zo veel mogelijk macht krijgen en daartoe het leven van hun burgers domineren.

[SchulieBug]

En dus straks verschillende rootstore's per browser, allemaal weer apart bij te houden? Is dit niet gewoon een manier om Chrome te pushen?

[NielsFL]

Het is denk ik andersom: Chrome heeft nu voldoende marktaandeel dat ze de volgende stap kunnen zetten: de rootstore zelf beheren.

Als het aan Google ligt is je Windows PC straks gewoon een Chromebook waar toevallig Windows nog onder draait. Het wachten is Android app ondersteuning.

[Paul]

Het is eerder een manier om gebruikers weg te jagen. Dit (moeilijk doen over OS store) is één van de redenen waarom ik een hekel heb aan Firefox.

[SkiFan]

Knap waardeloos. Verlies je als beheerder nog meer mogelijkheden om de boel zelf veilig te houden. Hoe ga ik dan mijn eigen SSL certificaten er tussenin krijgen, zodat ik ook SSL verkeer op malware kan scannen?

[PPie]

Dat lukt je sowieso niet als er certificate pinning gebruikt wordt...

[ELD]

Hoe ga ik dan mijn eigen SSL certificaten er tussenin krijgen, zodat ik ook SSL verkeer op malware kan scannen?

Switchen naar een product dat dit wel toestaat e.g. Firefox of Edge

[robertpNL]

Laat onderliggende besturingssysteem andere rootstores eigenlijk toe? Of wordt dit een rootstore binnen de applicatie (Chrome in dit geval) en mogen andere applicaties/browers daaar geen gebruik van maken?

[FreezeXJ]

Dat laatste dus, en bijvoorbeeld Java en Firefox doen dat ook al. We krijgen als het zo doorgaat gewoon tig verschillende root-stores, die je dus allemaal moet bijhouden, en die allemaal een kwetsbaar punt zijn voor de applicatie.

[Gomez12]

Erg jammer deze gedachtengang. Straks krijgen we weer certificaten per app. Daar moesten we nu net al tig jaar vanaf zijn.

Ik vind het al erg irritant dat java hierin apart is.
Maar straks wil je dus iets nabootsen met curl / wget dan mag je even 2 aparte certificaat installaties doen voor die 2 "browsers"

[Amiga3000]

Stop deze onzin van Google, gebruik andere browsers dan zijn we hier van af.
Iedereen was eerder altijd aan het zeuren over IE maar dit wordt zo langzamer hand veel erger.

Waarschijnlijk doen ze dit om hun macht verder uit te breiden, heb je zo meteen een Google certificaat nodig voor alles wat van Google komt of toeleveranciers daarvan (Apps).

Apple en Google zijn steeds meer belust op controle over JOUW apparatuur.