Hou de NSA buiten met Perfect Forward Secrecy

SSL-encryptie is tegenwoordig overal aanwezig, zodat je bijna zou geloven dat het onfeilbaar is. Enkele maanden geleden heeft de Heartbleed-bug reeds het tegendeel bewezen, maar dat is niet het enige gevaar. We weten dat de NSA op grote schaal encrypted traffic verzamelt, in de hoop dit achteraf te kunnen ontcijferen. Dankzij Perfect Forward Secrecy kun je je daartegen wapenen.

 

De meeste computergebruikers kennen SSL enkel van de https://-websites. Uiteraard ondersteunen ook andere protocols SSL-encryptie (denk maar aan IMAPS, SMTPS of FTPS), maar die laten we hier in dit artikel buiten beschouwing.

De bedoeling van HTTPS is tweeledig: vermijden dat vertrouwelijke informatie door derden kan worden afgeluisterd én verzekeren dat de client met de juiste server communiceert. Dat laatste is net zo belangrijk als het eerste. Wat voor zin heeft het immers dat de verbinding tussen jouw PC en een internetbankieren-website geëncrypteerd is als je in feite verbonden bent met de server van een oplichter? De client (de webbrowser) moet dus op één of andere manier de identiteit van de server controleren. Authenticatie in omgekeerde richting is overigens ook mogelijk: de webserver controleert dan de identiteit van de client. In Belgiëwordt dat bijvoorbeeld gebruikt bij de online belastingaangifte Tax-On-Web. De elektronische identiteitskaart bevat jouw public/private keypair. Dat wordt (na het ingeven van je PIN-code) in je webbrowser geladen via een smartcard reader. De browser presenteert het certificaat tenslotte aan de webserver en die controleert of het geldig is.

Certificate Authorities

 

In de huidige SSL-implementaties spelen zogenaamde Certificate Authorities of CA’s een centrale rol. Zodra je browser een beveiligde verbinding probeert op te zetten met een webserver, presenteert die laatste zijn certificaat. Dat bevat onder andere de identiteit van de webserver (Subject), de CA die die identiteit heeft gecontroleerd (Issuer), de public key van de webserver en een digitale handtekening van het certificaat (Certificate Signature). De digitale handtekening is een hash van de certificaatinformatie, die vervolgens versleuteld is met de private key van de CA. De CA stelt zich dus garant voor de identiteit van de webserver. Wie bij een CA een certificaat aanvraagt voor paypal.com zal dus eerst moeten bewijzen dat hij effectief in opdracht handelt van Paypal. Op die manier is het onmogelijk om een certificaat te bemachtigen voor een domeinnaam die je niet beheert.

 

Je webbrowser kan de digitale handtekening van het certificaat decrypten met de public key van de CA. De public keys van een aantal vertrouwde CA’s zijn immers voorgeïnstalleerd in alle browsers. Daarna berekent je browser zelf een hash van het certificaat en vergelijkt die met de zojuist gedecrypte digitale handtekening. Het certificaat is enkel geldig als beide hashes overeenkomen. Is dat niet het geval, dan heb je zeer waarschijnlijk te maken met een vervalst certificaat en ben je niet verbonden met de correcte server! Je browser toont dan een waarschuwing en verbreekt meteen de verbinding. Hoewel het huidige systeem van Certificate Authorities behoorlijk goed werkt, is het niet geheel waterdicht. Hackers hebben in het verleden meerdere malen de private keys van een CA bemachtigd, waardoor ze vervalste (maar geldige!) certificaten konden aanmaken. Op die problematiek gaan we hier niet verder in.

 

Algoritmes

 

Het opzetten van een beveiligde verbinding (de zogenaamde TLS handshake) omvat meer dan enkel de controle van het servercertificaat. Om te beginnen geeft de client aan welke TLS-versies, cipher suites en compressiemethodes hij ondersteunt. De server kiest daaruit de meeste veilige opties, die hij zelf ondersteunt en communiceert de gekozen opties aan de client, samen met zijn certificaat. Tot hiertoe verloopt alle communicatie unencrypted. In de volgende stap gebruikt de client de public key van de server om data te versleutelen. Public/private-key encryptie is een vorm van asymmetrische encryptie: data encrypted door de public key kan enkel decrypted worden door de private key en vice versa. Dergelijke encryptievormen zijn echter behoorlijk rekenintensief en dus ongeschikt voor grote hoeveelheden data. Daarom genereert de client een zogenaamd PreMasterSecret, dat de client encrypted verstuurt naar de server. Zowel de server als de client berekenen op basis van dat PreMasterSecret eenzelfde MasterSecret. Daaruit wordt een key voor symmetrische encryptie afgeleid (de session key) waarmee de TLS-verbinding vervolgens wordt versleuteld. Dit proces is de zogenaamde key exchange.

 

Cipher suite

 

Een cipher suite is een combinatie van algoritmes, die gebruikt worden in verschillende stadia van een TLS-verbinding. We zetten die nog eens kort op een rijtje:

 

1. key exchange: via asymmetrische encryptie een symmetrische key aanmaken om de data te versleutelen.

 

2. authentication: de identiteit van de server (of client) verifiëren aan de hand van het certificaat en de public key van een CA.

 

3. cipher / symmetric encryption: wordt gebruikt om de data van de TLS-verbinding te versleutelen ná de key exchange.

 

4. Message Authentication Code of MAC: een hash encrypted met een symmetrische key, om te controleren of de verzonden data wel correct is ontvangen.

 

In Firefox controleer je als volgt de gebruikte cipher suite van een SSL-verbinding: klik op het grijze slotje naast https:// in de URL-balk en kies More Information…. Onder Technical Details krijg je nu zowel een algemene omschrijving van de cipher suite te zien (bijvoorbeeld High-grade Encryption) als de precieze algoritmes (bijvoorbeeld TLS_RSA_WITH_RC4_128_SHA, 128 bit keys). Dat betekent dat de key exchange en authentication via RSA verlopen, de cipher RC4 met een key van 128 bits is en voor message authentication SHA(-1) wordt gebruikt.

SSL kraken?

 

Alles welbeschouwd is SSL behoorlijk veilig, al is geen enkele beveiliging 100% sluitend. Zo bevatten oudere versies (met name SSL versie 2) nog een aantal kwetsbaarheden. Maar ook bepaalde ciphers bleken na verloop van tijd toch niet zo veilig te zijn als men dacht. Dat zijn zaken die server administrators in het achterhoofd moeten houden: we gaan verderop in dit artikel nog wat dieper in op die materie. Een ander gevaar zijn man-in-the-middle (of MITM) attacks, waarbij een aanvaller zich tussen jouw browser en de webserver nestelt. Een succesvolle MITM-attack verloopt echter zelden onopgemerkt. De aanvallers gebruiken immers een vervalst certificaat, tenzij ze een CA gehackt hebben of op één of andere manier de lijst van vertrouwde CA’s op jouw computer hebben aangepast. En dan is er natuurlijk nog Heartbleed, een bug in OpenSSL die de SSL-encryptie op grote delen van het internet potentieel waardeloos maakte. Het is nog steeds niet duidelijk of er op grote schaal misbruik is gemaakt van die bug, al zijn de meeste servers intussen wel gepatcht. Maar in dit artikel concentreren we ons dus op een andere, veel subtielere kwetsbaarheid: het gebrek aan Forward Secrecy in de meeste SSL-implementaties.

 

Forward secrecy

 

Het is geen geheim meer dat de NSA het internetverkeer op grote schaal afluistert. Minder bekend is het feit dat men ook versleuteld verkeer bijhoudt. Op het eerste gezicht lijkt dat niet erg nuttig, maar blijkbaar denkt de NSA daar anders over! Je hoeft nu niet meteen te vrezen dat populaire encryptie-algoritmes via cryptanalyse gekraakt zullen worden. In realiteit is het veel eenvoudiger voor de NSA om HTTPS-verkeer te ontcijferen. Hoe kan dat nou? We zagen hierboven reeds dat de eigenlijke TLS-verbinding wordt versleuteld met een symmetrische, tijdelijke key: de session key. Maar die is wel afgeleid van het PreMasterSecret dat de client aan de server bezorgt tijdens de key exchange. En de key exchange werd beveiligd door de public key van de server. Met andere woorden: als je de private key van de server bemachtigt, kan je de key exchange decrypten. Dat geeft je het PreMasterSecret, waaruit je alle gebruikte sessions keys kunt afleiden. Oftewel: met de private key kun je niet enkel toekomstige verbindingen ontcijferen, maar ook SSL-encrypted data uit het verleden! Snap je nu waarom de NSA ook die data bijhoudt?

 

Hoe groot is nou de kans dat de private key in de toekomst in de verkeerde handen komt? Dat is moeilijk te zeggen, maar ondenkbaar is het zeker niet. Misschien is de server die de key bevat niet voldoende beveiligd. Of is de key eenvoudig te terug te halen uit een back-up? Misschien wordt iemand omgekocht om de key te bemachtigen? Of nog erger, misschien kan men in de toekomst zelfs van rechtswege gedwongen worden de key prijs te geven? Gelukkig bestaan er ook key exchange algoritmes, die niet aan bovenstaand euvel lijden. In dat geval spreken we eigenlijk meer over key generation algoritmes. De session keys worden immers niet meer rechtstreeks uitgewisseld. Momenteel zijn er twee van zulke algoritmes beschikbaar: ephemeral Diffie-Hellman (DHE) en ephemeral Elliptic Curve Diffie-Hellman (ECDHE). Die algoritmes berekenen het Master Secret (en zodoende de session keys) volledig onafhankelijk aan client- en serverzijde. Dat gebeurt deels op basis van publiek toegankelijke informatie (die client en server unencrypted uitwisselen) en deels op basis van informatie die enkel bekend is bij de client of de server. De public key van de server dient uitsluitend voor authenticatie en wordt op geen enkele manier gebruikt om de session key aan te maken. Zodoende is de private key ook waardeloos om achteraf SSL-versleutelde data te ontcijferen. In de cryptografie noemt men dat fenomeen Forward Secrecy of – iets ambitieuzer – Perfect Forward Secrecy.

 

PFS in de praktijk

 

SSL-verbindingen zonder Perfect Forward Secrecy kunnen we vandaag de dag gerust als onveilig beschouwen. Het is in de praktijk niet erg moeilijk (zeker niet voor mastodonten als de NSA) om dergelijke verbindingen af te luisteren. Werk je met erg vertrouwelijke informatie en wil je die zo goed mogelijk beschermen? Vermijd dan (indien mogelijk) servers die geen PFS ondersteunen. Op zoek naar een nieuwe provider voor je mailbox of cloud storage? Controleer dan eerst of de webservers wel PFS ondersteunen! Helaas is Perfect Forward Secrecy niet eenzijdig afdwingbaar langs de client- of serverkant. Zowel de client als de server moeten de vereiste key generation algoritmes ondersteunen. Bovendien moeten ze ook nog overeenkomen dat één van de algoritmes, die forward secrecy garanderen, ook de beste keuze is. Het is immers goed mogelijk dat beide partijen wel PFS ondersteunen, maar dat de server alsnog een ander algoritme verkiest. Er bestaan verschillende online tools om te controleren welke cipher suites browsers en webservers ondersteunen, onder andere van DCSec (voor browsers: http://bit.ly/JzIq20), Paranoid Security (voor webservers: http://bit.ly/1nLzyZu) of SSL Labs (voor browsers: http://bit.ly/1ha5PCq, voor webservers: http://bit.ly/1hwwzSp). 

In afbeelding 1 kon je zien hoe je in Firefox de gebruikte cipher suite voor een bepaalde website opzoekt. Helaas is Firefox nogal optimistisch en spreekt het zelfs van High-grade Encryption zonder PFS of met oudere, onveilige ciphers. Wil je in één oogopslag controleren hoe veilig een bepaalde SSL-verbinding nu écht is? Installeer dan de Firefox add-on “Calomel SSL Validation”. Die voegt een extra icoontje toe vóór de URL-balk met een kleurcode: grijs voor unencrypted, rood voor een erg zwakke SSL-beveiliging, geel voor een aanvaardbare beveiliging, blauw voor een sterke beveiliging en groen voor échte high grade encryption.  Een klik op dat icoontje toont je meteen of PFS ondersteund wordt of niet, samen met gedetailleerde informatie over de cipher suite, het certificaat, enzovoorts. Wat ons betreft een absolute aanrader!

Apache en PFS

Momenteel implementeert slechts een kleine minderheid van de webservers Perfect Forward Secrecy (zie kader “SSL Pulse”). Beheer je zelf een Apache-webserver? Dan moet je mogelijk nog enkele configuratiewijzigingen doorvoeren om Perfect Forward Secrecy te activeren. De key generation moet immers bij voorkeur via het DHE- of ECDHE-algoritme verlopen. Helaas wordt geen van beide algoritmes door alle bekende webbrowsers ondersteund. Zo kan Internet Explorer niet overweg met DHE, terwijl andere (voornamelijk oudere) clients geen ECDHE ondersteunen. Je kunt dus het beste beide algoritmes aanbieden. DHE is trager dan ECDHE, maar aan de andere kant hebben een aantal cryptografen hun twijfels bij de betrouwbaarheid van ECDHE. Kort gezegd hangt de betrouwbaarheid van elliptic curve cryptography sterk af van de keuze van een aantal essentiële parameters. De parameters in kwestie blijken nu door de NSA gekozen te zijn. Bovendien is het onduidelijk hoe zij precies tot die parameters gekomen zijn. In theorie is het dus mogelijk dat de NSA de algoritmes voor elliptic curve cryptography met opzet verzwakt heeft en er dus een backdoor aanwezig is in ECDHE. Om die reden kun je misschien toch beter kiezen voor DHE in plaats van ECDHE voor clients, die beide algoritmes ondersteunen.

 

 

 

In afbeelding 4 zie je hoe je de SSL cipher suites in Apache configureert. Die directives vind je in mod_ssl’s configuratiebestand, bijvoorbeeld /etc/apache2/mods-available/ssl.conf in Debian/Ubuntu of /etc/httpd/conf.d/ssl.conf in RHEL/CentOS. Dit is de standaard Speed-optimized SSL Cipher configuration zonder Perfect Forward Secrecy, maar dat lossen we straks op. Belangrijk is ook de SSLHonorCipherOrder-optie. Die zorgt ervoor dat Apache uit de opgegeven lijst de eerste cipher suite kiest die de client ondersteunt. Om PFS in te schakelen moet je dus alle mogelijke cipher suites met (EC)DHE vooraan plaatsen. Ondersteuning voor ECDHE is echter relatief recent toegevoegd aan Apache, namelijk in versies 2.2.26 en 2.4.0. Daardoor vallen verschillende oudere distributies buiten de boot, onder andere RHEL 6, Ubuntu 12.04 en Debian 7. In die distributies kun je dus enkel DHE aanbieden, waardoor gebruikers van Internet Explorer geen Perfect Forward Secrecy krijgen.

 

Kwetsbaarheden

 

De hamvraag is nu natuurlijk welke cipher suites je moet aanbieden om de SSL-verbinding zo goed mogelijk te beveiligen én de compatibiliteit met oudere clients te garanderen. Daarbij gaat het niet alleen over het al dan niet ondersteunen van Perfect Forward Secrect. Zo zijn er de afgelopen jaren in verschillende algoritmes kwetsbaarheden naar boven gekomen. In de praktijk zijn die niet allemaal even gemakkelijk uit te buiten. Toch kan het geen kwaad om er rekening mee te houden bij Apache’s SSL-configuratie. We sommen er enkele op:

 

–      CRIME / TLS compression: specifiek gericht op verbindingen met TLS-compressie. De enige oplossing is TLS-compressie volledig uit te schakelen op de server.

 

–      BREACH: gelijkwaardig aan CRIME, maar ditmaal voor een aantal specifieke gevallen met HTTP-compressie. Op te lossen door HTTP-compressie (in Apache verzorgd door mod_deflate) uit te schakelen.

 

–      BEAST: lange tijd was dit een theoretische kwetsbaarheid, die als praktisch onbruikbaar werd beschouwd. De kwetsbaarheid werd opgelost in TLS 1.1, maar in 2011 bleek die toch succesvol te zijn met CBC-ciphers (bijvoorbeeld AES) in oudere SSL-versies, zoals TLS 1.0. Intussen ondersteunen de meest recente browsers wel TLS 1.1 of hoger. Als oplossing werd aangeraden om de RC4-cipher te gebruiken in plaats van AES. Ook browsers implementeerden work-arounds.

 

– RC4: helaas bleek het RC4-algoritme in 2013 ook een aantal kwetsbaarheden te bevatten. Hoewel daarvoor nog geen praktische implementaties bekend zijn, geeft het toch aan dat RC4 langzaamaan aan vervanging toe is. Intussen wordt het risico van de RC4-kwetsbaarheid hoger ingeschat dan BEAST. De BEAST work-around uit 2011 kun je dus beter niet meer gebruiken.

 

Best practices

 

Zie je na bovenstaande uitleg door de bomen het bos niet meer? Geen paniek, want er zijn verschillende “best practices” beschikbaar voor een correcte SSL-implementatie. Een interessant vertrekpunt is SSL Labs’ “SSL/TLS Deployment Best Practices” (http://bit.ly/1nkv5tF). Dit beknopte document bevat een aantal algemene richtlijnen in verband met private keys, certificaten, protocols, cipher suites, enzovoorts. Concrete richtlijnen voor bijvoorbeeld Apache vind je er niet in. Daarvoor verwijzen we je naar Mozilla’s Wiki. De ontwikkelaars van Mozilla weten natuurlijk wel het één en ander over SSL. Hun bevindingen hebben ze samengevat in het uitstekende document “Server Side TLS” (http://mzl.la/Uew3xY). Daarin leggen ze haarfijn uit welke ciphers volgens de laatste stand van zaken de beste beveiliging bieden. Maar er is ook gedacht aan compatibiliteit met oudere clients. Mozilla’s aanbevolen instellingen voor Apache zie in je afbeelding 5. Ook het Better Crypto-project heeft een interessante handleiding geschreven over SSL-encryptie (http://bit.ly/1hXclwX). Het is een samenwerking van een 25-tal experts op gebied van SSL en is vooral bedoeld als praktische implementatiegids voor systeembeheerders. Niet alleen webservers zoals Apache passeren de revue, maar ook software zoals Postfix, Dovecot, OpenVPN, OpenSSH, Squid, MySQL, ejabberd, enzovoorts. Het document is een work-in-progress waaraan iedereen kan meewerken. Het grootste verschil met Mozilla’s richtlijnen is dat SSLv3 wordt uitgeschakeld en ook de cipherselectie ziet er iets anders uit.

 

 

 

 

Met de eerder aangehaalde SSL Server Test van SSL Labs (http://bit.ly/1hwwzSp) test je het effect van de wijzigingen. Vul gewoon de hostname in van jouw server en klik op Submit. Twee minuten later krijg je een uitgebreid rapport van jouw SSL-implementatie. In afbeelding 6 zie je enkele resultaten uit het rapport van een server met Apache 2.2.22 met Mozilla’s aanbevolen configuratie. Globaal gezien scoren we een A-, wat zeker niet slecht is. Volgens het laatste rapport van SSL Pulse scoren we daarmee even goed als ongeveer 22% van de SSL-websites. Nog geen 8% scoort beter en ruim 70% scoort slechter. We hebben vooral strafpunten gekregen, omdat onze Apache-versie nog geen ECDHE ondersteunt. Er is dus geen Perfect Forward Secrecy voor Internet Explorer-gebruikers. Bovendien vallen IE6 en IE8 op Windows XP terug op het onveilige RC4-algoritme. Voor de overige browsers is er geen probleem. Dat alles vind je in één oogopslag terug in het onderdeel Handshake Simulation (zie afbeelding 7). Een tweede test met de aanbevolen instellingen van Better Crypto resulteerde wederom in een A- en een gebrek aan PFS in Internet Explorer. De RC4-kwetsbaarheid is nu weliswaar opgelost, maar dat gaat ten koste van Windows XP-gebruikers met Internet Explorer. Zij kunnen onze SSL-website nu immers niet meer openen! Voor een betere score moeten we echt upgraden naar Apache 2.2.26/2.4 of hoger.

 

 

 

 

Betere encryptie

 

Niet alle SSL-servers zijn even goed beveiligd. Vooral het gebrek aan Perfect Forward Secrecy vormt een risico voor wie bezorgd is om de NSA-afluisterpraktijken. Zonder PFS kan beveiligde data immers nog jaren na datum ontcijferd worden met de juiste private key. Met de Calomel add-on voor Firefox zie je meteen welke SSL-websites goed beveiligd zijn en welke niet. En dankzij de tools van SSL Labs en de documentatie van Mozilla en Better Crypto is het niet erg moeilijk om je eigen webserver correct te configureren. Op alle platformen ondersteunen de nieuwste browsers wel één of andere vorm van Perfect Forward Secrecy. Het is alleen jammer dat Apache 2.2 slechts vanaf versie 2.2.26 PFS kan aanbieden aan Internet Explorer-gebruikers.