image

Kabinet wil https en hsts voor alle overheidssites verplichten

maandag 2 september 2019, 17:12 door Redactie, 13 reacties

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.

Reacties (13)
02-09-2019, 17:21 door Anoniem
Goh, nu al. Bestaat gelukkig nog niet zo lang. Ook niet echt van nieuwswaarde om eerlijk te zijn, maar goed.
02-09-2019, 17:49 door Anoniem
Dan zijn ze wel een van de laatsten in Nederland.
02-09-2019, 18:31 door Briolet
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.

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)
02-09-2019, 18:49 door Ron625
Overheidsorganisaties hebben nu nog de mogelijkheid om de voorgeschreven standaarden niet toe te passen als hiervoor een zwaarwegende reden is.
Wanneer het niet toegepast wordt, dan moet in het jaarverslag staan, waarom het (technisch) niet mogelijk was/is, om aan de standaarden te voldoen.
Dit is het leg uit gedeelte.
02-09-2019, 18:50 door Anoniem
Ik dacht dat het al verplicht was. Maar goed om te zien dat ze wat met ICT uit de voeten beginnen komen.
02-09-2019, 20:23 door Bitwiper - Bijgewerkt: 02-09-2019, 20:38
Hopelijk realiseren beheerders zich dat er zowel voor plaatsnaam.nl als voor www.plaatsnaam.nl een HSTS record in de HSTS database van de bezoekende browser moet worden aangemaakt (of geüpdatet).

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.
02-09-2019, 20:29 door Anoniem
Door Bitwiper: Hopelijk realiseren beheerders zich dat er zowel voor plaatsnaam.nl als voor www.plaatsnaam.nl een HSTS record in de HSTS database van de bezoekende browser moet worden aangemaakt (of geüpdatet).

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
02-09-2019, 22:42 door Bitwiper
Door Anoniem: De betere oplossing is natuurlijk HSTS in te schakelen voor alle subdomeinen (op de apex)
Tenzij je zeker weet dat geen enkele van je subdomeinen ooit nog http zal gebruiken, is dat niet handig. Maar sowieso geldt dan nog steeds dat vaak de fout wordt gemaakt dat de browser nooit https//plaatsnaam.nl/ aandoet (aan IncludeSubDomains voor www.plaatsnaam.nl heef niemand normaal gesproken iets).

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).

Door Anoniem: en het domein op de preload list te plaatsen. Zie ook https://hstspreload.org/ voor het aanmelden van preloaden
Ik weet niet hoe hun acceptatiebeleid is, maar ik kan me zo voorstellen dat zo'n lijst te lang wordt als iedereen z'n https site kan toevoegen (ik ben hier overigens niet ingedoken, dus heb geen idee m.b.t acceptatiecriteria).
03-09-2019, 08:41 door Anoniem
Door Bitwiper:Tenzij je zeker weet dat geen enkele van je subdomeinen ooit nog http zal gebruiken, is dat niet handig.
Gezien de eenvoud van het aanvragen van een publiek erkend certificaat vandaag de dag, denk ik dat een 'death by enforced security' een acceptabel risico zal zijn.

Door Bitwiper:Ik weet niet hoe hun acceptatiebeleid is, maar ik kan me zo voorstellen dat zo'n lijst te lang wordt als iedereen z'n https site kan toevoegen (ik ben hier overigens niet ingedoken, dus heb geen idee m.b.t acceptatiecriteria).

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).
03-09-2019, 08:46 door Anoniem
Door Anoniem: Goh, nu al. Bestaat gelukkig nog niet zo lang. Ook niet echt van nieuwswaarde om eerlijk te zijn, maar goed.
Elke scheet met 'internetconsultatie' heeft nieuwswaarde.


Door Bitwiper:
Door Anoniem: en het domein op de preload list te plaatsen. Zie ook https://hstspreload.org/ voor het aanmelden van preloaden
Ik weet niet hoe hun acceptatiebeleid is, maar ik kan me zo voorstellen dat zo'n lijst te lang wordt als iedereen z'n https site kan toevoegen (ik ben hier overigens niet ingedoken, dus heb geen idee m.b.t acceptatiecriteria).
Dit klinkt als alweer zo'n geweldig idee van de webshits.
03-09-2019, 09:14 door Anoniem
Wil je deze informatie meegeven in de internet consultatie? (linkje bovenin deze page) Da's enorm waardevol, die info wordt dan meegenomen bij de adviezen voor implementatie. Dat werkt echt, ik ben forum lid, ik zal er zelf op letten.
Tx!
Michiel


Door Bitwiper: Hopelijk realiseren beheerders zich dat er zowel voor plaatsnaam.nl als voor www.plaatsnaam.nl een HSTS record in de HSTS database van de bezoekende browser moet worden aangemaakt (of geüpdatet).

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.
03-09-2019, 10:28 door Anoniem
Lekker bezig die overheid, deze standaarden zijn al verplicht, dus waarom zou je dat nogmaals verplichten? Hebben ze niks beters te doen in Den Haag?
03-09-2019, 13:26 door Anoniem
Door Anoniem: Lekker bezig die overheid, deze standaarden zijn al verplicht, dus waarom zou je dat nogmaals verplichten? Hebben ze niks beters te doen in Den Haag?

Ze bieden geen PTOLU mogelijkheid meer voor die standaarden. Dat is het belangrijke onderdeel van het besluit.

Peter
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.