Google verbetert HTTPS-encryptie met forward secrecy
Google heeft een beveiligingsmaatregel aan Gmail, de zoekmachine en andere webapplicaties toegevoegd, die de aanwezige encryptie moet versterken. Sinds vorig jaar ondersteunen Gmail en de zoekmachine HTTPS, die nu met forward secrecy is versterkt. Websites die HTTPS zonder forward secrecy aanbieden, lopen namelijk het risico dat de encryptie in de toekomst wordt gekraakt. Een aanvaller die versleutelde berichten en zoekopdrachten nu onderschept, maar niet kan kraken, kan dit mogelijk wel over tien jaar als computers veel sneller zijn geworden.
Bij forward secrecy worden de privésleutels van een verbinding niet permanent bewaard. Een aanvaller die een enkele sleutel kraakt, kan daarmee niet maanden aan andere verbindingen kraken. Zelfs de beheerder van de server kan niet "retroactief" de HTTPS-sessie ontsleutelen.
Forward secrecy is nu ingeschakeld voor Gmail, SSL Search, Docs en Google+. De zoekgigant heeft daarnaast ook de aanpassingen aan de open source OpenSSL library die dit mogelijk maken vrijgegeven.
Internet Explorer
Chrome, Firefox en Internet Explorer op Windows Vista of nieuwer ondersteunen forward secrecy. In eerste instantie zullen alleen Chrome en Firefox het standaard voor Google diensten gebruiken, omdat IE niet de combinatie van ECDHE en RC4 ondersteunt. De zoekgigant hoopt Microsoft's browser in de toekomst te kunnen ondersteunen.
"We zien graag dat forward secrecy de norm wordt en hopen dat onze uitrol de haalbaarheid van deze visie demonstreert", zegt Adam Langley van het Google Security Team. In Chrome is forward secrecy te herkennen door op het groene slot te klikken. Daar zal vervolgens ECDHE_RSA als sleutelmechanisme worden vermeld.
Ja, want dan is het nog steeds relevant. 10 jaar in ICT is nogal wat. ^^
Volgens mij heeft dit niet zo veel zin. Ik heb altijd begrepen van SSL (en dus ook HTTPS) dat er een sessie-sleutel wordt gegenereerd. Deze sessie-sleutel wordt dmv asymetrische encryptie tussen client en server afgesproken/uitgewisseld en is per sessie anders (vandaar ook sessie-sleutel). Met deze sessie-sleutel wordt de rest van het verkeer middels een symetrische encryptie gecodeerd. Ook al heb je die initiele asymetrische sleutels niet, je kunt altijd nog de symetrische sessie-sleutel kraken (desnoods met brute-force). Dit wordt enigszins makkelijker gemaakt omdat een deel van het HTTPS verkeer voorspelbaar is.
Forward secrery, betekend dat je een bepaald sleutel(1) hebt, waarmee je het eerste bericht encrypted, het volgende bericht versleutel je met sleutel(2)=hash(sleutel(1)), het derde bericht met sleutel(3)=hash(hash(sleutel(1))).
Het idee is dan zorgt dat je de hashing formule niet te inverteren valt dus sleutel(1)=inverse_hash(sleutel2) niet mogelijk is, en de functie niet herhalend/periodiek is.
Op het moment dat de aanvaller dan een sleutel te pakken krijgt kan hij alle berichten ontcijferen na deze sleutel maar geen van de berichten daarvoor, vandaar "Forward secrecy"
Alice en Bob zijn met elkaar de session key k overeengekomen. Nu willen ze graag forward secrecy over de door hun verstuurde berichten. Ze kiezen er voor om voor het eerste bericht sleutel k te gebruiken, voor het 2e bericht h(k), voor het ne bericht hn(k). h is een hash functie die aan de volgende eisen voldoet:
Als ik die eerste sessie-sleutel kraak, kan ik, omdat het hashing algoritme bekend is, de tweede, derde en alle volgende zelf uitrekenen. Als ik de tweede sessie-sleutel kraak kan ik de derde uitrekenen etc. Wat ook op tweakers staat:
Bovendien kan ik nog steeds elke sessie-sleutel afzonderlijk kraken, wat net zo veel moeite kost voor de tweede of derde als voor de eerste. Het enige verschil lijkt dat de sessie-sleutels vaker wisselen maar dat juist dit wisselen voorspelbaar is.
Bovendien kan ik nog steeds elke sessie-sleutel afzonderlijk kraken, wat net zo veel moeite kost voor de tweede of derde als voor de eerste. Het enige verschil lijkt dat de sessie-sleutels vaker wisselen maar dat juist dit wisselen voorspelbaar is.
Bovendien kan ik nog steeds elke sessie-sleutel afzonderlijk kraken, wat net zo veel moeite kost voor de tweede of derde als voor de eerste. Het enige verschil lijkt dat de sessie-sleutels vaker wisselen maar dat juist dit wisselen voorspelbaar is.
Wat dan ook, heb je je best gedaan voor een open & vrij Internet, word het op slot gezet!...
IP bekend bij Redactie.
Bij normaal gebruik wordt een sessie-sleutel afgesproken aan de hand van een key-exchange protocol. Daarin wordt bijvoorbeeld het SSL-certificaat van de server gebruikt, en die server moet daar de bijbehorende geheime sleutel van kennen.
Stel nu dat die geheime sleutel uitlekt (of gekraakt wordt). Niet alleen kan dan iemand zich voordoen als de als die server, maar hij is ook in staat om daarmee alle sessie-sleutels opnieuw te berekenen en daarmee dus oude ssl-verbindingen alsnog in te zien.
Forward secrecy zegt eigenlijk maar één ding: dat wanneer die geheime sleutel uitlekt, dat dan alle oude sessie-sleutels niet meer te berekenen zijn en dat dus alle oude communicatie nog steeds veilig is.
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.
