Veilig verbinding maken met WordPress via TLS/HTTPS

De tweede verwijzing die ik kreeg naar aanleiding van mijn blogpost ging naar SSL Labs (de eerste ging over IPv6). Daar kun je je SSL verbinding laten testen. En eigenlijk is de naam van de site net zo achterhaald als mijn kennis van SLL / HTTPS was. Want SSL (Secure Socket Layer) is inmiddels opgevolgd door TLS (Transport Layer Security). En sinds oktober 2014 worden zowel SSL 1.0, 2.0 als 3.0 als onveilig beschouwd nadat de POODLE-kwetsbaarheid bekend werd (ik citeer even Wikipedia).

De standaard SSL opties zoals die in Virtualmin beschikbaar zijn (waarmee ik mijn server beheer) bieden ondersteuning voor SSL 2.0, 3.0 en TLS 1.0, maar alle drie worden standaard aan gezet. De test bij SSL Labs maakte duidelijk dat ik zowel de ondersteuning voor alle drie de SLL-versies uit moest zetten als voor de TLS versies 1.0 en 1.1. In plaats daarvan moest ik alleen TLS versie 1.2 aan zetten. Dat kon niet vanuit de standaardinterface, maar van Michiel Schok kreeg ik een verwijzing naar deze SURFnet blogpost.

Op basis daarvan  kon ik achterhalen dat ik in /etc/httpd/conf/httpd.conf de toevoeging

SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA
SSLHonorCipherOrder on
SSLProtocol TLSv1.2

moest opnemen.
Daarnaast bleek ik het certificaat niet volledig juist geïnstalleerd had. Ik moest ook nog de root- en intermediate certificaten van het GeoTrust RapidSSL SHA-2 certificaat installeren. Daar had ik wel een link naar gekregen, maar had geen idee gehad wat ik daar mee moest doen.

Als je eenmaal weet waar je die moet uploaden, dan is het heel eenvoudig en via de Virtualmin interface hoef je e.e.a. niet handmatig te doen. Het resultaat in httpd.conf ziet er dan als volgt uit:

SSLEngine on
SSLCertificateFile /home/..../ictoblog.nl/myssl.cert
SSLCertificateKeyFile /home/..../ictoblog.nl/myssl.key
SSLCACertificateFile /home/.../ictoblog.nl/myssl.ca

Daarmee voldeed ik aan de meeste van de eisen op Internet.nl:

• de certificaat-keten is compleet en ondertekend door een vertrouwde root CA
• de publieke sleutels in de certificaten zijn voldoende lang
• alle certificaten zijn ondertekend met een voldoende veilige hash-methode
• de hostname van de website komt overeen met het certificaat
• de website biedt TLS aan
• de “forward secrecy”-instellingen zijn voldoende veilig
• alle aangeboden cipher-methoden zijn voldoende veilig
• verbinding alleen mogelijk voor ondersteunde TLS-versies
• de server staat geen TLS-compressie toe
• de server ondersteunt “secure renegotiation”
• de server staat geen “client-initiated renegotiation” toe

Er was er echter eentje die ik nog niet voor elkaar had (al vond Internet.nl inmiddels wél al dat ik voldeed en ook SSL Labs gaf me een A!). Ik moest namelijk een “TLSA Record (DANE)” hebben. Weer zo’n ding waar ik nog nooit van gehoord had. DANE staat voor “DNS-Based Authentication of Named Entities” en zorgt er voor dat je zeker kunt zijn dat de beveiligde verbinding met het juiste TLS certificaat opgezet is. Prima, de details hoefde ik even niet te begrijpen, er is gelukkig een handige webpagina hier. Daar hoefde ik alleen de inhoud van mijn certificaat in PEM-formaat in te voeren voor de bijbehorende regel die daarna in mijn DNS zou moeten worden opgenomen.

Het certificaat in PEM formaat kon ik downloaden via Virtualmin, het resultaat ziet er dan ongeveer zo uit:

_443._tcp.ictoblog.nl. IN TLSA 3 1 1 172bdf50a0462cf72e5b0e2d556bd733066c778999588f6cc7b114263322c6efc1

Was er nog maar één probleem: de DNS-editor van Bhosted.nl waar de DNS-info voor deze site bijgehouden wordt biedt geen ondersteuning voor het invoeren van dit soort entries. Gelukkig was een mailtje naar de helpdesk ook op zondagochtend voldoende om binnen een uur of zo een mail terug te krijgen dat het voor me gedaan was. Daarna was het een kwestie van een uur of zes wachten totdat de wijziging actief was. Je kunt dat hier eenvoudig testen voor een site.

DNSSEC
In de categorie “magie” viel wat mij betreft zeker ook het onderdeel DNSSEC, de Domain Name System Security Extensions. Via de DNS-server van Bhosted.nl was het voor mij allemaal geregeld en scoorde ik daar zonder problemen op in de test bij Internet.nl, maar om het zelf voor elkaar te krijgen op mijn eigen DNS-server, bij een andere domeinnaam provider (registrar), dat lukt me nog niet zomaar.  Uit de melding van Internet.nl (b)lijk ik te moeten afleiden dat mydomain.com daar geen ondersteuning voor heeft. Dat zou dus betekenen overstappen naar een registrar die daar wel ondersteuning voor heeft. Ook niet iets wat ik voorzichtig moet doen.
Het systeem lijkt echter wel weer voordelen te hebben en gewoon een vast onderdeel te worden van de totale beveiligingsketen van het web.
Wat DNSSEC betreft laat overigens UPC me voorlopig blijkbaar ook in de steek (of gaat het ergens onderweg mis) want ik gebruik blijkbaar geen DNSSEC:

Ga je voor een A+?
Toen ik de screenshot van mijn A-score op Twitter zette, kreeg ik meteen de vraag of ik ook voor HSTS (HTTP Strict Transport Security) ging. Dat vond ik een goede vraag, waar ik nog even geen definitieve beslissing over genomen hebt. Met HSTS zorg je er voor dat *alle* verkeer voor een domein via HTTPS gaat. Dat is informatie die een browser bij het eerste bezoek aan een site “te horen” krijgt. Voortaan zal hij dan altijd via HTTPS verbinding. Daarbij kun je voor zorgen dat je (op termijn) op een lijst komt in de verschillende browsers zodat gebruikers altijd, ook als een bezoeker voor de eerste keer langs komt.
Ik begrijp dat het volgend jaar onderdeel wordt van de standaard check van Internet.nl:

.@PeterMcAllister Congrats! Ook nog #HSTS? Wordt onderdeel volgende versie Internet.nl. Check https://t.co/CIrE2cNFqH CC @michielschok #TLS

— Internet.nl (@internet_nl) May 2, 2015

Probleem is echter dat ik eerst even iets meer zou willen weten over de extra overhead die dat voor deze site zou betekenen. Nu gebruik ik HTTPS voor het admin-deel, de beheeromgeving van de server, mijn NAS thuis etc.
Om nu *alle* domeinen die ik heb van HTTPS/TLS te voorzien, dat gaat in de papieren lopen. Ik heb er op het moment een stuk of 13, niet allemaal even actief, maar 13 certificaten betekent wel 130 euro per jaar aan extra kosten. Dat is een verdubbeling van de kosten.
Ik verwijs even naar deze tweet voor wat aanvullende info:

@michielschok @PeterMcAllister @httng Check ook Twitter-conversatie over nut van en trend naar https op: https://t.co/zJAlStM4vt #TLS

— Internet.nl (@internet_nl) May 3, 2015

En deze met een aankondiging van een initiatief voor gratis certificaten:

@michielschok @PeterMcAllister @httng @SURFnet @SURFSPOTNL Veelbelovend initiatief voor gratis DV-certificaten: https://t.co/RkkooVPJKa #TLS

— Internet.nl (@internet_nl) May 3, 2015

Mijn eigen suggestie was al dat SURF/SURFnet daarbij voor medewerkers in het onderwijs en studenten een rol zou moeten kunnen spelen. Ze weten al wie ik ben (via SURFconext), het zou mooi zijn als ik daar dan gratis certificaten kan genereren. Zou ook wel zo handig zijn voor studenten!

Conclusie
Het was leerzaam om uit te zoeken. Maar ik vraag me wel af: wie gaat die privé doen?
Ik heb een paar dagen vrij, had wel zin om het uit te zoeken, het gegeven dat via Twitter meegelezen en gedacht werd hielp natuurlijk ook, maar hoeveel procent van de eigen webloghosters gaat dit in de komende 12 maanden doen? Ik vrees niet veel.

Andere berichten in deze serie:

• Verbinding maken met WordPress via IPv6
• Veilig verbinding maken met WordPress via SSL/HTTPS (het eerste bericht dat dus aangevuld moet worden met dit bericht!)