Plasterk: Https bij overheidswebsites alleen nodig bij gevoelige gegevens

Minister Plasterk van Binnenlandse Zaken vindt dat de berichtgeving over het gebrek aan https-gebruik van overheidswebsites 'enige nuance verdient'. Hij stelt dat het gebruik van een beveiligde verbinding afhangt van het versturen van gevoelige informatie.

Plasterk doet de uitspraken bij de beantwoording van Kamervragen. Deze kwamen tot stand naar aanleiding van de berichtgeving over het rapport dat de Open State Foundation begin december publiceerde. De conclusie van het rapport was dat de helft van de homepagina's van Nederlandse overheidswebsites geen https gebruiken of dit verkeerd implementeren. Plasterk zegt bij de beantwoording van de vragen dat het rapport enige nuance verdient, omdat 'het belang van het beveiligen van de verbinding naar een overheidswebsite afhangt van of de website gevoelige informatie uitwisselt'.

Daarom zijn de overheidsinstellingen zelf verantwoordelijk voor het beveiligen van hun websites, aldus de minister. Hij voegt daaraan toe dat er intussen verschillende acties worden ondernomen om de implementatie van https te versnellen. De techniek bestaat sinds 1994 en wordt breed ondersteund. De overheid streeft ernaar om eind 2017 alle overheidswebsites waar persoonsgegevens en andere gevoelige gegevens worden gecommuniceerd van een versleutelde verbinding te voorzien. Op de vraag of de minister de mening van onder andere Bits of Freedom deelt dat 'het onbegrijpelijk is dat de overheid niet beter presteert' op het gebied van https, antwoordt dat hij zich niet kan vinden in de uitspraak.

Het rapport van de Open State Foundation richtte zich op de homepagina's van overheidswebsites en niet op andere delen van de websites. Https zorgt ervoor dat de verbinding tussen de gebruiker en de server is versleuteld, maar vereist ook een degelijke implementatie en andere technieken, waaronder hsts. Uit het onderzoek bleek dat in zes procent van de gevallen de overheidswebsites wel waren voorzien van https, maar dat het fout ging bij de implementatie. Naast versleuteling laat een geldig beveiligingscertificaat de gebruiker bijvoorbeeld de identiteit van de website controleren.

Reacties (226)

[RagingRaven]

Als de wet zegt:
"De verantwoordelijke legt passende technische en organisatorische maatregelen ten uitvoer om persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking.".
Het orgaan dat hierop controleert (Autoriteit Persoonsgegevens) zegt:
"Wilt u gevoelige informatie verzenden, zoals uw creditcardgegevens? Dan is het belangrijk dat u gebruikmaakt van een beveiligde internetverbinding. Bij een beveiligde internetverbinding staat er https:// in de adresbalk van uw browser in plaats van het normale http://."
Dan moet de overheid zich gewoon net zo goed aan deze wet houden en is het toch van de zotte dat Plasterk deze opmerking maakt?!
Een gemiddeld persoon kan hiervoor een boete krijgen tot €4500,- als hij zijn zaken niet op orde heeft.

Zie ook een eerder nieuwsbericht hier op tweakers waarin zelfs bij een contactformulier dit vereist is: nieuws: Toezichthouder: contactformulier moet via https bij bijzondere persoo...
Nu wordt hier wel gesproken over 'bijzondere pesoonsgegevens', maar de wet zelf spreekt alleen over "persoonsgegeven: elk gegeven betreffende een geïdentificeerde of identificeerbare natuurlijke persoon;", dus dit lijkt me iets breder dan gegevens zoals een BSN.

Nu heb ik geen juridische achtergrond, dus wellicht is het bij een simpel contactformulier niet nodig, maar ik zou het risico niet willen lopen.

[Reactie gewijzigd door RagingRaven op 26 juli 2024 14:28]

[Rubén89]

Je gaat hier toch iets te kort door de bocht.

Waar het in deze om gaat is art. 13 van de Wet bescherming persoonsgegevens (Wbp), dat artikel luidt alsvolgt:
"De verantwoordelijke legt passende technische en organisatorische maatregelen ten uitvoer om persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking.
en:
"Deze maatregelen garanderen, rekening houdend met de stand van de techniek en de kosten van de tenuitvoerlegging, een passend beveiligingsniveau gelet op de risico's die de verwerking en de aard van te beschermen gegevens met zich meebrengen. De maatregelen zijn er mede op gericht onnodige verzameling en verdere verwerking van persoonsgegevens te voorkomen."

De verantwoordelijke (lees: de organisatie die om de gegevens vraagt, deze ontvangt en / of verwerkt) moet dus een passend beveiligingsniveau garanderen. Wat passend is kan geval tot geval verschillen, dit is mede afhankelijk van de aard van de te beschermen gegevens.

Dan is er (en dit artikel is belangrijk) art. 16 van de Wbp:
"De verwerking van persoonsgegevens betreffende iemands godsdienst of levensovertuiging, ras, politieke gezindheid, gezondheid, seksuele leven, alsmede persoonsgegevens betreffende het lidmaatschap van een vakvereniging is verboden behoudens het bepaalde in deze paragraaf. Hetzelfde geldt voor strafrechtelijke persoonsgegevens en persoonsgegevens over onrechtmatig of hinderlijk gedrag in verband met een opgelegd verbod naar aanleiding van dat gedrag. "

De (Europese) wetgever heeft gemeend dat de in art. 16 Wbp genoemde (en door mij onderstreepte zogenaamde "bijzondere persoonsgegevens") dermate gevoelig zijn dat verwerking ervan in principe verboden, tenzij aan de even verderop in de Wbp voorwaarden wordt voldaan. 'Nee, tenzij' dus.

(Het burgerservicenummer wordt in het artikel niet met naam en toenaam genoemd maar wordt ook aangemerkt als een bijzonder persoonsgegeven.)

De aard van de hiervoor genoemde bijzondere persoonsgegevens is dus dermate, dat aan de beveiliging hiervan veel strengere eisen worden gesteld als aan "gewone" persoonsgegevens.

Als jij mensen via een webapplicatie gezondheidsgegevens wil laten verstrekken, of gegevens over iemands seksuele leven dan moet dat via HTTPS.

Dat is ook in lijn met het artikel waarnaar jij linkt; de autoriteit persoonsgegevens oordeelde naar aanleiding van een vraag van het KNGF dat wanneer die zogenaamde bijzondere persoonsgegevens via het contactformulier van een website wordt verstrekt c.q. verwerkt, HTTPS een vereiste is.

Máár een en ander is dus altijd afhankelijk van, onder andere, de aard van de persoonsgegevens, bij verwerking van bijzondere persoonsgegevens via een website is HTTPS dus verplicht, gaat het niet om bijzondere persoonsgegevens dan is HTTPS géén vereiste.

Als jij dus - bijvoorbeeld - professioneel schoenmaker bent en jij hebt een contactformulier op je bedrijfswebsite, dan is het in de regel dus niet vereist dat jij dat contactformulier (uitsluitend) beschikbaar maakt via HTTPS.

Plasterk heeft dus, wanneer je alleen kijkt vanuit het oogpunt van de privacywetgeving, wel degelijk een punt.

[Reactie gewijzigd door Rubén89 op 26 juli 2024 14:28]

[Blorgg]

Je gaat hier toch iets te kort door de bocht.
...
Dan is er (en dit artikel is belangrijk) art. 16 van de Wbp:
"De verwerking van persoonsgegevens betreffende iemands godsdienst of levensovertuiging, ras, politieke gezindheid, gezondheid, seksuele leven, alsmede persoonsgegevens betreffende het lidmaatschap van een vakvereniging is verboden behoudens het bepaalde in deze paragraaf. Hetzelfde geldt voor strafrechtelijke persoonsgegevens en persoonsgegevens over onrechtmatig of hinderlijk gedrag in verband met een opgelegd verbod naar aanleiding van dat gedrag. "
...
Als jij mensen via een webapplicatie gezondheidsgegevens wil laten verstrekken, of gegevens over iemands seksuele leven dan moet dat via HTTPS.
...
Plasterk heeft dus, wanneer je alleen kijkt vanuit het oogpunt van de privacywetgeving, wel degelijk een punt.

Wanneer HTTP gebruikt wordt kun al snel zien wat voor pagina's iemand bezoekt. Met HTTPS wordt dat een stuk moeilijker. Het surfgedrag van mensen geeft inzicht in de zaken die jij noemt die beschermt moeten worden. HTTPS op alle overheid sites moet daarom verplicht om de burger te beschermen.

Plasterk weet zoals wel vaker niet waar hij het over heeft en verkondigt onzin.

[tedades]

Daarnaast is HTTP (via een MITM of malware) makkelijk en ondetecteerbaar te wijzigen. Bij het proberen te openen van een pagina kun je dan al een redirect doen naar een nepdomein. Dit nepdomein kan gewoon gebruik maken van HTTPS waar de niets vermoedende gebruikers (die wel stukje HTTPS hebben gecontroleerd) hun privegegevens achterlaten.
Je moet iedere overheidspagina veilig kunnen bezoeken. De moeite om een certificaat aan te vragen is echt niet zo lastig dat ze dit niet al hadden kunnen regelen. De kosten om HTTPS te gebruiken zijn echt niet heel hoog, hier krijg je de certificaten en een certificaat-installatie tool (kunnen sommige misschien wel gebruiken) gratis: https://letsencrypt.org/ (heeft wel een limiet op hoeveel sub-domeinen je per week kan registeren, maar goedkoper krijgen dan gratis wordt lastig).

[cracking cloud]

Snap niet dat je weggemod wordt want je hebt een goed punt. mitm is idd een reden om https te kiezen, zodat je zeker weet dat de content die je op de overheidspagina ziet afkomstig is van de overheid en bv niet onderweg is aangepast door zeg het maar Russische hackers. Dus ook voor een homepage is https belangrijk.

[CH4OS]

Ook met HTTPS zijn MITM-attacks mogelijk, zij het een stuk lastiger. Zo maakte het lek bij Diginotar dergelijke aanvallen wel heel makkelijk.

[Anoniem: 470811]

En aanvullend, als niet de hele website https is, kan ook geen hsts gebruikt worden. Je kan dat alleen differentiëren op basis van subdomeinen, maar ideaal is dat niet.

[Rubén89]

Wanneer HTTP gebruikt wordt kun al snel zien wat voor pagina's iemand bezoekt. Met HTTPS wordt dat een stuk moeilijker. Het surfgedrag van mensen geeft inzicht in de zaken die jij noemt die beschermt moeten worden. HTTPS op alle overheid sites moet daarom verplicht om de burger te beschermen.

Ik denk dat jij het niet helemaal goed begrepen hebt, HTTPS is absoluut niet, zoals jij stelt, een "silver-bullet", waardoor je surfgedrag niet meer in kaart kan worden gebracht.

Stel ik surf naar https://stopitnow.nl/wie-ben-jij/ de website van een organisatie die hulp biedt aan mensen met met pedofiele gevoelens of familieleden daarvan. Deze website biedt HTTPS aan en daarvan maak ik gebruik.

Dan is mijn bezoek aan die pagina alsnog prima te volgen want:

• Ik doe een DNS-lookup: welk ip-adres hoort er bij de domeinnaam stopitnow.nl. DNS-query's zijn in de regel niet versleuteld. Iemand met toegang tot het netwerk, of met toegang tot de nameserver (logs) kan dus aan de lookup zien dat ik geïnteresseerd ben in een website over pedofilie.
• Ik verstuur gegevens naar poort 443 van de server met IP-adres 83.149.71.107 en ontvang van dit IP-adres gegevens.
  Deze server / het IP-adres (83.149.71.107:443) host alleen de website van Stop it Now!
  Dat ik die gegevens verzend naar Poort 443 en van die server ontvang is door mensen met toegang tot het netwerk te zien, en hieruit blijkt dus dat ik die website bezoek HTTPS of géén HTTPS.
• Mijn webbrowser poogt een TLS-verbinding te maken met 83.149.71.107:443 daarbij verstuurt mijn webbrowser de hostname van 't domein wat ie wil bereiken in plain text naar de server (dus: "stopitnow.nl") . Een en ander conform, de Server Name Indication TLS-extension. Ook hierdoor is op te maken welke website ik bezoek.
• De server stuurt vervolgens in plain text het certificaat dat hoort bij de domeinnaam naar mijn computer waaruit ook weer is op te maken dat ik een website bedoeld voor personen met pedofiele gevoelens bezoek.

Nogmaals, HTTPS is niet de silver-bullet die je privacy beschermt, je surfgedrag anonimiseert etc...

Een bedrijf als Google doet het wel als zodanig voorkomen en pusht het gebruik van HTTPS agressief, maar dergelijke bedrijven hebben er dan ook alle belang bij dat jij onbekommerd over het web surft. Google verdient daar (lees: met jouw surfgedrag) haar geld mee.

Dit geeft een false sence of security (en met name een false sence of privacy), bovendien zullen mensen wellicht denken: Google is zo druk met de beveiliging daar kan ik mijn privégegevens wel stallen, waarmee zij haar eigen privacy-invasieve praktijken maskeert.

(Om me nog maar niet uit te laten over het data-minen van Google zelf, laat staan dat we stilstaan bij het feit dat de Google's van deze wereld gewoon verplicht zijn gegevens aan een organisatie als de NSA te verstrekken en dit ook zonder meer doen, of deze gegevens nu via HTTPS of HTTP verzonden zijn.
Ook het plaatsen van - bijvoorbeeld - tracking-cookie's en het gebruik van browser-fingerprinting wordt niet voorkomen wanneer men [alleen] HTTPS gebruikt.)

[Reactie gewijzigd door Rubén89 op 26 juli 2024 14:28]

[Sandwalker]

Helder verhaal! Ik denk ook niet dat je er met alleen https bent. Het is echter wel een verschil of men kan zien dat ik gathering.tweakers.net of dat ik op het forum erg druk aan het zoeken ben geweest naar informatie over TOR. Als je gesteld bent op je privacy, wil je voorkomen dat voor een ieder duidelijk is welke sites je bezoekt, en wat je vervolgens op die sites doet. Dus liever wel https dan niet om te voorkomen dat de inhoud transparant is.
Ik vermoed dat met de datahonger van de grote jongens als facebook en google, zelfs met https en een vpn, er toch nog behoorlijk wat data over mij wordt verzameld, die dan misschien niet direct aan mijn ip hier in de lande, maar wel aan mijn persoon gekoppeld kan worden.

[Syzzer]

Ook welke pagina van een https-website je bezoekt is niet moeilijk te achterhalen. Vrijwel elke pagina heeft namelijk een eigen grootte. Door een website te indexeren, en de grootte van jouw verzoeken naar die website te vergelijken met de grootte van de verschillende websites, is iemand die meeluistert op de lijn er al snel achter welke pagina's je bezoekt. Dat werkt zelfs bij diensten zoals Tor.

Lees bijvoorbeeld (de abstract van) dit paper eens: https://anonymous-proxy-s...aper/wpes11-panchenko.pdf. (Edit: mocht de link ooit niet meer werken, dit is de paper "Website Fingerprinting in Onion Routing Based Anonymization Networks".)

[Reactie gewijzigd door Syzzer op 26 juli 2024 14:28]

[djwice]

Daarvoor hebben we tegenwoordig eliptische algoritmes en forwarded secrecy.

Gevolg is dat de grote van de paketjes die jij ontvangt niet gelijk hoeven zijn aan de mijne en dat ik elke keer weer nieuwe sleutels krijg. Waardoor 2x dezelfde bytes de tweede keer anders van grote kunnen zijn. En bij een 2e bezoek wordt je methode lastiger door de 304 responses.

Maar goed, als je de landingspagina kunt aannemen en je weet wat dasrvandaan linkt, dan is de kans op fout raden beperkt, hoe langer het bezoek hoe groter de waarschijnlijkheid van het klikpad.
Voor sites met voornamelijk dynamische content wordt het wellicht wat lastiger...

Google Brotli compressie (waarbij de lookup tabel vast ligt) maakt deze methode ook effectiever.
Dan http/2 header compressie met fixed lookup tabel (ook idee van Google).

hmmmm...

[Reactie gewijzigd door djwice op 26 juli 2024 14:28]

[Blorgg]

Ik denk dat jij het niet helemaal goed begrepen hebt, HTTPS is absoluut niet, zoals jij stelt, een "silver-bullet", waardoor je surfgedrag niet meer in kaart kan worden gebracht.

Hou even op met onzin praten. Nergens heb ik gesteld dat HTTPS een "silver-bullet" is. Sterker nog, ik weet prima hoe HTTPS werkt en hoet het geimplementeerd kan worden. Daarom kan ik ook met zekerheid zeggen dat HTTPS op alle overheid sites aan moet.

Je krijgt een +3 voor jouw relaas over wat HTTPS niet kan. Terwijl je totaal aan het probleem voorbij gaat dat Plasterk onzin praat, en jij verdedigt hem. De eerste alinea van het artikel:

Minister Plasterk van Binnenlandse Zaken vindt dat de berichtgeving over het gebrek aan https-gebruik van overheidswebsites 'enige nuance verdient'. Hij stelt dat het gebruik van een beveiligde verbinding afhangt van het versturen van gevoelige informatie.

Het versturen van gevoelige informatie.

Je geeft een goed verhaal over wat HTTPS vooral niet doet. Wat je echter niet hebt gedaan is vertellen wat HTTPS wel doet. Het zorgt er voor dat de inhoud die jij op een site raadpleegt verborgen blijft voor derde partijen.

Goed, als jij naar een site als ikbenhomo.nl gaat dan is het niet moeilijk te raden wat jouw sexuele geaardheid is. Echter als jij op belastingdienst.nl zoekt naar informatie over regelingen voor homo stellen, dan kan dat wel afgeschermd worden door het gebruik van HTTPS. Dat jij op belastingdienst.nl zit is niet vreemd, maar wat jij daar doet gaat niemand iets aan.

HTTPS geeft geen false sense of security zoals jij stelt. Het doet een paar hele specifieke dingen die samen met andere maatregelen kunnen helpen om jouw persoonsgegevens te beschermen zoals dat wordt vereist in de wet bescherming persoonsgegevens.

Net zoals alle ICT beveiligingsmaatregelen is HTTPS er een die niet op zichzelf staat. Dit soort maatregelen werkt het beste wanneer ze worden gebruik in combinatie met andere maatregelen.

[CH4OS]

En wat nu, als ik via Google op die website ben gekomen? Geef ik dan ook mijn geaardheid prijs? Het gaat niemand wat aan, wat een ander op welke website dan ook doet. Of dat nu de Belastingdienst.nl is of Ikbenhomo.nl maakt daarbij natuurlijk totaal niet uit. En zou dat ook niets over de persoon mogen zeggen, voor hetzelfde geld kom je er omdat je op iets gezocht hebt, bijvoorbeeld.

Plasterk baseert zijn uiting wellicht op oude smoesjes om HTTPS vooral niet te implementeren. Anno 2016 is er geen reden meer om HTTPS niet te gebruiken.

[Reactie gewijzigd door CH4OS op 26 juli 2024 14:28]

[sip5080]

Op zich een hele leuke analyse, het bewijs van kennis en feitelijk helemaal juist. Maar.. laten we niet vergeten: de essentie van HTTPS gaat niet om de genoemde bewijzen. HTTPS is in eerste instantie ontworpen voor confidentiality van de payload en integrity van de gebruiker en server .

[RielN]

Jammer dat je goed begonnen stuk uitmondt in een offtopic, ongenuanceerde rant over Google...

[Stammie82]

Ik denk dat veel mensen geloven wat google zegt. Als het klopt wat Ruben 89 zegt dan is het m.i. een goede aanvulling.

[Reactie gewijzigd door Stammie82 op 26 juli 2024 14:28]

[djwice]

Wat er van klopt is dat onder HTTPS de domeinnaam en het IP bekend is bij alle tussenliggende nodes en bij de gebruikte DNS.

Naar mijn idee heeft hij het mis met betrekking tot het afdoende zijn van http in bepaalde gevallen van het verwerken van persoonsgegevens.

Als iedereen er tussen ook jouw persoonsgegevens zonder jouw explicite toestemming kan zien (= http), dan is er m.i. niet

een passend beveiligingsniveau gelet op de risico's die de verwerking en de aard van te beschermen gegevens met zich meebrengen. De maatregelen zijn er mede op gericht onnodige verzameling en verdere verwerking van persoonsgegevens te voorkomen

aangezien 3-den deze gegevens dan zonder dat jij of de site eigenaar dat merken jouw persoonlijke gegevens dan onnodig kunnen verzamelen of verwerken voor een ander doel dan waarvoor jij die hebt verstrekt.

[EraYaN]

Nou zou het bij de overheid alleen overheid.nl kunnen zijn, of je nou informatie over ziekte uitkeringen of over emigreren aan het opzoeken bent. Beiden gegevens zouden gebruikt kunnen worden om je onder druk te zetten.

[goarilla]

Mooi uitgelegd. Heb jij "Silence on the wire" al gelezen ?

[djwice]

Wat https wel versleuteld en niet zichtbaar maakt is of je daar dan naar het "meld misbruik" formulier naar de "word gold member" sectie gaat.

[elbizarre]

Waarom denkt iedereen dat Plasterk diepgaande IT kennis zou moeten hebben? Hij is minister van Binnenlandse zaken. Hij moet globale kennis hebben van zowat alles.

Hij geeft enkel aan wat hem door zijn achterban / team wordt verteld. En ik neem maar even aan dat dit mensen zijn die wel degelijk ervoor door gestudeerd hebben.

Dit, los van het feit of ik het er mee eens ben, is heus wel met gegronde reden gezegd. Wellicht willen ze enigszins de rust bij bedrijven krijgen dat zij nu niet allemaal ad hoc alles moeten doen om al hun internet ingangen met SSL te beveiligen wanneer hier geen gevoelige overheen gaan.

[GekkePrutser]

Het probleem is dat het niet alleen gaat om het sniffen van privégegevens. TLS voorziet ook in server verificatie zodat je weet dat je met de juiste partij spreekt.

Het stelselmatig gebruiken van http maakt het een stuk makkelijker om bijvoorbeeld een phishing aanval te doen door een nep DigiD scherm in het verkeer te stoppen.

Bij gebruik van Https kan dit niet zonder dat je aan het certificaat ziet dat ermee is gerommeld.

[3raser]

Dit alleen zou al voldoende reden moeten zijn om alle overheidswebsites van SSL/TLS te moeten voorzien. De gemiddelde burger heeft geen idee waar ze mee bezig zijn en snapt dus ook niet dat als er om persoonlijke gegevens wordt gevraagd ze eerst moeten controleren of de website wel beveiligd is. Criminelen kunnen hier handig gebruik van maken door websites te spoofen en verkeer om te leiden.

De oplossing is dat de overheid ALTIJD voorziet van beveiligde websites en op hun websites de bezoeker daar ook over informeert in de vorm van "Vult u hier uw gegevens in? Controleer dan de groene balk, bla bla...". Op die manier raakt de burger hiermee bekend en zullen ze eerder onveilige situaties herkennen.

[pasz]

Moeten ze ook :
https://www.forumstandaardisatie.nl/standaard/tls

[CH4OS]

Als toevoeging op Rubén zijn reactie: de URL's zijn natuurlijk ook gelogd. Dus de stukken áchter het domeinnaam /wie-ben-jij in het voorbeeld van Rubén. Ook dat is immers onversleuteld.

HTTPS betekend alleen dat het netwerkverkeer zelf (zoals gegevens die jij vanuit een formulier naar de server hebt verstuurd) tussen jou en de server versleuteld is, de rest is onversleuteld, anders zag je geen plaatjes, maar encrypted afbeeldingen.

[GekkePrutser]

Nee bij https wordt de url wel degelijk versleuteld. Die wordt pas doorgegeven als de encryptie al is opgebouwd.

Maar zoals iemand hierboven al zei, je kan wel een redelijke inschatting maken op basis van de precieze datahoeveelheid. Zeker als de site veel statische pagina's bevat.

[CH4OS]

De inhoud van de pagina wordt versleuteld het GET request zelf (van het adres uit de adresbalk) is waar ik het over heb.

[GekkePrutser]

Dat snap ik, maar dat wordt wel versleuteld met HTTPS.

Wat het doet is verbinden met het IP van de domeinnaam, en eventueel de hostnaam (het stuk voor de derde /) doorgeven voor Server Name Indication (dat TLS mogelijk maakt voor meerdere domeinen op hetzelfde IP). Dan zet het een beveiligde verbinding op, en dan wordt de paginanaam (dus het GET request) pas verstuurd.

Dus de domeinnaam kan je zien ja, maar het GET request niet, de inhoud inderdaad ook niet. Kijk maar eens met bijvoorbeeld wireshark.

[Reactie gewijzigd door GekkePrutser op 26 juli 2024 14:28]

[curry684]

Wanneer HTTP gebruikt wordt kun al snel zien wat voor pagina's iemand bezoekt. Met HTTPS wordt dat een stuk moeilijker. Het surfgedrag van mensen geeft inzicht in de zaken die jij noemt die beschermt moeten worden. HTTPS op alle overheid sites moet daarom verplicht om de burger te beschermen.

HTTPS maskeert alleen de specifieke resource op de site zelf. Domain is gewoon inzichtelijk voor iedere MitM. Voor puur een informatieve non-interactieve site voegt HTTPS dus, zoals Plasterk volstrekt correct stelt, idioot weinig toe. Pas als binnen een site er zowel secties zijn met "goede" en "slechte" content helpt HTTPS tegen het in kaart brengen van jouw bezoek ervan.

Los daarvan is content injection een groter probleem van HTTP vs HTTPS, maar weinig relevant hier - of jij geredirect kunt worden naar phishing/malware is van secundair belang.

Plasterk weet zoals wel vaker niet waar hij het over heeft en verkondigt onzin.

Verbazend dat dat soort extreme uitspraken meestal komen van mensen die een spiegeltje behoeven

[Blorgg]

[...]


HTTPS maskeert alleen de specifieke resource op de site zelf. Domain is gewoon inzichtelijk voor iedere MitM. Voor puur een informatieve non-interactieve site voegt HTTPS dus, zoals Plasterk volstrekt correct stelt, idioot weinig toe. Pas als binnen een site er zowel secties zijn met "goede" en "slechte" content helpt HTTPS tegen het in kaart brengen van jouw bezoek ervan.

Los daarvan is content injection een groter probleem van HTTP vs HTTPS, maar weinig relevant hier - of jij geredirect kunt worden naar phishing/malware is van secundair belang.


[...]


Verbazend dat dat soort extreme uitspraken meestal komen van mensen die een spiegeltje behoeven

Voorbeeld: Dat je als volwassene op belastingdienst.nl kijkt is heel normaal. Echter de inhoud die je daar raadpleegt gaat niemand wat aan.

Als je op belastingdienst.nl kijkt naar informatie over huwelijk voor homo stellen, of informatie over belasting teruggave bij giften aan religieuse instanties, dan zijn dat zaken die tussen jou en de belastingdienst zijn en die door de overheid beveiligt moeten worden onder artikel 16 van de wet bescherming persoonsgegevens.

Deze zaken kunnen prima afgeschermt worden voor derde partijen door het gebruik van HTTPS.

Er is dus niets extreems aan mijn uitspraken. Plasterk, en jij ook, praten onzin. HTTPS op alle overheid sites moet gewoon aangezet worden.

[curry684]

Plasterk, en jij ook, praten onzin. HTTPS op alle overheid sites moet gewoon aangezet worden.

Sorry jongen maar je hebt echt heel veel klokken en klepels gehoord en Plasterk heeft een stuk betere adviseurs.

Dat alle websites ter wereld HTTPS zouden moeten hebben bestrijd ik op geen enkele manier. Het gaat hier enkel om de kwesties a) zijn de geldende regels gebroken en b) heeft dat ernstige consequenties. Beiden zijn niet het geval, hoe vaak je jezelf ook herhaalt of op de persoon Plasterk aanvalt met onderbuikonzin. Dat het een incompetente lamlul is staat los van dat ie prima mensen achter zich heeft om dit soort rapporten op te stellen op basis van feiten.

[i-chat]

en daar gaat ook jouw technische implementatie van de wet fout... een ssl cert en de bijbehorende server configuratie is namelijk helemaal niet van die aart dat de meerprijs ongerechtvaardigd is die paar duizend euro voor een EV is nihil...

bovendien valt vrij eenvoudig te beargumenteren dat ELKE comunicatie tussen mij en mijn overheid vertrouwelijk is, identificeerbaar is, immers altijd wordt gevraagt naar naam en contactgegevens en de aard van wat je precies wilt... een afspraak voor het ophalen van een IDkaart... het zou niet moeten kunnen gebeuren dat criminelen weten dat ik geen ID kaart heb en daar op slinkse weize misbruik van gaan maken...

ergo, de risico's en het maatschappelijke bewustzijn zijn ondanks het relatief ongevaarlijke caracter van de data nog steeds aanmerkijkelijk groter dan de verwaarloosbare meerprijs voor het uitrollen van SSL

[djwice]

Ik heb de indruk dat je niet snapt dat http geen afdoende maatregel is voor verwerking van persoonsgegevens.

Verwerking over http betekend dat iedereen op het zelfde LAN die gegevens kan lezen want ze worden plain/text over dat netwerk gestuurd.

Bijvoorbeeld bij gebruik via een WIFI hotspot, een bedrijfsnetwerk, universiteitsnetwerk, huisnetwerk etc.
Maar ook alle routers en proxies tussen de klant en de server en tussen servers onderling.

De gegevens moeten daarnaast ook versleuteld opgeslagen worden, ook bij de schoenmaker. Het zijn persoonsgegevens, niet iedereen mag die zo maar zonder toestemming van de persoon in kunnen zien.
Dus ook de hostingpartij die backups maakt niet.

[Reactie gewijzigd door djwice op 26 juli 2024 14:28]

[Anoniem: 426269]

Ja, het is ook voor een simpel contactformulier al nodig, want alleen een naam (en een emailadres) is ook al een persoonsgegeven. Ik heb dat meerdere malen gelezen op de officiele websites zoals die van de Autoriteit Persoonsgegevens toen het in het nieuws was een tijdje terug. Kan nu even die pagina's niet meer vinden.

En inderdaad, elke Jan L#l kan hier zomaar een boete van 4500 euro voor krijgen. Zie de wettekst op: https://autoriteitpersoon...t-65-tm-75/artikel-66-wbp

[Rubén89]

Ja, het is ook voor een simpel contactformulier al nodig, want alleen een naam (en een emailadres) is ook al een persoonsgegeven.

Ook jij gaat hier te kort door de bocht:
een e-mailadres is inderdaad een persoonsgegeven en kan zelfs een bijzonder persoonsgegeven zijn, maar dat is geheel afhankelijk van de context.

Dat is gelegen in het onderscheid tussen de zogenaamde "direct"- en "indirect" bijzondere persoonsgegevens.

Direct bijzondere persoonsgegevens zijn persoonsgegevens die direct iets zeggen over de in art. 16 Wbp genoemde categorieën, dus harde informatie over bijvoorbeeld je geaardheid: of je homo- of heteroseksueel bent.

Een e-mailadres is in de regel geen bijzonder persoonsgegeven maar kan wel een zogenaamd "indirect"- bijzonder persoonsgegeven zijn, dat is - zo schreef ik hiervoor al - afhankelijk van de context waarin het e-mailadres gebruikt wordt. De Autoriteit Persoonsgegevens licht dat, met het het navolgende voorbeeld, heel mooi toe¹:

"Een organisatie voor jongeren met belangstelling voor sadomasochisme (sm) organiseert een feest en verstuurt per e-mail een bevestiging van deelname aan iedereen die zich voor dit feest heeft aangemeld.
Bij de verzending van de mailing maakt de organisatie een fout, waardoor alle e-mailadressen zichtbaar zijn voor alle 65 ontvangers van de e-mail.
Een e-mailadres is een persoonsgegeven en kan, bijvoorbeeld als het de voor- en achternaam van de betrokkene bevat, de betrokkene direct identificeren.
Normaal gesproken is een e-mailadres geen gevoelig gegeven maar in dit geval ontstaat er door de context, deelname aan een sm-feest, een relatie met het seksuele leven van de betrokkene en wordt het gegeven alsnog gevoelig. De verantwoordelijke moet in zo’n geval extra beveiligingsmaatregelen treffen om het uitlekken van de e-mailadressen te voorkomen."

Het e-mailadres is dus normaal geen bijzonder persoonsgegeven. Echter, nu komt het e-mailadres (in het voorbeeld) voor in een mailinglist voor SM-feesten.
Het feit dat het e-mailadres in de adressenlijst voorkomt maakt dat het e-mailadres gekoppeld kan worden details over iemands seksuele leven.
Dat maakt het e-mailadres een (indirect) bijzonder persoonsgegeven.

Voor bijzondere persoonsgegevens is HTTPS een harde eis, voor de normale persoonsgegevens niet, zie: mijn reactie van 19:18.

[1]College Bescherming Persoonsgegevens, CBP Richtsnoeren Beveiliging van Persoonsgegevens, Den Haag, 2013, p. 19

[Reactie gewijzigd door Rubén89 op 26 juli 2024 14:28]

[djwice]

Waar ga jij hier in de interpretatie fout.
Bij sm-feesten is niet het e-mail maar de combinatie een bijzonder persoonsgegeven.

De e-mail zelf is een persoonsgegeven. En ten allertijden mogen deze door organisaties niet zonder vooraf toestemming verstrekken aan anderen.

Doen zij dit wel dan is dat een datalek. Dus ook als het een mailing was over madeliefjes, schoenveters, of van alle mensen in je straat.

Dus altijd zijn versleutelde verbindingen vereist als je persoonsgegevens verstuurd. En in rust dienen persoonsgegevens versleuteld te zijn opgeslagen. Ook bij de schoenmaker.

Waarom zou het niet erg zijn als zijn databestand met persoonsgegevens op straat komt te liggen? Denk je dat je dan meer of minder spam krijgt? Zou Zalando willen weten welk type schoenen jij laat hetstellen en hoe vaak?

[Reactie gewijzigd door djwice op 26 juli 2024 14:28]

[StephanVierkant]

Dat is toch precies wat Plasterk zegt? Hij zegt precies hetzelfde als de Autoriteit Persoonsgegevens.

En persoonsgegevens beveiligen is wel iets meer dan alleen https inschakelen. Ik heb liever een goed-beveiligde http-site, dan https en zo lek als een mandje (xss, sql injection, you name it). In het eerste geval kunnen bad guys mij afluisteren, maar in het tweede geval liggen alle gegevens op straat.

[DrBreakalot]

In het eerste geval kunnen bad guys de website aanpassen en hebben ze xss helemaal niet meer nodig.

[Hieronymuski]

Heb jij enig idee wat SSL doet?
SSL zorgt alleen maar voor een beveiligde verbinding. Wat er met die data gebeurt op het moment dat het op de server belandt, heeft geen hol met SSL te maken.
Wanneer een bad guy dus de website aanpast, kunnen jouw gegevens netjes over een beveiligde verbinding naar een aangepaste, malafide website gaan.

[Qauters]

Hij bedoelt dat het nu mogelijk is om overheidwebsites aan te passen met schadelijke content (ipv een xss-aanval). Dit kan hij doen wanneer je bijvoorbeeld op een openbare hotspot zit die hij bezit (vrij eenvoudig te faken ook). Met het activeren van https, is dit niet mogelijk aangezien hij niet het juiste certificaat bezit.

Uiteraard helpt https niet tegen malifide websites zelf, maar dat is ook niet het punt wat gemaakt wordt.

[Hieronymuski]

Ja, dan pas je dus niet de website aan maar onderschep je het verkeer.
Gebruik dan wel de juiste termen om een punt duidelijk te maken.

[DrBreakalot]

Tja, de website die de gebruiker ziet is toch echt aangepast.

[i-chat]

je kunt wel degelijk de website (client side) aanpassen.. en code injecteren op proxy-niveau. ook kun je niet zeggen dat " Ik heb liever een goed-beveiligde http-site, dan https en zo lek als een mandje" want op het moment dat een site je wachtwoord in plaintext naar de server stuurt is je site per definitie al zo lek als een mandje, zelfs als je gebruik maakt van onetime-passwords.

[SunnieNL]

Het rapport gaat voornamelijk om de homepages van verschillende overheidsinstanties. Ze kijken niet naar formulieren (die staan vaak dieper op de homepage) en ik hoop dat de overheid die wel beveiligd heeft.

Het rapport kijkt of https over de hele website wordt gebruikt. Dat is o.a. Nodig om straks überhaupt nog vindbaar te zijn op Google, anders vind je eerst 100den pagina's van bedrijven in gemeenten die wel https vereisen op hun website, omdat die hoger geïndexeerd worden. Daarnaast zorgt het ervoor dat er niet door man in the middel ineens een andere pagina kan worden getoond waarbij andere zaken op het systeem van de bezoeker kan worden geïnjecteerd en je als gebruiker niet hoeft te kijken of het contactformulier wel naar https springt.

Bij een simpel contactformuliertje gaan al snel persoonsgegevens over de lijn (emailadres of telefoonnummer in combi met naam) en die moeten altijd beveiligd zijn.

[Reactie gewijzigd door SunnieNL op 26 juli 2024 14:28]

[w00t00w]

"Do as we say, not as we do"...
Maar wees eerlijk, had je echt iets anders verwacht van Ronald "Ik kan me niet vinden in kritiek" Plasterk? Die vent heeft een plank voor de kop om U tegen te zeggen, en dat draagt dan verantwoordelijkheid...

[cmegens]

Een opmerking die minister onwaardig is. Je verwacht toch dat de minister op deze post of goed op de hoogte en bij de tijd is, of zich omringt met mensen die dat zijn. Als hij 1 van de 2 zou zijn of zou hebben zou hij deze uitspraak nooit zo doen. De mensen die er verstand van hebben trekken nu hun twijfels over de kennis en kunde van de minister en ministerie. De mensen die geen kennis hebben kunnen hierdoor een verkeerd beeld krijgen van hoe veiligheid in zijn werk gaat. Al met al een hele domme uitspraak, minister Plasterk wint niets met het doen van deze uitspraak.

[To_Tall]

ga je nu niet voorbij dat dit de homepage betreft?
Dus je gaat naar een website. Netjes HTTP:// je klikt daarna na inloggen en je wordt geredirect naar HTTPS://

[Mit-46]

https://developers.google...rypt-in-transit/why-https

Wanneer zelfs de "The Big Brother" een pagina omtrent HTTPS begint met, "You should always protect all of your websites with HTTPS, even if they don’t handle sensitive communications" dan denk ik dat meneer Plasterk totaal geen idee heeft waar dit technologie gerelateerde item nu daadwerkelijk over gaat.

[Uchiha1911]

Ter aanvulling:

• Intruders both malignant and benign exploit every unprotected resource between your websites and users.
• Many intruders look at aggregate behaviors to identify your users.
• HTTPS doesn't just block misuse of your website. It's also a requirement for many cutting-edge features and an enabling technology for app-like capabilities such as service workers.

[mrdemc]

En dan nog. Ik vind het bezoek van een overheidswebsite sowieso 'gevoelige informatie' al het verkeer is daarmee onversleuteld dus zoekopdrachten en paginabezoeken zijn gewoon inzichtelijk voor de onderschepper. Een zoekopdracht bij het UWV of de SVB of Belastingdienst kan daarmee voor een gebruiker een hoop gevoelige informatie verwerken via HTTP. Jammer dat de ministers zo digitaal incapabel zijn. Vraag me ook af wie ze hierover informeert of adviseert. Of zou hij dit zelf verzinnen?

[Meijuh]

Van die webpagina: "Intruders include intentionally malicious attackers, and legitimate but intrusive companies, such as ISPs or hotels that inject ads into pages." Is toch wel een sterk argument. Alleen hierom al vind ik dat Plasterk de plank misslaat.

[Barsonax]

Tijd voor een ministerie van ICT met iemand die wel weet waarover hij het heeft zou ik zeggen. Het is onderhand zo'n belangrijk onderdeel van ons leven geworden dat dat wel echt nodig is.

[mae-t.net]

Dus omdat zelfs Google het zegt moet het wel waar zijn? Google is een van de grootste pushers achter de invoering van https, dus "zelfs" lijkt me niet de goede omschrijving. Het is gewoon een partij met een ideologisch en/of zakelijk belang in deze zaak dus je kunt het als kritische burger / kritische ICT-gebruiker beter voor jezelf nagaan dan je oren daar alleen maar naar te laten hangen.

In principe is het verstandig om de beveiliging precies goed genoeg te kiezen voor datgene dat je beveiligt. Dus als je geen gevoelige informatie verspreid dan hoef je die ook niet te beveiligen alsof het om gevoelige informatie gaat.

De volgende vraag is dan natuurlijk in hoeverre het bij overheidssites gaat om gevoelige informatie. Wat je daar kunt lezen is in principe publiek, dus niet gevoelig. Https voorkomt ook niet dat eventuele afluisteraars te weten komen dat je naar die bepaalde site gaat. So far so good. Het kan indien correct toegepast echter wel "voorkomen" dat afluisteraars te weten komen naar welke informatie je precies op die site zocht, dus dat kan een winstpunt zijn. Immers hoeft niet elke man-in-het-midden te weten wat voor zaken je met de overheid wilt doen.

Volgende vraag is hoe belangrijk het is dat degene die de site bezoekt "zeker" moet zijn dat de informatie die hij leest ook echt de informatie is die hem door de overheid verstrekt wordt. Dat lijkt me een minstens zo belangrijk punt, want je moet op informatie van de overheid kunnen vertrouwen als burger.

Ik neig er dus naar om te zeggen: https wordt vaak onnadenkend gehypet, maar in de gevallen die Plasterk bagatelliseert, lijkt het me best zinnig om het algemeen toe te willen passen.

P.S. "voorkomen" en "zeker" schrijf ik tussen aanhalingstekens omdat het eigenlijk gaat om "voldoende moeilijk maken" en "redelijk zeker". Immers kunnen beginpunt en eindpunt van de communicatie ook gecompromitteerd zijn en zijn man-in-het-middenaanvallen ook met gebruik van versleuteling nooit volkomen uitgesloten.

[Reactie gewijzigd door mae-t.net op 26 juli 2024 14:28]

[Mr_Light]

Google baseert zich deels op hun empirische data maar ook gewoon op onderzoek van beveiligingsbedrijven en academisch onderzoek en daaruit komt voor al sinds 1994 keer op keer uit dat bij het selectief toepassen keer op keer weer die ene pagina gemist word waardoor de site 'lek' raakt.

In recentere tijden komt hier nog eens bij dat je bepaalde maatregelen niet kan toepassen als niet de hele site bereikbaar is onder https waardoor het relatief gemakkelijk word de browser met hun legacy behavior te misleiden om toch over http te verbinden. En als de website dan toch al volledig beschikbaar moet zijn waarom nog http aanbieden daar de overhead van https minimaal is.

De daadwerkelijke implementatie is eenvoudiger om simpelweg alles over https te doen, minder tijdrovend en je kost niet meer aan certificaten of je 1 pagina onder een domein over https serveert of alle.

Selectief https:
- werkt de menselijke fout in de hand.
- voorkomt aanvullende beveiliging maatregelen
- is duurder en ja het zijn wel mijn belasting centen.

+ data over http is niet te vertrouwen daar het onderweg aangepast kan worden, waardoor het volk dus verkeerd geinformeerd kan worden wat tot desastreuze gevolgen kan leiden. Het is weliswaar niet de wbp die dit afdwingt maar simpelweg het feit dat een regering zijn burgers goed dient te informeren dat de hele discussie een loze maakt, alles dient https te zijn.

// Beetje retoriek: MiTM is wel voorkomen met https (er komt overigens meer bij kijken dan alleen versleuteling) begin en eindpunt zitten immers niet in het midden. Natuurlijk kan je tussen het binnenhengelen en op het scherm zetten gaan zitten maar dat is weer een nieuw 'pad'/verbinding

[DigitalExorcist]

Ja en als ze het wél doen, krijg je daarna een 2e Diginotar-affaire natuurlijk. Daar kun je de klok op gelijk zetten..

[_root]

Diginotar was GEEN overheidsinstelling, dus wat die er mee te maken heeft weet ik niet.
Dit was een normale commerciële partij...

[tweaknico]

Ja het was een normale commerciele partij, maar toen bleek dat de Diginotar certificaten al enige tijd misbruikt werden, ZONDER dat bekend was hoeveel misbruik er was, stond de NL overheid er op dat Diginotar niet op de zwarte lijst mocht....
Diginotar was wel de preferred supplier voor de NL overheid. Beter was een noodcertificaat op de plank te hebben liggen die gedeeld kon worden en diginotar WEL accuut af te sluiten. Ik ben benieuwd of als de nieuwe certificaat voorziening op een dergelijke manier faalt of we weer dezelfde ellende krijgen.

Het probleem is dat alle Misbruik certificaten dan ook gewoon gebruikt kunnen blijven worden. Bij misbruik van de CA certificaten is de enige remedie om de CA certificaten ASAP (liefst met terug werkende kracht..., gaat helaas niet) buiten gebruik worden gesteld.
Start SSL et.al is een iets andere case, daar is de CA verschillende malen gemaand om zorgvuldiger met procedures om te gaan er is geen misbruik aangetoond van certificaten, maar wel een zeer groot gebrek aan transparantie waar tijdens de afhandeling van het ene incident uit de remedie voor dat incident bleek dat er nog andere incidenten waren... en dat verschillende keren achtereen.

[_root]

De overheid wilde Diginotar wel op zwarte lijst, maar wilde een maand uitstel.
Als je per direct alles ongeldig maakt gaat er nogal wat stuk. De websites zijn dan het minste probleem, maar vooral de communicatie tussen systemen gaat dan echt kapot en daar ga je in het dagelijkse leven behoorlijk tegen aan lopen.
De uitgegeven certificaten konden ongeldig gemaakt worden, maar het vertrouwen in Diginotar als CA onherstelbaar beschadigd.

Even een noodcertificaat op de plank, met als root De staat der Nederlanden, is een dure aangelegenheid, we hebben het dan niet over een 100 euro per certificaat. maar veelvouden daarvan

[Reactie gewijzigd door _root op 26 juli 2024 14:28]

[tweaknico]

Maar wat belet de huidige leverancier ook ook gehackt te worden?
Nogmaals de route van diginotar?

[_root]

Wat is het alternatief?
Alles draait om vertrouwen in de CA bij uitgifte van certificaten
Helaas was het bij Diginotar zo dat het ABSOLUTE vertrouwen in een paar dagen weg was, mede veroorzaakt door Diginotar zelf door geen open kaart te spelen.
Maar je hebt helaas geen garanties dat de volgende leverancier niet gehackt wordt. Het beste wat je kan doen door met audits de veiligheid te bewijzen, maar dat dit niet altijd werkt heeft ook Diginotar bewezen.

[tweaknico]

Denk na over wat CA certificaten betekenen...

ABSOLUUT VERTROUWEN dat zaken in orde zijn.

Op het moment dat er geen ABSOLUUT VERTROUWEN meer is kun je niet zeggen dat je het een beetje niet vertrouwd...
Het een kwestie van WEL / GEEN Absoluut vertrouwen.
Dus wat is beter:
1) We hebben ABSOLUUT VERTROUWEN maar weten het niet zeker of het echt OK is (Wel Certificaat)
2) We weten ABSOLUUT ZEKER dat we het niet weten... (==>Dus geen certificaat).

Mijns inziens Optie 2, dan is het voor iedereen direct duidelijk.
En als je besluit dat je Het certificaat wel nog blindelings vertrouwd (ondanks de rest van de wereld) dan mag je natuurlijk zelf je certificaten vertrouwd maken.
Waarbij wel aangetekend moet worden dat herstel spoedig moet plaatsvinden, en dat moet binnen enkele weken gedaan kunnen worden. Daarnaast zouden evt. termijnen die afhankelijk zijn van deze deadlines bv. 2-4 weken verlengd moeten worden.

Eenzelfde optie geldt ook voor het omgekeerde..., waarom wordt een deel van de websites van de NL overheid ondertekend met certificaten die code executie toestaan. (Code Signing). Ik heb de meeste van dergelijke CA certificaten uit m'n trusted store verwijderd. Ik verwacht geen code van de NL overheid te moeten ontvangen en laten lopen...

[_root]

Diginotar was een gerespecteerde CA, door notarissen opgezet.
Dus jaren lang ABSOLUUT vertrouwen tot er berichten verschenen dat certificaat door Diginotar uitgegeven misbruikt was.

Welke partij is wel geheel hackbestendig en maakt geen fouten?
Volgens mij hebben alle grote partijen al steken laten vallen...

[tweaknico]

Degenen waar het ontdekt is zijn af door de zijdeur:

Een van de subsidiaries van Comodo, recent Wosign, StartSSL.
Comodo als geheel is er nog wel juist omdat zij zelf aan de bel getrokken hebben over een van hun ondergeschikte bedrijven.

Het probleem is denken dat dit stilletjes voorbij kan gaan.
Het probleem is dat je maar een keer het vertrouwen kan beschamen... en dan is het ook definitief. Dus ook revoke & Blacklist.

Toevoeging:
PKI falen: https://sslmate.com/certspotter/failures

[Reactie gewijzigd door tweaknico op 26 juli 2024 14:28]

[supersnathan94]

Je kan wel degelijk alle certificaten van een CA in 1 klap ongeldig maken. Wat je dan met terugwerkende kracht wil doen (de certificaten vorige week dinsdag ongeldig verklaren gaat immers lastig) weet ik niet, maar het vereist wel de hulp van alle browser bouwers. Die moeten per direct de CA blacklisten.

[Blokker_1999]

Je kan wel degelijk een revocation doen op certificaten uitgegeven na datum X. Maar dan moet je er ook weer op vertrouwen dat de uitgefitde datum correct is, iets waar StartSSL enige tijd terug nog op betrapt werd.

[tweaknico]

Dat klopt, dat zeg ik ook. Alleen de NL Overheid STOND er op bij de Certificaat beheerders (Microsoft, Mozilla, om er een paar te noemen) om de Diginotar certificaten nog een jaartje in leven te laten ipv. te blacklisten.
Blacklisten kan ik de meeste gevallen binnen een week.
En terug werkende kracht is per definitie niet mogelijk, maar voor Diginotar zou 4 maanden terug werkende kracht destijds zeer wenselijk zijn geweest.

[Rutix]

Ik weet niet waar je vandaan haalt dat ze het een jaar in leven wilde houden want dat is helemaal niet waar. Ze wilde een maand uitstel zodat ze tijd hadden om al die systemen (en dat zijn er echt heel veel) van vervangende certificaten te voorzien zonder dat het allemaal stuk ging. En dat snap ik echt wel.

[tweaknico]

Hm. verkeerde bron blijkt, bij Mozilla staat dat de meeste Diginotar CA certificaten WEL revoked waren alleen de root van de "Staat der Nederlanden" voorlopig even niet.
Alleen heeft het wel bijna jaar geduurd voordat het uit de verschillende truststores verdwenen was.

Probleem was dat het al 4 maanden stuk was, en aantoonbaar misbruikt werd, voor ontdekking. Feitelijk is het onderzoek naar uitsluiting getriggered door het misbuik.

[_root]

Met de CA "Staat der Nederlanden" is ook niets mis.
Met deze worden andere CA getekend die de feitelijke signing doen van de certificaten.

Maar ik zat hel dicht op het vuur destijds, kan jij mij aangeven waar het "aantoonbaar misbruikt" werd voordat de eerste meldingen binnen kwamen.
Ik ben benieuwd of we dit eerder aan hadden kunnen zien komen, want toen het omviel was het dikke paniek.

Bij mijn beste weten ging het mis met het getekende gmail certificaat en kwam toen alles binnen een paar dagen

[tweaknico]

Google was de trigger voor het eind. Die hadden nav. het issues vanuit Iran van een vervalst certificaat schijnbaar afkomstig van Comodo extra controles ingebouwd bij gebruik van certificaten om te detecteren of andere dan hun eigen certificaat leverancier(s) als CA ondertekenaar voorkwamen.

Of er eerdere signalen waren is niet duidelijk in het Mozilla issue wordt gemeld: "Active in the wild" . (September 2011).

Zie ook:
https://blog.mozilla.org/...inotar-removal-follow-up/

Aanvulling: Volgens het artikel is gemeld dat Diginotar zei dat er 6 weken voor ontdekking een issue in het bedrijf was gezien, ik heb ergens gelezen (link niet meer gevonden) dat later audits melden dat er 4 maanden voor die tijd al issues waren. Diginotar wist in ieder geval 6 weken voor google het ontdekte al dat het mis was, en TOEN hadden er al maatregelen genomen moeten worden.

Toevoeging:
PKI falen: https://sslmate.com/certspotter/failures

[Reactie gewijzigd door tweaknico op 26 juli 2024 14:28]

[PuzzleSolver]

Die destijds de signer was van alle overheids certificaten.

[djiwie]

Nee hoor, er waren toen al meerdere aanbieders, KPN bijvoorbeeld.

[tweaknico]

Yep maar op het moment van falen van Diginotar was die de prefered supplier, KPN heeft die rol daarna overgenomen.

Er waren op dat moment een 50-tal CA leveranciers actief.

[DigitalExorcist]

dat dus.

[ToolBee]

De man is micro-bioloog. What else would you expect!

Ik had nog even hoop dat Mevr. Hennis deze post, na die andere opa's, zou krijgen...

[divvid]

Ja, en? Volgens mijn universiteits papiertje ben ik scheikundige. dat weerhoud mij er niet van om al mijn sites op https te zetten. Juist Plasterk is in de positie om dit met een pennestreek te regelen. De Kamervragen alleen al kosten meer dan alle certificaten die ze nodig hebben. Er is geen enkel excuus.

[Paul]

"De Kamervragen alleen al kosten meer dan alle certificaten die ze nodig hebben. Er is geen enkel excuus." Ooit met / voor grote organisaties gewerkt? Ja, de certificaten zelf hoeven niet zo heel duur te zijn; het werk om ze geïnstalleerd te krijgen op de servers daarentegen... Dat begint al met weten aan wie je kunt vragen waar die site ook alweer in beheer is. Dan het verzoek opstellen (1 week), offerte opvragen (nog een week), offerte ongelezen accorderen à € 2500 want men heeft toch geen idee wat het betekent of hoeveel het mag kosten (3 weken, want degene die mag tekenen is op congres), in laten plannen (1 week), uit laten voeren (5 minuten), en dan de hele mallemolen weer van voren af aan want het initiële verzoek had maar de helft van de info en de dienstverlener heeft dat op de goedkoopst mogelijke manier, maar wel exact volgens contract uitgevoerd.

Om het vervolgens nog een 3e keer te mogen doen want degene die de aanvraag opstelt heeft geen idee wat HSTS is en heeft dat in het verzoek overal vervangen door HTTPS.

Een jaar later heb je voor € 7500 de eerste site aangepast...

[divvid]

Ik werk zelf binnen een grote 10k+ organisatie en het is echt geen probleem om de juiste persoon te pakken te krijgen. Budgetering en accordering is fijnmazig zodat dit nooit een probleem hoeft te zijn bij dit soort kleine verzoeken.

Overigens is in mijn gemeente naar aanleiding van de berichtgeving binnen een dag een onbeveiligde dienst keurig beveiligd. Zo slecht als jij het schetst is het dus zeker niet.

[Paul]

Dan is het bij jullie wel goed geregeld, goed zo Dat is echter lang niet overal zo helaas.

[Raymond Deen]

Ik heb gekeken in bovenstaande posts of ik kon terug vinden waarom volgens mij het verplicht zou moeten zijn om HTTPS te gebruiken op ALLE overheidssites, maar kon het zo snel niet vinden...

De Overheid gebruikt het medium internet als hoofdkanaal om de burgers van informatie te voorzien.
Deze informatie zal dus gegarandeerd van de Overheid af moeten komen om betrouwbaar te zijn als primaire bron van informatie.

Daar bovenop zal dus ook een link naar een formulier waarop je als burger persoonlijke gegevens invult, gegarandeerd de juiste link moeten zijn. Zoals @87Dave hierboven terecht aanhaalt, ben je al mogelijk de pineut door de verkeerde link aangeboden te krijgen.

Natuurlijk zijn er nog veel meer eisen waaraan een site van de Overheid moet voldoen, namelijk dat alle geserveerde pagina's bijvoorbeeld vanaf hetzelfde domein verstuurd worden, dat de browser de instructie krijgt om HTTPS te blijven gebruiken, dat je geen fallback krijgt naar minder sterke encryptie-protocollen, etc.

Elke bedrijf die websites een beetje professioneel bedrijfsmatig online zet voor de wereld, moet aan deze en nog veel meer eisen voldoen, dus waarom niet je eigen Overheid die die regels nota bene zelf opgesteld heeft???

[onetime]

Als ik met "mijn prima werkende windows2000 computer" overheidssites wil bezoeken kan dat nog? Veilgheid is niet de enige eis, toegankelijkheid is dat ook...

[Raymond Deen]

Windows 2000 SP4 ondersteunt volgens mij al tls. Anders even zoeken naar KB977377.

Nou moet ik zeggen dat Windows 2k natuurlijk al behoorlijk bejaard is en je omwille van vooruitgang op een gegeven moment als bedrijf toch echt moet kunnen zeggen tegen gebruikers dat ze nou maar eens naar een volgende versie moeten overstappen.

En anders kan zo'n beetje elke redelijk recente smartphone de website alsnog gewoon openen; de websites van de overheid zijn echt voor zoveel mogelijk types gebruikers benaderbaar.

[onetime]

Dank voor je reactie. (en de KB977377) Maar de overheid is geen bedrijf. En kan personen niet vertellen dat ze maar moeten overstappen naar iets anders. Dat recht hebben ze gewoonweg niet. (werken overheidssites op Palm-OS? (paar jaar jonger dan W2k))

edit: ik interpreteerde

als bedrijf toch echt moet kunnen zeggen tegen gebruikers dat ze nou maar eens naar een volgende versie moeten overstappen.

als bedrijf dat zijn medewerkers op een nieuwe versie laat overstappen. Een bedrijf dat iets verkoopt kan dat never nooit niet aan zijn klanten zeggen.

[Reactie gewijzigd door onetime op 26 juli 2024 14:28]

[Raymond Deen]

Bedoelde met het bedrijf Microsoft en niet de Overheid.

Of het met Palm OS werkt zou ik niet weten, maar als het ook al meer dan 10 jaar oud is dan geldt daar naar mijn mening ongeveer het zelfde voor als win 2k apparaten, misschien zelfs nog wel sterker omdat mobile devices in de laatste 10 jaar nog veel meer in ontwikkeling zijn geweest dan pc's.

[onetime]

Ah, misverstand. Ik bedoel dat de overheid niet van burgers kan verlangen het nieuwste van het nieuwste te gebruiken, maar bij bijna alles moet zorgen dat het werkt. Van windows98 durf ik dat niet meer te eisen, al vind ik het zelfs van W95OSR2 wel wenselijk, maar van Windows2000 zeker wel.

En een bedrijf dat iets verkoopt mag dat never nooit niet laten stoppen met werken. En als ze willen dat ik overstap zorgen ze maar dat het net zo werkt als wat ik al heb en geven me de benodigde hardware erbij. Gaan ze beiden niet doen.
Wat mij betreft is Windows2000 het beste microsoft product, en X-Windows de beste windows

[Perkouw]

Doe dit soort uitspraken nou gewoon niet als je niet weet waar je het over hebt. Wanneer wordt er eens iemand aangesteld die daadwerkelijk weet waar hij het over heeft? Dit kan gewoon echt niet meer anno 2017.

Eigenlijk is het gewoon als gevaarlijk te bestempelen die man met al zijn uitspraken. Het raakt kant noch wal en is veelal pertinent onjuist. Belachelijk gewoon.

[mashell]

Dat zijn zware woorden maar zijn die wel terecht? Het enige waar ik bezwaar tegen heb is deze zin: "De overheid streeft ernaar om eind 2017 alle overheidswebsites waar persoonsgegevens en andere gevoelige gegevens worden gecommuniceerd van een versleutelde verbinding te voorzien." Daar ontbreekt het woord januari. Onversleuteld persoonsgegegevens verwerken kan gewoon niet, dat aanpakken heeft prioiriteit en moet in dagen en niet in maanden zijn afgerond. Maar homepages en dergelijke versleuteld versturen is echt van minder groot belang en zijn geen zware woorden tov de minister waard. Hij geeft belastinggeld uit. Als belastingbetaler stel ik het op prijs als hij daar wat terughoudend mee is en verstandige keuzes maakt.

[Perkouw]

Ik heb het dan ook niet over dit ene voorbeeld. Hij heeft in het verleden al meerdere malen laten blijken totaal geen kaas gegeten te hebben van het fenomeen dat IT heet. Dit soort dingen kunnen gewoon pertinent niet al denkt hij daar anders over.

[Rutix]

Hij is Minister van Binnenlandse Zaken. Weet je hoeveel verschillende soorten kennis hij zou moeten hebben als je al die replies van jou op alles waar hij over gaat zou toepassen? Hij heeft een achterban die hem van informatie voorziet. Als je dus zegt "er is geen kennis van zaken" dan zit dat probleem in zijn achterban en niet zozeer bij hem.

[Perkouw]

Misschien zit daar hem het probleem ook wel gewoon en hebben we een minister nodig die én verstand van zaken heeft én zich met dit domein bezig houd. IT lijkt af en toe wel een onderschoven kindje. En dan gaan mensen uitspraken doen die weer niet zo handig zijn, dat zie je keer op keer als je de nieuwsberichten op T.net er alleen al op naslaat.

Dat moet toch gewoon beter kunnen?

[dutchgio]

Je kunt wel weer lekker Overheid en IT 'bashen' maar wat betreft htpps op homepages is dat natuurlijk niet terecht: wat is het nut om die van https te voorzien?

Dat je privacy gevoelige gegevens nog niet over https verstuurd lijkt me wel 'not done'.

[supersnathan94]

Het nut daarvan is dat je zeker weet dat de info die jij voorgeschoteld krijgt ook daadwerkelijk zo verstuurd is.

Stel dat de hoofpagina van de belastingdienst ineens een extra regel bevat:
"Iedereen in nederland heeft sinds januari 2017 de verplichting om bij iedere aangifte €1 te betalen aan nlXXabnaxxxxxxxxxx tnv pietje".

Dat mag natuurlijk niet gebeuren en dat voorkom je dus met HTTPS. Tussen het verzenden en ontvangen is er niemand die met de data zou kunnen spelen.

[Blokker_1999]

maar met standard DV certificaten heb je nog altijd geen bevestiging of je aan de andere kant ook echt communiceert met de belastingsdienst.

[supersnathan94]

Klopt. Alleen is een man in the middle vele malen realistischer dan dat de belastingdienst gehacked is cq dns spoofing en dat er ook nog een certificaat wordt uitgegeven voor een domein wat op die manier wordt gebruikt. Plain HTML aanpassen is vrij simpel.

[CAPSLOCK2000]

Het probleem is dat iemand moet beslissen of deze ene pagina wel of geen HTTPS moet krijgen. Dat gaat regelmatig fout. Als je altijd HTTPS gebruikt kan dat aspect in ieder geval niet meer fout gaan.

[Anoniem: 300525]

Precies. Ik snap dutchgio's comment niet.
Beter altijd https toepassen, om verwarring, maar ook minder veilige pagina's te voorkomen (voor zover dat kan).

[dutchgio]

Dat zit wat in natuurlijk, maar in het rapport wordt daar een onderdeel als 'niet/minder veilig' aan gegeven. Qua overzichtelijkheid is het inderdaad veel logischer om alles te doen (technisch ook niet moeilijk), maar qua security klopt de nuance wel.

[GertMenkel]

Bijvoorbeeld omdat verbindingen over HTTPS niet laten zien welke webpagina's je bezoekt. Alleen de servernaam/hostname (zoals rijksoverheid.nl) is te zien, de exacte URLs zijn verder helemaal versleuteld. De overheidswebsite heeft zowel informatie over de samenstelling van het parlement als informatie over hoe men een misdaad moet melden of een klacht moet indienen bij de arbeidsinspectie.

Je werkgever vindt het misschien niet zo leuk om te zien dat jij naar het rapporteren van misstanden naar de arbeidsinspectie zoekt maar het bekijken van informatie over het parlement maakt hem niet zoveel uit.

Niet alleen de informatie die je verstuurd kan gevoelig zijn, ook de informatie die je opvraagt kan een probleem zijn. En daarom is TLS wel zo goed om te implementeren bij een autoriteit die veel werkt met gevoelige informatie zoals de overheid.

[Reactie gewijzigd door GertMenkel op 26 juli 2024 14:28]

[dutchgio]

Dat klopt, in dit geval ging het alleen on de homepagina's. Je kunt toch altijd al zien dat het domein bezocht werd, dus dat maakt geen verschil.

Verder stel ik inderdaad wel dat privacygevoelige gegevens wel over HTTPS zouden moeten, daar kunnen dat doort pagina's dan ook onder vallen.

[tweaknico]

Niet helemaal waar, Door de SNI indicator is de sitenaam wel openlijk leesbaar bij de eerste setup van een verbinding.

[GertMenkel]

Klopt helemaal! Dat is ook waarom ik dat voorbeeld van de overheidssite erbij zette, ik zal mijn bericht wat duidelijker verwoorden.

[Barsonax]

Welke pagina's dan wel en welke niet? Zit je sws weer met 2 technieken te werken. Hou het dan lekker simpel en gewoon altijd https.

[dutchgio]

Klopt, qua overzichtelijkheid en technisch gezien kun je beter alles doen, maar de nuance dat de hoofdpagina's zelf niet een enorm groot risico vormen klopt ook.

[frickY]

Nog zo iemand die denkt dat het alleen om het versleutelen van ingevulde gegevens gaat.

Maar wélke URL's je opvraagt kan net zo goed gevoelige informatie zijn.
Mijn werkgever, provider, uitbater van een wifi-hotspot, of wie dan ook, hoeft niet te kunnen zien dat ik op https://www.rijksoverheid...ds/meld-misdaad-anoniem-m of https://www.rijksoverheid...enen-bij-de-inspectie-szw ben geweest.

[Reactie gewijzigd door frickY op 26 juli 2024 14:28]

[DDX]

Als je werkgever dat wilt zien kan die ook logging op de dns server aanzetten en zien dat jij een resolve hebt opgevraagd van een van die websites.
Of zien dat er verkeer loopt naar een ip die als reverse overheid.nl oid heeft.

Als je dat niet wilt laten zien moet je met een proxy server oid gaan werken.

[RobinF]

Het bijhouden van deze gegevens (zoals DNS queries) valt onder de WPB, en mag dus, volgens de WPB, alleen gebeuren met een legitiem doel.

[kuurtjes]

DNS is alleen voor de domein naam en niet voor het path van de request. HTTPS versleuteld ook alle headers waardoor je dus niet kunt zien welke pagina opgevraagd wordt.

[Anoniem: 834471]

DNS logs ja. Ofwel, vertalingen van naam naar IP. Je weet daarmee evengoed nog niet welke informatie opgezocht is en daar zit hem nou net de crux.

[tweaknico]

Tenzij de sitenaam een vrij eenduidig etiket is voor het bezoek doel.

[MadEgg]

Dat dacht ik ook inderdaad. De requests zijn ook een stukje gevoelige informatie, zeker bij overheidswebsites. De voorbeelden die je geeft zijn gelukkig wel https

[tweaknico]

Maar moderne browsers laten de gevraagde hostnaam WEL enclair passeren in de announcement om certificaat selectie op een server mogelijk te maken.
Zoek maar eens op SNI (Server Name Indication)

[Blokker_1999]

De hostname kan je op vele manieren afvangen en die doet er vaak nog niet toe omdat menige site met reverse look-up ook weer te vinden zijn.

[tweaknico]

SNI is bedoeld voor multihost sites, zodat HTTPS net zo gebruikt kan worden als HTTP voor dergelijke sites( ie. de server kan kiezen welke certificaat die gaat gebruiken voor een net gemaakte sessie). Reverse lookup betekent dat er een, 1-op-1 relatie zou zijn tussen hostname en ip adres. Geloof me, dat is niet zo.

SNI betekent dus een positieve indicatie WELKE hostnaam bedoeld is.
Een IP adres is dat niet, zeker niet bij multi host sites.

[WhatsappHack]

Wil niet vervelend zijn, maar die links gebruiken toch ook netjes SSL?
Ik snap je punt trouwens wel. Wat jij opzoekt op overheidssites is privé. Of ik nou opzoek of ik een uitkering kan krijgen of iets simpels als wat de openingstijden zijn voor het loket om m'n rijbewijs te verlengen, dat gaat niemand iets aan.

[Reactie gewijzigd door WhatsappHack op 26 juli 2024 14:28]

[Ozzie]

Rijksoverheid.nl is juist HTTPS only Samen met nog heel veel andere overheidswebsites.

[frickY]

Het zijn slechts voorbeelden om mijn punt te maken. Maar ben wel nieuwsgierig naar de beweegredenen waarom het voor deze site goed is geregeld terwijl dat van de minister niet hoeft.

[Maulwurfje]

Is er hier iemand die wilt toelichten hoe makkelijk of moeilijk het is om een beveiliging in te stellen. Het blijft schandalig; maar als het technische lastig is klein beetje verdedigbaar.

[SunnieNL]

Een certificaatje aanvragen en toevoegen aan een Apache of IIS site voor een volledige url kan in een kwartiertje wel,gedaan zijn. Zitten er proxies, firewalls etc tussen, kost het je misschien iets meer, maar soms ook minder tijd.
Het is geen rocketscience. Het meest lastige is vooral onthouden dat je het na een jaartje ff verlengt

[PolarBear]

Mja, dat is te kort door de bocht. Je wil wel zeker weten dat de servers waarop je een certificaatje toevoegt goed is geconfigureerd en beveiligd. Ik bedoel als je een brakke server hebt die de private key lekt om maar wat te zeggen dan zijn de rapen gaar natuurlijk.

[SunnieNL]

Tja, een deurgat zonder beveilig je inderdaad niet met alleen een slot. Als de webserver niet veilig is heeft de inhoud erop beveiligen idd geen nut. Maar Plasterk gaat er in zijn verhaal vanuit dat die webserver al wel veilig is. Anders hebben we het over een nog groter probleem dan waar we het in het artikel over hebben.

[Reactie gewijzigd door SunnieNL op 26 juli 2024 14:28]

[SampleUser]

Het ergste is nog dat ze een eigen CA hebben die zo'n beetje overal vertrouwd is, waarom gebruiken ze die dan niet?

https://cert.pkioverheid.nl/

[tvdijen]

Deze wordt wel degelijk goed gebruikt.. Let wel dat de overheid zelf geen certificaten uitgeeft, maar dit is neergelegd bij een x-aantal intermediates.

[SampleUser]

Voor een overheidsproject waar miljoenen in wordt gestoken?

Nou, nee.

[CEx]

Lekker kortzichtig weer, de problemen die optreden bij het leveren van verkeerde informatie kunnen variëren van onschuldig, grappig, tot gigantisch groot.

[Keypunchie]

SSL geeft geen enkele garantie over juiste informatie. Strikt genomen zelfs niet of de identiteit van de leverancier wel klopt (voor de overheid mag je daar wel van uitgaan, alhoewel: Diginotar!!).

SSL zorgt er alleen maar voor dat niemand tussen de twee endpoints mee kan lezen. Dat is alles.

[CEx]

Voor de gemiddelde consument is het groene balkje in de browser inmiddels aan het inburgeren. SSL zorgt er niet alleen voor dat er niet meegelezen kan worden maar dat er ook niets aangepast kan worden.

En tja... Diginotar

[MrDrako]

Niets aangepast is niet helemaal waar, alleen niet aangepast op het moment dat je informatie ophaalt van de server. De server zelf kan door hackers allang foutieve informatie bevatten. Een virus kun je ook prima via https/SSL binnen halen.

[xFeverr]

Maar de informatie komt wel aan zoals het verstuurd is. Er is onderweg niet aan gerommeld. Dat er daarvoor en daarna iets veranderd kan worden betekend niet dat je dan maar gelijk alle beveiliging moet opgeven

[Anoniem: 613]

Weet je wel waarom Diginotar een probleem werd.

Dit kwam omdat ook (lees vooral het woord ook) de geheime dienst van Iran de beschikking kreeg over de root-key.

De gehele voorgaande periode van openstaan door Diginotar was geen probleem, mogelijk zelfs gewenst.

[CEx]

Dat weet ik ja.

[fiftyhillswest]

Dat is niet helemaal waar. "Standaard" certificaten bieden beveiliging én authenticiteit, dus je verbindt met de site waarmee jij ook denkt te gaan verbinden. Alleen EV certificaten bieden ook identiteit garantie.

[GrooV]

Keypunchie bedoelt namelijk dat er altijd een weakest link is. Als je wilt zijn EV cert's ook te vervalsen, echter zal de desbetreffende CA snel ingetrokken worden. Dit is namelijk ook zo bij DigiNotar gebeurd, een vertrouwde CA die malafide cert's uitdeelde

[Reactie gewijzigd door GrooV op 26 juli 2024 14:28]

[WhatsappHack]

"Dat is alles" is wel een beetje kort door de bocht imho, dat maakt namelijk wel een wereld van verschil... Je doet het haast klinken alsof t nauwelijks winst oplevert ten opzichte van plain-text communicatie met de server.

[tweaknico]

Niet alleen kan een man in the middle niet meelezen, de informatie kan ook niet on the fly gewijzigd worden. Dus als de overheid boodschap X wil uitdragen dan kan een ISP niet onderweg van de X een Y maken.

In de UK is dit jaren geleden al eens gedaan door een ISP, die meer geld wilde verdienen door om ALLE web content een advertentie deel te bouwen, dan wel van advertenties die opgevraagd werden de content te vervangen.

Aanvulling:
Naast een HTTPS + Certificaat zou er nog meer ingericht moeten worden.
Te beginnen met DNSSEC, alleen HTTPS is onvoldoende ook HSTS (met een heel lange tijd) en een goede DH gebaseerde sleutel generatie zijn vereisten.

[Reactie gewijzigd door tweaknico op 26 juli 2024 14:28]

[CAPSLOCK2000]

SSL geeft geen enkele garantie over juiste informatie. Strikt genomen zelfs niet of de identiteit van de leverancier wel klopt (voor de overheid mag je daar wel van uitgaan, alhoewel: Diginotar!!).

SSL zorgt er alleen maar voor dat niemand tussen de twee endpoints mee kan lezen. Dat is alles.

Het is niet perfect, maar het is in ieder geval een stuk beter dan niks doen.

[DigitalExorcist]

Zolang de diverse overheidsdiensten nog gewoon USB-sticks en laptops rond laten slingeren op straat kun je stellen dat hun definitie van 'gevoelige gegevens' niet helemaal overeenkomt met die van de rest van Nederland...

Laat Plasterk nou éérst eens zorgen dat die Miljoenennota niet uitlekt elk jaar. Dán mag hij een mening vormen over https en gevoelige informatie.

[Blokker_1999]

Je mag alsnog met een zeer correct beleid komen over hoe men met gevoelige data moet omgaan, mensen zullen altijd vinden dat veiligheid hun productiviteit in de weg zit en proberen de regels te breken om he werk toch maar gedaan te krijgen.

[DigitalExorcist]

Juist. In een ideale wereld zouden gebruikers in dienst van de ICT'ers moeten staan.. maar ja..

En deels snap ik dat ook wel. Je moet van goede huize komen wil je de urgentie van een goed veiligheidsbeleid over kunnen brengen naar de budgethouders van je bedrijf/klant. Of dat nou om simpelweg backups gaat, of wachtwoordbeleid ("ik snap dat Jantje en Pietje elke 2 maanden hun wachtwoord moeten wijzigen, maar ik ben directeur, maak voor mij maar een uitzondering, ééns per jaar is genoeg"). Gelukkig kom ik die laatste categorie eigenlijk nooit tegen, maar tóch zijn dat situaties die voor kunnen komen. Een firewall die ook naar buiten helemaal dicht staat? Prima plan. Totdat je als ICT'er élk .exe bestandje moet gaan lopen vrijgeven dat gedownload wordt (en legitiem is). Dan ben je er zelf óók wel klaar mee op een gegeven moment...

[CivLord]

Juist. In een ideale wereld zouden gebruikers in dienst van de ICT'ers moeten staan.. maar ja..

Met die instelling zal het nooit wat worden. Het zijn juist de ICT-ers die optimaal in dienst zouden moeten staan van de gebruikers. Natuurlijk is dat niet slaafs doen wat de gebruikers vragen, maar zorgen dat de gebruikers geen last hebben van ICT.
Zodra bv. beveiliging het werken lastig maakt, wéét je dat het werk onveiliger wordt doordat gebruikers die beveiliging proberen te omzeilen. Zodra je bv. zware eisen gaat stellen aan de lengte en complexiteit van wachtwoorden, wéét je dat dat talloze plakkers op monitoren oplevert waar wachtwoorden op staan. Daar kun je over bitchen, daar kun je weet ik wat aan willen doen, maar dat is de realiteit, dat zijn de randvoorwaarden waarbinnen je moete werken. Daar moet je dus rekening mee houden wil je ICT echt kunnen beveiligen.

[DigitalExorcist]

Precies, dat is het probleem ook een beetje. Nu ben ik zelf ICT'er, maar als ik ARBO-medewerker zou zijn zou iedere restaurantkeuken over een antislip-vloer beschikken, scheelt een hoop ongelukken. Maar als ik bij de Voedsel en Warenautoriteit zou werken, zou elke restaurantkeuken een gladde vloer hebben omdat die goed schoon te houden is en dus hygiënischer zou zijn.

Kortom: de wereld is niet ideaal en inderdaad, het beste netwerk is een netwerk waar géén gebruikers op zitten.

[WhatsappHack]

Dat is de menselijke factor waar je niets tegen doet, en naar ik vermoed juist wenselijk dat het lekt; ook al doen ze het voorkomen van niet... Zit altijd marketing vast aan het "lek".

[DigitalExorcist]

De mééste datalekken hebben een commercieel oogpunt. In dat geval wordt de data verkocht aan de hoogste bieder. Marketing of handel, same same..

[CAPSLOCK2000]

De mééste datalekken hebben een commercieel oogpunt. In dat geval wordt de data verkocht aan de hoogste bieder. Marketing of handel, same same..

Nee, de meeste datalekken zijn domme pech, vergeetachtigheid, ongeinteresseerdheid, gebrek aan geld en tijd of domweg incapabiliteit. De meeste datalekken veroorzaken we zelf. Als de data eenmaal op straat ligt dan wordt er ook gretig gebruik van gemaakt door allerlei foute figuren, maar volgens mij zijn er zoveel gaten dat hackers hun handen te vol hebben om ze allemaal te misbruiken.

[dakathefox]

Wij zijn er pasgeleden toe overgegaan om al onze websites - ook de informatieve - te voorzien van een SSL Certificaat. Niet omdat het moet, maar omdat het kan én omdat het nou net even een tikkeltje verzorgder staat. Het is een kleine moeite, zeker voor wie gebruik maakt van Let's Encrypt. Mocht Plasterk moeite hebben met de bijkomende kosten, dan is dát dus eigenlijk geen excuus meer.

[MadEgg]

Let's Encrypt is niet geschikt voor overheidswebsites. Ze zouden in principe prima een eigen implementatie van LE kunnen bouwen middels hun eigen root-certificaat, maar EV-certificaten zijn wel op zijn plaats bij de overheid.

[Blokker_1999]

EV voor https heeft imho slechts een zeer beperkte meerwaarde. Zelfs Google kiest voor DV certs.

[MadEgg]

Tja, en dan kun je dus net zo goed géén certificaten gebruiken, of de gebruiker ermee vermoeien. DV zegt zo weinig, zoals de geautomatiseerde wijze waarop LE ze verstrekt duidelijk laat zien. Dan heb je dus alleen encryptie en nagenoeg geen verificatie. Voor banken is dat not done, en voor DigiD en andere kritische overheidszaken ook echt niet. Informatieve websites zijn wat minder belangrijk qua verificatie. Toch zou ik beter verwachten van een overheid.

[dakathefox]

Je hebt gelijk. Maar het is in ieder geval allicht nog beter dan niets.

[RobinF]

Zou je dit kunnen uitleggen? Alhoewel ik er misschien niet super veel kaas van gegeten heb denk ik dat een DV-certificaat zeker genoeg is voor overheidswebsites waar bijvoorbeeld alleen informatie getoond wordt.

[djiwie]

Geautomatiseerd verlengen a la Let's Encrypt en EV lijken mij niet samen te gaan qua auditregels.