Over WordPress, Registrars, DNS, VPS en DNSSEC #3

“It’s Easy As… 1,2,3” schrijven ze op de WordPress website. Meer dan 3 stappen komen er niet kijken bij het in de lucht brengen van een WordPress website. Het eerste deel en tweede deel van deze serie zouden je voldoende basis gegeven moeten hebben voor de wat meer complexe begrippen die in deel 3 aan bod komen: HTTPS, SSL, TLS, certificaten, DNSSEC en HSTS. Die ben je ook allemaal tegen gekomen in dit bericht, ik loop er nu op basis van de eerste twee delen nog een keer kort doorheen.

HTTPS
Hier begon het eigenlijk allemaal mee. Ik heb al een paar jaar HTTPS in gebruik om van “buiten” (buiten mijn eigen netwerk) veilig verbinding te kunnen maken met de Synology NAS server die ik thuis heb staan. Maar het bijbehorende certificaat stond op het punt te verlopen. Dat was een aanleiding om ook eens te kijken of ik de admin-deel van het weblog hier niet beter kon beveiligen.

HTTP, het HyperText Transfer Protocol, het protocol dat we gebruiken om webpagina’s op te vragen is namelijk vanuit zichzelf “niet veilig”, d.w.z. alle communicatie tussen jou en de server waar je verbinding mee maakt gaat als leesbare tekst over het internet. Dat is niet zo’n vreselijk probleem als je gewoon blogposts op dit weblog aan het lezen bent, maar wat vervelender als je de toegangscodes tot je online bank aan het intypen bent (en niet alleen omdat de NSA mee wil kijken natuurlijk). Bij HTTPS worden de gegevens versleuteld en kunnen anderen niet meekijken, ook niet als ze het verkeer tussen jou en de server (en omgekeerd) onderscheppen.

Om HTTPS voor je weblog aan te kunnen zetten heb je een certificaat nodig.

Certificaten
Net als bij je domeinnaam, DNS en hosting, kun je bij een certificaat zelf kiezen waar je dat wil kopen (“huren”). Eenvoudige optie is vaak bij je hostingprovider. Die bieden in veel gevallen de mogelijkheid om een SSL certificaat via hen aan te schaffen. Dat gaat dan eenvoudig.

Maar, die hostingprovider zal dat certificaat niet zelf verstrekken, maar voor je bestellen bij bijvoorbeeld Comodo, GeoTrust, Thawte, GlobalSign. Dus het meest eenvoudige plaatje op basis van het Bhosted.nl voorbeeld ziet er dan zo uit:

1. Registrar: Bhosted.nl
2. Certificate tussenpersoon: Bhosted.nl
3. Certificate provider: GeoTrust
4. DNS: Bhosted.nl
5. Hosting: Bhosted.nl

In mijn geval, voor dit weblog, heb ik geen gebruik gemaakt van Bhosted.nl als tussenpersoon voor de certificaten, ik heb een goedkopere tussenpersoon gebruikt:

1. Registrar: Bhosted.nl
2. Certificate tussenpersoon: Xolphin
3. Certificate provider: GeoTrust
4. DNS: Bhosted.nl
5. Hosting: VPS via directVPS.nl

In dit bericht kon je lezen hoe ik het certificaat op de server heb geïnstalleerd. Dat kon ik in mijn geval zelf doen. Of jouw hostingprovider jou ook toestaat om zelf certificaten die je elders gekocht hebt te installeren zal afhangen van de situatie. Dat moet je dus even uitzoeken of navragen bij je hostingprovider.

En natuurlijk is niet elk certificaat gelijk aan elkaar. Grofweg zijn er drie hoofdgroepen:

1. Domein validatie – bevatten geen bedrijfsgegevens (vanaf zo’n 10-15 euro per jaar)
2. Organisatie validatie – bevatten bedrijfsgegevens, controle op basis van openbaar register (bv Kamer van Koophandel) en telefoontje met het bedrijf (vanaf zo’n 35-50 euro per jaar)
3. Uitgebreide validatie – bevatten bedrijfsgegevens, prominent zichtbaar in adresbalk, controle op basis van openbaar register, telefoontje met bedrijf en ondertekende documenten (vanaf zo’n 125-150 euro per jaar)

Je zou het al haast niet anders verwachten, hoe uitgebreider de validatie, hoe duurder het certificaat al zit er ook tussen de certificaatverstrekkers wel de nodige verschillen. Deels komt dat omdat een aantal certificaten wél voorgeïnstalleerd zijn op mobiele apparaten en andere niet. En als de browser/smartphone het certificaat van de certificaatverstrekker niet kent, dan zal de bezoeker toch nog een melding/waarschuwing krijgen.

Ook is het zo dat je een certificaat niet, zoals een domeinnaam, zomaar voor alle subdomeinen in een domein koopt. Dus als ik een certificaat voor ictoblog.nl koop dan is dat niet zomaar bruikbaar voor blog1.ictoblog.nl en blog2.ictoblog.nl. Dat kan wel, maar ook dat is weer duurder. In mijn geval heb ik een certificaat gekocht dat zowel voor www.ictoblog.nl als voor ictoblog.nl geldig is.

SSL en TLS
Goed, we hebben een certificaat, hebben het op de server geïnstalleerd, dan nog zijn we niet helemaal klaar voor wat betreft onze keuzes. Hét meest verwarrende wat mij betreft was dat iedereen het nog steeds over “SSL Certificaat” heeft. En tot vorige week wist ik ook niet beter dan dat SSL en HTTPS hand in hand met elkaar gingen. Maar zoals ik beschreef in mijn follow-up post, SSL (Secure Socket Layer), oorspronkelijk uit 1994 en via versie 1.0, 2.0 in 1996 aangekomen bij SSL 3.0 bleek in oktober 2014 niet zo veilig vanwege iets dat de “POODLE-kwetsbaarheid” heet.
Conclusie: het gebruik van SSL 1.0, SSL 2.0 en SSL 3.0 wordt niet meer als veilig gezien bij het versleutelen van SSL-verbindingen.

Gelukkig was er inmiddels al een alternatief: TLS (Transport Layer Security), die ook drie versies kent (op dit moment): TLS 1.0, TLS 1.1 en TLS 1.2.
Van deze drie versies is TLS 1.0 sinds 2011 aantoonbaar te kraken en dus onveilig, TLS 1.1 wordt nauwelijks gebruikt en TLS 1.2 uit 2008 is daarmee de enige als veilig bekend staande optie voor het versleutelen van netwerkverkeer.

Hier geldt weer hetzelfde als met DNS: als je alles bij één aanbieder regelt, dan zal die ook het instellen van de webserver voor zijn/haar rekening nemen.
Gebruik je, zoals bij mij het geval is, een VPS en voer je het beheer zelf in, dan zul je er zelf voor moeten zorgen dat TLS 1.2 gebruikt wordt. In mijn geval bleek dat niet standaard zo, in deze post kun je lezen wat ik moest doen om dat voor elkaar te krijgen.

TLSA Record (DANE)
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. Doordat niet alleen het certificaat zelf, maar ook een “hash” van dat certificaat worden opgeslagen in de DNS kan de browser controleren of het certificaat dat ontvangen wordt ongewijzigd is. Maken van zo’n hash kan op basis van je certificaat (in PEM-formaat) en deze handige webpagina hier. Het resultaat ziet er dan ongeveer zo uit:

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

Ook hier is het een beetje afhankelijk van je situatie of je er iets mee moet. Het kan zijn dat je hostingprovider het TLSA Record automatisch toevoegt als je daar ook het certificaat gekocht hebt en hun DNS gebruikt. Gebruik je je eigen DNS-server dan is het toevoegen meestal geen probleem (en beetje afhankelijk van de server). In mijn geval had ik een klein 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 hier eenvoudig testen voor een site of er een TLSA record wordt meegeleverd.

HSTS
Ik gebruik op het moment van typen van dit bericht alleen HTTPS voor het admin-gedeelte van dit weblog. Ik kreeg echter meteen de vraag of ik ook voor HSTS (HTTP Strict Transport Security) ging. Daarbij 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.
De keuze hiervoor is deels een principiële: wil je er voor zorgen dat alle verkeer versleuteld is en (in combinatie met andere beveiliging) wil je er voor zorgen dat een bezoeker zeker weet dat hij/zij een pagina van jouw weblog aan het bekijken is en geen kopie die door iemand nagemaakt is, voorzien is van extra content (scripts) etc.

Voor mij is dat nog even een volgende stap aangezien ik dan er ook “even” voor moet zorgen dat ik door de bestaande berichten (zijn er 6.537 op dit moment) heen ga om alle bestaande absolute verwijzingen naar http:// bijvoorbeeld voor afbeeldingen aan te passen, embeds naar YouTube en andere plekken vanuit de tijd dat ze nog niet via HTTPS gingen, etc.
Anders krijgen bezoekers voor die berichten alsnog een melding dat delen van de pagina over een niet veilige verbinding lopen.

DNSSEC
Ook helemaal nieuw voor mij was DNSSEC, de Domain Name System Security Extensions.  Op DNSSEC.nl wordt het als volgt in omschreven:

DNSSEC is een uitbreiding op het Domain Name System (DNS). DNSSEC verhelpt een aantal kwetsbaarheden in DNS waardoor de ‘bewegwijzering’ van het internet veiliger en vertrouwder wordt.

Uitdaging bij DNSSEC is dat, om het écht te laten werken, alle relevante tussenliggende onderdelen van de verbinding, ondersteuning moeten hebben voor DNSSEC. Dus:

1. Registrar,
2. DNS,
3. Browser.

Voor dit weblog was dat:

1. Registrar: Bhosted.nl
2. DNS: Bhosted.nl
3. Browser: Google Chrome

Via de DNS-server van Bhosted.nl was het voor mij bijna allemaal geregeld en scoorde ik daar zonder problemen op in de test bij Internet.nl, op mijn PC moest ik extra software (DNSSEC-trigger) installeren om de keten gesloten te krijgen. Ik begrijp van Internet.nl dat Ziggo/UPC dit ook zou moeten kunnen regelen:

@PeterMcAllister Mooi! Je gebruikt DNSSEC-trigger van @NLnetLabs. Zou wel goed zijn als @ZiggoWebcare (voorheen: UPC) ook DNSSEC op 1/2

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

Helaas blijken zowel mydomain.com (mijn registrar voor .com domeinen) als BuddyNS.com (mijn secondary DNS) geen ondersteuning hebben voor DNSSEC. Die moet ik dus beiden vervangen door een aanbieder die dat wél heeft (ben nog even op zoek).

Tot zover….
Tot zover de drie delen over WordPress, Registrars, DNS, VPS en DNSSEC. Voor mij zijn het genoeg aantekeningen om het verder uit te zoeken voor mijn andere domeinen. Laat even weten of het ook voor jou duidelijk is, of al je aanvullingen hebt, tips, tools, ervaringen….