Google heeft oplossing voor SSL-systeem
Twee onderzoekers van Google hebben een oplossing voor het SSL-systeem aangedragen dat de laatste tijd regelmatig onder vuur ligt. SSL wordt gebruikt voor het versleutelen van de communicatie tussen bezoekers en websites, en laat de bezoeker ook de identiteit van de website vaststellen. Inbraken bij DigiNotar en Comodo, waarbij aanvallers vervalste certificaten voor allerlei domeinen uitgaven, lieten zien dat het systeem niet waterdicht is.
Adam Langley en Ben Laurie hebben een oplossing bedacht die dit soort incidenten moeten voorkomen. Alle certificate authorities (CA) moeten cryptografische details over elk uitgegeven SSL-certificaat publiceren. Die informatie wordt gesigneerd en in een publiek toegankelijke audit-log bewaard. Daardoor zou een aanvaller niet, of met veel meer moeite, valse certificaten kunnen laten genereren.
"Servers leveren naast het certificaat, het bewijs dat het certificaat is geregistreerd. Clients controleren dit bewijs en domeineigenaren monitoren de logs", aldus Langley. "We denken dat dit ontwerp een grote, positieve impact op een belangrijk deel van de internetveiligheid zal hebben en dat het is uit te rollen. De uitrol zal echter niet eenvoudig zijn en hopelijk zullen we het niet alleen uitrollen", voegt Laurie toe.
Ik weet niet of dit echt een oplossing is.
En als iedereen dan toch die logs moet gaan vertrouwen: hoe verifieer je echtheid van zo'n log? Met een certificaat?
1. Dat misbruik in Iran uiteindelijk gedecteerd werd door Google's chrome browser. Wat voor controle hadden zij die de andere browsers/aplicaties niet hadden?
2. Dat Fox-it als eerste de OCSP-responder bij Diginotar heeft omgedraaid van een negatieve controle (blacklist) naar een positieve controle (whitelist).
Zonder OCSP wordt alleen geverifieerd of een certificaat is ingetrokken (CRL: blacklist) terwijl het idee van Google om de uitgegeven certificaten te signeren een vorm van whitelisting is. Het maakt dat een hacker een extra component zal moeten manipuleren. Als deze logfile met hetzelfde certificaat gesigneerd mag worden, dan sluit ik me aan bij hotboy: wat schiet je ermee op?
Maar wellicht zijn er andere mogelijkheden. De kern van het probleem was m.i. dat een identiteit aan het certificaat vals is gekoppeld (bijv.google.com) terwijl de binding van dit certicaat aan de betreffende server een andere was. Oftewel: zouden wij de registrars niet moeten toevoegen in de SSL-keten? Terug naar het voorbeeld van de logfiles: als de betreffende registrar ziet dat een uitgegeven certicaat inderdaad is toegepast aan het domein waarvoor het beweerd te zijn uitgegeven, dan signeert de registrar het uitgegeven certificaat in de logfile. Daarmee had m.i. het Diginotar incident niet kunnen plaatsvinden want het google.com certificaat had alleen door een registrar van het.com-domein gesigneerd kunnen worden.
Vindt het toch wel een grote impact qua uitrollen omdat alle browsers en applicaties een extra controle moeten inbouwen, maar ten opzichte van het hele systeem op de schop gooien kan het misschien niet anders.
Wie heeft er meer ideeen?
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.
