'Ondanks verbetering nog steeds veel overheidswebsites zonder https'

De Open State Foundation heeft opnieuw onderzoek uitgevoerd naar het gebruik van een https-verbinding bij de homepagina's van overheidswebsites. Ondanks een toename van het aantal https-pagina's is slechts iets meer dan de helft van de homepagina's van de techniek voorzien.

De organisatie meldt dat aantal https-homepagina's het afgelopen kwartaal met twintig procent is gestegen ten opzichte van de eerste meting in december. Toen gebruikte 44 procent van de websites een beveiligde verbinding; nu is dat aantal gestegen naar 52 procent. De totalen verschillen wel enigszins met respectievelijk 1816 en 1843 onderzochte domeinen. Van de 961 websites met https zijn er 90 verkeerd geconfigureerd, aldus de Open State Foundation.

Op verschillende niveaus is vooruitgang geboekt, zo is het aantal veilige websites van waterschappen gestegen van 40,9 procent naar 76,1 procent. Naar aanleiding van de invoering van het Pulse-programma, waar het scannen naar https-gebruik onder valt, heeft de Belastingdienst volgens de organisatie zijn pagina's voorzien van de techniek. In de eerste scan kwam bijvoorbeeld nog naar voren dat de homepagina van de fiscus van http gebruikmaakte.

Minister van Binnenlanse Zaken Ronald Plasterk maakte in januari bekend dat de wettelijke invoering van https voor alle overheidswebsites zal gelden. Daarmee kwam hij terug op een eerdere uitspraak, waarin hij een beveiligde verbinding alleen nodig achtte bij websites die gevoelige gegevens verwerken.

Onder andere SIDN kwam eind januari met een onderzoek, waarin de organisatie bedrijfswebsites onderzocht. Daaruit bleek dat ongeveer 85 procent van de bedrijfswebsites die gevoelige gegevens verwerken niet gebruikmaken van https. Het Forum Standaardisatie bracht eind februari een advies uit, waarin het adviseerde om https en hsts te verplichten in plaats van de technieken alleen aan te bevelen.

Reacties (91)

[Johan9711]

Zolang de pagina's geen gevoelige gegevens versturen naar de server is HTTPS toch helemaal niet nodig? Kost alleen maar meer servercapaciteit.

[Stoelpoot]

Nee, dat is een onjuiste aanname. Inloggegevens zijn bijvoorbeeld inderdaad gevoelig. Maar bijvoorbeeld een pagina die linkt naar een pagina met inloggegevens? Als hacker kan ik de link wijzigen om het naar mijn eigen, identieke pagina te sturen. Geen hond die erop let. Of als ik mijn eigen 'nieuwe functie' een in de pagina van de overheid stop? Je kan opeens op de hoofdpagina inloggen met je DigiD, gewoon in een popup die in wordt geladen. Aan de URL zie je het niet, maar stiekem gaat er een mooi plaintext wachtwoord naar mijn computer.

HTTPS kan geen half werk zijn. Het begint bij de eerste pagina, en stops pas bij de laatste. Elke onveilige pagina die ertussen zit kan je verkeer onderscheppen en je wegleiden van het beveiligde domein naar een vals domein.

[FvdM]

HTTPS alleen is niet genoeg tegen valse omleidingen, een aanvaller kan de alternatieve route immers ook over HTTPS doen. Niets is onkraakbaar, maar bij HTTPS kan je pas echt van beveiliging spreken als de client stricte verificatie toepast op HPKP, het DNS TLSA record icm DNSSEC en OCSP certificate revocation. En dan is er natuulijk nog de beveiliging van de hosting, nameserver en alle scripts daar omheen, maar dat is buiten de scope van de client.

Bijkomend is het aan de client om geen mixed content toe te staan, d.w.z. HTTP materiaal in een HTTPS parent. De meeste (moderne) browsers doen dat al.

Edit: mixed content

[Reactie gewijzigd door FvdM op 24 juli 2024 15:06]

[Keypunchie]

De meeste moderne CPU's hebben speciale crypto-instructies, die de overhead verminderen, daardoor wordt de CPU steeds minder belast:
https://en.wikipedia.org/wiki/AES_instruction_set

Voor alles dat het niveau IoT overstijgt is het voor het servergedeelte geen issue. Als client mag het voor geen enkel apparaat een issue zijn, dan is het ding gewoon underspecced en zou het het internet niet op moeten mogen.

De meer filosofische vraag is "wat zijn gevoelige gegevens"? Wat is wel/niet erg dat MitM kunnen meelezen. Is het feit dat je de pagina over chlamydia op Wikipedia leest wel of niet gevoelig? Is het opvragen van een plaatje met "great tit" in de naam iets dat verkeerd begrepen zou kunnen worden?
Om het maar niet te hebben over zaken als meta-data en wat de gevolgen kunnen zijn van iemand die _verkeerde_ informatie in je "niet gevoelige" gegevenssstroom stopt.

Daarnaast is er ook een argument uit het versimpelen van beheer. Wat ik nu, in heel professionele omgevingen, vaak genoeg zie gebeuren is dat een specifieke dienst uitvalt, omdat "het certificaat" verlopen was.
Zelfs Apple en Google overkomt het.
http://nos.nl/artikel/206...blemen-mac-app-store.html
http://www.pcworld.com/ar...srupts-gmail-service.html

Als je _alles_ van certificaten voorziet, dan wordt het ook het vervangen van die certificaten een veel routineuzer onderdeel van beheer. Scheelt ook dat je helemaal geen tijd hoeft te besteden aan discussies of iets "gevoelig" is of niet. Gewoon 1 veilige standaard voor alles. Die minimale kosten die je hebt aan iets meer capaciteit in hardware haal je er alleen aan de vergaderingen over "is een SSL-certificaat nodig" die je niet meer hoeft te houden, al uit.

Ik hoor nu al zeggen "Ja maar, Google en Apple met verlopen certificaten is toch juist een argument tegen overal SSL?" Nou ik durf te stellen dat bij kleintjes dit soort incidenten veel vaker gebeuren, relatief grotere impact op de bedrijfsvoering hebben en ook heb ik in de praktijk gezien dat vanwege gebrek aan ervaring met certificaten het tot wel dagen kon duren voordat ze het gefixt hadden.

[Reactie gewijzigd door Keypunchie op 24 juli 2024 15:06]

[Verwijderd]

Allemaal mooi.

Ik snap niet waarom het zo moeilijk is dit te implementeren? Kan iemand me uitleggen hoe veel werk het nu is om zoiets te doen? Is het niet iets triviaals? Of is dat ene s-je een Enorm Karwei?

Kom nou, is toch een uurtje werk?

[Yggdrasil]

Naast wat de anderen al zeggen moet je zorgen dat het hele proces geborgd is:
- Je moet een proces hebben voor verlenging van de certificaten. Overheden durven (of mogen) vaak niet met Let's Encrypt werken dus is verlenging arbeidsintensief handwerk.
- Mensen moeten misschien getraind worden. TLS is best complex is kan ingrijpende gevolgen hebben als je het verkeerd implementeerd.
- Er moet gemonitord worden dat de certificaten correct verlengd worden.
- Een team moet verantwoordelijk zijn voor het opvolgen daarvan en voor het bijhouden van ontwikkelingen op het gebied van cryptografische standaarden. Als zich immers zoiets als Heartbleed voordoet of als een cipher onveilig wordt verklaard dan moet iemand actie ondernemen en moet het team met prioriteit alles aanpassen.
- Je moet je applicaties aanpassen zodat ze bijv. de HSTS-header versturen, 'secure'-cookies zetten, etc.
- Het ontwikkelproces moet aangepast worden, zodat dit alles gebouwd en getest kan worden.
- Om de performance van je site niet veel te vertragen moet je Session-tickets of Session-cache in je server implementeren. Mogelijk is hiervoor een upgrade van je serversoftware nodig.
- Je moet bepalen welke TLS ciphersuite je gaat gebruiken. De meest veilige werkt alleen in moderne browsers. Een 'gemiddelde' suite werkt ook in oudere browsers (en bij overheidswebsites moet je die vaak ondersteunen) maar moet eerder aangepast worden als er kwetsbaarheden gevonden worden in algoritmes.
- Andere reacties noemden al dat je moet zorgen dat alle content via https geserveerd moet worden, ook ingeladen content van derden. Dit kan aanpassingen in het gebruikte CMS vereisen. Soms is dat gewoon een aan/uit setting maar als in de site hardcoded URL's zijn gebruikt dan moeten die allemaal bijgewerkt worden. Content van derden is misschien zelfs niet via https beschikbaar.

[Merkane]

Het ligt er maar net een beetje aan wat voor functionaliteiten je website heeft. Als het een plain html pagina is, kost dit nog geen 5 minuten werk In feite, hoe meer functionaliteit en complexiteit je website heeft, des te meer dingen moet je gaan controleren of alles nog werkt zoals verwacht als je de site via https benaderd. De meeste dingen zullen gewoon werken maar je hebt ook kans dat code herschreven moet worden omdat er hardcoded (ja dat kan nog steeds anno 2017) http links overal staan.

[MuffinZor]

Of dat er externe diensten / sites gebruikt worden in de site die nog niet op https bereikbaar zijn. Of ongeldige certificaten gebruiken..
Waardoor in de meeste degelijke browsers tegenwoordig die content actief geblokkeerd word, want er zitten onveilige elementen in je 'veilige'(https) pagina.
Het zijn dus dependencies waar je rekening moet mee houden.

Je kan druk zetten op die externe partijen om sneller de switch te maken naar https maar ondertussen kan je wel zitten wachten..

[MadEgg]

Het nare van SSL cerificaten is de geldigheidsduur. Hoe vaak ik niet mensen aan de telefoon heb om te melden dat hun browser het certificaat niet accepteert. Dan blijkt hun laptop recent zonder batterij gezeten te hebben waardoor de klok compleet verkeerd staat. Daar zouden moderne besturingssystemen best eens een berichtje over kunnen tonen:

"hee, uw klok staat in 1970, toen was dit OS nog niet geschreven. Internet gaat zo niet werken!"

[djiwie]

Elk modern OS heeft een vorm van tijdsynchronisatie ingebouwd.

[MadEgg]

Ja, maar dan moet die wel afgerond zijn. Als je batterij leeg was en je je laptop start en direct naar een website met SSL gaat, is de kans aanwezig dat je klok nog niet gelijk staat en je dus een beveiligingswaarschuwing krijgt. Probeer je het een minuut later dan kan het op eens wel werken, maar ondertussen hangen ze dus al wel bij je aan de telefoon.

[PolarBear]

Sorry hoor maar dit is echt een uitzondering geval wat je nu beschrijft.

[MadEgg]

Het is wel een uitzondering waar ik al tientallen klanten over aan de telefoon gehad heb, dus zo uitzonderlijk is het in de praktijk niet blijkbaar.

[Yarisken]

Nee hoor, heb het vroeger ook regelmatig voorgehad met users.

[RobinF]

Maar de tijdklok loopt niet op de laptopaccu. Die loopt op een aparte "batterij" die door loopt als de accu leeg is (of er zelfs uit is)

[MadEgg]

Geen idee wat de oorzaak is, maar mijn praktijkervaring is dat het nog best regelmatig voorkomt. En dan dus alleen als mensen te snel willen; zet je je laptop aan en ga je eerst koffie halen dan is er niets aan de hand. Klik je gelijk door naar een website met een SSL-certificaat dan gaat het fout.

Ik heb het zelf ook ervaren met de OwnCloud-client - die zet ook direct een SSL verbinding op met de server zodra je opgestart bent, wiens certificaat vervolgens wordt geweigerd omdat de client direct met het OS mee opstart.

Dode batterij = garantie op certificaatwaarschuwingen.

[hackerhater]

Dat lijkt me eerder een typisch probleem met Windows.
Ik heb het met Linux gehad dat de bios batterij + accu leeg was en het opstarten wachtte toch echt wel op de time-synch omdat het OS door had dat de datum niet kon kloppen.

Iets van kloktijd < uitgave time OS.

Maar dan heeft je machine wel vaak zonder stroom gezeten want de mobo-batterij hoort de klok in orde te houden.

[Reactie gewijzigd door hackerhater op 24 juli 2024 15:06]

[mjtdevries]

Dat lijkt me eerder een typisch probleem met Windows.

Grappig dat je dat zegt, want 1970 wijst nou juist typisch op Linux (Unix) Die telt namelijk de tijd vanaf 1970.
Windows telt vanaf 1601

[hackerhater]

Je bedoeld dat windows afwijkt van de internationale afspraak dat timestamp 0 1-1-1970 is?

[mjtdevries]

Je bedoeld dat windows afwijkt van de internationale afspraak dat timestamp 0 1-1-1970 is?

Oh jij denkt dat er een internationale afspraak voor is? Toch wel typisch dat alleen posix/unix die dan gebruikt. (en alles wat daarvan afgeleid is)
Wellicht kun je aangeven waar het bij IETF gedefinieerd is?

Overigens wel grappig om te zien hoeveel verschillende systemen er zijn en wat voor vreemde jaartallen daar bij zitten. 1601, 1753, 1840, 1858 etc etc. Je vraagt je af hoe iemand er bij komt om zo'n jaartal te kiezen.
https://en.wikipedia.org/wiki/System_time

[hackerhater]

Tjah je hebt officiële standaarden en een gentleman's agreement.
Als iedereen zich eraan houd, maar de laatkomer op netwerken-gebied Windows niet, wie wijkt er dan af?

Als je zegt timestamp zonder iets erbij zal elke programmeur en sysadmin verwachten dat je een unix-timestamp bedoeld...........

[mjtdevries]

Als je zegt timestamp zonder iets erbij zal elke programmeur en sysadmin verwachten dat je een unix-timestamp bedoeld...........

Alleen heeft niemand het woord timestamp gebruikt.:)

En laten we eerlijk zijn. Zo vroeg was unix nou ook weer niet. Zij weken ook gewoon af van de eerdere systemen. (waarvan je in de link een aantal voorbeelden kan zien)
Maar ach, tot de jaren 80 was het normaal dat een computer de tijd helemaal niet bij hield. Dus het boeide niemand...
Nu niet meer voor te stellen

[Ero-Sensei]

Dus een simpele wijziging in het certificaat dat de controle op datum/tijd niet lokaal gebeurd maar centraal en dit is opgelost.

Toch hopeloos dit. Een certificaat op je computer die alleen aangesproken zal worden tijdens een online toepassing die dan de datum lokaal/offline gaat uitlezen.

En dan nog maar niet te spreken over de schijnbaar vele knoopcellen die in jouw omgeving kapot gaan.

[Hendrik53]

Geen enkel probleem met Owncloud en Nextcloud clients. Ook de server geen enkel probleem. Er staat een heel goed voorbeeld van een correcte configuratie voor Apache, Nginx en LetsEncrypt op de site. Werkt gewoon prima en heel stabiel. Ook de controle op onveilige instellingen.

[smiba]

OS X doet dit vriendelijk

Windows zou de tijd synchronizeren binnen enkele minuten na een verbinding en als die verbinding er al is bij het opstarten vrijwel direct.

[MadEgg]

Ik zelf zelf dit probleem anders ook vaak meegemaakt op mijn MacBook Pro. Weet niet wat jij er vriendelijk aan vond, maar ik kreeg gewoon een 'Deze verbinding is niet veilig' waarschuwing en verder niets.

De synchronisatie is niet het probleem, het probleem is dat het OS niet doorheeft dat de tijdsinstelling buiten de te verwachten datums valt en dat daaruit af te leiden is dat de tijdssynchronisatie mogelijk nog niet is afgerond.

[smiba]

Bij het opstarten zou er "Tijd incorrect" als melding moeten komen, net zoals je normale push berichten ontvangt. Hier staat ook de instructies om de goede tijd in te voeren en dat de datum voor nu is teruggezet is naar 1 Januari, 2001

[Reactie gewijzigd door smiba op 24 juli 2024 15:06]

[MadEgg]

Ik gebruik OS X het afgelopen jaar niet meer regelmatig want mijn MBP is vervangen, maar push messages? Die ken ik op mijn iPhone maar heb ik op m'n laptop nog nooit ontvangen. Wanneer is dat ingevoerd?

[smiba]

Zit er volgens mij al enige tijd in, geen idee of het echt deel uitmaakt van het systeem of een deel van Safari zelf is. Weet namelijk wel dat websites push notifications mogen kunnen versturen.

Natuurlijk kunnen daemons op de achtergrond ook een eigen push service of iets dergelijks draaien om zo notificaties in het Notification Centre weer te geven

EDIT: Lijkt in 2014 geïntroduceerd te zijn in Safari.

[Reactie gewijzigd door smiba op 24 juli 2024 15:06]

[hackerhater]

De makkelijkste oplossing op OS-niveau is om de tijd-synch al te starten tijdens opstart indien mogelijk.
Ipv dat pas te doen wanneer de omgeving van de gebruiker ingeladen is.

[Maurits van Baerle]

Je zou eigenlijk denken dat het voor een OS een koud kunstje moet zijn om een heleboel van dat soort gevallen accuraat te detecteren.

Als je de datum waarin het OS geinstalleerd is (en daarna ophoogt bij iedere update van het OS die geinstalleerd wordt) uitleest moet het voor het OS makkelijk vast te stellen zijn dat de systeemklok staat op een tijd van voordat het OS/update geinstalleerd werd en er dus iets mis is.

In zo'n situatie zou het OS de hoogste prioriteit kunnen geven aan het tijdssynchronisatieproces of zelfs een dialoogvenster kunnen weergeven om de huidige datum in te voeren voordat je verder kunt.

[Genius-General]

Hierom:
https://developers.google...rypt-in-transit/why-https
https://https.cio.gov/everything/

[jerkitout]

Maar je will ook niet dat je klein hobby website wordt gehijacked door een ISP die zijn eigen ads dan in je website inject.

Dit is eerder al in Amerika gebeurd.

[bantoo]

Als of die bakken op het encryptie deel een bottleneck hebben. Dit is een leugen 99/100 keer dat het als argument gebruikt wordt.

[Johan9711]

Nah, ik heb een aantal webservertjes draaien met niet al te goede hardware, en dan merk je het snel in de performance hoor, niks geen leugen aan.

[Rataplan_]

Ik denk niet dat de overheid op raspberry pi's draait. Op een fatsoenlijk Xeon systeem merk je dat niet (of je moet echt gaan meten). Ik doe een volle gbit HTTPS encryptie op onze systemen en dan belast ik maar één thread een beetje. Nog 39 threads over.

[mxcreep]

Ik draai hier met Apache reverse proxies, Apache vanwege SAML authenticatie, voor een paar applicatie clusters met tienduizenden gebruikers, Apache doet hier ook SSL termination voor Tomcat. De grotere clusters hebben 2 GB ram en 2 vCPU's, voornamelijk vanwege de SAML module. De kleinere clusters doen het met 1 GB ram en 1 vCPU...

Dat het veel resources kost is dus onzin, dit is virtueel en ook nog eens redelijk laag geschaald. Een beroerde config voor Apache kost meer performance dan HTTPS inschakelen.

[Dorank]

Het is ondertussen al weer enkele jaren geleden (2012/2013), maar op het moment dat er CPUs met AES-NI op de markt kwamen was het tijd om de Brocade loadbalancers met SSL offloading toch maar geen SSL meer te laten afhandelen, de backend servers (met een up to date openssl) waren veel sneller (in throughput en latency in het opbouwen van de connectie) en de extra CPU overhead op de backend was nihil.

[bytemaster460]

Ik denk dat het anno 2017 standaard moet zijn dat je websites via https aanbiedt, ongeacht de info die over de lijn gaat.

[himlims_]

precies dat, zolang er geen data over en weer gestuurd wordt, is de noodzaak beperkt

[Verwijderd]

Today, there is no such thing as non-sensitive web traffic, and public services should not depend on the benevolence of network operators.

Lijkt me reden genoeg. Ook al heb jij / ik / de buurman niets te verbergen, zou je het prettig vinden dat iemand over je schouder aan het meekijken is?

SSL / HTTPS is niet zo spannend (integratie) en de performance valt ook best mee. Ik heb 14 servers met verschillende en ook echt vrij grote sites en doen qua performance net zo snel als met / zonder https. Het ligt er ook aan hoezeer je de site weet te tweaken en de overhead gewoon minimaal houdt.

[Stoelpoot]

Data over en weer sturen is letterlijk wat een web pagina is

[ASS-Ware]

Zolang de pagina's geen gevoelige gegevens versturen naar de server is HTTPS toch helemaal niet nodig?

Zeker wel.
De bezoeker wil zeker weten dat hij op de juiste website terecht is gekomen, met een SSL/TLS certificaat wordt dat gecontroleerd.
Bovendien wil je zeker weten dat de data/informatie van de website onveranderd aankomt bij de bezoeker en niet is aangepast middels een MiM attack.

[Shaggie_NB]

Zo makkelijk dat overheids bashen...
Kijk bv eens dit onderzoek:
https://www.sidn.nl/downl...190217%20(definitief).pdf
waar banken en bedrijven veel minder beveiligd zijn dan de gemeentes.
Uit het onderzoek blijkt dat gemeentes bijna de hoogste scores hebben met 63% waar beursgenoteerde bedrijven op 12% zitten....

[kozue]

Verschil is natuurlijk dat als een bedrijf geen https gebruikt, je kan kiezen om geen diensten of producten van ze af te nemen en naar de concurrentie te gaan. Bij de overheid zijn er geen alternatieven want er is maar 1 overheid. Bovendien spelen overheden met ons belastinggeld, en bedrijven met hun eigen inkomsten. Als een bedrijf gehacked wordt en failliet gaat door vergoedingen, compensaties, boetes, etc, laat ik daar geen traan om, maar bij een overheid is dat wel erg vervelend, want je kan niet zonder ze.

[Verwijderd]

Tja, zolang er geen controle is op zaken als BIR (Baseline Infrormatiebeveiliging Rijksdienst) en er onvoldoende Architectuur richtlijnen zijn blijft het sappelen. In feite was https al vanaf 01-01-2015 verplicht maar daar werd niet op gecontroleerd. Alleen het neerleggen van een baseline zonder daar een goede interpretabele uitleg bij te geven is voor de gemiddelde persoon bij de overheid totaal onduidelijk. Met andere woorden: tijd om de BIR uit 2012 een compleet te herzien en strikte eisen te stellen. Ook een jaarlijkse herziening zou niet misstaan. Ook zou de BIG (Baseline Infrormatiebeveiliging Gemeenten) gelijk moeten zijn aan de BIR. want Rijksoverheden, provincies en gemeenten hebben weer andere baselines en kunnen die ook weer op geheel eigen wijze interpreteren.

Zachte heelmeesters maken stinkende wonden. Dit geld zeker voor de huidige manier van het opstellen van de informatiebeveiligings richtlijnen die er momenteel zijn binnen de overheid.

[buzzin]

En laten we de BIR dan ook eens opstellen in het algemeen en niet 99,99999% gericht op windows systemen. En haal a.u.b. alle onzinnige dingen er ook uit.
Hier hebben ze dingen moeten implementeren omdat iemand dat ooit belangrijk vond.....een banner in je ssh sessie die zegt dat je niet stout mag zijn .... ja, want dan gaat de hacker stoppen.
Maar ondertussen echte beveiliging negeren, want tis geen windows.

[wizzkizz]

Een banner gaat een hacker inderdaad niet stoppen. Maar het is vast een juridisch dingetje dat later de kans op een succesvolle rechtsvervolging vergroot. Een aangezien het quasi geen moeite is om zo een banner te tonen, zou ik me daar niet zo druk over maken. Je laatste punt is wel een dingetje ja...

[Luno]

De BIR zou het meer over intenties moeten hebben, wat wil je bereiken. En windows is een implementatie. Maar het lijnmanagement dat verantwoordelijk is voor het laten toepassen van de BIR begrijpt alleen maar windows. Dus een abstracte BIR werkt ben ik bang ook niet.

En er staan best wel wat onzinnige, of toegepast op jouw situatie onzinnig, dingen in. En dan kun met explain (comply of explain) een deel negeren.
Vervolgens komt er iemand van boven die gaat afvinken of je alles complied. Dat explain een even goede beslissing is, wordt niet gezien. En dan moet je maatregelen nemen die overbodig zijn, maar genomen worden om de account tevreden te stellen. Daarmee kweek je weerwil, en oplossingen die goed ogen voor de accountant, maar het niet zijn.

[Verwijderd]

De BIR is niet gericht op windows. in de BIR staan alleen algemene richtlijnen. Het invoeren van een banner staat dus ZEKER niet in de BIR. Ik geloof dat je de BIR verwart met de implementatie van oplossingen. BIR is een richtlijn (of Richtsnoer zoals het officiele rijks vocabulaire voorschrijft) en de rijksdiensten kunnen deze zelf interpreteren zoals hen goed dunkt. Dus ik gok dat jij een Architect hebt gehad die dat graag wilde zien.

[Verwijderd]

Ik begrijp je punt; het snijd ook enigszins hout alleen je manier van verwoorden is niet al te best. om in te gaan op je opmerking:

Natuurlijk is dit een gezegde en waarom ik heb gebruik is: binnen de overheid ontstaan er teveel discussies zodra mensen niet snappen wat er moet gebeuren of zodra mensen het er niet mee eens zijn.

Je kunt hem (de BIR) niet direct online vinden (helaas) maar ik heb hem nu tientallen keren doorgelezen en het probleem blijft dat het zo vrij interpreteerbaar blijft dat iedereen die het leest het weer anders ziet.

Binnen de overheid is er bijvoorbeeld geen vaststaande security autoriteit die door alle overheden als leidend word gezien. Om er toch voor te zorgen dat alle overheden enigszins het zelfde doen is de eerdergenoemde BIR als richtlijn opgesteld.

Het aanvraag proces van een certificaat is momenteel onnodig lastig. De aanvraag kan zomaar 10 tot 12 weken duren. Je begrijpt dat dit de uitgifte van certificaten onnodig moeilijk maakt en vertragend werkt. De meeste projecten wachten daar niet op en gaan voor een http oplossing. iets wat tijdelijk is toegestaan (max 12 weken I.V.M. de bovenstaande aanvraag.) Je begrijpt: zodra de website in de lucht is en het project succesvol wordt afgerond; de restpunten nooit meer worden opgepakt (https).

Om dit te voorkomen zou de Overheid iets als een Rijks SOC moeten inrichten wat centraal de oplossingen gaat aanbieden aan alle rijksoverheden. En daarmee bedoel ik dan dat zij centraal de security architectuur oppakken en gaan toetsen bij alle rijksoverheden op de naleving hiervan. Op die manier komt de controle meer bij de minister te liggen.

Zo even mijn 5 cent..

Edit: typo.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:06]

[Verwijderd]

Het is niet alleen een gezegde het is een feit. Het probleem van de overheid is dat de diensten van de overheid geen geldwaarde op de markt hebben. Er is dus geen winst/verlies analyse te maken op de activiteiten van de overheid. Er zijn dus ook geen efficiëntie slagen zoals een bedrijf dit zou doen. Namelijk de kosten verlagen, zonder dat de marktwaarde van een dienst of product daalt.

Kijk naar een Yahoo die gehacked is, dat heeft de aandeelhouders honderden miljoenen gekost. Een hack van een overheidsbureau zal geen invloed hebben op de marktwaarde. Er is namelijk geen marktwaarde. Waar bedrijven dus een direct belang hebben bij het zo efficiënt mogelijk oplossen van dit soort risico's, heeft een bureaucratie dit niet. En dit is natuurlijk een enkel voorbeeld. Dit geldt bij vrijwel alle activiteiten van de overheid.

Je kunt het de mensen bij de overheid ook niet kwalijk nemen, het is inherent aan bureaucratie.

Edit: multiple typo's

[Reactie gewijzigd door Verwijderd op 24 juli 2024 15:06]

[tvdijen]

De BIR staat weldegelijk online:
http://www.earonline.nl/i...IR_TNK_1_0_definitief.pdf

Wat betreft de security-autoriteit, die is er inderdaad niet in die hoedanigheid, maar er wordt natuurlijk wel geaudit door de ADR en in voorkomende gevallen door de NBV of MIVD. Als die met een rapport komen kun je die ook niet zomaar naast je neerleggen als overheidspartij.

Wat je zegt over certificaten is onzin.. Deze worden dezelfde dag nog geleverd, waarbij het proces volledig digitaal / paperless is (of kan zijn, het hangt ongetwijfeld af van welke leverancier je kiest).

[Verwijderd]

Fijn dat je de link deelt. Bij het overheidsonderdeel waar Ik zat zat alles achter accounts en wachtwoorden. ook fijn dat je het eens bent met mijn standpunt met betrekking tot een overkoepelende security autoriteit.

In de 2 jaar dat ik bij de rijksoverheid heb gewerkt heb ik geen ADR, NBV of MIVD gezien. Ik had ze graag ontvangen om diverse projecten de ernst van de situatie te kunnen laten inzien. Ook op andere vlakken dan alleen https certificaten werden daar dikke beveiligingsblunders gemaakt.

Certificaten bij de rijksoverheid zijn heel iets anders dan een particulier aangevraagd certificaat. Wellicht zit jij bij een onderdeel waar dit beter geregeld is. Bij het onderdeel waar ik zat was dit geregeld zoals door mij beschreven. Alles gaat daar via een externe partij. Ik heb er persoonlijk voor gepleit om dit weer in eigen beheer te nemen echter liep dat contract destijds net 1 jaar en was er voor 5 jaar getekend. Jammer dat je het meteen afdoet als "onzin". je weet nooit hoe goed of slecht het geregeld is bij een ander onderdeel.

[tvdijen]

Dan moet je het niet brengen alsof het bij de gehele Rijksoverheid zo is, want dan is het onzin
Ik herken de praktijk wel die je omschrijft, maar die zie je vaak bij de eigenwijze onderdelen die alles zelf willen doen... Er zijn echter prima voorzieningen op Rijksniveau.

Bij ons komt de ADR in ieder geval jaarlijks langs voor een audit, maar dat komt misschien ook door het vakgebied/expertise van de afdeling waar ik werk.

[diekli]

Er is een perceptie dat SSL 'goed' is voor de mensen, maar dat is het NIET.

Door het gebruik van encryptie worden de meeste beveiligingsoplossingen omzeilt. Oftewel je bent niet meer beschermd tegen de bedreigingen op het Internet. Bij veel bedrijven is het nog altijd zo dat onder druk van legal, HR en/of vakbonden wordt geprobeerd om SSL Scanning te voorkomen, terwijl het juist essentieel is als onderdeel voor de uitvoering van je beleid.

Privacy is belangrijk, maar als een trojan (RAT) je informatie (inclusief Webcam) beheert dan heb je een veel groter probleem dan dat iemand ziet welke pagina's je op Tweakers bezoekt.

[Martin.l]

Virus scanners als Avast lossen dat probleem heel makkelijk op door een eigen root certificaat te installeren op je computer.

Nu is dat ook niet ideaal natuurlijk, maar https is zeker niet onmogelijk te inspecteren door beveiligingsoftware.

[Maurits van Baerle]

Er is anders ook een hoop kritiek op malwarescanners die feitelijk een MITM aanval uitvoeren op je verbinding. Je malware scanner wordt daarmee in zekere zin ineens een attack vector zelf.

Ik heb zelf niets tegen malware scanners, mits goed ontwikkeld en goed geimplementeerd, maar het uitpakken van TLS verbindingen gaat mij te ver.

Het is ook helemaal niet nodig om TLS connecties uit te pakken om malware te onderscheppen. Zolang het encrypted is kan zowel malware als de eindgebruiker niets dus het wordt sowieso aan het einde gedecrypt. Op dat punt heeft een malwarescanner toegang tot het geheugen én de schijf en zou dus prima in staat moeten zijn om te onderscheppen.

[tvdijen]

Het probleem is dat je je malware dan al je vertrouwde interne netwerk in hebt gesleurd. Daarom wordt er vaak 'aan de voordeur' al geoffload/geïnspecteerd.

[diekli]

Inderdaad, als je de rommel stopt voordat het je netwerk/device bereikt, dan hoef je niet meer (alleen) op een endpoint oplossing te vertrouwen. Je wilt meerdere lagen voor je beveiliging...

@MartinJ
Voor mij is een endpoint generiek, ik heb het dus niet alleen over Windows/MAC/Linux, maar ook over IOS/Android etc.
Te vaak zie je nog bedrijven die andere policies hanteren op basis van lokatie (op kantoor zijn er Next-Gen Firewalls, Proxies, IPS -> thuis niet beschikbaar) of op basis van device (Anti-Virus, Personal Firewall, DLP clients op je Windows, maar hoe veel van die oplossingen draaien op IOS?)

[Keypunchie]

Bij veel bedrijven is het nog altijd zo dat onder druk van legal, HR en/of vakbonden wordt geprobeerd om SSL Scanning te voorkomen, terwijl het juist essentieel is als onderdeel voor de uitvoering van je beleid.

Hoezo dat, je kunt a) gewoon nog steeds malware domeinen blocken b) op je endpoints zelf scannen c) SSL interception gebruiken (ok, dat is dat je zelf de MitM uitvoert, maar dat kan alleen omdat je ook de endpoints beheerd)

[CAPSLOCK2000]

Er is een perceptie dat SSL 'goed' is voor de mensen, maar dat is het NIET.

Door het gebruik van encryptie worden de meeste beveiligingsoplossingen omzeilt. Oftewel je bent niet meer beschermd tegen de bedreigingen op het Internet. Bij veel bedrijven is het nog altijd zo dat onder druk van legal, HR en/of vakbonden wordt geprobeerd om SSL Scanning te voorkomen, terwijl het juist essentieel is als onderdeel voor de uitvoering van je beleid.

Privacy is belangrijk, maar als een trojan (RAT) je informatie (inclusief Webcam) beheert dan heb je een veel groter probleem dan dat iemand ziet welke pagina's je op Tweakers bezoekt.

In de netwerkwereld bestaat de perceptie dat je beveiliging op netwerkniveau moet doen. De rest van de wereld beweegt langzaam naar end-to-end security en daarom wordt alle beveiliging op netwerkniveau steeds moeilijker.
Er zijn er die het een goed idee vinden om alle verbindingen via een centraal punt te laten lopen daar de encryptie open te breken. Dat klinkt geweldig tot die doos gehacked wordt, dan ben je al je veiligheid in één keer kwijt. Typisch is die doos dan ook nog een of andere zeer complexe blackbox die je zelf niet kan onderhouden.

End-to-end beveiliging is de way to go, want als je het niet doet is er altijd een stuk van het pad dat niet wordt beveiligd. Daarbij heb je op de eindpunten de meeste informatie om de juiste beslissingen te nemen.

Privacy is belangrijk, maar als een trojan (RAT) je informatie (inclusief Webcam) beheert dan heb je een veel groter probleem dan dat iemand ziet welke pagina's je op Tweakers bezoekt.

Als iemand kan zien welke pagina's ik bezoek dan kan die persoon ook een MITM doen en die trojan in de pagina's van Tweakers embedden voor ze op mijn computer aankomen.

[diekli]

Security heeft bij voorkeur meerdere lagen, dus naast endpoint heb je een netwerk oplossing nodig.

Je hebt helemaal gelijk dat via een (of regionale) gateways (centraal punt) een volledig achterhaalt model is. Deze passen niet in een infrastructuur van mobiele devices en Cloud oplossingen. De informatiestroom gaat (bijvoorbeeld) van een mobiel device via een 4G verbinding naar Azure/AWS/icloud/box/etc. Hier zit geen enkele gateway meer tussen.

Dit is trouwens ook van toepassing op SDWAN of Hybride netwerken, dat verkeer haal je ook niet meer centraal. Dus je zult Security in de Cloud moeten doen - als je een meerlaags Security model wilt hebben.

Misschien dat je op een eindpunt (enduser device) bepaalde beslissingen kunt nemen, maar ik kom steeds vaker dat die devices als untrusted worden beschouwd. Denk maar aan BYOD, je hebt weinig zeggenschap over het device, je kunt hoogstens bepaalde policies afdwingen (remote wipe etc) .

* Voor compliancy redenen is het totaal onwenselijk dat er end-to-end encryptie gebruikt wordt. *
Hoe kan een bedrijf garanderen waar hun data is, of iemand het verstuurd heeft?
Hoe kun je dadelijk aangetoond worden mbt de nieuwe Europese regelgeving (GDPR) welke data er gelekt is? Dat zijn behoorlijk forse boetes...
Als je niet in de uitgaande informatiestromen mag/kan kijken kun je niet meer voldoen aan die eisen. Je kunt een end-to-end tunnel opzetten met je Cloud platform, en daar API based controles gebruiken, maar je zult in parallel een Gateway/Cloud oplossing moeten hebben die al het verkeer controleert. op Data Leakage

[TomWassenberg]

"Toen gebruikte 44 procent van de websites geen beveiligde verbinding; nu is dat aantal gestegen naar 52 procent."

Deze zin is een beetje dubbelzinnig, het aantal websites dat geen beveiligde verbinding gebruikt is juist gedaald, niet gestegen.

[Blinkin]

Ja en het gaat om 8%, niet 20%. Heb het 5x gelezen omdat ik het niet snapte maar zo staat het er toch echt.

[TheDevilOnLine]

Van 44% naar 52% is een stijging van 8 procentpunt en daarmee een stijging van 20%. 44 + 20% = +/- 52

[Blinkin]

Aah, ja je hebt helemaal gelijk. Het is ten opzichte van de vorige meting. Iets te snel gelezen.
Het aantal websites dat een beveiligde verbinding gebruikt is dus echt met 20% gedaald. Das niet zo mooi.

[Reactie gewijzigd door Blinkin op 24 juli 2024 15:06]

[jordees]

Ik vond het ook al een tegenstrijdig verhaal. Nuance zit in de g.

[Jay47]

Zolang er veel oudjes of ondeskundigen bij de overheid werken zal je altijd bureaucratie hebben.
Zie het bij meerdere bedrijven, oudere mensen blijven vaak hangen in hun eigen denkwijze en willen niet met de tijd mee gaan.
Vaak zie je ook mensen die echt verstand van zaken hebben overruled worden door mensen die er er totaal geen kaas van hebben gegeten.
Omdat ze dan een idioot manager hebben die het werk zelf nooit gedaan heeft en direct van school is gekomen en dingen bepaald.
Vaak gaat het om geld, en dan besparen ze op totaal verkeerde projecten etc etc.

[Reactie gewijzigd door Jay47 op 24 juli 2024 15:06]

[cracking cloud]

Zo heel veel kost een SSL certificaat niet hoor. Ik hoor vaak dat als argument dat het niet zulke belangrijke informatie is die over het lijntje gaat en dat men het daarom niet wil doen.

[buzzin]

Bedenk er a.u.b. wel even bij dat overheidscertificaten een stuk duurder zijn als 'gewone' ssl certificaten. Overheidsinstanties hebben geen keuze waar ze een certificaat kopen, dat word voor ze bepaald.
Standaard certificaatje hier voor extern gebruik met 1 fqdn zonder wildcards is al honderden euro's (Rijksoverheid).
En dat is nog niet met meerdere fdqn's, wildcard of Extended Validation.
Het is niet alleen onkunde, maar ook gewoon een kosten plaatje.
De grote instanties bepalen dat het duur moet zijn, maar de kleine afdelingen met eigen potjes moeten het vervolgens ophoesten.....

[tvdijen]

Overheidsinstanties kunnen PKIoverheid-certificaten afnemen bij vier verschillende marktpartijen. Kosten per certificaat ~1200 euro voor 3 jaar.
Het aantal FQDN's is vaak door de leverancier beperkt op ~10 per certificaat, maar is bij standaard niet gelimiteerd. Sommige leveranciers rekenen hier wel extra voor.
Wildcards zijn volgens de standaard geheel verboden.

[InjecTioN]

Bij ons op kantoor gaan er redelijk wat aanvragen voor SSL-certificaten voor klanten van ons over "de toonbank". Momenteel is de hoeveelheid klanten die een SSL-certificaat wilt hebben voor hun website met misschien 10% gestegen. De groei blijft opmerkelijk gezien alsnog een stuk lager dan verwacht. We hadden, vooral gezien de meldingen die Firefox inmiddels maakt, het idee dat de groei een stuk hoger zou zijn!

Nu zullen Safari, Chrome, Opera en IE nog met meldingen moeten komen.

[alexwijn]

Chrome doet dat ook al een tijdje. Indicatie geven dat het "niet veilig" is bij de eerste keer dat je een website bezoekt die niet via SSL werkt.

Of doet Firefox dit anders?

[biglia]

Firefox gaat sinds deze week zelfs een stapje verder. Bij elk formulier op een HTML pagina zonder SSL staat er in het invulveld een waarschuwing dat het niet veilig is.

Voorbeeld: https://i1.wp.com/www.the...securePasswordWarning.png

[Reactie gewijzigd door biglia op 24 juli 2024 15:06]

[Verwijderd]

Ik heb ook 2400 url's actief maar voel echt niet de noodzaak voor iedere site een SSL certificaat te gaan installeren. Ik ben net begonnen met experimenteren met Lets encrypt. So far so good, maar ik wacht het eerst een jaartje aan alvorens ik het grootschalig (voor de kleine sites) toe ga passen.

Google beloonde enigzins gebruik van https in de organische zoekresultaten, maar daar is echt 1% nog van over. Als je site al goed liep dan doet https daar weinig meer aan (sommige kopen echt alleen een ssl voor seo) en als je site ruk loopt loopt het na SSL ook nog steeds ruk

[MadEgg]

Gelukkig hoef je ze met Let's Encrypt niet te kopen. Ik heb met 1 instelling alle sites op mijn server van HTTPS voorzien. Minuutje werk, en certbot doet de rest.

Voor SEO maakt het vrij weinig uit maar het kost niets en is zo gedaan, dus waarom niet?

Dat het voor grote overheidswebsites net iets anders ligt (als ook voor Tweakers.net) spreekt voor zich. Maar de gemiddelde hostingprovider zou dit in een mum van tijd voor de meeste sites automatisch kunnen regelen.

[Tozz]

Ik vind het echter een slechte zaak dat door dit pushen van HTTPS door Google en browsers het halve Internet afhankelijk is geworden van Lets Encrypt.

[MadEgg]

Ach, het hele certificaatsysteem is toch een kaartenhuis.

SSL is heel er wenselijk, maar die certificaten zijn bullcrap. Een implementatie als DANE past veel meer bij de gedistribueerde opbouw van het internet, en dat kan me ook niet snel genoeg breed ondersteund en toegepast worden. Tot het zo ver is is Let's Encrypt een prima lapmiddel.

[ultimate-tester]

DANE is ook niet alles. Het zorgt er alleen voor dat er een geencrypte verbinding kan worden gestart maar doet totaal niks aan verificatie. De enige manier om te verifieeren of een domein is wie het zegt dat het is, is door dit aan een centraal en beschermd punt te vragen!

[MadEgg]

Dat valt wel mee. DANE toont aan dat je controle over de DNS hebt van de domeinnaam. Certificaten met een CA tonen ook dat aan, verder niets.

Je moet een bestandje op een webserver zetten die de CA je hebt gegeven of een code overtypen die ze je per e-mail toesturen op dat domein. Heb je controle over DNS dan kun je DANE toepassen en dan kun je CA toepassen. Met als belangrijkste voordeel voor DANE dat je het volledig in eigen beheer hebt en niet afhankelijk bent van je CA.

Ok, je bent nog steeds afhankelijk van je registrar voor de ondertekening met DNSSEC, maar dat ben je toch al als je een domeinnaam registreert.

EV-cerficaten is nog net iets anders - daar kan DANE wat moeilijker mee concurreren, aangezien er dan ook verificatie plaatsvindt over de organisatie achter de domeinnaam. Voor de standaard certificaten gebeurt dat toch niet.

[djiwie]

Voor SEO is het effect meestal verwaarloosbaar, maar browsers gaan steeds meer waarschuwen voor non-HTTPS-sites. Ik weet niet wat voor sites je hebt, maar ik kan me voorstellen dat het voor de conversie beter werkt als er 'Secure' in beeld staat (in groene letters) ipv 'Insecure' in rode letters en met een uitroepteken er naast.

[Yggdrasil]

Mijn internetburo is nu wel bezig om HTTPS automatisch voor élk domein in te schakelen.

Waarom?
- Voor bepaalde zgn. "powerful features" die we gebruiken in onze sites, zoals geolocation, notifications, etc., is tegenwoordig HTTPS vereist door o.a. Chrome.
- We willen de snelheidsvoordelen van HTTP/2 benutten. HTTPS is dan praktisch vereist.
- Het is makkelijker om het overal in te schakelen dan telkens per site bepalen wie wel en wie niet.
- Met dank aan Let's Encrypt is het volledige proces te automatiseren én gratis.
- Het geeft onze klanten de perceptie van extra veiligheid en 'luxe', dus een klein competitief voordeel.

Voor ons is dus het omslagpunt bereikt dat HTTP een betere keuze is dan HTTP.

Om dit makkelijk te maken gebruiken wij daarvoor Traefik.io, een reverse-proxy die het hele Let's Encrypt proces automatiseert en HTTP/2 ondersteund. Zodra er een aanvraag via HTTPS binnenkomt voor een hostname die nog geen certificaat heeft dan wordt dat automatisch aangevraagd, gevalideerd, geïnstalleerd en later weer verlengd. Dit kost maar een paar seconden extra voor de eerste bezoeker. Afgezien van de initiële tests en deployment van de proxy kost het ons niks meer als het eenmaal in gebruik is.

[Justin_]

Gebruik het via cloudflare. Werkt snel en makkelijk

[Buzz_Fuzz]

Kan iemand mij eens uitleggen waarom https echt zoveel veiliger is, als op het werk blijkbaar een Forcepoint proxy perfect aan SSL inspection kan doen en ik alsnog mooi een groen slotje te zien krijg?

[Yggdrasil]

Dat komt omdat het hun PC's zijn. Systeembeheer op je werk heeft een CA certificaat van Forcepoint op alle door hun beheerde apparaten geïnstalleerd. De verbinding tussen de proxy en de bezochte website over het publieke internet is nog steeds versleuteld, maar de proxy doet eigenlijk een Man-in-the-middle aanval waardoor de verbinding tussen de proxy en je PC door hen onderschept kan worden.

Daarmee omzeilen ze feitelijk een deel van het SSL systeem, maar dat kan alleen omdat ze admin-toegang hebben tot het endpoint, je PC. Ja, dat is vervelend maar als één van de eindpunten (jouw pc of de webserver) 'gehackt' is (ook al is het door een goedaardige beheerder) dan kun je feitelijk niks vertrouwen.

Ik verwacht dat dit in de toekomst overigens moeilijker zal worden voor bedrijven omdat d.m.v. systemen als DANE (als dit ooit aanslaat) de oorsprong van certificaten beter beveiligd kan worden.

[sugarlee89]

Snap die overheid websites nooit, lopen altijd 5 jaar minimaal achter de feiten aan. Ik weiger https loze websites voor kritische zaken. Zelfs webshops zonder https komen er bij mij niet in