Twee derde van zorgwebsites ondersteunt nog geen https

Uit onderzoek van de Open State Foundation blijkt dat een overgrote meerderheid van de websites van zorgbedrijven nog geen https ondersteunt. In enkele gevallen wordt hierbij ook informatie in onlineformulieren zonder encryptie verzonden.

De Open State Foundation keek voor dit onderzoek naar 22.393 websites. Hiervan ondersteunen er 8637, ofwel 39 procent, de beveiligde verbinding. Bij 1786 van deze websites wordt https echter niet afgedwongen, waardoor in deze gevallen de verbinding bij de meeste gebruikers alsnog niet beveiligd is. In totaal dwingt slechts 31 procent van de zorgwebsites het gebruik van https af.

Het onderzoek is verder onderverdeeld per type zorg. Aanbieders van paramedische zorg scoren het laagst, waar 24 procent van de websites https ondersteunt. Bij fysiotherapeuten is dit aantal 30 procent en bij geestelijke gezondheidszorg en thuiszorg is het 34 procent. Bij tandartsen, mondhygiënisten en aanbieders van gehandicaptenzorg is bijna 40 procent van de websites beveiligd met https en bij apotheken is dit een kleine 50 procent.

Meer dan de helft van de websites van aanbieders van jeugdzorg ondersteunt https, namelijk 56 procent. Bij slechts 37 procent wordt dit echter ook daadwerkelijk afgedwongen. Websites van huisartsen en ziekenhuizen presteren het best: 66 procent van de huisartsenwebsites ondersteunt https en 61 procent dwingt het af. Bij ziekenhuizen zijn dit respectievelijk 75 en 68 procent.

De Open State Foundation merkt verder op dat uit een steekproef bleek dat verschillende van deze onbeveiligde websites onlineformulieren aanbieden. Deze formulieren vragen onder andere om persoonsgegevens en medische aandoeningen. Zonder beveiligde verbinding kan dergelijke informatie relatief eenvoudig onderschept worden.

Https is voor meer sectoren een zorg. In maart maakte de Open State Foundation bekend dat 52 procent van de overheidswebsites ondersteuning biedt voor de versleuteling. Ronald Plasterk, de minister van Binnenlandse Zaken, wil alle overheidswebsites verplicht stellen om https te implementeren. Mogelijk wordt hiervoor in 2018 een wet ingevoerd.

Reacties (155)

[cracking cloud]

Er moet toch nog wel heel wat gedaan worden aan goede informatie over wat HTTPS wel doet en wat het niet is. Bijvoorbeeld dit stukje uit een artikel van de NOS over dit onderwerp:

"De Patiëntenfederatie Nederland is geschokt door de bevindingen, laat een woordvoerder weten. "Je mag toch verwachten dat kwetsbare patiëntgegevens veilig worden opgeslagen. Dat blijkt in een zeer groot aantal gevallen niet zo te zijn. Dat is kwalijk", zegt directeur Dianda Veldman."

SSL gaat dus niet over het veilig opslaan. Alleen over het versleuteld versturen. En een ander voorbeeld is dat een bedrijf dacht dat ze geen SSL nodig hadden omdat ze een firewall hebben... (link). Of dat men dacht dat sql injection niet meer mogelijk was, want men had een SSL certificaat.

[b2vjfvj75gjx7]

Schokkend ook dat het geschreven is door Joost Schellevis, ex-Tweaker redacteur; die moet toch van beter niveau zijn dat deze kinderjournalistiek, zou je zeggen...

...en dan dit als keiler (titel op de homepage) gebruiken;

"Meerderheid zorgsites onbeveiligd, privacy-autoriteit dreigt met boetes"

https:// zegt he-le-maal niets over de beveiliging van de site, maar over de communicatie tussen server en browser (en of dat dan encrypted gebeurt, of niet).

Door iets te encrypten, wordt je site niet opeens veilig... en door gebrek aan encryptie is je site niet per definitie onveilig.

Typisch een oppervlakkig click-bait artikel van de NOS dit.

[paultje1983]

Daarnaast vraag ik me af, hoeveel medische gegevens er op een website van een zorgaanbieder staan.

Zijn patiënten programma zit hier niet aangekoppeld, dit zijn allemaal systemen die NEN7510 gecertificeerd zijn.

De koppelingen voor patiënt gegevens gaan via andere beveiligde verbindingen (VECOZO Certificaat en UZI-pas).

Zolang er geen invul formulieren of gegevens opstaan mag het best een HTTP website zijn hoor.
Alleen jammer dat er niet wordt aangegeven hoeveel % van deze website patiënt gegevens heeft of vraagt.

[Aaargh!]

Zolang er geen invul formulieren of gegevens opstaan mag het best een HTTP website zijn hoor.

Echt niet. Als je bijvoorbeeld informatie zoekt over bepaalde ziekten dan hoeft ook de hele wereld dat niet te weten. Welke sites je bezoekt en welke pagina's op die site je bekijkt kan ook al privacy gevoelige informatie zijn. Zeker op de site van een zorgaanbieder.

Stel je zoekt vanaf je PC op het werk naar informatie over hulp bij alcoholverslaving, en je werkgever blijkt al het HTTP verkeer te monitoren, je wilt toch niet dat ie dat weet.

[eborn]

Misschien moet je dat dan ook niet op je werk doen? Even los van het feit dat een werkgever volgens mij niet zomaar al het verkeer mag monitoren. Plus dat het zoeken nog niets zegt over jouw persoonlijke situatie. Misschien zoek je het wel voor een buurman, je oom of een wildvreemde n.a.v. een item op televisie.

Ik ben ook een voorstander van alles HTTPS, maar dat wil niet zeggen dat iets zonder HTTPS maar altijd op straat moet liggen en gebruikt mag worden.

[Aaargh!]

Misschien moet je dat dan ook niet op je werk doen?

Het was natuurlijk maar een voorbeeld, eerste wat me te binnen schoot.

Even los van het feit dat een werkgever volgens mij niet zomaar al het verkeer mag monitoren.

Je mag ook niet stelen, dus maar niet de deur op slot doen ?

[menne]

Plus dat het zoeken nog niets zegt over jouw persoonlijke situatie. Misschien zoek je het wel voor een buurman, je oom of een wildvreemde n.a.v. een item op televisie.

Je Google zoekhistorie zegt natuurlijk ook niks over jouw situatie, misschien dat je vaak je buurman of oma ergens bij probeert te helpen Natuurlijk zegt dit vrijwel altijd iets over je persoonlijke situatie. Misschien dat in een enkel geval iemand het opzoekt voor iemand anders, maar die kans is vele malen kleiner. En ach, voor de geïnsteresseerde, dan maar een aantal false-positives meepakken in die enkele gevallen dat het niet voor jezelf is wat je opzoekt.

[mg794613]

Of je nou http of HTTPS gebruikt hij ziet de requests toch wel. Dus daar zit geen verschil in. Hij kan alleen niet kan WAT er in de packets zat, maar de requests komen ongeacht http of HTTPS gewoon door DNS en de routing welke niet encrypt is.

[Aaargh!]

Je weet welk IP je mee connect. Meer niet. Zeker niet welke specifieke server of welke pagina.

[mg794613]

Hoe denk je dat die DNS resolved word? Hoe denk je dat je gateway weet waar hij het heen moet sturen?

[R4gnax]

door gebrek aan encryptie is je site niet per definitie onveilig.

Het bestaan van de mogelijkheid tot man-in-the-middle aanvallen maakt dat een gebrek aan een beveiligde communicatielijn er gewoon altijd voor zorgt dat een site gewoon zo lek als een mandje is. Punt.

Een aanvaller kan zonder een beveiligde communicatielijn nl. altijd met de inhoud van de initiële pagina request rommelen, waardoor 'beveiligingen' die pas client-side gestart worden, effectief nutteloos zijn.

[Reactie gewijzigd door R4gnax op 27 juli 2024 09:40]

[elbizarre]

Klopt als een bus, maar dat maakt je website nog steeds niet 'Onveilig'.
Als de externe website enkel contact gegevens bevat en wat mooie referentie user stories en andere info, waarom moet dit dan https ziin?
Ik word een beetje moe van de tegenwoordige http heksenjacht.
Je kan niet alle 'onbeveiligde' websites klakkeloos afschieten zonder context.

[Verwijderd]

Tegenwoordig is het zo ongelofelijk makkelijk om https in te bouwen, dat ik niet begrijp waarom je het Überhaupt niet zou doen. Genoeg platforms waar je dit letterlijk met 3 muisklikken kunt verzorgen. Dat kwartiertje werk hoort gewoon een "nieuwe" standaard te zijn. Los van https, gebrek aan security kan redelijk definitieve schade aan je bedrijf aanrichten.

[Luuk1983]

Je doet net alsof elke site zomaar even op https draait zonder problemen. Je moet alles nalopen en goed controleren. Webservices werken niet zomaar ineens via https zonder endpoint configuratie, embedded content kan via http ingeladen worden, waarbij lang niet alle embedded content via https-beschikbaar is.

Niet dat het heel interessant is, maar om je een idee te geven: ik was bezig met een site te ver-https-en en op de site stond een widget van weeronline voor het weer. Deze widget is niet beschikbaar via https. Dus ik moest gaan zoeken naar een goed alternatief. Nou is dit maar een heel klein dingetje wat redelijk makkelijk op te lossen is, maar ik vind het nogal ver gaat om te zeggen dat het even met drie muisklikken geregeld is.

Voor nieuwe sites ben ik het overigens met je eens. Als je nu nog sites ontwikkeld die niet via https kunnen werken, dan moet je je afvragen hoe goed je bezig bent.

[Verwijderd]

Het eerste woord in mijn comment is dan ook tegenwoordig. Maar ik begrijp de rest van je response.

[Luuk1983]

Fair enough!

[elbizarre]

Komt er nog bij dat het omzetten naar HTTPS niet een eenmalige actie is. Je moet op deze systemen de certificaten bijhouden, de Ciphers bij ieder gevonden lek aanpassen naar de nieuwe standaarden, etc. Alleen het op HTTPS zetten en verder nooit meer naar kijken is zinloze actie. Dan moet je het ook goed doen anders heeft het nóg geen zin.

[To_Tall]

Zo makkelijk is het soms niet.. Als jouw website jaren geleden is gebouwd en er wordt op de DB verder gebouwd. met links naar HTTP en niet naar HTTPS.. dan kan het bij het afdwingen van HTTPS dan kan dat betekenen dat de website niet of niet goed bereikbaar er meer is.

Zeker niet als je een front-end, back-end database gebruikt. Het is niet altijd maar een apache servertje met een wordpress installatie Het kan zomaar zijn dat 1 systeem voor tientallen zorgverleners gebruikt wordt.. SSL ofloading is ook niet altijd wenselijk. in die gevallen zou je behoorlijk wat werk moeten verzetten om toch SSL af te kunnen gaan dwingen.

[Verwijderd]

Wat heeft een DB in godsnaam te maken met een SSL link op frontend niveau ??

[R4gnax]

Wat heeft een DB in godsnaam te maken met een SSL link op frontend niveau ??

Geen moer. Gevalletje klok-klepel, als je het mij vraagt.

[Verwijderd]

Of hij moet links incl http(s):// op willen slaan ???

[Aaargh!]

Als de externe website enkel contact gegevens bevat en wat mooie referentie user stories en andere info, waarom moet dit dan https ziin?

Iemand kan een MiTM uitvoeren en het telefoonnummer aanpassen, vervolgens bel jij met het verkeerde nummer en geef je je gegevens door aan de verkeerde persoon.

[elbizarre]

klopt. daar heb je wel een klein puntje al acht ik dat risico wel erg klein. dan zou je dus een hacker partij moeten treffen die én nederlands is, én kennis van de zorg heeft om niet door de mand te vallen.

[Aaargh!]

Je kan ook nummer doorverbinden met het originele nummer en dan het gesprek afluisteren.

[R4gnax]

Je kan ook nummer doorverbinden met het originele nummer en dan het gesprek afluisteren.

Of het telefoonnummer met een duur betaald nummer vervangen wat doorverbindt naar het originele nummer en vervolgens wachten tot het geld binnenstroomt.

[Soldaatje]

Is niks mis met het artikel hoor.
De quote is van een directeur niet van Joost en de titel is ook goed. Kwestie van interpretatie.

[marcieking]

Daarvoor zou ik dan [sic] verwachten in het artikel.

[i7x]

Lijkt me nogal logisch dat het om de beveiliging van je verstuurde gegevens gaat middels een laag versleuteling, en niet per sé veiligheid tegen aanvallen of wat dan ook, maar dat staat er dan ook helemaal niet.

Naar mijn mening dus niets mis met de titel.

Dat het oppervlakkig is zal vast kloppen (heb het niet gelezen), want voor diepgang zou ik ook niet als eerste het staatsjournaal aanraden.

[Reactie gewijzigd door i7x op 27 juli 2024 09:40]

[0xygen500]

Da stukje van cracking cloud is een quote van een ander persoon, niet van Joost schellevis.

[To_Tall]

Het artikel van de NOS gaat toch echt duidelijk over het verkeer tussen browser/server en niet over opslag van gegevens.

Waarin ook meerdere malen staat aangegeven dat het met een onversleutelde (http) verbinding kwaadwilligen zouden kunnen mee kijken met de gegevens die via formulieren worden verstuurd.

Wel had in het artikel meer naar boven moeten komen dat gegevens die via een computer via het internet worden verstuurd naar de website alleen die gegevens onderschept zouden kunnen worden. Dit artikel zegt niets over de beveiliging op de servers zelf.

[kr4t0s]

Ja dat is het probleem. Men heeft er 0,0 verstand van en men wil er geen geld aan uitgeven. SSL, security headers, WAF, cookie encryptie. En dat is alleen nog het eerste laag van een omgeving.

[mekkieboek]

Https is een ding, het gebruik van (google)analytics is een tweede. Een korte check (nhg,org, tandarts.nl, allebei netjes via https) geeft bij view source telkens weer de google analytics code in de webpagina's. Dat is op zijn minst kwalijk. Ben je door griep (om een onschuldig voorbeeld te noemen ) geveld en nietsvermoedend op zoek naar verlichting, zit google toch weer mee te gluren en zijn profielen aan te vullen.

Ik begrijp dat je als website eigenaar inzicht wilt en moet hebben over je gebruikers. Maar ik vraag me telkens weer af of het echt zo lastig is je eigen metrieken te verzamelen. Kost moeite ja en het ziet er mss minder flashy uit.

[Reactie gewijzigd door mekkieboek op 27 juli 2024 09:40]

[Bart.net]

Goede opmerking. Echter analytics kan niet bij je BSN en medische gegevens als je die invult. En patiënten met erectie problemen worden niet meer naar nhg.org gestuurd, maar naar thuisarts.nl. Thuisarts is ook van nhg en gebruikt Pikwik.
Dus wees je bewust wanneer je google analytics gebruikt, maar het is niet zo kwalijk als http.

[vosManz]

Goede opmerking. Echter analytics kan niet bij je BSN en medische gegevens als je die invult.

Jawel hoor. Google Analytics is gewoon een javascript file die wordt ingeladen. Google kan dus gewoon een scriptje maken om de waarden van alle invulvelden terug naar Google te sturen. Ik hoop niet dat ze dat doen, maar het kan zeker wel.

[R4gnax]

[...]

Jawel hoor. Google Analytics is gewoon een javascript file die wordt ingeladen. Google kan dus gewoon een scriptje maken om de waarden van alle invulvelden terug naar Google te sturen. Ik hoop niet dat ze dat doen, maar het kan zeker wel.

De service-voorwaarden van Google Analytics staan niet toe dat accounthouders in enige vorm dan ook persoonsgegevens naar de servers van Google uploaden. Daar controleren ze actief op en als je er op betrapt wordt, wordt je account gesloten en de data vernietigd.

[mekkieboek]

Dank voor de tip. De dnslog van thuisarts.nl is inderdaad lekker kort.

[b2vjfvj75gjx7]

Maar ik vraag me telkens weer af of het echt zo lastig is je eigen metrieken te verzamelen. Kost moeite ja en het ziet er mss minder flashy uit.

https:// icm. Google Analytics is net zo erg als http:// lijkt mij.

Daarom moet je dat hele Google Analytics ook mijden en gewoon iets als Piwik gebruiken;

https://piwik.org/

Net zo flashy (eigenlijk nog flashier) dan Google Analytics, geen third-party code en tenminste een systeem dat anoniem track en DNT (do not track) goed naleeft.

En het draait op je eigen server; niet op een commerciële third-party server van een bedrijf dat leeft van het misbruik maken op privacy, van mensen die er niet eens erg in hebben...

[hkuiling]

Het is toch werkelijk schandalig dat dit anno 2017 nog gebeurd? Zo moeilijk is het niet om verkeer met encryptie mogelijk te maken en veel geld kost het ook niet. De kosten van een projectvergadering kost net zoveel of meer aan personeelskosten e.d. dan versleuteling.

[cracking cloud]

Behalve een ssl certificaat moet je ook e.e.a. goed doortesten zodat je geen problemen krijgt met content die over http wordt aangeboden. Je CMS moet er mee overweg kunnen, redirects moeten goed ingesteld staan zodat je geen duplicate content krijgt in google etc.

[Ventieldopje]

Zo groot zijn die aanpassingen niet, als die er al zijn. Redirect doe je met een 301 zodat je ook geen problemen krijgt met de SEO.

Veel belangrijker nog is de SSL configuratie van de webserver. Als onveilige ciphers toestaat of oudere versies gebruikt sta je open voor allerlei narigheid en zegt dat groene slotje niks

Zelfs al ondersteund je applicatie/webserver geen (veilige) SSL dan kun je met een reverse proxy werken die de SSL afhandeling op zich neemt.

[Reactie gewijzigd door Ventieldopje op 27 juli 2024 09:40]

[b2vjfvj75gjx7]

Zo groot zijn die aanpassingen niet,

Zo groot zijn die aanpassingen wel... ik heb met regelmaat, sinds een jaar of twee - sinds de https:// "hype" aan de gang is, meerdere sites overgezet van protocol A ) naar B ).

Je wil niet weten hoeveel content hardcoded is met http:// headers, en dus direct errors triggeren als de site zelf overgaat op https:// (het is maar wat je liever hebt als aanbieder; een melding dat de site nog http:// is of dat het probeert https:// te zijn - maar dat dit niet lukt, omdat er onveilige content wordt ingeladen).

Veel scripts van derden, assets op third-party servers, images op shared-hosting, etc... geven issues als je overstapt, logins werken niet meer, ajax-calls die van http:// naar https:// worden ge-redirect verliezen hun content (probeer maar een ajax-post te redirecten als de API overgaat van http:// naar https:// 1x redirecten en de content in de headers is weg), etc...

Los daar van is het vaak schijnveiligheid;

Liever een Fort Knox site op http:// dan een brakke Wordpress / Joomla / Drupal / Kirby installatie op https:// waar alle backdoors wagenwijd openstaan.

[Verwijderd]

Een http site met login kan nooit veilig zijn.

[ExIT]

Nou, nee? Je kan clientside met een javascript een wachtwoord hashen en versturen samen met een afzender/tijd-secret in plaats van het plain text password. In dat geval is het veilig. Maar https is beter.

[Reactie gewijzigd door ExIT op 27 juli 2024 09:40]

[R4gnax]

Nou, nee? Je kan clientside met een javascript een wachtwoord hashen en versturen samen met een afzender/tijd-secret in plaats van het plain text password. In dat geval is het veilig.

Fout.

De initiële request voor de site is HTTP plaintext en onderhevig aan een man-in-the-middle aanval waarmee een stukje script geinjecteerd kan worden wat jouw ongehashte wachtwoord oppikt en naar de aanvaller terugstuurt.

[mkooiman]

Daarnaast gewoon het feit dat als je op de client gaat hashen dat je hash in feite gewoon je wachtwoord is geworden, als je de hash kan onderscheppen is het al genoeg om in te kunnen loggen, daar heb je het originele wachtwoord ook helemaal niet meer voor nodig.

Wat je zou kunnen doen is over meerdere requests asymmetrische encryptie op het wachtwoord toepassen, maar als je daar al mee begint is vrijwel altijd https een makkelijkere oplossing

[R4gnax]

Daarnaast gewoon het feit dat als je op de client gaat hashen dat je hash in feite gewoon je wachtwoord is geworden, als je de hash kan onderscheppen is het al genoeg om in te kunnen loggen

Dat juist niet; de hashmethode die ExIT voorstelt zou een afzender+tijd component bevatten die valide moet zijn.

[mkooiman]

Wou inderdaad net even toevoegen dat je zou kunnen gaan salten, maar je reactie was me voor.

Neemt niet weg dat een man in the middle attack natuurlijk gewoon nog altijd mogelijk is.

[Reactie gewijzigd door mkooiman op 27 juli 2024 09:40]

[ExIT]

Vooruit. MITM is bijna niks tegen te doen. Dan resteert HTTP Digest nog? Is ook zonder HTTPS maar wel MITM proof, niet?

[Verwijderd]

Ja, maar je kan dan weer 'cookie stealing' krijgen, waarmee ze je sessie kunnen overnemen. Daar kan je niets aan doen als je geen TLS gebruikt.

[1nsane]

Daar heb je absoluut een punt maar ik vraag me wel af hoeveel "fort-knox" sites er daadwerkelijk zijn op http://...

Als je aan die kant alles goed dicht hebt getimmerd, dan lijkt het me sterk dat https:// nog niet de aandacht heeft tenzij je daarin al in een transitie zit.

[b2vjfvj75gjx7]

Exact dat; in die zin is https:// eigenlijk een sluitstuk voor de veiligheid van je site.

Eerst regelen dat de site zelf gewoon goed beveiligd is, je database niet openbaar op straat ligt, etc... en als dat op orde is ga je over naar https:// (als je dat al niet gedaan had).

Maar puur overstappen op https:// en dan denken dat je site opeens veilig is, slaat nergens op.

https:// heeft niets met de veiligheid van je site of database te maken, maar geeft enkel aan dat het verkeer tussen browser en server encrypted is.

Als je browser en/of je server vervolgens zo lek als een mandje zijn, heeft dat hele https:// totaal geen nut.

[marcoboers94]

Ik denk eerder dat @1nsane bedoelt dat bij iemand die zegt zijn site goed beveiligd te hebben maar nog niet iets relatief simpels als https ondersteund moet afvragen hoe dicht dat "fort-knox" zit.

[b2vjfvj75gjx7]

Ach, Tweakers is 15 jaar nooit gekraakt geweest (dus Fort Knox, in mijn terminologie) en pas sinds 2 jaar over op https://

Je kan dus best een volledig dichtgetimmerde site hebben, en toch vrolijk http:// draaien...

[rodebest]

Terwijl ik vroeger op de middelbare school met een simpele cookiegrabber app van android gewoon iemand anders zijn sessie kon overnemen waarbij ik opeens ingelogd was op iemand anders account. Ik ben toch wel heel blij dat dat niet meer kan...

[To_Tall]

Ach in mijn tijd op school, was de computer lokaal gekoppeld aan het netwerk waar ook docenten PC's op stonden..

Niets was zo eenvoudig als even je cijfers bekijken en aanpassen want het stond op elke Docenten PC als TXT bestand op C:\... Lang leven Windows 3.11 icm WordPerfect . Ik hoefde alleen de computer naam te raden en die waren de lokaal nummers

[Reactie gewijzigd door To_Tall op 27 juli 2024 09:40]

[CAPSLOCK2000]

Ach, Tweakers is 15 jaar nooit gekraakt geweest (dus Fort Knox, in mijn terminologie) en pas sinds 2 jaar over op https://

Je impliceert dat gekraakt worden het enige probleem is, maar het uitlekken van informatie omdat een verbinding onderschept wordt kan ook vervelend zijn. Als iemand mee zou kijken terwijl ik Pricewatch bezoek dan zou dat ongetwijfeld interessante informatie opleveren over mijn voorkeuren. Ben ik op zoek naar een nieuwe telefoon of naar een nieuw toetsenbord? Bekijk ik budget-telefoons of flagships? Zoek ik een GPS-houder voor een Golf of voor een Tesla?

Wel zie ik, en @marcoboers94, https niet als het sluitstuk maar het begin van veiligheid. HTTPS kun je opzetten zonder inhoudelijke kennis van het product, je kan het al regelen nog voor de eerste regel HTML is geschreven en het proces is zeer rechtlijnig en kan zelfs geautomatiseerd worden. Van alle moderne beveiligingsmaatregelen is dit een van de makkelijkste. Gebrek aan HTTPS is geen garantie dat de bijhorende site niet op orde is, maar het is wel een enorme rode vlag.

[Verwijderd]

https:// heeft niets met de veiligheid van je site of database te maken, maar geeft enkel aan dat het verkeer tussen browser en server encrypted is.

En dat is deel van je totale veiligheidsbeleid. Elke goede beheerder ziet de clientmachine als deel van zijn site op het moment dat die een formulier aan het invullen is. Je bent dan tenslotte heel dicht bij je eigen databases.

Je hebt echter geheel gelijk dat https geen voorwaarde is. Een site die alleen informatie geeft (zoals heel veel in dit onderzoek) kan prima veilig functioneren als hppt. Ik heb sterk de indruk dat als het geen komkommertijd was er niet veel aandacht aan gegeven zou zijn.

[Ventieldopje]

Dat zijn dan sites A] door een hobbyist in elkaar is gezet of B] op wel meer dingen dan alleen https achter loopt. Zeker in dat laatste geval ben je er niet met alleen HTTPS en heb je dus ook al geen "fort knox" op http:// als jij het noemt.

De enige uitdaging waar bijv. Tweakers ook tegenaan liep waren afbeeldingen en dan met name afbeeldingen waar je zelf geen controle over hebt zoals afbeeldingen tussen img tags.

[Reactie gewijzigd door Ventieldopje op 27 juli 2024 09:40]

[kr4t0s]

Je kunt ook http > https rewriten met een loadbalancer.

[Capital_G]

Sorry maar je verkoopt echt onzin, en ik snap de +2 echt niet. Als je geen brakke wordpress-achtige applicatie hebt, en als je alles netjes ontwikkelt dan hoef je alleen een redirect in te stellen van http naar https.Thats it. Het feit dat je het al over statische content met http linkjes hebt betekend (IMHO) dat je het verkeerd doet.

Https is veiliger en beter. Punt. Geen discussie mogelijk.

[cracking cloud]

klopt, gelukkig zijn er genoeg goede sites om je SSL installatie te testen

[Soultaker]

Om te beginnen zou je het informatieve deel van de website (wat gewoon publieke informatie bevat) kunnen scheiden van het beveiligde gedeelte waar klanten op in kunnen loggen. Dat tweede deel moet helemaal niet door zoekmachines geïndexeerd worden, dus SEO is daar ook niet op van toepassing. Het is mijns inziens niet uit te leggen dat dat niet beveiligd is.

Maar er zit wel wat overlap tussen die twee delen. Bij veel zorgverzekeraars kun je bijvoorbeeld een offerte opvragen voordat je klant wordt, en dan moet je vaak gegevens als je geslacht en geboorte-datum opgeven. Die gegevens zouden eigenlijk al wel beveiligd verstuurd moeten worden.

[Reactie gewijzigd door Soultaker op 27 juli 2024 09:40]

[CAPSLOCK2000]

Vijf jaar geleden was dat nog een acceptabel excuus, maar vandaag de dag niet meer. Als je toen was begonnen met je voorbereiden was je nu wel klaar geweest. Als je dat niet hebt gedaan dan heb je flink zitten slapen als professionele IT'er. De meeste websites worden iedere drie tot vijf jaar volledig vernieuwd, dat is een prima moment om https toe te voegen.

[MarcoC]

Niemand betwist dat het invoeren van https niet heel triviaal is. Het is echter wel een opgelost probleem, alleen de implementatie kost wat inspanning. Laat 10 man zich hier drie weken druk over maken en het is opgelost. Kwestie van doen.

[PhilipsFan]

Ik had het laatst met m'n fysiotherapeut. Wilde dat ik me online inschreef via de website. Formulier vroeg om BSN (en andere gegevens uiteraard) en werd gewoon via http verzonden. Ik heb 'm hierop gewezen, zijn reactie: dat kan ik me niet voorstellen, ik heb een hele goede webhoster...

Binnenkort maar even een melding naar de Autoriteit Persoonsgegevens.

[Superkanjo]

Binnenkort maar even een melding naar de Autoriteit Persoonsgegevens.

Want? Er wordt toch geen wet overtreden, of zijn er gegevens gelekt?

[Arnoud Engelfriet]

Jawel, artikel 13 Wbp wordt overtreden, er zit geen adequate beveiliging van (medische) persoonsgegevens op die lijn als er geen https gebruikt wordt.

[Superkanjo]

Dank voor de toelichting, wist niet dat http gebruiken (momenteel) strafbaar is als niet adequate beveiliging.

[PhilipsFan]

NSB-streek? Ik heb 'm op de hoogte gebracht van zijn probleem, heb netjes uitgelegd waarom dat fout is, maar hij wilde niet luisteren en deed alsof er niks aan de hand was. Tja, dan houdt het op. Ik heb absoluut geen tijd om zijn website te gaan bijhouden of hosten, daar moet hij zelf maar een oplossing voor verzinnen. Hij is zelfstandig ondernemer en verdient daar z'n brood mee, dan moet ie het ook volgens de regels doen. Zeker als het om gegevens van patienten gaat. Als ie het van mij niet wil horen, dan misschien wel van de AP.

Of er gegevens gelekt zijn kun je natuurlijk niet weten. Maar het zou helemaal niet moeten kunnen. Als het om algemene informatie over de praktijk gaat is https niet nodig, maar dit ging om een invulformulier waar om persoonsgegevens wordt gevraagd.

[Verwijderd]

Hij is zelfstandig ondernemer en verdient daar z'n brood mee, dan moet ie het ook volgens de regels doen.

En dat doet ie tot er nieuwe wet is. Ik ben het met je eens dat het niet netjes is maar het is niet tegen de regels. Als jij de Autoriteit Persoonsgegevens belt zullen die je dat geduldig uitleggen. Zolang jij geen vermoeden hebt dat er data gelekt is zou ik niet de tijd verspillen.

[Arietje]

Je bent op dit moment al in overtreding hoor. Die nieuwe wet gaat over overheidswebsites in het algemeen. Als jij nu persoonlijke informatie via http laat versturen zit je fout.

[PhilipsFan]

Wat bazel je nou. "Kan hij er niet bij hebben"? Hij heeft het zelf veroorzaakt! Iedereen doet net alsof zorgverleners zomaar opeens uit het niets een onveilige site hebben en dat ze daar niks aan kunnen doen. Maar dat is flauwekul. Ze hebben die site zelf gemaakt of iemand daar opdracht toe gegeven. Dus ze moeten het zelf fixen of iemand daar opdracht toe geven. Niet als het een keer uitkomt, maar NU METEEN! Het gaat hier om gegevens van je patienten! Die kunnen ernstige problemen krijgen als die gegevens uitlekken, je kunt het je toch niet veroorloven om daar risico's mee te nemen? Ik zie nu pas dat je problemen tussen aanhalingstekens hebt staan. Volgens mij begrijp je niet helemaal wat er allemaal kan gebeuren als die gegevens uitlekken. Ga daar maar eens wat beter over nadenken...

Waarom zou ik hem in vredesnaam de helpende hand moeten bieden? Ik ben niet deskundig genoeg, als ik het fix dan zit er vast ook weer een lek in en dan heb ik het ineens gedaan. Hij moet zijn site laten bouwen door een persoon of bedrijf dat daar kundig in is. Ik begrijp niet wat ik daar als patient mee te maken heb. Ik heb het probleem geconstateerd, hij wist het zelf niet, ik heb het 'm gemeld, het is nu aan hem om daar wat mee te doen.

Wat bedoel je precies met "de samen leving"? Het lijkt wel alsof de hele wereld op z'n kop staat. Ik constateer dat mijn fysio een fout op z'n website heeft waardoor mogelijk patientgegevens kunnen uitlekken en waardoor hij niet aan de wet voldoet, ik meld hem dat, en dan moet ik opeens het probleem voor 'm oplossen? Terwijl ik dat niet eens kan? Totaal van de wereld...

[Reactie gewijzigd door PhilipsFan op 27 juli 2024 09:40]

[jeffhuys]

Je reageert vanuit emotie omdat een van jouw ouders een fysiotherapeut is. Probeer dat eens aan de kant te zetten en goed na te denken over dat dit écht fout kan gaan. Als er een lek bestaat op die website, dan kan die fysiotherapeut een gigantische boete krijgen, en is het gedaan met zijn/haar klandizie. Het is niet de taak van PhilipsFan om daar iets aan te doen, naast natuurlijk uitleggen wat er kan gebeuren. En dat heeft-ie gedaan. Als de fysio daar niets mee doet is het zijn/haar eigen schuld, punt. Huur gewoon iemand in die het voor je fixt.

[Verwijderd]

Niets van emotie bij hoor, dat stel jij.

Ik stel alleen wat er gaande is en dat het zeer vervelend is om de wijsneus uit te gaan hangen maar geen oplossing te kunnen bieden en nog irritant gaan doen ook, de streek welke hierboven geformuleerd wordt snap ik dan ook geheel omdat je gewoon iemand dwars gaat zitten zonder dat hij hier iets aan kan doen, hij neemt een product af bij zijn hoster of designer en denkt daar mee klaar te zijn. Hij mag dit ook verwachten.

Hij heeft als een hoster/designer ingehuurd, vandaar dat het onbehoorlijk is om dan te gaan tippen terwijl er nog geen kans geboden is om het op te lossen.

[BeosBeing]

Hij heeft het zelf gedaan ? Hij is een Fysio en geen IT-er.

Hij hoeft ook niet per sé een website te hebben om zijn vak uit te oefenen.
Zelfs als hij dat wel heeft, dan kan hij mensen om die gegevens vragen als ze bellen of als ze de eerste keer langs komen.

Wilt hij dat via de website doen, omdat het hem daarmee werk scheelt, dan moet hij zorgen dat het veilig gebeurt. Punt. Zoals je uit de andere reacties hier kunt zien is dat tegenwoordig ook wettelijk verplicht.

[Cartman!]

Als hij die kennis zelf niet heeft dan moet hij daar iemand voor inhuren net als dat hij wordt ingehuurd als fysio. Er is hem uitgelegd dat hij in overtreding is en kan daar iets mee doen, als hij dat verzuimt staat ieder in z'n recht dat te melden. Als dat potentieel lekken van gevoelige informatie kan voorkomen dan is dat imo zeker geoorloofd. Netjes met elkaars gegevens omgaan is ook gewoon onderdeel van de samenleving

[curkey]

Meh, hij kan een ticket aanmaken bij zijn hoster of web master, dat een klant geconstateerd heeft dat eea niet klopt. Die mensen kunnen dan prima van repliek dienen.

[carpcatcher]

Dus als jij bij de Bakker een brood gaat halen en constateerd dat de deurklink stuk is ga jij die ook vervangen? want ja hij heeft het zo druk en dat soort problemen kan hij er niet bij hebben..

[Verwijderd]

Wat heeft een deurkruk met veiligheid te maken ? Ik tip vaak even een mannetje waar ik van weet dat die dat per direct op kan lossen ja, en bel hem nog op dat er een klusje voor hem is ook.

Vind ik geen probleem en ik ga geen inbreker bellen om te zeggen... hé de deurkruk is defect zonder te weten dat het slot wel werkt en er alleen maar onnodige schade wordt aangericht.

[Houtenklaas]

Je wil niet weten hoeveel werk een Fysio heeft dezer dagen, ze kunnen dit soort "problemen" er echt niet bij hebben.

Dan moet je een ander vak gaan kiezen. 't Is nu éénmaal onderdeel van het werk en dat gaat gewoon door. Kan je dat niet meer aan of wordt de regeldruk teveel, dan moet je daar iets aan doen. Protesteren tegen de regels, maar niet domweg negeren zoals @PhilipsFan al aangaf. Ook ik ga maandag even aan mijn tandarts melden dat zijn website ook niet voldoet aan de hedendaagse regels. Doe ik trouwens dan wel NA het boren

[Verwijderd]

Je weet echt totaal niet waar je het over hebt, een ander vak gaan kiezen... er zit maar 24 uur in de dag kerel en jij wil steeds minder ziektekosten verzekering betalen.

Als jij nu even 100 euro op een jaar meer betaalt gaat er vast een wereld voor je open

[Houtenklaas]

Je weet echt totaal niet waar je het over hebt, een ander vak gaan kiezen... er zit maar 24 uur in de dag kerel en jij wil steeds minder ziektekosten verzekering betalen.
Als jij nu even 100 euro op een jaar meer betaalt gaat er vast een wereld voor je open

De boodschap beste man is dat je moet voldoen aan de wet. Ook als ZZP'er. Daarnaast wil ik graag 2X zoveel premie betalen als daarmee de zorg ook echt structureel beter wordt en breder wordt ingezet voor zieken die nu in de marge vallen. Alleen verhelpt dat geen IT issues, dat heeft te maken met fatsoen en inzet en heeft niets, maar dan ook niets te maken met premies. Met een dergelijke insteek heeft zo iemand niets te zoeken in de IT. Alsof je boven te wet staat als je het druk hebt ...

[Reactie gewijzigd door Houtenklaas op 27 juli 2024 09:40]

[Verwijderd]

Waarom moet een Fysio iets zoeken in IT ? Hij neemt een service beste kerel, jij probeert er gewoon een punt van te maken waar deze persoon zelf weinig aan kan doen in de eerste instantie, hij kan het wel (laten) veranderen.

Tevens wil jij helemaal geen extra premie betalen je verandert namelijk mijn insteek daarmee, dat is lekker makkelijk en zo verschuil je je achter een "maatschappelijk iets" waarvan je weet dat dat dan nog steeds niet uit kan, jij zal dan meer betalen voor JOUW zorg want dat wil je toch beter ?

Ik vind het altijd prachtig die mensen die in één keer voor of als community reageren of hier voor in staan wanneer het het om een utopi gaat... want dergelijke mensen lijken hier een beter ego van te krijgen, daar gaat het al mis... hun eigen ego...

[Houtenklaas]

Wat leg je me toch een woorden in de mond. Ik zou iets gaan lezen over beroepsethiek als ik jou was, met zo'n insteek ben je gewoonweg een schande voor je beroepsgroep. Ik wens je al het goede, je zal het nodig hebben in je verdere carrière. Mocht die er ooit komen.

[Verwijderd]

Ik raad je aan je woordenschat iets meer te ontwikkelen, je reactie slaat kant noch wal.

Mag jij bepalen wie er succes nodig heeft (als je dat uberhaubt lukt)

[Houtenklaas]

Ik dacht dat je een ordinaire troller was, maar gezien je karma punten kan dat niet. Daarom toch nog deze reactie. Je haalt er dingen bij die er niets mee te maken hebben. Wat ik wel of niet aan premie wil betalen doet helemaal niet ter zake. Waar het om ging, is dat een beroepsgroep gewoon moet voldoen aan de wet. En daar kom je met een nogal emotionele reactie dat die beroepsgroep wel wat anders te doen heeft. Dat mag je vinden, maar daarmee is dat natuurlijk nog niet OK.

Iedere beroepsgroep moet gewoon voldoen aan de wet. Ben je het niet eens met de druk die de wet oplegt aan een beroepsgroep? Dan moet je daar iets aan doen. De wet niet volgen is geen enkele optie. En wil - of kan - je dat niet, dan heb je niets in die beroepsgroep te zoeken. Zo simpel is dat.

Mijn vader, ZZP'er in de petrochemische industrie was er trots op dat ondanks alle regelgeving hij gewoon netjes voldeed aan alle regels en daarmee bijdroeg aan het image van de beroepsgroep. Hij was daarin eindverantwoordelijk, verwijzen naar een toeleverancier (in jouw geval de IT leverancier) dat de fout daar ligt is natuurlijk kinderachtig gedrag. Het is jouw bedrijf, het is jouw verantwoording.

Denk er maar eens goed over na, iemand met zoveel karma punten weet best hoe het zit, jouw reacties passen niet bij je karma status.

Edit: Typo's

[Reactie gewijzigd door Houtenklaas op 27 juli 2024 09:40]

[Verwijderd]

Nou doe er wat aan! Je hebt een gat in de markt gevonden gezien al je onderbouwingen niet ?

[Step5]

Daar betaalt hij toch die goede webhoster voor? Dat ga je als fysio toch ook niet zelf zitten knutselen

[Verwijderd]

Dat zou je hopen en denken... maar blijkbaar houdt iedereen de Fysio er hier verantwoordelijk voor wat enigzins mag maar je adviseert hem dan toch even contact op te nemen met zijn webhoster, die kerel snapt er echt niets van verder wat die hoster allemaal zou moeten kunnen... probleem van veel (grote) hosters... wat niet weet wat niet deert extra personeel scheelt!

[Verwijderd]

Hij ziet er dus blijkbaar de ernst nog niet van in. Zeg hem dan tenminste dat je anders genoodzaakt bent de AFM in te lichten (met mogelijke boete tot gevolg), misschien dat hij dan wel wakker wordt. Anders vind ik het ook wel een NSB-streek ja. Want die man weet er dus niets vanaf en krijgt dan opeens een boete op de deurmat.

Een SSL-certificaat installeren is echt een peace of cake, tenminste zo'n Lets Encrypt ding op Cpanel of DirectAdmin wel. Daarna is het slechts 2 regels in de htaccess en dat ding loopt altijd via https.

[incaz]

De AP kan ook zelf gewoon eerst een aanzegging doen toch?
'Hee, we zien dat jullie formulier via http loopt, wat tegen de wet is. Fix dat binnen een maand, en je krijgt geen boete.'
Dat is eigenlijk precies wat ik van zo'n orgaan wil: dat juist zij dit soort meldingen goed kunnen oppakken, met wortel en stok.

[Verwijderd]

Volgend jaar worden er (forse) boetes uitgedeeld. Kijken of er dan wat veranderd.

Gezien het aantal onveilige sites vermoed ik dat de staatsschuld een stuk kleiner wordt.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 09:40]

[telenut]

kans is groot dat de staat zichzelf veel boetes mag geven ook...

[Verwijderd]

En [url=/nieuws/124103/chrome-gaat-gebruikers-vaker-waarschuwen-bij-http-sites.html]vanaf oktober[/url] gaan Chrome-gebruikers hopelijk zelf ook nog zeuren bij hun zorgverleners en -verzekeraars. Misschien, héél misschien, wordt dán eens de druk opgevoerd bij de hostingpartijen en/of de leveranciers van de software achter die zorgwebsites.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 09:40]

[Soldaatje]

Dat doet Firefox al sinds januari, gelukkig wel.
Snap ook niet wat de reden is om een website niet beveiligd aan te bieden, is daar nog een legitieme reden voor?

[Blokker_1999]

Het is echt niet altijd zo eenvoudig als snel een certificaat aanvragen en dit aan je webserver te koppellen. Afhankelijk van de complexiteit van de site en de achterliggende infrastructuur zijn er ineens een hele hoop elementen waar je rekening mee moet houden. Bij Tweakers heeft het ook enige tijd gekost.

En als je het niet op enkele uren kunt doen moet je er dus een project van maken. In grotere ondernemingen moet dat project ook gebudgeteerd zijn in je jaarbudget. Dus je neemt dat mee voor volgend jaar. Je plant dat in meer naar het einde van het jaar omdat er belangrijkere projecten zijn die eerst afgehandeld moeten worden. Komt het project er eindelijk aan, blijkt dat ze het budget voor een ander probleem hebben gebruikt en dat er voor dit jaar geen geld meer is. De budgetering voor het volgende jaar is ook al lang ingediend dus schuift het project opnieuw 2 jaar op. Ben je zo 5 jaar verder voor het project in een grote onderneming is uitgevoerd omdat het management het niet als prioriteit ziet aangezien de site zonder ook werkt.

[eric.1]

Als het 5 jaar duurt voordat je een SSL certificaat hebt kunnen installeren als bedrijf zijnde moet je toch gewoon toegeven dat je het hele IT verhaal niet serieus neemt?

Als het je echt niet lukt om je website over te zetten van http naar https...dan bel je je hosting provider op en vraag je wat er mogelijk is. Reverse-proxy of ssl-offloading op de fw of loadbalancer is niet zo heel ongewoon, kost letterlijk in totaal 30 minuten werk (incl. aanvraag certificaat).

Maarja...wie niet wilt (of de noodzaak niet ziet) zal altijd excuses naar voren kunnen toveren.

[Verwijderd]

Als het je echt niet lukt om je website over te zetten van http naar https...dan bel je je hosting provider op en vraag je wat er mogelijk is. Reverse-proxy of ssl-offloading op de fw of loadbalancer is niet zo heel ongewoon, kost letterlijk in totaal 30 minuten werk (incl. aanvraag certificaat).

Er ligt een gouden toekomst voor je klaar! Als jij kan garanderen dat een wat grotere site in 30 minuten over is kan je werkelijk rijk worden.

Helaas is het in praktijk niet zo makkelijk en heeft heel veel software not harde links naar http addressen, is veel software gewoon nog niet klaar voor hhtps etc. Doe het een keer in de praktijk en je zal zien dat die 30 minuten al gauw dagen en dagen worden. Natuurlijk niet bij jou, maar bij alle anderen, die niet zo snel en slim zijn.

Je zou op tweakers toch echt verwachten dat dit soort reacties niet zo vaak meer zouden voorkomen. je zou denken dat tweaker de complexiteit van moderne systemen wel zouden inzien. Maar 'certificaatje derin pleuren' lijkt toch vaak de oplossing die voorgesteld word.

Alleen al bekijken wat er mogelijk als problemen konden zijn koste mij al 5000 euro. De totale oplossing voor alle 15 servers (15 x 30 minuten, kan makkelijk in een dag volgens jou) koste een stuk meer. En ik vond het spotgoedkoop. Heel jammer dat ik jou bericht niet eerder las, had me blijkbaar heel veel geld gescheeld.

[eric.1]

Als je een "oplossing" gebruikt zoals in het gequote deel genoemd is..maken de meeste harde links naar http geen moer uit, that's the whole point.

Maar goed, leuk te horen dat ik het nog nooit in de praktijk heb verzorgd.

Ik zal toegeven dat er uitzonderingen zijn...maar dan praat je wel over zeer complexe omgevingen (of uiterst matig opgezet).

Een heel aantal van deze "zorg"sites zijn echt niet heel complex (welke ik zo snel even heb bezocht) en/of zijn vrij standaard WP omgevingen. Daar zal jouw verhaal van 5k aan onderzoekskosten en vele dagen werk sowieso niet voor op gaan....

[Verwijderd]

Even tussendoor:

SSL certificaat

ssl-offloading

Hier gaat het al mis. Het protocol heet al bijna twee decennia TLS. Ruim twee jaar terug is SSLv3 praktisch doodverklaard. Zelfs de al tweemaal overbodig gemaakte standaard voor X.509-certificaten uit 1999 noemt SSL alleen als een voorbeeld van "legacy applications". Het is alleen maar verwarrend om voor TLS de naam SSL te blijven gebruiken.

[Blokker_1999]

En toch spreekt iedereen de dag van vandaag nog altijd over SSL certificaten wanneer het over encryptie gaat ook al wordt er in de praktijk TLS gebruikt. Het gebruik van de term SSL is niet verwarrend aangezien zowat iedereen begrijpt wat ermee bedoeld wordt.

[Peetz0r]

Ja, het kan behoorlijk complex zijn en veel tijd kosten. Juist daarom is het werkelijk belachelijk dat ze er nu pas mee beginnen.

Zoals je zelf al zei, bij Tweakers.net was het ook niet vanzelfsprekend. Maar zij zijn er optijd aan begonnen en het is inmiddels dan ook al een behoorlijke tijd af.

[Reactie gewijzigd door Peetz0r op 27 juli 2024 09:40]

[PhilipsFan]

Als je als zorginstelling persoonsgegevens vraagt via een onbeveiligd formulier, dan moet je je ogen uit je kop schamen. Niet aankomen met smoesjes als projecten en budgetten, je had het al 10 jaar geleden moeten doen, je veegt al 10 jaar de vloer aan met de gegevens van je klanten en eigenlijk verdien je het gewoon dat niemand meer klant wordt totdat het opgelost is. Moet je eens kijken hoe snel het dan opeens wel kan.

[hkuiling]

Net zoals je techniek en functionaliteit test test je ook je beveiliging. Dat is een wezenlijk onderdeel. Geld en waardepapieren worden ook niet opgeslagen in een sinaasappelkistje. Waarom persoonsgegevens wel?
En denk dan ook eens aan de autorisaties in de applicaties en de mogelijkheden om bijvoorbeeld gegevens op te slaan op een USB-stick omdat dat zo makkelijk is. Ook dat hoort bij beveiliging.
En je wilt niet weten hoeveel USB-sticks en andere gegevensdragers ik in de loop van de tijd ben kwijtgeraakt. Maar ik was me er wel van bewust wat voor gegevens daar op stonden.

[waspoeder]

Via let's encrypt kan je toch sowieso even snel je site encrypten ?

[curkey]

Voor een simpele statische site, ja. Maar met een backend omgeving en externe content etc is het wat meer werk.

[waspoeder]

A ok vandaar
Bedankt

[Wim-Bart]

Gewoon een Linux doos met reverse proxy er tussen, misschien zelfs met HA proxy, of een Netscaler of een Baracuda of een F5 of een Juniper of een Paolo Alto. Certificaat er in rammen en klaar. Dan maakt de backend ook niks meer uit. Daarnaast misschien wat rewrite rules in de proxy engine opvoeren om hard coded http: om te zetten naar https: en je bent klaar. Daarna tijd nemen om de site aan te passen om native op https over te gaan.

Het beroepen op de complexiteit van de omgeving is meer een excuus voor: We hebben het niet gedocumenteerd... Of: We hebben onze IT niet onder controle... Of: We hebben geen kennis.

Ik heb nu de laatste jaar zo veel dooddoeners gehoord en de praktijk anders zien uitvallen dat ik me afvraag of mensen veiligheid wel serieus nemen.

[Reactie gewijzigd door Wim-Bart op 27 juli 2024 09:40]

[Blokker_1999]

En daar kom je direct weer bij mijn punt dat zoiets niet goedkoop is, ook gebudgeteerd en gepland moet worden en dus vaak goedkeuring moet krijgen van mensen die er de noodzaak niet van inzien. Snel iets er tussenzetten gaat niet altijd even snel. En zeker in dat soort omgevingen ga je daarna echt geen tijd krijgen om je hard coded http om te zetten naar https want waarom zouden ze daar geld voor vrijmaken als je toch al met https werkt dankzij die nieuwe appliances die veel geld hebben gekost?

[Verwijderd]

In dat geval zorg je maar dat mensen er de noodzaak van inzien. Krijg je geen budget voor backups? Delete prod. Krijg je geen budget voor geheimhouding? Meld gewoon even een datalek bij de ACM.

[Wim-Bart]

Goed lezen, rewrite rules en daarna de site onderhanden nemen om native te gaan. Mijn ervaring is dat dit met de meeste websites namelijk eenvoudig is in te richten en ik heb er een zooi onder handen gehad. Grootste issue zijn die wazige plugins op Joomla en Wordpress die had coded http praten.

Er is niks mee dat een backend in eerste instantie http praat met een "slimme" reverse proxy er tussen waarbij een aantal slimme rewrite rules of content mod rules worden toegepast. In een later stadium wordt het wel recht gezet.

[Douweegbertje]

Je snapt denk ik niet hoe zo'n proxy werkt. Heel de verbinding is veilig tot aan de webserver, die vervolgens ssl eigenlijk heeft laten vallen na de proxy. Kan je dus als http verder werken maar alles wat terug wordt gestuurd is weer secure. Immers is alles naar de proxy gewoon https. "Intern" dus http, maar dat boeit ook niet want er wordt niet verstuurd.

Concreet houdt het in dat dus https kan afdwingen zonder dat je applicatie daar last van heeft of het überhaupt merkt.

[Webgnome]

Ach, vandaag op de radio daadwerkelijk gehoord dat 'we van boven af zijn begonnen om onze beveiliging te verbeteren. Dan begin je boven met beleid en op een gegeven moment bij de website zijn uitgekomen'. Zolang beleidsmakers bij zorginstellingen zo denken kunnen we nog wel een aantal jaren wachten voordat alle (zorg) websites https zijn..

[R4gnax]

Zolang beleidsmakers bij zorginstellingen zo denken kunnen we nog wel een aantal jaren wachten voordat alle (zorg) websites https zijn..

Het OM moet eens wakker worden en dat type beleidsmaker crimineel gaan vervolgen.

HTTPS is door gewaarwording tegenwoordig tot zo'n gemeengoed geworden, dat het niet opzetten ervan voor omgevingen die met persoonsgegevens omgaan, makkelijk gezien kan worden als opzettelijke nalatigheid ten aanzien van de wet bescherming persoonsgegevens. Deze eist dat er courante en adequate technische middelen ingezet worden om de gegevens en overdracht te beveiligen.

Daarvoor kan het OM vervolgen en daar staat een half jaar cel of een geldboete tot € 10.000,- op.

[Reactie gewijzigd door R4gnax op 27 juli 2024 09:40]

[hkuiling]

Die boete en celstraf geldt voor personen. Uiteindelijk zal iemand die onder in de hiërarchie staat wel de Sjaak worden.

Wat bedrijven betreft geloof ik veel meer in naming and shaming. Dat zet pas echt zoden aan de dijk. Dat kost geld en je reputatie.

[Superkanjo]

Wat bedrijven betreft geloof ik veel meer in naming and shaming. Dat zet pas echt zoden aan de dijk. Dat kost geld en je reputatie.

Lijkt me geen wenselijke situatie....Daarnaast wat als de ICT dienstverlener nalatig is geweest? Dan straf je het bedrijf mijnsinsziens te zwaar... Tweakers weten hoe het in elkaar zit, maar veel ondernemers leunen en vertrouwen op de kennis van hun dienstverleners. Tuurlijk mag er gestraft worden, en is het bedrijf zelf ook verantwoordelijk maar naming and shaming, nee.

[burne]

Het OM [..]

gaat daar niet over. In Nederland hebben we een aparte wetgevende macht. Dat is de regering. Als je nou het artikel nog eens leest zul je zien dat er in staat dat de politiek (Plasterk) van plan is een wet te maken. Moet jij je kamerleden in de Tweede en Eerste kamer nog even bellen dat ze voorstemmen, en dan komt het helemaal goed.

[Verwijderd]

Het OM moet eens wakker worden en dat type beleidsmaker crimineel gaan vervolgen.

Mooie grote woorden! Je weet dat het nog niet strafbaar is he? Dat het artikel (gewoon lezen) je verteld dat er mogelijk volgend jaar wetgeving voor komt?

Waar jij je half jaar en 10.000 vandaan haalt?

[R4gnax]

De wet op bescherming persoonsgegevens stelt in staat om bij gevallen waar opzettelijk nalatig gehandeld is ten opzichte van de de voorwaarden voor het verwerken van persoonsgegevens zoals gesteld in desbetreffende WbP, de verantwoordelijken te vervolgen. Daar staat max. een half jaar cel of geldboete tot € 10.000 op.

Maar inderdaad; ik heb even de exacte wetstekst er bij gepakt en dan blijkt dat die maatregel alleen geldt voor het nalatig handelen omtrent het aanmelden van een verwerking van persoonsgegevens en een aantal situaties waarbij gegevensverwerking buiten Nederland en de EU plaatsvindt terwijl dat niet mag of niet juist geregeld is.

Zegt helemaal niets over de waarborgen voor afscherming van de gegevens. Nalatigheid op dat vlak is kennelijk alleen bestuurlijk te beboeten. In elk geval voorlopig dan.

[Reactie gewijzigd door R4gnax op 27 juli 2024 09:40]

[SilentLucidity]

En om gelijk het 'maar tweakers heeft ook pas sinds twee jaar https' gezeik te voorkomen, er word nieuws gerapporteerd waar door tweakers geen mening over word gevormd.

[WokeBroke]

Dat komt altijd weer ter spraken. Maar als er een site is waarvan iedereen mag weten wat ik bij de input formulieren invul, is dat wel tweakers. Ik heb hier nog nooit een sofi nummer in hoeven vullen.

[Guardian Angel]

Aanvulling:
Men zal ook nooit meer om je sofinummer vragen omdat dit in januari 2014 is vervangen door het BSN (Burgerservicenummer)

Heb zojuist mijn apotheek gecontroleerd en deze heeft wel https. In hoeverre de website en mijn gegevens in hun systeem daadwerkelijk 100% beveiligd zijn weet ik niet. Later eens navragen.

[Reactie gewijzigd door Guardian Angel op 27 juli 2024 09:40]

[cracking cloud]

kleine correctie, dat was 2007

[Guardian Angel]

Zocht het nogmaals op en het is deels juist [url]https://https://nl.m.wikipedia.org/wiki/Sofinummer[/url]

Het sofinummer (Sociaal Fiscaal nummer) werd alleen door de belastingdienst gebruikt en het BSN (burgerservicenummer) wordt door het ministerie van binnenlandse zaken gegeven.

Het is dus iets ingewikkelder gelopen en de link legt het beter uit als ik.

[Verwijderd]

Je gaat dat serieus navragen ? Dan niet gaan lopen mekkeren dat je wellicht een uur lang doorverbonden wordt en ventueel kosten moest maken hè

[Guardian Angel]

Er is zoiets als email schijnt het.

Contact is misschien genoeg om het bedrijf wat achter de apotheek zit alert te houden. Zal niet de eerste keer zijn dat een zgn "domme" vraag verrassende reacties oplevert.

De noob spelen is echt handig.

[Verwijderd]

Als jij er je lol aan beleeft, be my guest. Gelukkig heb ik betere dingen te doen, zoals velen.

[True]

Wat is je wachtwoord dan?

[The Zep Man]

Wat is je wachtwoord dan?

Het wachtwoord werd in het verleden wel met encryptie verstuurd, met uitzondering van een formulier waar ik ooit een bug report voor heb ingediend.

Let op dat T.net een jaar de tijd nodig had om van een 'http' een 'https' te maken voor dat formulier. Als je het client-side forceerde, dan werkte 'https' gewoon. Er moest dus letterlijk een karakter toegevoegd worden om het probleem op te lossen. Voor één karakter had een technische site een jaar nodig.

[Reactie gewijzigd door The Zep Man op 27 juli 2024 09:40]

[jeffhuys]

Heb je wel eens iets in productie draaiend gehad, met een cluster aan microservices? Als je die naar https om moet zetten is het niet zo simpel. Het klinkt alsof je zelf het een en ander aan het klussen bent geweest en denkt dat het zo ook werkt in de "echte" IT wereld.

[Verwijderd]

Zo simpel is het hoor, als je alles frontend HTTPS doet en op je interne netwerk niet dan heb je dat zo gefixt.

[jeffhuys]

Nou, nee. Dat is gewoon niet waar. Als je complexe systemen draait waar klanten op rekenen en anders de downtime in rekening brengen, is dat niet "zo gefixt". Je hebt duidelijk nog geen ervaring met dit soort systemen Of je hebt heel veel geluk gehad. Je zal nog wel een keertje terugdenken aan dit bericht als je de pech hebt om zo'n systeem "ff te fixen" hahaha

[Verwijderd]

Je hebt vast gelijk, mijn cluster draait anders zeer goed en dergelijke zaken kan ik gewoon realtime doorvoeren hoor, nooit downtime.

Kwestie van goed design, dan heb je geen downtime en kun je realtime migreren, wellicht heb je zelf nog wat te leren en ervaring op te doen

[jeffhuys]

Zou je denken he. Gelukkig bedoel ik een situatie waarin je een legacy systeem overneemt. Natuurlijk gebruik ik technieken waarbij je zonder downtime alles kunt doen, ik ben geen idioot. Als er echter een bedrijf wordt overgenomen, moeten we die systemen naar onze standaarden migreren. Dat is niet zo even gefixt. Maar dat snap je wel lijkt me.

[Verwijderd]

Definieer Legacy, Legacy zou JUIST super mainstream moeten zijn en aan alle standaarden moeten kunnen voldoen.

Wie zegt dat jullie standaarden beter zijn dan wat er al geinplementeerd is... wellicht doen jullie het de hard way ?

[TheBrones]

Ik vind https eigenlijk pas echt relevant voor sites met persoonlijke gegevens. Voor nieuws sites is het naar mijn idee niet noodzakelijk maar je voorkomt er natuurlijk wel mee dat er iets zoals een man in het middle kan worden uitgevoerd. Daarnaast bied https gewoon meer privacy omdat je zeker weet dat niemand de verbinding kan bekijken of data kan veranderen.
Meer HTTPS kan na mijn idee nooit kwaad. Zeker niet als er login gegevens naar toe gaat, dan vind ik het in 2017 wel een vereiste.

[Devaqto]

Los van het feit dat bijvoorbeeld Tweakers een nieuwssite is, hoort er bij elke website waar formulieren (login o.a.) worden gesubmit HTTPS verbinding te zijn. Je wilt natuurlijk niet dat welke vorm van data onderschept wordt met een MITM aanval.

[Wim-Bart]

Https is relevant voor iedere site waarop gegevens uitgewisseld worden. Formulier op site, SSL verplicht. Er is totaal geen excuus tegenwoordig om geen SSL te hebben.

[ASS-Ware]

Ik vind https eigenlijk pas echt relevant voor sites met persoonlijke gegevens.

Ik vind van niet.
Op een informatieve pagina kan ssl/tls voorkomen dat iemand de info, die jij te zien krijgt, aanpast middels een MiM attack.

[downtime]

Sinds wanneer is Tweakers een zorgwebsite?

[SilentLucidity]

Dat beweer ik nergens, ik zie alleen vaak bij dit soort https nieuwsberichten mensen flaimen dat tweakers het ook nog maar 'pas' heeft.

[Fastfreddy666]

Als je patientdossier op straat ligt is dat veel erger voor de privacy. Sommige potentiele werkgevers of verzekeringsmaatschappijen zullen het dan niet nalaten van deze gegevens gebruik te maken met alle gevolgen van dien.

Wat je op je (tweak)blog doet is iets wat je juist wilt delen met medetweakers. Maar het is toch goed dat ze het gedaan hebben want er zitten ook privacy gevoelige gegevens in de gebruikersdatabase. Als mijn email adres op straat ligt is dat ook niet prettig. Ik krijg al nieuwsbrieven en spam genoeg.

Disclaimertje dan maar:

Vrijwaring: De verantwoordelijkheid voor de inhoud van deze publicatie ligt volledig en uitsluitend bij de auteurs. Deze geeft niet noodzakelijkerwijs de mening van tweakers.net weer.

Dat is juridisch geneuzel of je alvast indenken voor schadeclaims. Recht is een geweldig vakgebied.
Maar dit speelt meer in de VS want schadeclaims zijn daar aan de orde van de dag.

[Genius-General]

Dit is toch wel zorgwekkend

[ruud1234]

Toevallig blijkt de overgang naar https echt nog niet zo soepel te gaan als velen hier willen doen geloven. Ik heb enige tijd geleden een nieuwe WP testsite gebouwd. Eerst op http en nadien overgezet naar https. Hoewel dit ogenschijnlijk soepel verliep, is de FTTB met een factor 10 hoger op https. Zowel de provider als ikzelf komen er niet achter waarom dit zo is.

Kortom, zo simpel is het toch echt niet. Mocht iemand nog een goede suggestie hebben..?

[R4gnax]

Oud, maar kan nog relevante punten bevatten:
https://www.igvita.com/20...x-tls-time-to-first-byte/

[ruud1234]

Thanks!! Ik zal dit meteen met mijn provider bespreken.
Het beschrijft de situate uitstekend.