Google wil public key pinning in Chrome gaan verwijderen
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.
Zo zijn er wel meer grote (commerciele) bedrijven die een standaard bedacht hebben. Niets mis mee.
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/
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.
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.
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:
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)
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
stuit onmiddellijk op het volgende bezwaar:
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.
Ter aanvulling:
...maar sedert recent heeft google.com een CAA record in de DNS...
of, als bijv. je dig command te oud is:
Bij Google bevat de reply hun indrukwekkend korte gTLD:
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.
HPKP (RFC7469), waar we het hier over hebben, was anders ook al gewoon door Google ontwikkeld :-)
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.
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?
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
