Kabinet wil https en hsts voor alle overheidssites verplichten
Het kabinet wil dat alle overheidssites en -webapplicaties gebruik van https en hsts gaan maken en is nu een internetconsultatie gestart waarin het publiek om reacties wordt gevraagd. Volgens het ministerie van Binnenlandse Zaken moeten gebruikers van overheidswebsites erop kunnen vertrouwen dat ze via een beveiligde verbinding op een vertrouwelijke manier informatie kunnen uitwisselen.
Al begin 2017 liet de minister van Binnenlandse Zaken weten dat https voor alle overheidssites verplicht zou worden. Naast https voor een beveiligde verbinding wordt ook hsts verplicht. HTTP Strict Transport Security (hsts) zorgt ervoor dat websites die via https te bezoeken zijn alleen via https worden bezocht, ook al wordt er door de gebruiker http in de adresbalk ingevoerd.
Op dit moment geldt voor overheden het zogenaamde pas-toe-of-leg-uit-beleid voor open standaarden. Wanneer een overheidsorganisatie in een ict-systeem of dienst investeert, moeten de relevante standaarden van de pas-toe-of leg-uit-lijst van Forum Standaardisatie worden toegepast. Het gaat dan onder andere om https en hsts. Overheidsorganisaties hebben nu nog de mogelijkheid om de voorgeschreven standaarden niet toe te passen als hiervoor een zwaarwegende reden is. Dat zal straks niet meer mogelijk zijn.
Het ministerie stelt dat de verplichting om https en hsts toe te passen op overheidswebsites geen gevolgen voor burgers en bedrijven heeft. Overheidsorganisaties die de standaarden nog niet toepassen zullen die op de webserver moeten instellen, alsmede het installeren van tls-certificaten. Tot 20 oktober van dit jaar kan er op het besluit "beveiligde verbinding met overheidswebsites en -webapplicaties" worden gereageerd.
Dit klopt niet. Als de site geen redirect naar https doet, zul je bij elke inlog op http blijven zitten. HSTS zorgt er pas voor dat je vanzelf met https verbind, nadat je de site een keer met https bezocht hebt. (Of als de brouwsermaker deze site toevoegt aan hun hsts bestand)
Dit is het leg uit gedeelte.
Als de gebruiker plaatsnaam.nl in de URL-balk invoert (en er nog geen HSTS record voor bestaat) maakt de browser verbinding via http (een verbinding die betrekkelijk eenvoudig kan worden onderschept en/of omgeleid). Vaak genereert de site dan een redirect naar https://www.plaatsnaam.nl/, d.w.z. zonder dat er verbinding met https://plaatsnaam.nl/ wordt gemaakt (gebruikelijk is dat er voor https://www.plaatsnaam.nl/ een HSTS record aan de browser wordt toegevoegd).
Als de verbinding wordt onderschept door een MitM (Man in the Middle), zal de verbinding tussen de gemeente en de MitM daarna via https plaatsvinden, terwijl de verbinding tussen de MitM naar zijn keuze http blijft, of -met een iets afwijkende domeinnaam- een separate https verbinding wordt (bijv. https://www.secure-plaatsnaam.nl/).
Het probleem is vaak tweeledig: beheerders vergeten vaak dat https://plaatsnaam.nl/ ook een HSTS record moet laten maken (dus de juiste header moet meesturen), en daarnaast dat de browser die verbinding dan ook wel moet maken (dat kan overigens ook door de browser een 1x1 transparant pixel plaatje vanaf https://www.plaatsnaam.nl/ op te laten halen).
Als dit niet correct wordt geïmplementeerd heeft de bezoeker NIETS aan HSTS als deze de site steeds bezoekt door plaatsnaam.nl in de URL-balk van haar/zijn browser in te voeren, want die verbinding is dan steeds via http en kan elke keer worden onderschept en/of omgeleid.
Anders uitgelegd ("plaatsnaam" ingekort tot "p" voor de leesbaarheid):
FOUT: http://p.nl/ --redirect--> https://www.p.nl/ (met HSTS header)
FOUT: http://p.nl/ --redirect--> https://p.nl/ (zonder HSTS header) --redirect--> https://www.p.nl/ (met HSTS header)
GOED: http://p.nl/ --redirect--> https://p.nl/ (met HSTS header) --redirect--> https://www.p.nl/ (met HSTS header)
GOED: http://p.nl/ --redirect--> https://www.p.nl/ (met HSTS header) haal iets van https://p.nl/ (met HSTS header)
Meer info: https://www.security.nl/posting/566101/NL%3A+veel+brakke+https+sites.
De betere oplossing is natuurlijk HSTS in te schakelen voor alle subdomeinen (op de apex) en het domein op de preload list te plaatsen. Zie ook https://hstspreload.org/ voor het aanmelden van preloaden
Overigens vond ik zojuist een andere site die waarschuwt voor deze veel gemaakt fout: https://https.cio.gov/hsts/ (zie onder "In addition, in many cases, there may never be a first visit to https://domain.gov).
Mijn eigen site, welke niet meer dan 1 bezoeker en een handje vol bots aan verkeer ziet, is hier ook op geaccepteerd. Met acceptatie zit het dus wel goed.
Overigens zijn er nog steeds nieuwe ontwikkelingen en initiatieven op dit gebied, wellicht dat een automatische HTTPS redirect ook mogelijk wordt bij de aanwezigheid van nieuwe HTTPSVC DNS records. Daarmee zou geen lijst meer nodig zijn (al hoop ik wel dat DNSSEC validatie op endpoints eerst flink toeneemt).
Tx!
Michiel
Als de gebruiker plaatsnaam.nl in de URL-balk invoert (en er nog geen HSTS record voor bestaat) maakt de browser verbinding via http (een verbinding die betrekkelijk eenvoudig kan worden onderschept en/of omgeleid). Vaak genereert de site dan een redirect naar https://www.plaatsnaam.nl/, d.w.z. zonder dat er verbinding met https://plaatsnaam.nl/ wordt gemaakt (gebruikelijk is dat er voor https://www.plaatsnaam.nl/ een HSTS record aan de browser wordt toegevoegd).
Als de verbinding wordt onderschept door een MitM (Man in the Middle), zal de verbinding tussen de gemeente en de MitM daarna via https plaatsvinden, terwijl de verbinding tussen de MitM naar zijn keuze http blijft, of -met een iets afwijkende domeinnaam- een separate https verbinding wordt (bijv. https://www.secure-plaatsnaam.nl/).
Het probleem is vaak tweeledig: beheerders vergeten vaak dat https://plaatsnaam.nl/ ook een HSTS record moet laten maken (dus de juiste header moet meesturen), en daarnaast dat de browser die verbinding dan ook wel moet maken (dat kan overigens ook door de browser een 1x1 transparant pixel plaatje vanaf https://www.plaatsnaam.nl/ op te laten halen).
Als dit niet correct wordt geïmplementeerd heeft de bezoeker NIETS aan HSTS als deze de site steeds bezoekt door plaatsnaam.nl in de URL-balk van haar/zijn browser in te voeren, want die verbinding is dan steeds via http en kan elke keer worden onderschept en/of omgeleid.
Anders uitgelegd ("plaatsnaam" ingekort tot "p" voor de leesbaarheid):
FOUT: http://p.nl/ --redirect--> https://www.p.nl/ (met HSTS header)
FOUT: http://p.nl/ --redirect--> https://p.nl/ (zonder HSTS header) --redirect--> https://www.p.nl/ (met HSTS header)
GOED: http://p.nl/ --redirect--> https://p.nl/ (met HSTS header) --redirect--> https://www.p.nl/ (met HSTS header)
GOED: http://p.nl/ --redirect--> https://www.p.nl/ (met HSTS header) haal iets van https://p.nl/ (met HSTS header)
Meer info: https://www.security.nl/posting/566101/NL%3A+veel+brakke+https+sites.
Ze bieden geen PTOLU mogelijkheid meer voor die standaarden. Dat is het belangrijke onderdeel van het besluit.
Peter
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
