Google-onderzoekers vinden ernstig lek in oude ssl-versie - update

is het vooral een probleem met oude IE gebruikers

plus browsers die kwetsbaar zijn voor een downgrade aanval. Dat is namelijk wat deze lek zo ernstig maakt. Google Chrome is kwetsbaar vandaar het Google bericht. Echter Internet Explorer (wanneer draaiend op Vista of hoger!) is bijvoorbeeld niet kwetsbaar, ook al zou je SSL 3.0 aan laten staan.

Een moderen browser zal immers ongeacht of het SSL 3.0 ondersteunt normaal een TLS 1.x variant gebruiken. Google heeft echter met de beste bedoelingen een downgrade mechanism ingevoerd als de connectie faalt. Dit was omdat vroege TLS 1.2 implementaties buggy waren. Gevolg is dat een MITM-aanvaller enkel de connectie van Google Chrome met een server hoeft te verstoren, en de browser probeert opnieuw met TLSA 1.1. De anvaller verstoort het opnieuw, etc en zo kun je een moderne Chrome dwingen op SSL 3.0 te gaan verbinden.

Internet Explorer is hiervoor niet kwetsbaar. Firefox geloof ik weer wel.

Het was al langer bekend dat Google hier een potentieel veiligheidslek had, maar tot nu toe was er geen bekende methode om dit te misbruiken.

Overigens is er dan nog geen panniek, want deze POODLE attack is eigenlijk enkel bruikbaar in combinatie met encrypted cookies. Een gewone connectie met je bank, zelfs over SSL 3.0, is in principe veilig. Dit omdat de aanval simplistisch gesteld als volgt gaat:

- aanvaller plaatst zich tussen jou en de server
- aanvaller verstoort indien nodig de TLS handshake en dwing een SSL 3.0 connectie af
- aanvaller hoopt dat er een CBC cypher gebruikt wordt en geen RC4. Anders faalt de aanval. (Maar RC4 is weer kwetsbaar voor een andere aanval.)
- aanvaller onderschept het cookie (wat hij niet kan lezen), en vervangt enkele bytes, en stuurt deze door naar de server
- aanvaller kijkt naar de het gedrag van de server en hoopt dat er een merbaar verschil is tussen een correct gedecodeerd cookie en corrupt cookie. Zo ja, heeft hij 1 byte kunnen decrypten.
- herhaal de vorige stap met een andere stukje vervangen data in het cookie tot je het hele cookie ontsleuteld hebt.

Het is een beetje een technisch verhaal, maar CBC cyphers gebruiken vaste blok-grootes. Als de data die je wilt encrypten kleiner is, vult hij het op met 'padding'. Omdat in SSL 3 er geen afspraken zijn over hoe dat moet, kan een ontvanger niet controleren of de padding correct is. De ontvanger kan enkel controleren of de decryptie lukt.

Een aanvaller kan met enige gericht gokken proberen het laatst blokje zo te vervangen dat de decodering lukt omdat het aantal padding bytes correct is. De aanvaller is er dan nog lang niet, maar er lekt zo wel informatie waarmee men misschien verder kan gaan. Echter 'misschien' kunnen decoderen is eng genoeg om geen risico te willen nemen.

Bij TLS 1.0 en hoger is de paddig beter definieerd en faalt deze aanval daarom.


Het advies SSL 3.0 uitzetten is overigens verder een goed advies. In draai zelf zo al ruim een jaar en heb nog maar 2 sites gevonden die SSL 3.0 nodig hadden. Bij IE kun je dan tijdens 'runtime' SSL 3 even aanzetten, die site bezoeken in een apart tabje, en dan weer uitzetten. Firefox (config optie) en Chrome (command line) is wat lastiger omdat het de browser restarten vereist, maar ook dat is waarschijnlijk niet zo vreselijk problematisch.