Dit zijn goede berichten! Zo je maar weer dat er toch vooruitgang zit in de beveiliging van websites, het zal hackers weer extra moeite kosten... Maar ze blijven het proberen!

"Hackers"? Je bedoelt computerkrakers. Waarom zouden die miljoenen in computerapparatuur investeren om jouw email te kunnen lezen? Die komen nog vooral binnen door de mazen in de code, niet door sleutels te factoriseren. Niet voor niets dat een introductiecollege cryptografie meer dan de helft van de tijd kwijt is aan het uiteenzetten hoe een enkele regel code of het bestaan van een enkele extra foutmelding je systeem compleet open kan leggen voor een aanvaller.

Dat wil niet zeggen dat het niet onderhand tijd was om de sleutellengte te vergroten. Elders hadden ze iets meer gedaan dan een persbericht overtikken en haalden ze een cryptograaf aan die meldde dat "met de publieke kennis en beschikbare hulpbronnen" (en ook zonder doorbraak in factorisatiemethoden) 1024bits RSA sleutels nog wel vijf jaar veilig genoeg te schatten waren.

Nu moet je weten dat er geschat wordt dat 's werelds grootste afnemer van rekenkracht alsook 's werelds grootste werkgever aan wiskundigen ongeveer vijf jaar voorloopt in kennis op de publieke literatuur, en genoeg computerkracht heeft om er eens even flink de schouders onder te zetten. Dus als je tussen de regels doorleest staat er "we denken dat de NSA nu ongeveer door die 1024bits heen aan het raken is".

Zo moet je dat lezen.

De meeste certificaat providers eisen dit toch al sinds vorig jaar?
Men doet alsof men vooroploopt maar volgens mij is eind 2013 de deadline voor deze operatie voor iedereen.
Wij hebben al heel lang een 2048 bit certificaat, onze provider eiste dat vorig jaar al toen we wilden verlengen.

Merk op dat het hier voornamelijk gaat om de waarde van data in de toekomst. De enige manier om een bericht voor een aantal jaar te bewaren alvorens het vrij te geven is door het te versleutelen met een sleutelsterkte die verwacht wordt dat tegen die tijd kraakbaar is. Zo heeft Ron Rivest, de bedenker van onder andere MD5 en RC4, een encrypted stuk tekst gepubliceerd dat tegen 2034 gekraakt zou moeten kunnen worden (lcs35).

Om terug te komen op het onderwerp, dat is dus wat Google aan het doen is: Zelfs als er een MITM-aanval plaatsvindt die enkel data opslaat zal 2048-bits langer veilig blijven dan 1024-bits encrypted data, en hopelijk zo lang dat de data uiteindelijk waardeloos is.

De reden waarom we met z'n allen nog niet op 4096-bit keys of hoger zitten (hoger heeft ook veel minder ondersteuning) is omdat het ook best wel wat trager is en meer rekenkracht kost. Vooral met de opkomst van mobiele apparaten en laptops die de hele dag mee moeten gaan is dit best wel een issue.

Hoelang 1024-bits of 2048-bits veilig blijven alvorens het, gegeven voldoende geld en enkele maanden tijd, gekraakt kan worden weet ik niet. Ik kan een vage gok doen gegeven de wet van Moore, maar ik kan het niet preciezer berekenen dan dat.

Ik vraag me trouwens ook af in hoeverre het nuttig is en in hoeverre Google dit doet voor de show. Ze zijn wel een grote speler, maar vooralsnog is 1024-bits best wel veilig: http://security.stackexchange.com/a/4528/10863
Merk ook op dat data niet encrypted wordt met deze 1024-bits sleutel, enkel het certificaat wordt ermee gesigneerd. De daadwerkelijke encryptie verloopt via een symmetrisch protocol zoals AES (of voorheen RC4) omdat dit vele malen sneller is dan RSA. De reden dat RSA wordt gebruikt om het certificaat te signeren is omdat asymmetrische encryptie simpelweg nodig is voor veilige communicatie op te zetten over een onveilig kanaal. Zelfs als je dus de data op zou slaan van een https sessie, is de kans nog altijd klein dat je jaren later daadwerkelijk data kan achterhalen, gegeven dat voor het symmetrische protocol een lang genoege sleutel gebruikt is. Misschien dat Google ook nog iets kan zeggen over de configuratie daarvan... maar dat zal wel te geek zijn en minderheden zijn voor hun geen prioriteit.

Het is grotendeels afhankelijk van de server's instellingen met wat voor key de daadwerkelijke communicatie plaatsvindt. Daarom is het ook belangrijk dat je je webserver goed configureert wanneer je https aanzet. De server biedt meerdere protocollen en keylengtes aan, en de client pakt de sterkste van de set die hij ook ondersteunt. Het probleem is echter dat in deze initialisatiefase de communicatie nog volledig MITM-baar is. Een aanvaller kan zonder al te veel moeite de client vertellen dat de server alleen DES+MD4 ondersteunt, waarna een client geforceerd is dat te gebruiken als hij verder wil communiceren. Als de client dat probeert, en de server weigert vervolgens de connectie door zijn configuratie, kan de aanvaller tenminste de data niet aftappen. Dit is dus de zwakheid die nog altijd in communicatie zit: beschikbaarheid valt uit te schakelen. (Vertrouwelijkheid, integriteit en beschikbaarheid zijn de drie basiselementen van informatieveiligheid. Vertrouwelijkheid wordt gewaarborgd door de encryptie en integriteit door het MAC-systeem dat SSL/TLS gebruikt. En dan heb ik het over een Message Authentication Code, niet een Macintosh.)

Idem dito voor de client overigens, maar nagenoeg niemand verandert deze instellingen. De client kan ook de verbinding weigeren bij configuraties die te zwak zijn of bekend zijn een lek te hebben (TLS compressie maakt bijvoorbeeld de CRIME-aanval mogelijk door de manier waarop lz77 werkt in combinatie met een chosen-plaintext aanval).

Misschien nog eens een artikeltje over schrijven, ik merk dat er veel uitvloeit als ik eenmaal begin over SSL. Kan ook iets te maken hebben met dat ik een keer in een tijdschrift heb gestaan over dit onderwerp :P

Sorry hoor. Maar Google encrypt het alléén tijdens het transport van de data. Zodra het bij hen staat, is het natuurlijk weer leesbaar. M.a.w. ze encrypten het zodat in ieder geval niemand anders de data kan lezen die zij zo graag voor zichzelf houden.
Als je Google vertrouwt, is dit een goede maatregel, want je zorgt ervoor dat anderen er niet zo gemakkelijk aan kunnen komen.
Als je Google niet vertrouwt, blijft je probleem even groot als daarvoor.
M.a.w. Wil je dat Google al jouw data ziet? Zo niet, gebruik dan gewoon geen Google services, of het encrypted is of niet.

Inderdaad. Op de schaal van google (qua aantallen clients) speelt dat natuurlijk aan de server/front-end kant.
Ook met hardware accelerators is er een vrije lage grens aan het aantal sessie-setups per seconde (waar de RSA encryptie gebeurt) dat een device aankan.


Wat me nou behoorlijk ergert is dat een prima doordachte post als bovenstaand twee minnen krijgt.

Wat een enorm gebrek aan clue bewijzen die minklikkers; Ik zou eigenlijk hopen op een model waarbij onterechte afwaardering ook leidt tot het afwaarderen van het 'min-vermogen' van een poster.
Kortom, als je gebrek aan onderscheidingsvermogen demonstreert, dat je opinie in het vervolg ook minder of niet meetelt.

Bedankt, ik vroeg me inderdaad al af wat er mis was met mijn post. Misschien klopt er iets niet, maar mensen reageerden ook niet dus ik wist het niet...