image

Google wil public key pinning in Chrome gaan verwijderen

zondag 29 oktober 2017, 09:41 door Redactie, 14 reacties

Google is van plan om public key pinning in Chrome te gaan verwijderen, een maatregel die Chrome-gebruikers tegen man-in-the-middle-aanvallen moet beschermen. Via public key pinning kunnen eigenaren van websites aangeven welke certificaatautoriteiten voor hun domeinnaam een certificaat mogen uitgeven.

Certificaten die door andere certificaatautoriteiten zijn uitgeven worden dan niet meer vertrouwd. De hack in 2011 van de inmiddels failliete Nederlandse certificaatautoriteit DigiNotar werd via public key pinning ontdekt. Een aanvaller had bij DigiNotar voor tientallen domeinen geldige certificaten gegenereerd. Het ging onder andere om een certificaat voor Google.com. Alle browsers accepteerden dit certificaat, behalve Chrome. Chrome maakt namelijk gebruik van public key pinning en Google had ingesteld welke certificaatautoriteiten voor Google.com een certificaat mogen uitgeven. DigiNotar stond hier niet tussen, waardoor Google een waarschuwing ontving en internetgebruikers kon waarschuwen.

Volgens Google maken webmasters en domeineigenaren echter weinig gebruik van public key pinning. Dit komt mede doordat de maatregel lastig is te gebruiken en die ervoor kan zorgen dat websites onbruikbaar worden. Google is dan ook van plan om de ondersteuning van public key pinning af te bouwen en uiteindelijk helemaal te verwijderen. Het voorstel is nu om de support van http public key pinning, waarbij er met dynamische 'pins' wordt gewerkt, in Chrome 67 uit te faseren. Deze versie staat gepland voor 29 mei 2018. Uiteindelijk zal ook de ondersteuning van statistische pins worden gestopt.

Certificaattransparantie

In plaats van public key pinning wil Google voor alle publiek vertrouwde certificaten op certificaattransparantie overstappen. Dit is een door Google ontwikkelde technologie en is bedoeld om verschillende structurele fouten in het certificaatsysteem te verhelpen en bijvoorbeeld onterecht uitgegeven certificaten in bijna real-time te detecteren. Bij certificaattransparantie verplichten browsers dat een https-website bewijs aanlevert dat het certificaat in een openbaar certificaattransparantie-log voorkomt. Dit is een eenvoudige netwerkdienst die een archief van certificaten bijhoudt.

Certificaten kunnen alleen aan dit log worden toegevoegd en niet worden verwijderd of aangepast. Ze gebruiken verder een cryptografische methode om manipulatie te voorkomen en kunnen door het publiek worden gecontroleerd. Via zogeheten 'monitors' wordt er periodiek in de log-bestanden naar verdachte certificaten gezocht. Zodoende kunnen onterecht uitgegeven certificaten worden gedetecteerd, alsmede certificaatautoriteiten die zijn gehackt of kwaadaardig zijn. Chrome-ontwikkelaar Chris Palmer, die het plan voor het uitfaseren van public key pinning aankondigde, weet echter nog niet wanneer Chrome voor alle certificaten certificaattransparantie zal verplichten.

Reacties (14)
29-10-2017, 09:56 door [Account Verwijderd] - Bijgewerkt: 29-10-2017, 10:13
[Verwijderd]
29-10-2017, 11:19 door Anoniem
Door OpenXOR:
Dit is een door Google ontwikkelde technologie...
Ja hoor. De volgende stap van Google om het internet naar eigen hand te zetten. Wat een naar bedrijf is het toch.
Of ze verzinnen iets wat wel goed gebruikt kan worden?
Zo zijn er wel meer grote (commerciele) bedrijven die een standaard bedacht hebben. Niets mis mee.

Dit komt mede doordat de maatregel lastig is te gebruiken...
Onzin. Het kost niet veel moeite om uit te zoeken wat het is en hoe het werkt. Er zijn meer dan genoeg handleidingen en toolings te vinden om dit in te stellen.
Blijkbaar wel, en als het fout gaat, is je site niet meer te gebruiken. Dat is best een belangrijk risico wat je niet moet onderschatten. En een handleiding zegt niet meteen dat het ook werkt en dat iedereen het snapt die het moet onderhouden.

Dit is een eenvoudige netwerkdienst die een archief van certificaten bijhoudt.
Kijk, daar is het Google om te doen. Een index van alle websites automatisch aangeleverd aan Google.
[/quote]Dat is jou interpretatie en je gaat meteen weer uit van al het negatieve. Denk eens juist aan het positieve. Iets wat juist goed gebruikt gaat worden waardoor Privacy en Security verbeterd gaat worden.
29-10-2017, 11:46 door Anoniem
En als het handig is voor Google is het ook handig voor surveillance.

Ziet men nu nog niet, wat er gespeeld wordt?

Is het echt zo ondoorzichtig? En het wordt nog ondoorzichtiger, voor de eindgebruiker dan althans?

Geen zicht meer op wat er gebeurt op het niet-publieke Internet deel.

"One to rule them all by browser engine and api engine!".

Alle grote publieksbrowsers op een kluitje voor dezelfde doeleinden.

Nog meer reden voor developers en hosters om zich naar Google (in) te richten,
wel zo makkelijk, wel zo voordelig. Maar niet zo leuk voor jou en mij.

Het is net de lepel levertraan. "Mond open, even slikken, goed voor je".

Kijk eens hier wat er van uw privacy op meeste websites is overgebleven:
https://privacyscore.org/
29-10-2017, 12:28 door Anoniem
Gelukkig zijn er nog andere browsers die kunnen worden gebruikt:)
29-10-2017, 12:43 door Anoniem
Door OpenXOR:
Dit is een door Google ontwikkelde technologie...
Ja hoor. De volgende stap van Google om het internet naar eigen hand te zetten. Wat een naar bedrijf is het toch.

Dit komt mede doordat de maatregel lastig is te gebruiken...
Onzin. Het kost niet veel moeite om uit te zoeken wat het is en hoe het werkt. Er zijn meer dan genoeg handleidingen en toolings te vinden om dit in te stellen.

Dit is een eenvoudige netwerkdienst die een archief van certificaten bijhoudt.
Kijk, daar is het Google om te doen. Een index van alle websites automatisch aangeleverd aan Google.
Lekker substantieel.
Toch eigenaardig dat bij een website dat reageren zonder account ondersteunt de meest hardnekkige "trolls/fanboys" gewoon een accountje aanmaken. Niet dat jij per definitie zo'n troll/fanboy bent maar je triggert hier wel m'n security.nl troll/fanboy-alarm.

OT: van mij hoeft het niet volledig te verdwijnen maar denk dat HPKP maar het beste terug naar de tekentafel kan. Het kan zeker nuttig zijn maar ook een gevaar en als vrijwel niemand het vervolgens inschakelt heeft het eigenlijk geen zin en moet je je afvragen of het niet juist vooral tegenwerkt. Was ook al vrij snel duidelijk dat Certificate Transparency een veel adequatere oplossing is voor verkeerd uitgegeven certificaten en rogue CA's.
29-10-2017, 13:19 door SPer
Beste OpenXOR , het is vast ook wel mogelijk om een andere browser te gebruiken, voor het geval je geen andere weet :

FireFox, Safari, Lynx, Opera , internet explorer etc. ;-)
29-10-2017, 13:26 door Anoniem
FireFox, Safari, Lynx, Opera , internet explorer etc. ;-)

Dat is wat simplistisch en naïef gedacht. De google religie wordt geforceerd via de eigenaren van websites, die hopen beter in de zoekresultaten te komen.
29-10-2017, 17:21 door Anoniem
Certificate pinning is niet ideaal. Dat klopt wel.
Het alternatief wat ze nu voorstellen, je browser een lijst te laten raadplegen of het certificaat erin opgenomen is,
stuit onmiddellijk op het volgende bezwaar:

W i e....h o u d t....d i e....l i j s t....b i j ???!!!!

Dit lijkt me nl. typisch weer iets voor Google: onder het mom van veiligheid je privacy de grond in boren.
Wanneer immers jouw browser die lijst gaat raadplegen om het certificaat te controleren,
geef je je IP-adres af aan de houder van die lijst!
Daarmee geef je keurig aan welke website je van plan bent te bezoeken,
en als bijv. Google de houder van die lijst is, kan Google precies zien welke websites je vandaag allemaal weer hebt bezocht.

"Certificate Transparency" wordt daarmee tegelijk "Site Visiting Transparency" (voor Google)
29-10-2017, 18:52 door Anoniem
Het is niet alleen Google, er moeten ook nog unieke pre-certificaten worden gevalideerd en gelegd naast de uitgegeven certificaten. Een dubbel check systeem dus.

Dus Google speelt een rol samen met de CA's. Het gaat dus om het monitoren van bepaalde CT logs.

De beste oplossing om aan CT te voldoen is dat u een CA kiest die SCTa toevoegd aan uitgegeven certificaten die in overeenstemming zijn met Google's CT policy. De grote meerderheid van GlobalSign SSL Certificaten zijn reeds in overeenstemming met de Google policy en binnen een paar maanden zijn alle certificaten dat volledig, voor de Google deadline van April 2018.

De bekende logs zijn hier gespecificeerd (voor zo ver bekend): https://sites.google.com/site/certificatetransparency/known-logs

Het lijkt dus veel op een soort van gerichte overname van Google van de gehele "Certificeringstent".
Met de recente controverse versus Symantec is dus alles begonnen: Check ook hier: https://cryptoreport.websecurity.symantec.com/checker/views/certCheck.jsp
30-10-2017, 08:42 door Anoniem
Door Anoniem: Het alternatief wat ze nu voorstellen, je browser een lijst te laten raadplegen of het certificaat erin opgenomen is,
stuit onmiddellijk op het volgende bezwaar:

W i e....h o u d t....d i e....l i j s t....b i j ???!!!!
Dat is geen bezwaar, dat is een vraag. De FAQ zegt daarover:
Who is going to be running the logs?
Google is currently running a Certificate Transparency log. We welcome others who want to run logs. But keep in mind, anyone can run a log, since the log does not have to be trusted -- the verification protocols make sure of that.
https://www.certificate-transparency.org/faq
30-10-2017, 10:47 door Anoniem
Incompleet nieuws.
Ter aanvulling:

...maar sedert recent heeft google.com een CAA record in de DNS...
dig @ns1.google.com google.com CAA

of, als bijv. je dig command te oud is:
dig @ns1.unicycle.net trouwauto.limo TYPE257

Bij Google bevat de reply hun indrukwekkend korte gTLD:
google.com. 21599 IN CAA 0 issue "pki.goog"
30-10-2017, 17:26 door Anoniem
Nog een reden te meer om een niet-loggende VPN aan te schaffen
en 3rd party scripts te blokkeren.

We zien op de achtergrond de 'rapid prototyping' van de totale surveillance omgeving in volle gang.

Het Nederlandse onderdeel van nine eyes met de sleepwet surveillance lift mee met Google data profiling en ligt zo op st(r)oom. Men mag u zelfs nu legitiem gaan hacken.

Meer reden om volledige e2e encryptie te eisen, goede beveiliging op connecties (geen SHA1, zwakke cyphers, geen security headers, die ontbreken, fouten bij 'same origin' handhaving, geen verder tolereren van geen SRI-hashes geïmplementeerd, certificaten als root op de server, excessieve info proliferatie, verborgen tracking, canvas fingerprinting).

Men denkt natuurlijk, de eindgebruiker staat qua veiligheid en privacy al zo veel ronden achter, die heeft de handdoek al lang in de ring gegooid. Maar er komt nog gedecentraliseerd Internet, de vrees van elke rechtgeaarde Big Brother snoop agent: https://mysterium.network/

Innovatie tegen een spiedende en tappende overheid, die hand in hand gaat met corporatie-belangen. Burger, doe uw online gordijnen dicht en uw Internet jaloezieën omlaag. Een "doorzon" internet omgeving kan helaas in deze bange dagen niet meer.
30-10-2017, 18:52 door marcod - Bijgewerkt: 30-10-2017, 18:54
Door OpenXOR:
Dit is een door Google ontwikkelde technologie...
Ja hoor. De volgende stap van Google om het internet naar eigen hand te zetten. Wat een naar bedrijf is het toch.

HPKP (RFC7469), waar we het hier over hebben, was anders ook al gewoon door Google ontwikkeld :-)

Dit komt mede doordat de maatregel lastig is te gebruiken...
Onzin. Het kost niet veel moeite om uit te zoeken wat het is en hoe het werkt.

Maar daarmee ben je er nog niet. Je hoeft maar een klein foutje te maken en je site is voor maanden onbereikbaar. Dat is operationeel een behoorlijke uitdaging.

Eigenlijk is de mooiste oplossing hiervoor DANE (RFC6698), maar dat vereist DNSSEC en dat is ook nog lang niet overal beschikbaar. Gaat 'm dus niet worden.
30-10-2017, 23:03 door Anoniem
Gaat hem dus niet worden

Dus nog meer onveiligheid op websites, nog minder vasthouden aan eisen van 'best practices', lekker makkelijk voor de data-miners/graaiers en de surveillance spooks.

En daar gaat uw privacy het raam uit, te wijten aan bij voorbeeld slechte configuraties/ implementaties met bij voorbeeld risico door 3rd party embeds, bijv. fonts.gstatic.com etc. daarbij trackers als googleapis dot com. Verschil in content tussen wat er opgediend wordt via HTTPS en HTTP. Geen aanvullende maatregelen als bij voorbeeld een CSP header, een XFO header, een X-XSS protectie header, X-Content-Type Options header, referrer-policy header.

Bij voorbeeld voor de naamserver een wildcard EssentialSSL certificaat van Comodo RSA. Goed geconfigureerd daar met HSTS, maar dan weer met een onveilige log-in pagina - communicatie niet met encryptie -

Het wachtwoord wordt onveilig verstuurd in the clear naar http://XXX.XXX.XXX.XX/InlogServlet?tiucXXXXXXc64ie--FapKXXXXXZr0jc naar een nginx/1.10.2 webserver (server info proliferatie). Neen namen noemen we niet, het gebeurt hier in Nederland en op een webserver in de USA.

En met het geven van dergelijke voorbeelden en nog erger, kan ik nog wel uren en uren doorgaan. Ga je goed mee met de sleepwet in aantocht. Echt. Dit geeft de burger weer volop moed (NOT).

Wanneer gaan we het eens echt als beveiligingsgemeenschap onder ogen zien en aankaarten? Maar er gebeurt maar niets en al heel, heel lang. Net of men er niets aan wenst te veranderen, of alleen maar cosmetisch, tenminste die indruk krijg ik wel eens of wordt beveiligingskennis bij velen weggehouden?

Wie oh wie helpt mij uit de droom?
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.