De firma Networking4All beschrijft op zijn site de resultaten van een onderzoek naar de SSL-beveiliging van een aantal overheidssites en komt dan tot de conclusie dat ruim 80% daarvan onveilig is. Networking4all biedt ook de mogelijkheid om zelf de SSL-beveiliging van een website te controleren middels een tool die beschikbaar op hun website isdezesiteveilig.nl. Veel websites scoren als niet ‘veilig’ op basis van één van de testen die door Networking4All wordt aangeven met ‘Geen verbindings upgrade naar 128-bit voor oude browsers’.

Met de genoemde Networking4All test wordt gecontroleerd of de website in kwestie ‘sterke’ cryptografie ondersteunt in de hypothetische situatie dat een internet browser wordt gebruikt die uit de jaren ’90 van de vorige eeuw komt. Dergelijke internetbrowsers waren namelijk uitgerust met zwakke cryptografie (eufemistisch ‘Export grade’ genoemd) die standaard niet meer dan 40 bit versleuteling boden, hetgeen geen echte beveiliging biedt. Dit was het gevolg van de toenmalige Amerikaanse exportwetgeving (ITAR). Om in die tijd bepaalde partijen, met name banken, toch de mogelijkheid te bieden om sterke cryptografie (in het jargon 128 bits) te bieden konden deze partijen – met toestemming van de Amerikaanse overheid – speciale SSL server certificaten kopen. De browsers lieten bij het gebruik van dergelijke servercertifcaten wel toe dat sterke cryptografie werd toegepast.

Verouderde test

Een eerste kritiekpunt op de test is dat deze nogal hypothetisch is: een gebruiker die een browser uit de jaren ’90 van de vorige eeuw gebruikt is tenslotte nogal onwaarschijnlijk. Daarbij heeft zo’n gebruiker grotere beveiligingsproblemen te vrezen dan zijn cryptografische SSL beveiliging. Immers, sinds de jaren '90 zijn ettelijke grote applicatieve ‘exploits’ bekend geworden. De genoemde test van Networking4All is daarom op zijn zachtst gezegd nogal merkwaardig te noemen. Het is alsof je een leger afkeurt omdat ze niet goed weten hoe ze met pre-historische wapens moeten omgaan. Om op basis van deze test een websites als niet veilig te verklaren lijkt mij niet redelijk.

Nog ernstiger is dat de Networking4All test niet juist is. Wat mijns inziens namelijk getest moet worden is of de site in kwestie überhaupt zwakke cryptografie toelaat en niet of deze middels een upgrade van zwakke naar sterke versleuteling mogelijk maakt. Anders gezegd: een site die ‘slaagt’ voor de upgrade test kan toch nog een gebruiker voorzien van een zwakke beveiligde bevinding, bijvoorbeeld omdat de webbrowser een te lage SSL-beveiligingsinstelling heeft toegepast.

Beheerder is verantwoordelijk

Om dit iets duidelijker te maken, is een rudimentair begrip van de opbouw van een SSL verbinding noodzakelijk. Voordat de SSL-sessie tot stand komt, geeft de browser (‘client’ in SSL jargon) aan de webserver een lijst met de cryptografische protocollen (inclusief sleutellengten) die hij allemaal ondersteunt. De browser kan bijvoorbeeld zeggen: ik ondersteun ‘AES128-SHA’ en ‘DES-CBC-SHA’ oftewel 128 bit AES en 56 bit DES. De webserver kiest dan vervolgens de ‘sterkste’ cryptografie die de client aangeeft te kunnen ondersteunen én die hij zelf ook ondersteunt.

Als de server bijvoorbeeld ‘AES128-SHA’ ondersteunt en EXP-RC4-MD5 (40 bits RC4) dan zal de server gebruik gaan maken van AES128-SHA in het voorbeeld. De praktijk is overigens dat de browser niet zo kieskeurig is en alles behalve geen versleuteling (‘NULL’) accepteert. En waar het nou om gaat is wat de SSL-server accepteert. In de server met SSL-configuratie kan (en mijn inziens moet) de beheerder minimale eisen hebben ingesteld: als de browser aan de minimale eisen van de webserver kan voldoen, wordt er geen SSL-tunnel opgebouwd. Of in andere woorden: de gebruiker kan dan geen gebruik maken van de applicatie.

Internet Explorer

Als de webserver niet kieskeurig is en ook alles accepteert behalve geen versleuteling (‘NULL’) dan ontstaat een kwetsbaarheid. Immers als de SSL-beveiligingsinstelling van de browser op 40 bits versleuteling is ingesteld, dan zal de webserver altijd komen tot een zwakke (40 bits) SSL connectie tussen browser en server. Een dergelijke instelling kan een (vreemde) configuratiefout zijn maar kan ook een ‘aanval’ van een tegenstander zijn. De tegenstander is op die manier toch in staat de ‘versleutelde’ SSL-verbindingen te lezen; terwijl de gebruiker toch steeds ‘gele SSL-slotjes’ ziet. Het aanpassen van de Internet Explorer configuratie is in Windows erg eenvoudig en bestaat uit het aanpassen van een paar registry settings (HLM/SYSTEM/CurrentControlSet/Control/SecurityProviders/SCHANNEL/Ciphers) die waarschijnlijk niet zullen opvallen bij de meeste security scanners (Windows defender constateert het bijvoorbeeld niet).

Ik heb mijn browser zodanig aangepast zodat hij alleen 40 bits versleuteling ondersteunt en de eerste site waar ik mijn browser op heb gericht is die van Networking4All zelf. Dan blijkt dat het beveiligde gedeelde van die site gewoon nog werkt zoals ook uit onderstaande screendump blijkt. Uit het slotje blijkt ook dat er inderdaad maar 40 bits versleuteling actief is. Met andere woorden, de SSL configuratie van Networking4All is zelf ‘onveilig’!

Banken zijn veilig

Uiteraard heb ik veel meer websites bezocht waarbij tot mijn verbazing toch de meeste van de bezochte websites niet voldeden aan de ‘juiste’ test, dat wil zeggen dat zij toch 40-bits versleuteling ondersteunden. Ik denk niet dat het constructief is om met naam en toenaam aan te geven welke websites dat waren omdat deze dan mogelijk onredelijk veel slechte publiciteit krijgen terwijl het toch een algemeen gegeven lijkt te zijn. Overigens is het gebruik van een ‘Extended Validated’ (EV) certificaat (een andere test van Networking4All) geen enkele garantie dat een website geen 40 bits versleuteling ondersteunt; ik ben ook daadwerkelijk EV-gebaseerde websites tegengekomen die 40 bits versleuteling ondersteunen.

Laat ik wel als positief nieuws aangeven dat alle grootbanken (ABN Amro, Fortis, ING, Rabo) geen 40 bits versleuteling ondersteunen! Onderstaand de website van ABN Amro na een mislukte 40 bits SSL-connectie opbouw. Helaas voldeden niet alle banken aan de ‘juiste’ test, noch alle overheden.

128 bits is minimale versleuteling

Het praktische risico van het ondersteunen van 40 bits door een website kan beperkt worden genoemd; misschien is het meer een theoretisch risico dan een werkelijk risico, hoewel dit afhankelijk is van de dreigingen die een organisatie percipieert. Hoe dan ook, dit (potentiële) risico is eenvoudig weg te nemen door een eenvoudige webserver configuratie. Daarom zou mijn suggestie zijn om deze configuratie in ieder geval toe te passen op webservers waar zich enigszins gevoelige informatie op bevindt (financiële gegevens zoals bij internetbankieren of persoonsgegevens).

Mijn suggestie zou daarbij zijn om als minimale SSL webserver eisen AES (128 bits) of Triple DES (168 bits) voor de vertrouwelijkheid gecombineerd met SHA-1 voor de authenticatie/integriteit te hanteren. Dit zijn instellingen waar de grootbanken ook mee werken, dus dat lijkt mij een indicatie dat dit geen aanleiding geeft tot veel gebruikersklachten. Het gebruik van 128 bit RC2 of RC4 lijkt me niet (meer) verstandig.

Prof. dr. Eric Verheul is onderzoeker van de Security of Systems groep bij de Radboud University Nijmegen. Met dank aan ir. Gert Maneschijn CISSP, Corporate Security Officer van de RDW, voor het stellen van de vragen die tot dit artikel hebben geleid.

Bijlage: OpenSSL gebaseerde test

Als alternatief voor het aanpassen van de registry settings zodat de web browser alleen 40 bits versleuteling ondersteunt kan ook de bekende OpenSSL software (www.openssl.org) worden gebruikt. Deze software is beschikbaar voor zowel Windows als Linux. Een beveiligde website met URL U kan getest worden met de instructie:

Openssl s_client -connect U:443 -cipher EXPORT40

Als U = www.networking4all.com dan krijgt men een output waaruit blijkt dat de duiding ‘EXP’ erop wijst dat er inderdaad 40 bits versleuteling (gebaseerd op DES) wordt ondersteund.