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.
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.