Laten we eerst kijken naar de kwetsbaarheid zelf. Dat is een man-in-the-middle aanval, waarbij een aanvaller een SSL mogelijkheid kan gebruiken die 'negotiation' heet om kwaadaardige code te injecteren in een SSL sessie. Dat lijkt me geen goed nieuws, maar het is ook niet echt het einde van de wereld, dus voorlopig kunnen we kalm blijven. Laten we een en ander in perspectief plaatsen.

Oplossingen voor het probleem

Jazeker, er lijkt een serieuze kwetsbaarheid te zitten in SSL. Maar vanaf nu is die kwetsbaarheid bekend bij een relatief kleine verzameling mensen, die hard werken aan oplossingen voor het probleem. Dat gezegd hebbende, de technische details van het probleem zijn gepubliceerd, wat betekent dat de aanvallen ook ongetwijfeld zullen komen.

Maar het valt helemaal niet mee om een effectieve man-in-the-middle aanval uit te voeren. De aanvaller moet op hetzelfde lokale netwerk zitten als de gebruiker, of in het netwerkpad tussen de gebruiker en de server. Veruit de meest waarschijnlijke van deze scenario's, op korte termijn tenminste, is de aanval op een lokaal netwerk. En daar hebben we zelf ook wat over te zeggen.

Om te beginnen zouden we veilige VPN's moeten gebruiken om te verbinden met vertrouwde netwerken, zeker als we gebruik maken van netwerken die we niet zomaar kunnen vertrouwen, zoals netwerken van hotels en Wi-Fi hotspots op terrasjes. VPN's zijn redelijk algemeen, zelfs voor kleine bedrijven.

En ik heb al vermeld dat er een aantal mensen hard werkt aan oplossingen voor dit probleem. Het zou me verbazen als we in de nabije toekomst geen patches voor SSL tegemoet kunnen zien. In ieder geval aan de serverkant zouden die binnenkort beschikbaar moeten komen. Voor ons wordt het een echte uitdaging om die patches op onze productie-systemen te krijgen, maar dat is nu eenmaal ons werk, toch?

Grotere kwestie

Dus nee, het is niet het einde van de wereld. Er ligt een flink mankement op de loer ergens aan de horizon, en daar moeten we allemaal zeker voldoende aandacht aan besteden. Maar op dit moment hebben we nog geen aanvallen gezien in het wild, of zelfs maar proof-of-concept code.

Toch staan er hier grotere kwesties op het spel. Laten we daar eens wat beter naar kijken om te zien wat we er van kunnen leren.

SSL is vandaag de dag een belangrijk onderdeel van onze beveiligingsinfrastructuur. Iedereen die bedreigingen in kaart brengt of een beveiligingssysteem ontwerpt, zal bevestigen dat SSL een belangrijk onderdeel is in de beveiliging, waar alle andere componenten op verder bouwen. Als we onze systemen bouwen bovenop andere componenten, dan moeten we die afhankelijkheden begrijpen en weten welke impact ze hebben op onze systemen. Wat mij betreft is een mooi startpunt daarvoor om te kijken naar het ontwerp van een systeem en om daarin de meest waardevolle componenten te identificeren, vanuit het standpunt van de aanvaller, wel te verstaan.

Waardevolle doelwitten zijn vaak componenten zoals infrastructuur afhankelijkheden, authenticators, input validatoren, output encoders, access control mechanismen en belangrijke business logic. Het leeuwendeel van onze aandacht moet dan ook uitgaan naar het testen op beveiliging van die waardevolle doelen.

Een infrastructuur afhankelijkheid, zoals SSL, is heel interessant, omdat we in de meeste gevallen met een SSL implementatie werken van een derde partij, die we niet makkelijk kunnen beïnvloeden. We zouden code van derde partijen altijd rigoureus moeten testen op beveiliging – fuzzing zou ik bijna zeggen – zeker als de veiligheid van onze eigen applicaties afhangt van de correcte werking van die code.

Maar SSL is echt infrastructuur, toch? Wie is daar de baas, en hoe is er getest op die infrastructuurcode en -ontwerp? Zou deze fout met rigoureus testen eerder zijn ontdekt? Misschien, misschien niet. (En zelf zou ik mijn geld niet op 'misschien' zetten)

Keuzes en vergissingen

Dus waar staan we dan met SSL? Net als bij het selecteren van een standaard encryptie algorithme – SSL is een protocol, geen algorthme – moet de selectie heel voorzichtig en met overleg worden aangepakt en moet er om de zoveel tijd nog eens naar gekeken worden. In dat selectieproces moet rigoureus, extern en onafhankelijk worden beoordeeld en getest. Vergissingen die hier worden gemaakt worden immers verveelvoudigd over alle software die bovenop deze componenten worden gebouwd.

Ik probeer hier niet geringschattend te doen over de mensen die SSL ontwikkelen, maar ik denk dat de fouten die nu boven water komen het belang in de schijnwerpers zetten van de aandacht die moet worden besteed aan de selectie en implementatie van code waar zoveel van afhangt

Natuurlijk had niemand kunnen voorspellen hoe belangrijk SSL zou worden, toen het voor het eerst werd ontworpen. Maar die verkeerde inschatting is nu duidelijk geen excuus meer. De tijd is gekomen om terug te kijken, om onze aannames te herzien en om te repareren wat kapot is. Ik durf er wat om te verwedden dat deze laatste kwetsbaarheid in SSL niet de allerlaatste is.

Bron: Techworld