In lekentaal is SSL een algoritme dat een bericht versleutelt tussen een ontvanger en afzender. Dit gebeurd om te voorkomen dat de verstuurde informatie wordt gelezen door een aanvaller als deze wordt onderschept tijdens verzending. Denk dan bijvoorbeeld aan vertrouwelijke gegevens zoals je gebruikersnaam en wachtwoord of bank- of creditcard gegeven en dergelijke. En die wil je niet in verkeerde handen hebben.
Op 9 november schreef Jeroen een best wel complexe (technische) TekBlog getiteld: SSL / TLS Cipher Suites…uitgelegd. Deze blogpost gaat in op de verschillende technische varianten die de encryptiewereld kent en de rol van Cyphers. In dit artikel wil ik ingaan op wat SSL in het dagelijkse leven op het web voor ons betekent.
HTTP versus https
Op het internet kun je vrij makkelijk zien of een website berichten versleuteld of niet. Een website waarvan de link begint met HTTP gebruikt géén versleuteling. Een website waarvan de link met HTTPS begint maakt daarentegen wél gebruik van versleuteling. Om SSL-versleuteling te kunnen ondersteunen heeft een website een zogenaamd SSL-certificaat nodig.
Hieronder wordt in een heel simpel plaatje weergegeven hoe versleuteling werkt
Hoe biedt een SSL-certificaat precies bescherming?
Het concept van Secure Sockets Layer (SSL) is gebaseerd op het RSA-algoritme waarbij elk SSL-certificaat bestaat uit een openbare sleutel en een persoonlijke sleutel. Bij het verzenden van een beveiligd bericht wordt de openbare sleutel gebruikt om de informatie te coderen en de privésleutel wordt vervolgens gebruikt om de informatie van de afzender te decoderen. Wanneer je browser verbinding maakt met een beveiligd domein, verzendt de server een openbare sleutel naar de browser om codering uit te voeren. De openbare sleutel is voor iedereen beschikbaar, maar de privésleutel moet geheim worden gehouden om de integriteit te kunnen garanderen. Dus, voor een veilige communicatie, versleutelt de browser het bericht met behulp van de openbare sleutel en stuurt het vervolgens naar de server. Dit bericht wordt gedecodeerd zodra de server het bericht ontvangt met de privésleutel.
Ben ik veilig als mijn site via HTTPS werkt?
Niet noodzakelijkerwijs. Zoals in Jeroen's blog wordt uitgelegd is ook de SSL / tls-configuratie van de server belangrijk. Er zijn een aantal hackmethoden en openbaar beschikbare exploits die zich richten op zwakke punten in oudere ciphers waardoor servers mogelijk kwetsbaar zijn voor degradatie, brute force-aanvallen en zelfs op afstand onthullen van gegevens.
Een van de meest bekende exploits werd in april 2014 uitgebracht en kreeg de bijnaam Heartbleed. Dit betrof de openssl 1.0.1 tot en met 1.0.1f en OpenSSL 1.0.2-bèta standaarden. Het beveiligingslek dat een aanvaller (op afstand) in staat stelt om gevoelige gegevens, zoals gebruikersnamen en wachtwoorden, alsmede geheime sleutels te onthullen. Dit lek werd veroorzaakt door wat de techies een kwetsbaarheid (vulnerability) in het SSL-protocol noemen. In simpele bewoording kwam het erop neer dat het lek werd veroorzaakt door onjuiste verwerking van het geheugen in de TLS heartbeat-extensie. Die technische beschrijving kun je weer gauw vergeten. Waar het om gaat was dat de versleuteling geen bescherming meer bood.
Enge dingen, wat nog meer?
Op het moment van schrijven van deze post zijn er een aantal cipher-zwakheden die een aanvaller in staat zouden kunnen stellen om SSL-verkeer te ontsleutelen. Deze zwakheden krijgen vaak vrij komische namen mee zoals:
Google maar eens op het woord SSL in combinatie met een van de bovenstaande namen, dan kom je ze vanzelf tegen.
Naast alle bovenstaande zwakke SSL-coderingshulpprogramma's zoals RC4, SSLv2, SSLv3, TLS 1.0 TLS 1.1 enzovoort, wordt ook SHA-1 nu ook alom beschouwd als onveilig. Als je hierover meer wilt weten lees dan: SSL / TLS Cipher Suites…uitgelegd.
Een mitm aanval in een versleutelde verbinding?
Nu wordt het weer wat technischer. Wellicht heb je wel eens gelezen dat aanvallers met een “Man in the Middle (MitM) aanval bankgegevens proberen te stelen of manipuleren. Bij een MitM aanval gaat de hacker tussen het slachtoffer en bijvoorbeeld de bank zitten. Hij vangt de communicatie uit beide richtingen op en manipuleert deze. Terwijl jij denkt dat je 100 Euro overmaakt naar je spaarrekening zorgt hij er door manipulatie voor dat er 1000 Euro naar zijn eigen rekening gaat.
Maar, banking websites werken altijd met HTTPS, dus… hoe kan dat? Hoe kan een aanvaller een MITM (Man in the Middle) aanval uitvoeren op een persoon die zich op hetzelfde netwerk bevindt terwijl er met een HTTPS website wordt gewerkt?
Voor dit doeleinde zijn er door slimme hackers een aantal z.g.n. Python-scripts geschreven. De meest bekende is waarschijnlijk wel SSLstrip, met de nieuwste versie toepasselijk genaamd SSLstrip2. Dit werkt hoofdzakelijk door de volgende methodiek te gebruiken:
Slachtoffer Aanvaller Bank
Als je goed oplet zul je zien dat je geen HTTPS verbinding met je bank hebt, en een oplettende gebruiker zal dan weten dat het fout zit. Maar veel gebruikers zullen hier overheen kijken en denken dat ze met de bank communiceren.
De eerste SSLstrip werd gestopt door de extra veiligheidsmaatregel HSTS die als het ware boven op HTTPS werd gelegd, maar SSLstrip2 ging daar weer overheen. Al die technische bla bla moet je maar weer gauw vergeten. Ik geef dit hier weer omdat het een duidelijk voorbeeld is van het kat-en-muis spel dat op het gebied van internet beveiliging continue tussen aanvallers en verdedigers plaatsvindt. En dat is vervelend voor ons als gebruikers omdat je zo eigenlijk nooit helemaal zeker zult weten of je veilig bent of niet.
Ik ben een website-eigenaar, wat kan ik doen om de sterkte van mijn SSL-configuratie te controleren?
Gelukkig zijn er een aantal tools die je kunt gebruiken. Professionals gebruiken graag zoals SSLscan, die standaard beschikbaar is in Kali Linux. Maar je kunt ook een zeer grondige en gebruiksvriendelijk gratis test online krijgen op de Qualys-website. Deze test geeft je een beoordeling van A + tot F. Je kunt de link (URL) van je eigen website gratis controleren op de volgende website:
https://www.ssllabs.com/ssltest
We hebben onze eigen website eens getest. Daar kwamen de volgende resultaten uit:
De test geeft resultaten weer voor zowel het “oude” internetprotocol IPv4 (1) als het modernere IPv6 (2) protocol. Je kunt nu ook nog de scores per protocolversie bekijken:
IPv4:
IPv6:
Gelukkig heeft hackblock.nl een “A”, er is wél enige ruimte voor verbetering maar het is zeker niet slecht.
De Qualys-tool geeft ook aanbevelingen over wat je kunt doen om de score te verbeteren, bijvoorbeeld door ervoor te zorgen dat alleen TLS 1.2 de gewenste codering is en SSLv2, SSLv3, RC4, TLS 1.0, TLS 1.1 zijn uitgeschakeld.
