Inleiding
Sinds 1 juli zijn overheden verplicht om ervoor te zorgen dat hun publieke websites https en HSTS (HTTP Strict Transport Security) ondersteunen (zie https://security.nl/posting/801781/HTTPS+en+HSTS+voortaan+verplicht+voor+alle+overheidswebsites+en+webapps). Helaas lijken maar weinigen te beseffen hoe je HSTS correct configureert, zodanig dan bezoekers van een website daar optimaal van profiteren.

Al in 2018 wees Bitwiper hierop in https://security.nl/posting/566101/NL:+veel+brakke+https+sites. Zelf heb ik hier ook meermaals aandacht aan besteed, o.a. in https://security.nl/posting/797052: sites zoals https://gemeente.amsterdam/ en https://www.werkenbij.amsterdam/ zijn alleen bereikbaar als je https vervangt door http; het ontbreken van ondersteuning voor https door deze (doorsturende) websites lijkt mij een overtreding van de nieuwe wet.

In april constateerde ik dat ook uwv.nl (zonder www. ervoor) geen https ondersteunde: zie https://security.nl/posting/793201. Dat is ondertussen gefixed. Opmerkelijk is dat ik uit https://crt.sh/?Identity=uwv.nl&match=single opmaak dat er voortdurend een geldig certificaat voor uwv.nl heeft bestaan (gepruts dus). De HSTS-ondersteuning van uwv.nl is echter nog steeds waardeloos: https://uwv.nl/ verstuurt geen HSTS kopregel (waarom dat een probleem is leg ik verderop uit).

Om het verhaal compleet te maken leg ik eerst uit hoe https en HSTS werken, waarom je ze wilt gebruiken en hoe je HSTS correct configureert.

Gebruikte terminologie
Met een server en een browser bedoel ik respectievelijk een webserver en een webbrowser. Een site (of website) wordt gekenmerkt door de domeinnaam (feitelijk de FQDN, Full Qualified Domain Name), zoals www.security.nl.

Effectief is security.nl (zonder "www." ervoor) een andere website, die op dezelfde server kan "draaien" of ergens anders. Het is gebruikelijk dat één van de twee de echte website is, en het de taak van de andere website is om uw browser door te sturen naar de echte website. Dat kan overigens beide kanten op: bijvoorbeeld security.nl stuurt uw browser door naar www.security.nl, terwijl www.nos.nl uw browser doorstuurt naar nos.nl.

Verschil tussen https en http
Eerst de overeenkomsten tussen http en https:
• Het (DNS-) antwoord op de vraag wat het IP-adres van een domeinnaam (zoals van almere.nl) is, kan vervalst zijn (waardoor uw browser verbinding maakt met een nepserver - ondanks een correct getoonde domeinnaam in de adresbalk van uw browser);

• Overal "onderweg" (de normale route) tussen uw browser en de echte server kan een nepserver zich voordoen als de echte server;

• De route voor netwerkverkeer vanaf uw browser kan door criminelen zijn "omgeleid" naar een nepserver.

Het belangrijkste verschil tussen http en https is:
• Bij een https-verbinding, bijvoorbeeld met almere.nl, moet uw browser eerst een versleutelde verbinding hebben gemaakt met de server genaamd almere.nl, vóórdat die server (en alleen die server) uw browser naar een andere website kan sturen (hier bestaan wel enkele uitzonderingen voor, waarbij het grootste risico voor de meeste mensen is dat hun browser of toestel gecompromitteerd is; dan is niets meer te vertrouwen. Andere uitzonderingen komen in de praktijk nauwelijks voor).

Werking van https
Bij https ontvangt uw browser een certificaat van de server, vergelijkbaar met een kopietje-paspoort - waarbij een certificaat extreem lastig te manipuleren echtheidskenmerken bevat. Zowel paspoorten als certificaten worden uitgegeven door instanties die je erop zult moeten vertrouwen dat zij geen valste identiteitsbewijzen uitgeven, maar in de praktijk gaat dit bij certificaten zelden fout [#].

Tevens moet de server aantonen te beschikken over "het originele paspoort" (feitelijk een unieke private key passend bij de public key in het certificaat). Zolang die private key (of een kopie daarvan) niet in verkeerde handen valt, weet u behoorlijk zeker dat uw browser verbinding heeft met de bedoelde server.

[#] Wat wél absurd vaak gebeurt is dat certificaatuitgevers certificaten aan cybercriminelen verstrekken voor domeinnamen die overduidelijk misleidend zijn (sterk lijkt op een domeinnaam van een legitieme organisatie, bijv. met veelgemaakte tikfouten).

In dat certificaat staan alle domeinnamen die de server mag gebruiken, zoals almere.nl, www.almere.nl en belastingen.almere.nl. Uw browser controleert of de door u gevraagde domeinnaam (te zien in de adresbalk) vóórkomt in het ontvangen certificaat (en dat dit certificaat geldig en niet gemanipuleerd is), en dat de server over de juiste private key beschikt; als er iets niet klopt toont de browser een foutmelding (vaak kunt u die afwijzen en toch doorgaan).

Belangrijk: die foutmelding krijgt u nádat de verbinding versleuteld is, doch vóórdat er inhoudelijke informatie tussen de server en uw browser wordt uitgewisseld. Hierdoor kan uw browser niet éérder naar een andere server worden doorgestuurd dan nadat is vastgesteld dat de browser een versleutelde verbinding heeft met een geauthenticeerde (door u vertrouwde) server, nl. met de door u opgegeven domeinnaam.

Voorbeeld: de beheerder van https://almere.nl kan uw browser laten doorsturen naar www.almere.nl of zelfs naar zwolle.nl, maar om dat te kunnen moet https://almere.nl over een geldig certificaat en bijpassende private key beschikken.

Hopelijk ten overvloede: een https certificaat zegt niets over de veiligheid of betrouwbaarheid van een server.

Risico http
Probleem: nog steeds beginnen veel te veel verbindingen tussen browsers en webservers met het risicovolle "kaapbare" http protocol (in plaats van met https).

Risico: bij http kan uw browser vaak heel simpel naar een nepserver worden (door-) gestuurd - die óók een geldig certificaat kan hebben, namelijk indien deze een (iets) afwijkende domeinnaam heeft. De meeste mensen verwachten niet, na een domeinnaam te hebben ingevoerd (en wellicht op typfouten te hebben gecontroleerd voordat zij op de Enter-knop drukten), dat die domeinnaam vervolgens substantieel verandert - en als dat gebeurt, denken velen dat dit wel zo zal horen. En als men dat ziet, moet men maar net weten dat de nu getoonde domeinnaam niet van de door hen bedoelde organisatie is.

Risico nepservers
Sommige reageerders op security.nl menen dat nepservers geen probleem zijn als je alleen maar leest. Dat is natuurlijk onzin, weinigen willen fake news lezen of op andere wijze op het verkeerde been worden gezet. Daarnaast kan een nepserver een nepwaarschuwing geven dat uw computer een virus heeft (en u prijzige ondersteuning bieden) of liegen dat een software en/of een update moet installeren om die website goed te kunnen bekijken. Ook bestaat het risico dat u wordt overgehaald om in te loggen (met "Google" of met inloggegevens die voor de echte site bedoeld zijn), of om persoonsgegevens prijs te geven.

Oorzaken onbedoeld http i.p.v. https
1) Veel mensen tikken bijvoorbeeld almere.nl of www.zwolle.nl in de adresbalk van hun browser als zij een website willen openen, dus zónder https:// ervoor. In de papieren media en op TV zie je zelden dat je https:// vóór de domeinnaam zou moeten invoeren, en bijna niemand legt uit waarom. Het standaardprotocol in alle browsers is echter nog steeds http; als u niet expliciet https opgeeft, gebruikt uw browser http [*].

2) Er zijn nog steeds veel webpagina's en QR-codes met daarin opgenomen links die expliciet met http:// beginnen.

[*] In sommige browsers kunt u de standaard wijzigen in iets als "https-only"; dit is m.i. zeer verstandig, maar leidt tot waarschuwingen bij netwerk- en andere IoT-apparaten, alsmede bij intranetsites, indien zij geen https ondersteunen.

Gebruikelijke "oplossing"
De meeste webservers waar uw browser via http verbinding mee maakt, sturen uw browser dóór naar een https variant van die webserver. Dat is natuurlijk prima, tenzij de verbinding met de server "onderweg" wordt gekaapt!

Als u in de adresbalk van uw browser bijvoorbeeld security.nl invoert, wordt uw browser (als er geen kapers op de kust zijn) dóórgestuurd naar https://www.security.nl/ (die server kan overigens een ander IP-adres hebben en zelfs in een heel ander land staan).

Het volgende gebeurt dus (als alles goed gaat):
(met die 'v' bedoel ik doorsturen).

Maar die verbinding kan ook (zonder foutmeldingen) gekaapt worden:
Die site bestaat overigens echt, heeft momenteel een geldig Let's Encrypt certificaat en vermeldt:
Nb. dit kan anders zijn afhankelijk van de door u gebruikte browsers, instellingen en besturingssysteem. Bezoeken geheel op eigen risico (ik heb geen idee wie de eigenaar is van die domeinnaam).

Doel van HSTS
HSTS leidt ertoe dat de meeste browsers, voor een webserver (met een specifieke domeinnaam) die daar eerder om gevraagd heeft, twee dingen doen:

1) https gebruiken om met die website communiceren, zelfs als u expliciet om http vraagt;

2) Bij certificaatfoutmeldingen u niet te vragen of u desondanks toch door wilt gaan (dat kunt u dus niet met de door u gebruikte browser).

Merk op dat punt 2 anders is dan bij de instelling "https-only" die sommige browsers ondersteunen (tenzij de browser tevens een HSTS record heeft voor de domeinnaam): in dat geval kunt u (soms met veel waarschuwingen en meerdere keren bevestigen) wél informatie uitwiselselen met de webserver.

Het doel van HSTS is dus het beschermen van bezoekers, door zoveel mogelijk te voorkómen dat zij via het "kaapbare" http protocol verbinding maken met "jouw" website, maar ook dat een eventuele AitM-server (Attacker in the Middle, of MitM met de M van Miscreant) met een ongeldig (bijvoorbeeld "self-signed") certificaat een internetter weet over te halen om de foutmelding te negeren en die foute website toch te bezoeken.

Werking van HSTS
HSTS is een protocol waarmee een https website (onzichtbaar voor de gebruiker) een bezoekende browser kan "vragen" om die website "voortaan" via https te bezoeken (ongeacht of de gebruiker daar via http is terechtgekomen).

Met "voortaan" bedoel ik de komende n seconden, waarbij n vaak 31.536.000 is (365 dagen).

Dat "vragen" gebeurt als de webserver een "http kopregel" (http header) meestuurt, die eruit kan zien als volgt:
In zo'n regel zijn meer (optionele) parameters mogelijk (op internet is hier voldoende informatie over te vinden).

In een browser zie je kopregels normaal gesproken niet, maar op desktop-browsers kun je die vaak wel zichtbaar maken door op F12 te drukken, de pagina te verversen en een logregel te selecteren.

De meeste browsers berekenen (uitgaande van het bezoekmoment) de einddatum en tijd dat het verzoek vervalt, en slaan dat samen met de actuele domeinnaam op in een database. Als zo'n record al bestaat voor de gegeven domeinnaam, wordt het oude record overschreven met de nieuwe gegevens.

Merk op dat er twee legitieme redenen bestaan om uw browser "door te sturen", die beide van belang zijn voor de goede werking van HSTS:

1) van http naar https;

2) van security.nl naar www.security.nl (of van www.nos.nl naar nos.nl).

Deze website doet het bijna perfect:
Met een regel die begint met "Strict-" onder een URL bedoel ik dat de server uit die URL deze kopregel meestuurt.

Toelichting bij het bovenstaande diagram: als u in de adresbalk van uw browser security.nl heeft ingevoerd en uw browser nog géén geldig HSTS record heeft voor security.nl (en uw browser niet op https-only is ingesteld), maakt uw browser daadwerkelijk een http-verbinding met security.nl.

Die site (http://security.nl/) geeft uw browser opdracht om naar https://security.nl/ te gaan, wat uw browser normaal gesproken zal doen. Die site stuurt een HSTS kopregel mee - voor de domeinnaam security.nl dus.

Daarna zal die site uw browser doorsturen naar https://www.security.nl/, die een HSTS kopregel meestuurt maar nu voor www.security.nl.

Als ik vervolgens mijn browser (Firefox ESR onder Windows) sluit, zie ik in de HSTS database (het bestand c:\Users\Erik\AppData\Roaming\Mozilla\Firefox\Profiles\pk55p0v1.default\SiteSecurityServiceState.txt) de volgende twee regels bevat (voor de leesbaarheid heb ik 1 lege regel tussengevoegd):
Van belang hier zijn de domeinnamen www.security.nl en security.nl helemaal links, en de lange getallen die beginnen met 1720124: dat zijn de eindtijden in milliseconden sinds 1 januari 1980 (volgens https://unixtime.org/ zijn dat resp. Thu Jul 04 2024 22:15:50 GMT+0200 en Thu Jul 04 2024 22:15:49 GMT+0200).

Perfecte HSTS-configuratie
De configuratie van security.nl is niet perfect, want stel dat ik meestal een snelkoppeling gebruik die (nog) naar http://www.security.nl/ verwijst, dan gebeurt het volgende:
Daarna heb ik alleen de eerste regel in de HSTS database. Dat leidt ertoe dat als ik een keer niet mijn snelkoppeling gebruik, maar security.nl invoer in de adresbalk, er alsnog (een tweede) http-verbinding nodig is om het tweede record aan de HSTS database toegevoegd te krijgen.

Dat zou Security.nl kunnen oplossen door https://www.security.nl/ altijd bijv. een 1x1 pixel van https://security.nl/ te laten ophalen. De perfecte volgorde is dus:

Als je begint met http://www.security.nl zou dat moeten gaan als volgt:

Een nadeel hiervan is dat je dan altijd meteen twee HSTS records toevoegt, maar aangezien de meeste mensen die ik ken "www." weglaten, krijg je die sowieso op deze site.

Onbetrouwbaarheid van HSTS
De eerste keer dat uw browser verbinding maakt met een webserver, heeft u sowieso niets aan HSTS. Bovendien negeren browsers een HSTS kopregel indien deze hen via http bereikt. En aan een https-server heeft u ook niets als deze geen (geldige) HSTS kopregel verstuurt.

Een onjuiste serverconfiguratie kan ook roet in het eten gooien: browsers kunnen HSTS informatie negeren als een webserver meer dan één "Strict-transport-security" kopregel meestuurt (ook als ze identiek zijn).

Als u langer dan de in uw browser ingestelde tijd een website niet heeft bezocht, vervalt de informatie (en werkt HSTS niet meer). Bovendien verwijderen de meeste browsers hun HSTS database als u alle browser-geschiedenis wist.

En als u een andere browser of een browser op een ander apparaat (nieuwe smartphone bijvoorbeeld) gebruikt, kan een HSTS record ontbreken.

Ten slotte zijn er bugmeldingen die beschrijven dat HSTS niet werkt voor nieuw bezochte domeinnamen omdat "de database vol is" (voorbeeld: https://insinuator.net/2021/05/analysis-of-hsts-caches-of-different-browsers/). Ook corruptie van zo'n database kan niet worden uitgesloten, en indien het database-schema wijzigt bij een browser-update, zou de database stilletjes gewist kunnen worden.

Dit lijken wellicht een boel nadelen, maar in de praktijk valt dat reuze mee. HSTS is niet perfect, maar sowieso maakt HSTS het leven van "jagers op onversleutelde verbindingen" minder interessant naarmate er minder onversleutelde verbindingen zijn - terwijl internetters websites bezoeken zonder daarbij expliciet om https te vragen.

Ondoordachte HSTS configuratie
Zoals ik in de inleiding schreef, komt dit veel voor. Tijdens de internetconsultatie voor het verplichten van ondersteuning van HSTS op overheidswebsites, heb ik een PDF van 3 kantjes met implementatieadviezen geschreven en dat (bijtijds, 5 sept. 2019) ingediend. Daar heb ik vervolgens nooit meer wat van gehoord.

Sterker, in het "Verslag over de resultaten van de consultatie" met in de bestandsnaam "versie 20210211" (https://www.internetconsultatie.nl/overheidswebsites/document/6655 - PDF) is niets van mijn aanbevelingen terug te vinden, en ook niet in de gepubliceerde regels.

Ook voor een webex-meeting vandaag (https://forumstandaardisatie.nl/nieuws/open-spreekuur-wdo-en-amvb-https-hsts) ben ik niet uitgenodigd. Dit bevestigt voor mij wat een farce die internetconsultaties zijn; ik doe daar niet meer aan mee.

Steekproef gemeenten: https en HSTS (plus privacy)
Afgelopen dinsdag heb ik, met een steekproef, gekeken hoe het gesteld is met https en HSTS op websites van Nederlandse gemeenten - waarbij ik ook naar privacy heb gekeken. Hiervoor heb ik de websites van de eerste 10 (alfabetische volgorde) uit https://nl.wikipedia.org/wiki/Lijst_van_Nederlandse_gemeenten gekozen.

Resultaten in het kort:
• Alle 10 websites ondersteunen https;

• Drie van de tien hebben waardeloze HSTS-ondersteuning: als u in de adresbalk van uw browser aaenhunze.nl, almere.nl of alphenaandenrijn.nl invoert en op de Enter-knop drukt, ontvangt uw browser voor die domeinnamen géén HSTS header. Elk volgend bezoek (op dezelfde manier) vindt dan weer plaats via http;

• Van de 10 heeft alleen aalsmeer.nl HSTS perfect voor elkaar;

• De privacy van bezoekers wordt op alle sites met voeten getreden (vermoedelijk overtreden zij allemaal de AVG). Het gaat niet alleen om cookies: met allerlei "analytics" websites van derde partijen wordt (deels) identificerende informatie van bezoekers gedeeld. Op de sites waar je "cookies kunt weigeren" leek dit geen effect te hebben; sowieso werden soms al cookies gezet voordat ik de kans kreeg om ze te weigeren.

De details (kort en bondig opgeschreven) vindt u in de eerstvolgende posting hieronder. Ook als er meerdere connecties zijn naar websites van derden, noem ik ze maar één keer.

Disclaimer
Ik kan fouten hebben gemaakt of zaken over het hoofd hebben gezien. Eén uur na plaatsing op deze site kan ik mijn posts echter niet meer wijzigen; kijkt u a.u.b. verderop op deze pagina of ik aanvullingen/correcties beschrijf.