SSL en verder: Ik heb SSL, wat nu?

SSL certificaten staan voor veiligheid op het internet, maar u kunt er meer mee dan u denkt. In deze nieuwe serie nemen we een kijkje achter de schermen van SSL en laten we zien hoe u uw SSL certificaat nog beter voor u kunt laten werken.  

Hoofdstuk 1: Ik heb SSL, wat nu?

Gefeliciteerd! U heeft een SSL certificaat gekocht. U heeft gekozen voor een veilig certificaat van een CA die uw organisatie heeft gevalideerd, met een key die minimaal 2048-bits is. Maar wat nu? Om te beginnen moet u controleren of u het certificaat goed heeft geïnstalleerd. De makkelijkste manier om dit te controleren is door simpelweg naar uw website te gaan via de https://-link. Als uw certificaat werkt, staat het groene slotje in de adresbalk, en kunt u de gegevens van uw certificaat bekijken door op het slotje te klikken.

ssl-en-verder-groene-slotje-in-adresbalk

Maar het kan gebeuren dat uw website niet goed op HTTPS is ingesteld. De makkelijkste manier om uw foute instellingen te achterhalen, is door een snelle scan via de SSL test van SSL Labs. De resultaten van de scan van SSL Labs kunt u gebruiken om uw serverinstellingen aan te passen. Zo wordt er gekeken of, en hoe, uw server gevoelig is voor beveiligingslekken, en of uw server nog gebruik maakt van verouderde software. Deze aanpassingen kunt u zelf doorvoeren wanneer u de eigenaar en beheerder bent van uw eigen server. Als uw website gehost wordt op een shared hosting platform, zijn deze aanpassingen helaas meestal niet door u zelf te maken. U kunt wel de partij die uw website host op de hoogte stellen van deze beveiligingsproblemen of aangeven dat software verouderd is.ssl labs

Mocht uw certificaat volgens SSL Labs goed zijn geïnstalleerd, kan het alsnog zo zijn dat uw browser een fout aangeeft in de implementatie van HTTPS. Deze kan voorkomen als u bijvoorbeeld direct doorlinkt naar een niet-beveiligde website, uw afbeeldingen worden opgehaald uit een map die buiten de HTTPS valt, of als u externe bronnen die op een HTTP locatie staan aanroept. De scanner Why No Padlock biedt hierin uitkomst: deze controleert uw code op onbeveiligde calls in plaatjes, CSS en Javascript, verlopen data van certificaten (ook die van externe partijen), en het gebruik van SHA-1 of andere bekende beveiligingslekken binnen SSL.

Als uw certificaat goed is geïnstalleerd, de configuratie van uw server voldoet aan de controle van SSL Labs, en uw code geen verwijzingen meer maakt naar onbeveiligde content op welke manier dan ook, kunt u er zeker van zijn dat uw website volledig over HTTPS beveiligd is.

Met die basis kunt u door naar de volgende stap:

Heeft u uw certificaat goed geïnstalleerd voor alle platformen?

Uw certificaat wordt standaard geleverd met 3 afzonderlijke certificaatbestanden: uw eigen certificaat, het intermediate certificaat, en het rootcertificaat. Bij het installeren van uw certificaat op de server is het belangrijk dat het intermediate certificaat ook wordt geïnstalleerd. Deze vormt de link tussen uw certificaat, dat uitgegeven is op uw eigen website en uw domein dus beveiligt, en het rootcertificaat dat opgenomen is in uw OS.

Als u alleen uw eigen certificaat installeert op uw server, kan het zo zijn dat uw website wel gezien wordt als beveiligd als u deze bezoekt in uw browser, maar niet als u hem bezoekt via uw mobiele telefoon. Dit komt omdat intermediate certificaten op uw computer worden opgeslagen in de certificate store van uw OS. Uw mobiele operating system slaat deze certificaten echter niet standaard op, en maakt alleen gebruik van de certificaten die aanwezig zijn op de server van de bezochte website zelf. Installeert u dus alleen uw eigen certificaat en niet het meegeleverde intermediate certificaat, is uw website dus niet correct te benaderen vanaf een mobiele browser.

Daarnaast is het ook verstandig als u zorgt dat uw OS bijgewerkt is, zodat u er zeker van bent dat uw certificate store alle recente intermediate èn root certificaten bevat.

De sleutel tot veiligheid zit hem in de keys

Alleen het certificaat goed geïnstalleerd hebben is voor veel mensen nog niet genoeg zekerheid. Ten slotte is het al eens voorgekomen dat CA’s de veiligheid van hun eigen certificaten niet konden garanderen. Een belangrijk voorbeeld uit ons eigen land is de hack van de CA DigiNotar in 2011, waarbij een hacker toegang kreeg tot de systemen van DigiNotar en ruim 500 valse certificaten heeft uit kunnen geven voor onder andere Gmail, Hotmail, Twitter, Facebook en Skype. Hierdoor konden ze gespoofde websites uitgeven met een certificaat, dat door browsers niet als onveilig werd aangestipt. Ten slotte was het uitgegeven door een CA, was het certificaat geldig, en was de certificate chain tussen het root-certificaat, het intermediate certificaat en het klant-certificaat nog intact. Eindgebruikers konden niet weten dat de website niet veilig was.

Dit probleem wordt opgelost door de inzet van HTTP Public Key Pinning, oftewel HPKP. Hierbij wordt een lijst met public key hashes opgeslagen op de server en doorgegeven aan de browser bij het eerste bezoek van een website door middel van een HTTP response header. Elk volgend bezoek aan de website wordt deze public key gecontroleerd vanuit de browser: komen de keys niet overeen, is de website die bezocht wordt waarschijnlijk niet wie hij zegt te zijn. Deze extra beveiligingsstap zorgt er dus voor dat een website niet gespoofd kan worden.

HPKP-overzicht-2Om HPKP goed te kunnen gebruiken, moeten er meerdere pins meegegeven worden. De beste methode is het meegeven van een hash van de public key van het eigen certificaat, een hash van de key van het intermediate certificaat van de CA, en een back-up die niet binnen dezelfde certificate chain valt als het originele certificaat. Dit kan een ander uitgegeven certificaat zijn, maar kan bijvoorbeeld ook een hash zijn van een nieuwe CSR. Mocht de private key van het originele certificaat onverhoopt op straat komen te liggen, kan deze nieuwe CSR gebruikt worden om razendsnel een nieuw certificaat uit te geven. Omdat de CSR ook al toegevoegd is aan de lijst van toegestane key hashes voor HPKP, is de overgang van het oude naar het nieuwe certificaat dan naadloos. Ook wordt er een geldigheidsduur meegegeven aan de key hash, zodat deze vanaf het moment van vastleggen in de browser slechts een beperkte tijd geldig is.

HTTP Public Key Pinning voorkomt dus dat een website niet bereikbaar is wanneer de CA als onveilig verklaard wordt, en wordt door veel veiligheidsexperts gezien als een goede toevoeging op een certificaat. Helaas zitten er wel wat haken en ogen aan: zo wordt HPKP niet ondersteund door Internet Explorer/Edge en Safari, al hebben de ontwikkelaars van Edge de ondersteuning wel opgenomen in hun planning. Ook vergt het instellen van HPKP iets meer technische kennis dan nodig is voor het instellen van een SSL certificaat. Daarnaast is het ook afhankelijk van de instellingen van de server, dus is het niet of minder makkelijk in te stellen wanneer u niet de eigenaar van uw server bent.

Wilt u meer informatie over het toepassen van HPKP, lees dan vooral het blogartikel van Scott Helme over HTTP Public Key Pinning.

SSL gaat verder dan alleen een gezipt bestandje uitpakken en installeren op uw server. Met wat relatief kleine aanpassingen en toevoegingen aan uw serverinstellingen en uw configuraties bent u in een mum van tijd nóg beter beveiligd tegen aanvallen van buitenaf.

Volgende week gaan we dieper in op het onderwerp SSL en Verder met het hoofdstuk over Cipher Suites.

Categorie  SSL & Security | Tags  https Security ssl