Autoriteit Persoonsgegevens: gebruik sslv2 kan in strijd zijn met de wet

De Autoriteit Persoonsgegevens waarschuwt dat er 'verscherpte aandacht' is voor organisaties die nog steeds sslv2 ondersteunen en daarmee kwetsbaar zijn voor de onlangs ontdekte Drown-aanval. Bijna twintig procent van de websites van Nederlandse gemeentes voldoet niet aan deze eis.

De Nederlandse privacywaakhond legt uit dat organisaties in bepaalde gevallen in strijd met de Wbp handelen, als zij sslv2 ondersteunen. Volgens deze wet hebben organisaties die persoonsgegevens verwerken namelijk een verplichting om deze te beveiligen. Beveiligingsonderzoekers maakten begin deze week bekend dat ondersteuning van sslv2 ervoor kan zorgen dat beveiligde tls-verbindingen ontsleuteld kunnen worden. Op die manier zou het voor een aanvaller die gebruik maakt van deze Drown-aanval ook mogelijk zijn om persoonsgegevens te onderscheppen.

De toezichthouder wijst erop dat het NCSC richtlijnen heeft opgesteld voor veilig gebruik van tls en adviseert om een update van OpenSSL uit te voeren, omdat ook bleek dat bepaalde kwetsbaarheden in deze software het uitvoeren van een Drown-aanval eenvoudiger maken. De Autoriteit Persoonsgegevens voegt daaraan toe dat de eisen voor de bescherming van persoonsgegevens afhangen van de gevoeligheid van persoonsgegevens.

Uit een onderzoek, dat RTL Nieuws onder de websites van 175 Nederlandse gemeentes heeft verricht, blijkt dat haast twintig procent van deze sites niet aan de eis van de Autoriteit Persoonsgegevens voldoet. Zij maken nog steeds gebruik van ondersteuning voor sslv2. Dat is problematisch, omdat bij zaken die burgers online via deze sites kunnen regelen vaak persoonsgegevens verstuurd worden. Daarnaast zouden er zestien websites helemaal geen gebruik maken van een beveiligde verbinding. Het is niet duidelijk of de Autoriteit Persoonsgegevens maatregelen gaat nemen naar aanleiding van deze bevindingen.

Reacties (82)

Ik snap niet dat niemand de moeite lijkt te nemen om bij dit soort systemen zelfs als hotfix gewoon een frontend server of reverse proxy neer te zetten met de juiste configuratie. Legacy systemen, complexe applicaties of andere smoesjes zijn gewoon totaal geen reden om dit niet te doen. Je kan eigenlijk voor alles wat over TLS kan gewon iets als haproxy zetten in TCP mode. En als je het goed wil doen en echt per domein alles voor elkaar wil hebben zet je het er in HTTP(S) mode voor zodat je per domein kan zien wat er allemaal uitgespookt wordt. Als je upstream applicatie dan nog uit zakken stront opgebouwd is en het niet simpelweg te configureren is om iets anders dan SSLv3 te doen, dan laat je een frontend/edge server zoals haproxy of nginx toch lekker over SSL met je upstream applicatie babbelen. Kan je lekker intern en afgeschermd doen, geen applicatie die het door zal hebben.

Het kost je hooguit een uurtje werk om het compleet met configuratie management en monitoring neer te zetten, en als je het daarna nog verder wil specialiseren naar je applicatie kan je altijd nog 1 fte engineer neerzetten om dat een paar maanden te doen. Lijkt me sterk dat dat meer gaat kosten dan een boete...

Ben het in hoofdlijnen met je eens, maar het is niet altijd zo makkelijk. Appliances bijvoorbeeld mag je niet aanzitten anders ben je support/garantie kwijt, dan ga je zeuren bij de vendor maar 'die ziet het probleem niet', of 'in de volgende upgrade zit een patch, ETA 2 jaar'.

Een ander voorbeeld is internationale bedrijven, waar de wetgeving per landt verschild. In een aantal landen mag je geen sterke encryptie gebruiken, dus moet je per vestiging gaan onderzoeken welke wetgeving van toepassing is en een (aangepast) upgradeplan, testprocedure en implementatieplan gaan schrijven. Duurt soms tot 4-5 maanden voordat je dan één vulnerability behandeld hebt.

[Reactie gewijzigd door Viince1 op 4 maart 2016 19:30]

Appliances bijvoorbeeld mag je niet aanzitten anders ben je support/garantie kwijt, dan ga je zeuren bij de vendor maar 'die ziet het probleem niet', of 'in de volgende upgrade zit een patch, ETA 2 jaar'.

Je legt mooi uit waarom ik geen appliances koop. Je maakt jezelf afhankelijk van een blackbox die je niet zelf kan of mag repareren. Misschien dat deze wet daar iets aan verandert, als bedrijven boetes gaan krijgen omdat ze niet snel genoeg kunnen updaten gaan ze wel verhaal halen bij hun leveranciers en zorgen ze dat het de volgende keer in het contract staat.

In een aantal landen mag je geen sterke encryptie gebruiken,

Zijn die er nog steeds? Wat slecht. We zijn hier nu zo'n beetje maandelijks bezig met gaten dichtstoppen die we te danken hebben aan de Amerikaanse restricties op encryptie.

dus moet je per vestiging gaan onderzoeken welke wetgeving van toepassing is en een (aangepast) upgradeplan, testprocedure en implementatieplan gaan schrijven. Duurt soms tot 4-5 maanden voordat je dan één vulnerability behandeld hebt.

Dat is een reden , maar geen excuus. Als je niet de capaciteit hebt om met dit soort zaken om te gaan dan ben je te snel gegroeid. OK, het is wel een beetje makkelijk om dat vanaf de zijlijn te roepen, maar uiteindelijk is het wel waar het op neer komt. Als je bedrijfspand afbrandt dan zal de brandweer ook geen genoegen nemen met de uitleg dat de regels in het buitenland anders zijn en dat je daarom nog geen nieuwe batterijen in de rookmelders hebt gedaan.

Nu weet ik ook wel dat IT zo'n puinhoop is dat de meeste bedrijven het echt niet bij kunnen houden. Die situatie is echter wel (mede) ontstaan omdat we heel lang onveilige software hebben geaccepteerd (en de meeste bedrijven nog steeds). Zolang bedrijven er niet om vragen zullen de leveranciers er ook niet mee komen. Deze wet helpt om bedrijven op hun verantwoordelijkheden te wijzen.

We hebben het over Nederland, TLS 1.2 enz. is geen probleem hier. Qua appliances is er ook geen probleem: je kan prima een server met twee netwerk interfaces voor je appliance zetten. Appliance krijgt z'n verkeer volgens SLA en licentie, server regelt communicatie met clients met fatsoenlijke bescherming. Hell, je hebt de commerciële appliance om dit soort zaken te doen ook nog, Aloha. Die zeg je voor je appliance die problemen maakt en je probleem is weg.

[Reactie gewijzigd door johnkeates op 4 maart 2016 23:48]

Niet helemaal waar John. In bepaalde highperformance omgevingen is het niet zo eenvoudig als jij zegt om er even "snel wat voor te zetten' Sites/applicaties met een grote userbase (honderduizenden tot miljoenen) hebben vaak iets meer nodig dan een "proxietje" ervoor. En de vertraging die een extra hop oplevert kan soms gewoon nét even te veel zijn in situaties waar een continue delivery van belang is.

Maar voor eenvoudige sites zoals die van gemeenten e.d. is er geen enkel excuus en heb je volkomen gelijk.

Volgens mij is er geen enkele high performance web applicatie geen geen frontend server gebruikt. Of dat dan met een black box ADC gaat, nginx, haproxy of varnish, ze doen het allemaal. Zelfs Apache wordt er nog wel eens voor ingezet. Stel dat het niet eens voor TLS termination gebeurt, maar puur voor load balancing of failover, dan nog heb je er iets voor nodig en dan nog zit er wat voor. Een extra hop zou ik het niet willen noemen, het is geen router. Daarnaast kan je je frontend server ook persistente connecties met je achterliggende servers laten leggen zodat die niet opnieuw opgebouwd hoeft te worden. Qua performance maakt het ook geen zak uit, HAProxy kan meer verwerken dan een enkele webserver of applicatieserver kan verwerken; die 100000+ requests per seconde kan je met IIS of Apache direct aan het net wel op je buik schrijven. 40000 forwards per seconde ga je met je applicatie ook niet redden. En dat is op een consumentenstack van een Asus P5E en een E8200...

Er zijn maar een paar redenen waarom je je applicatieservers direct bloot stelt:

- Gebrek aan kennis
- Gebrek aan middelen
- Administratieve bepalingen

Je hoeft ook niet aan de appliances zelf te zitten, je kunt tussen de appliance en het internet een reverse proxy zoals bijv. nginx plaatsen. Deze kan als client optreden voor de appliance en het zelf weer aanbieden met een goed certificaat.
De kosten zijn enkel een server, wat tijd en een nieuw SSL certificaat.

Ik vraag me dan toch af hoe zo'n gemeente het gebruik van SSLv2 gaat verklaren... houd niemand die systemen actueel?
Ik zie het zelf nochtans als onderdeel van mijn takenpakket als ICT'er om dit soort zaken te monitoren en op eventuele issues te acteren.
Het is niet zo dat dit drown het eerste probleem is met dit protocol. Dat dat hele drown nog een ding is is gewoon absurd, of zie ik dat verkeerd?

Ik vraag me dan toch af hoe zo'n gemeente het gebruik van SSLv2 gaat verklaren... houd niemand die systemen actueel?

Ik denk dat een groot deel van het probleem is dat er een verkeerd beeld van IT bestaat, ook onder IT'ers. Het foute beeld is dat je een "oplossing" koopt, zoals een applicatie, een website of een apparaat, en dat je dan klaar bent, zowel in werk als in geld.
In werkelijkheid heeft alles onderhoud en beheer nodig. In de meeste gevallen zullen hiervoor hoger zijn dan de aanschafprijs. Op het moment dat je zo'n aanschaf doet moet je ook gled en tijd vrij budgetteren voor het onderhoud. Dat zie ik vaak verkeerd gaan.
Na drie jaar hangt er dan een doos in het netwerk waarvan niemand nog weet wat het wachtwoord is, hoe je patches moet installeren of waar het supportcontract is gebleven maar die wel essentieel is voor de bedrijfsvoering.

In mijn werk heb ik veel met kleine verenigingen, bureautjes en onderzoeksgroepjes te maken. Die willen dan ook wel een website en hebben 500 euro budget. Dan geven ze €475 uit een aan een Wordpress template en €25 euro aan een buget webhoster en dan is de poet op maar moet die website wel nog vijf jaar in de lucht blijven. Na een jaartje moet ik ze dan vertellen dat ze een probleem hebben dat dringed moet worden opgelost.

Ik zie het zelf nochtans als onderdeel van mijn takenpakket als ICT'er om dit soort zaken te monitoren en op eventuele issues te acteren.

Een ander probleem dat ik vaak zie is dat alles met een stekker "ICT" wordt genoemd en dat alle werknemers over één kam worden geschoren. Iemand die desktopondersteuning geeft heeft echter heel andere vaardigheden dan een netwerkbeheerder of een websitedesigner. Toch is het heel gewoon dat er maar één IT'er in een bedrijf of afdeling is die verantwoordelijk is voor alle IT. Dat is dan typisch een all-rounder die vooral veel van desktops, Windows en kantoorautomatisering weet maar niet zo veel van servers en infrastructuur.

Het is niet zo dat dit drown het eerste probleem is met dit protocol. Dat dat hele drown nog een ding is is gewoon absurd, of zie ik dat verkeerd?

Dat zie je helemaal goed, het is ook absurd. Laat het een waarschuwing zijn voor alle overheden: blijf met je tengels van encryptie af! Het DROWN-probleem hebben we grotendeels te danken aan de Amerikaanse exportbeperkingen op cryptografie. Zonder die regels was SSL2 waarschijnlijk al veel eerder uitgeschakeld.

Ben het met je eens dat het grotendeels voorkomen kan worden, enkele uitzonderingen daargelaten. SCADA (productiesystemen) worden vaak ontwikkeld met een levensduur van 30/35 jaar voor ogen, ook onze eigen belastingdienst draait op systemen van volgens mij al 30 jaar oud. Ik kan hier echter geen bron van terugvinden. Staat mij nog bij van een gastcollege gegeven door Fox-IT over de Diginotar crisis.

Dat iets 'legacy' is was vaak het go-to excuus. Ondertussen wordt dit in mindere mate geaccepteerd. Legacy draaien is prima, maar bij deze vulnerability kan je de vraag stellen of legacy dan echt als webserver via het internet toegankelijk moet zijn.

Legacy vind ik een onwenselijk maar acceptabel argument als je het over interne applicaties hebt. Zoals die Windows 3.11 PC die op het binnenhof iets doet met het klimaat of poortjes of weet ik veel wat.
Maar legacy is geen excuus om een onveilig protocol in dienst te houden dat gewoon te benaderen is via internet. Daar had dan allang een andere oplossing voor ge-implementeerd moeten worden.
Iets wat aan internet hangt moet op de eerste plaats veilig zijn. Als het op dat punt faalt mag het m.i. gewoon niet aan internet.

[Reactie gewijzigd door Anoniem: 80487 op 4 maart 2016 23:34]

SCADA systemen horen helemaal niet aan het internet te hangen. Als je die gegevens perse van buitenaf zichtbaar wil hebben dan zijn daar andere oplossingen voor (ik maak er toevallig eentje ;-) ), die wel gewoon veilig zijn...

Eh,. ik hoorde laatst nog dat ze bij een gemeente een oude commodore hadden gevonden uit 1985 ofzo, die verantwoordelijk was voor de airco,. (en nog steeds werkte!)

dus sslv2 verbaast me echt niks.

If it ain't broken, don't fix it. En indien een kritiek systeem wel liefst zien dat je een backup klaar hebt staan. Oude technologie werd gemaakt om decennia lang mee te gaan, vandaag moet evenwel alles zo snel en goedkoop mogelijk gemaakt worden. Vervang dat systeem door iets nieuw en modern en de kans is groot dat je tijdens het eerste jaar al meermaals een service technieker mag laten langskomen wegen opstartproblemen en dat er binnen de 10 jaar grote problemen ontstaan waarbij er wisselstukken nodig zijn die niet meer voor hande zijn.

Er wordt nog steeds techniek gemaakt die lang mee moet gaan maar die kost gewoon net zoveel als de oude techniek vroeger... Dus vaak te veel voor mensen nu. Je kunt gewoon "aircraft grade" of millitary grade electronica kopen, je betaald voor het echte spul alleen wel ECHT de hoofdprijs.

Klimaatsysteem 2e kamer toch?

Als het niet kapot is, repareer het dan ook niet. Gemeentehuis hier heeft ook zoiets, ken iemand die de techniek regelt die er zo over denkt. Zit aan geen enkel netwerk, enige wat het doet is airco aan en uit zetten met een knop.

Het probleem ligt em vaak in legacy software en hardware en de soms grote kosten om het te vervangen. En als het dan fout gaat dan is er weer een IT-project van de overheid dat faalt en dan heb je weer gezeik. Ze hebben geen oplossing die goed(koop) is dus veranderen ze waarschijnlijk gewoon niks.

Heel je verhaal gaat op voor bijvoorbeeld specifieke applicaties die domweg niet werken op bijvoorbeeld nieuwere systemen. Daarom zie je nog best vaak bij bedrijven nog een oude IBM bak of een DOS bakje staan met wat meuk. Heel dat ding is dan zo brak en lek als een roestig vergiet. Het punt is dat zoiets intern draait, en niet toegankelijk is van buitenaf. Helemaal prima dus, alleen jammer voor de gene die er mee moeten werken / onderhouden.

In dit geval gaat het om websites. Belangrijk hier om te weten is dat het eigenlijk voor zowel de browser als de applicatie het letterlijk geen ruk uitmaakt of het nu ssl v2, 3 of TLS is. Het is een protocol, geen core implementatie voor een applicatie!

Ik ken persoonlijk geen één website die niet meer functioneert onder TLS omdat ze over zijn gestapt. Laat staan dat een (simpele) website van een gemeente...

Nog een detail: Het gaat erom dat ze het ondersteunen Ik weet vrijwel zeker dat 80%++ van die websites gewoon met TLS werken, maar domweg nog ssl v2 ondersteunen. Nja simpel om zoiets dus op te lossen!

Het probleem is niet dat de site zelf niet werkt, maar dat clients die gebruik moeten maken van de site niet met bijv TLS overweg kunnen.
Denk aan bijvoorbeeld een interne zoekcrawler.

TLS 1.0 is meer dan 15 jaar oud. Clients die dat niet ondersteunen horen niet in een netwerk te hangen.

Een 2e proxy? Een SSL gateway ervoor? Het is gewoon een kwestie van competentie (laag) en prioriteit (nog lager).

Sorry, je hebt nog geen enkel normaal argument gegeven. Er zijn eigenlijk geen technische limitaties waarom het niet kan of moeilijk zou zijn, al helemaal niet voor een website van een gemeente.

Echt nogmaals ben ik het eens met het feit dat je verder moet kijken dan je neus lang is, en dat het in vele gevallen in de IT het niet een kwestie is van "een knopje omzetten". Echter zit zowel SSL als TLS -onder- de applicatielaag. Op het moment dat je al SSL hebt, moet je een server (of een client in jouw voorbeeld) enorm verpest hebben wil je TLS niet kunnen implementeren.

Verder: TLS 1.1 komt uit 2006 en 1.2 uit 2008. Als je na 8 jaar het nog niet voor elkaar hebt dan kun je maar één conclusie trekken.

Vervolgens kun je wel met 100 argumenten komen, maar dit praat je niet goed en hebben we het echt over onkunde, onwetendheid en eventueel luiheid.

[Reactie gewijzigd door Douweegbertje op 5 maart 2016 00:55]

Zelfs dan is het niet nodig en kan je een site gewoon achter een reverse proxy hangen die SSL voor je afhandelt en aan de achterkant gewoon desnoods standaard HTTP verder gaat. Voor onder de 1000 euries hebbie een Netscaler VPX of ander device.

Dat maakt dus geen zak uit. TLS-only frontends kan je altijd voor je legacy systemen plaatsen, ze zullen dat niet eens merken.

haproxy transparent proxy...
uurtje werk, maar de voorbereiding voordat het ambtelijk apparaat de EUR 1000 voor een systeem geregeld heeft duur nog een paar jaar. En doorhet aantal te bestenden uren van het ambtelijk appraat zullen de kosten ook wat hoger worden....

Wacht maar tot ze boetes beginnen te krijgen. Dan kan er in eens van alles. Of als iemand een grootschalige geautomatiseerde hack op zet.

Met de druk de laatste jaren om meer en meer te bezuinigen op het ambtenaren apparaat betaald de lokale overheid niet echt veel. Waarom zou je als goede ICT-er bij een gemeente willen werken als je in de particuliere branch meer kan verdien? Als een gemeente wel genoeg wil uitgeven voor goede mensen dan hebben ze simpelweg te weinig mensen om al het werk te doen vanwege dat beperkte budget.

Het zal geen mega vetpot zijn maar volgens mij is het niet zo slecht gesteld met de arbeidsvoorwaarden in ambtenarenland hoor...
Het gaat mij i.i.g. niet alleen om de centen.

[Reactie gewijzigd door Anoniem: 80487 op 4 maart 2016 23:31]

Tsja... daar ga je al de mist in. Dit soort zaken monitoren zou niet in de eerste plaats bij de techneut moeten liggen maar bij iemand die beveiliging/security als hoofdtaak heeft.

Ik sluit me er bij aan. Maar wellicht moet er dan ook gekeken worden naar de webshops, velen hebben nog niet eens SSL. Maar in die webshops laten we ook steeds meer gegevens achter. Ik denk dat dit dan ook een druppel is op een gloeiende plaat.

heb jij ooit je bsn moeten invullen bij bijv azerty mediamarkt of bol.com

Ja, zo gauw als je een zakelijke aankoop doet moet je je btw-nummer opgeven. Dat is opgebouwd, voor niet ingewijden, uit je bsn-nummer en een achtervoegsel, in de meeste gevallen 'B01'. Je btw-nummer staat ook verplicht vermeld op iedere factuur etc. die de deur uitgaat.
Een bsn-nummer als gevoelig gegeven beschouwen is totale onzin.

Een bsn-nummer als gevoelig gegeven beschouwen is totale onzin.

Het is wél gevoelig en wel om twee redenen.

Ten eerste staan gevoelig en geheim los van elkaar. Dat iets geen geheim is maakt het nog geen ongevoelige informatie. Mijn naam en telefoonnummer zijn geen geheimen maar wel gevoelige persoonsgegevens. Niet iedereen hoeft mijn nummer te hebben.

Ten tweede staat in de wet dat het per definitie wel zo is. Dat is misschien een beetje flauw maar het is de wet, je zal er dus gehoor aan moeten geven.
Dat de staat zo'n stomme constructie heeft bedacht die het onmogelijk maakt om het geheim te houden verandert daar niks aan. Als je een bedrijf hebt is het inderdaad onmogelijk om je BSN geheim te houden. Toch zegt de staat dat je dit wel moet:

Het BSN is strikt persoonlijk. Uitwisseling van burgerservicenummers is wettelijk niet toegestaan

van https://www.rijksoverheid...d/burgerservicenummer-bsn

[Reactie gewijzigd door CAPSLOCK2000 op 5 maart 2016 14:37]

Als zelfstandige in Nederland moet je dus eigenlijk kiezen welke wet je gaat overtreden als ik het goed begrijp?

Je mag geen van beide wetten overtreden. Het is dus illegaal om zakelijke transacties te doen waarbij je je bsn moet opgeven. Het zal er wel op neerkomen dat je volgens de letter van de wet geen recht hebt op 21% korting als zijnde niet-paticulier. Immers als je die korting wilt, moet je de wet overtreden.

Het gaat om persoonsgegevens, maar ook BSN valt daaronder:

BSN maakt deel uit van een BTW nummer voor bijv. ZZP ondernemers, ofwel de meeste freelancers. Laat het nou verplicht zijn om BTW nummers te gebruiken op een zakelijk factuur. Daarmee dus BSN ook geregistreerd.

Om het plaatje even compleet maken: het bedrijf dat de factuur uitschrijft is verplicht zijn eigen btw-nummer te vermelden. Het bedrijf, waaraan de factuur is gericht, is dat echter niet, mits beiden in hetzelfde land zijn geregistreerd.

De meeste op bedrijven gerichte webshops vragen standaard naar het btw-nummer van de besteller, wat dus nergens voor nodig is. Hoewel het invullen van het btw-nummer dikwijls optioneel is, is het onverplichte vragen ervan gezien de gevoeligheid van deze informatie merkwaardig, om niet te zeggen ongewenst, want misverstanden in de hand werkend.
http://www.belastingdiens...factuureisen/factuureisen

Nee. Echter gaat deze wetgeving niet over BSN nummers, maar over persoonsgegevens. Dit is elke vorm van informatie die teruggeleid kan worden naar een persoon. Naam, telefoonnummer en e-mail zijn dus ook persoonsgegevens en webwinkels moeten hier voorzichtig mee omgaan.

Webwinkels hebben vaak wel een prikkel om aan security te denken. Als een incident zich voordoet met flinke reputatieschade kan dat zomaar het einde zijn van de onderneming.
Een gebrek aan security wordt steeds vaker gezien als een risico voor de bedrijfscontinuïteit, in plaats van enkel een IT-risico.

Nee maar die websites hebben ook wel hun beveiliging op orde. Wat echter wel zorgelijk is dat er nog kleinere webshops nog zonder ssl beveiliging zijn. Als je dan op een publiek netwerk iets besteld, is het in theorie vrij eenvoudig om de ingevulde persoonsgegevens te achterhalen zoals je adres. Daarnaast zie ik ook nog té vaak webshops waar als je een account aanmaakt het wachtwoord doodleuk nogeens in plain text naar je wordt gemaild

Dat mailen bij registratie is het probleem niet. Op het moment van registratie heeft de server namelijk je plain tekst wachtwoord in zijn geheugen. Na het registreren is dit niet meer het geval.

Als ie bij "wachtwoord vergeten" je wachtwoord kan opsturen, dat is een slecht teken.

Dat snap ik ook wel, alleen geeft het mij niet echt vertrouwen dat dit daadwerkelijk goed beveiligd wordt opgeslagen.

Waarom niet?
Dat de server op het moment van registratie aan je wachtwoord kan is niks bijzonders. De stappen erna wel.
Bij de systemen die ik gemaakt heb ben ik het plain text wachtwoord kwijt na stage1 van het registreren.

Dat is wel jammer, dan moet je er dus altijd aandenken een wachtwoord te gebruiken wat niet erg is als dat in plain tekst naar je mailserver gaat.

Het is een van de "not-dones" van login - systeem design.

Ben je er bang voor dat je mail-hoster die emails in gaat kijken of zo?
De email gaat namelijk rechstreeks vanaf die site naar jouw mailserver. encrypted ook nog als beide partijen het ondersteunen.

Nee, maar je gaat me nou niet vertellen dat email nou zo veilig is. Wij hebben onze mail accounts misschien wel op orde, maar hoe vaak mensen niet hun account "kwijt raken" omdat ze vallen voor phising/social engineering.

Het blijft gewoon bad practice. Mail ze dan een tijdelijk wachtwoord dat maar 1 keer werkt.

Als criminelen toegang krijgen tot de inbox van iemand. W\at houd die crimineel dan tegen om even wachtwoord reset op de website aan te vragen?
Enigste dat daar tegen helpt is 2-factor authentication.
Het is ook een deel gebruikersvriendelijkheid.
Hoe vaak ik wel niet gebruikers gehoord heb dat ze niet kunnen inloggen en dan blijkt dat ze onbewust 1 teken verkeerd intikken omdat ze bij de registratie iets verkeerds ingetikt hebben (X2)

Het gaat tijd worden dat SSL, in de juiste versie, gratis beschikbaar komt. Als het zo belangrijk is, want er is inmiddels enorm veel software "gratis", dan gaat dit ooit ook aangeboden worden met een aantrekkelijke verdiensleutel.

Euhm de software om SSL/TSL te gebruiken op je webserver is gratis beschikbaar. De breed gedragen certificaten echter niet.

Ik weet niet of je het over de encryptiesoftware hebt of over de certificaten zelf maar beide zijn gratis en vrijelijk beschikbaar.
Het probleem waar het hier om gaat is een softwareprobleem, met het certificaat zelf is niks mis. De kosten van een certificaat zouden nooit een reden mogen zijn om nog SSL2 te draaien.

Dat is er toch al? Openssl en Let's encrypt

Ook voor website's? HTTPS? Uitleg hierover is uiterst summier en in bijna alle gevallen is het betalen geblazen. Hosting bedrijven zouden TSL, zeker de overheid, op orde moeten hebben, inderdaad. Het blijkt, lees ik hierboven, zelfs gratis te zijn.

Steeds meer hosting bedrijven, vooral die gene die DirectAdmin gebruiken, ondersteunen de gratis implementatie van Lets Encrypt (TLS 1.3).

Wat mij betreft mag er dus meer gecontroleerd worden op onbeveiligde websites.

Installatie van een betaald certificaat (vanaf 3 euro p/j) is ook geen hogere wiskunde.

[Reactie gewijzigd door SEQREEL op 6 maart 2016 18:36]

Lijkt me vrij sterk dat de autoriteit persoonsgegevens boete's gaat opleggen aan gemeenten. Die boete's kunnen oplopen tot 810.000 of 10% van de wereldwijde omzet. Dat zijn flinke bedragen voor bepaalde gemeentes.
De wetgeving is opgezet om ontwrichting van de maatschappij te voorkomen, bijvoorbeeld door een gigantisch lek in persoonsgegevens.
Een boete van 810.000 neerleggen bij een gemeente kan echter zulke implicaties hebben dat het juist de maatschappij gaat ontwrichten. Een gemeente zal niet failliet gaan, maar het is vrij lullig als het buurthuis dicht moet omdat SSLV2 nog aanstaat op de website.

Afijn, ik vind Drown weer lekker overdreven. Het is een klassieke downpadding attack die van toepassing is op een protocol wat al heel lang dood is (of hoort te zijn). Als het nu nog aanstaat heb je er een (goede, discutabele) reden voor of iets vertelt mij dat je security hygiene dan zo ver van het padje af is, dat DROWN niet je grootste probleem is. Hiernaast is het niet heel makkelijk uit te buiten , je moet (als hacker) toch de verbinding kunnen onderscheppen. Dit is al significant moeilijker dan een simpel pakketje sturen zoals dat bij HeartBleed het geval was. Ik lijk niet de enige te zijn met deze mening overigens.

Het RTL artikel trekt het geheel weer vreselijk uit context en het allemaal weer lekker spectaculair:

Je persoonsgegevens zijn bij minstens 49 gemeentewebsites niet veilig. Een hacker kan de verbinding tussen jou en de website van de gemeente onderscheppen en privacygevoelige informatie buitmaken.

[Reactie gewijzigd door Viince1 op 4 maart 2016 18:29]

Afijn, ik vind Drown weer lekker overdreven. Het is een klassieke downpadding attack die van toepassing is op een protocol wat al heel lang dood is (of hoort te zijn). Als het nu nog aanstaat heb je er een (goede, discutabele) reden voor of iets vertelt mij dat je security hygiene dan zo ver van het padje af is, dat DROWN niet je grootste probleem is.

Leuk, maar hoe weet jij als bezoeker dat een website al dan niet vatbaar is voor Drown (en dat dus je gegevens mogelijk gecompromitteerd kunnen zijn)?

Euhm, door dat te controleren op https://drownattack.com/ ?

Dat is onredelijk; je kunt van een normale gebruiker niet verwachten dat die überhaupt op de hoogte is van het bestaan van SSLv2 of de Drown-attack en dus dat hij/zij moet controleren of een website vatbaar is voor iets dergelijks. Je mag al in je handjes klappen als een normale gebruiker het verschil weet tussen beveiligd en onbeveiligd en wat het voordeel is.

Ten tweede is die website niet bullet-proof; een niet-bekende dienst (op een niet-standaard poortnummer) kan vatbaar zijn voor Drown en een zelfde certificaat gebruiken als een bekende dienst (http, https, smtp) die niet direct vatbaar is, waardoor ook die bekende dienst uiteindelijk vatbaar is.

Kortom; websites moeten zelf proactief zijn, hun diensten onderzoeken en deze upgraden.

Waarom zou de AP geen boetes aan gemeentes gaan opleggen? Dat zou een vrijbrief zijn om niets meer aan security te doen.
En juist dan krijgen we maatschappij-ontwrichtende taferelen: Jij vind het vervelend als het buurthuis dichtgaat, ik zou het vervelender vinden als de gehele IT van de gemeente onderuit gaat. Dat betekent niet alleen geen paspoorten, maar ook geen ondersteuning voor de minima en misschien zelfs dat de BRP voor jouw gemeente niet meer functioneert.

Het BRP is hét bronsysteem voor persoonsgegevens van de overheid. Als er problemen in de BRP zijn, kun jij en de overheid geen zaken meer met elkaar doen. Dan wordt het pas lastig...

Niks weerhoudt ze ervan boetes op te leggen aan gemeentes. Ik vraag me alleen af of de prikkel hetzelfde is. Ondernemers zullen balen, ze zijn immers hun zuurverdiende centen kwijt. Bij de gemeentes is het allemaal overheidsgeld.

Hiernaast denk ik dat het AP de aandacht voornamelijk gaat richten op bedrijven. HetIBD en Binnenlandse Zaken gaat toch wel de gemeenten dwingen om hun zaakjes op orde te brengen, voor de zoveelste keer.

Volgens mij kun je de betreffende gemeentes beter verplichten om te stoppen met hun website. Om te zorgen dat burgers hier geen hinder van hebben dient het gemeente huis dan ook s'avonds en in het weekend open te zijn voor de burgers. Alle handelingen die je dan normaal online zou doen, doe je dan persoonlijk.

Normaal kan het ambtenaren namelijk niet heel veel boeien, totdat ze persoonlijk vrijdag middag, s'avonds en in het weekend moeten werken

Voor gemeentes gewoon een aparte "boete" in die trant zou wel mooi zijn. Website onveilig? Zorg maar dat je gemeentehuis 24/7 bereikbaar is tot het gefixed is!

Niks weerhoudt ze ervan boetes op te leggen aan gemeentes. Ik vraag me alleen af of de prikkel hetzelfde is. Ondernemers zullen balen, ze zijn immers hun zuurverdiende centen kwijt. Bij de gemeentes is het allemaal overheidsgeld.

Ach, dat kun je zeggen over alles wat de overheid doet. Zo werkt het toch niet, de gemeente heeft geen grote kelder voor geld waar ze naar wil uit kunnen scheppen. Iedere afdeling binnen een gemeente heeft z'n eigen budget. Als er een boete betaalt moet worden dan ben je je budget kwijt en zal je moeten bezuinigen op andere zaken. Politici moeten dan weer aan hun kiezers uitleggen waarom het geld op is en dat is niet goed voor hun positie. Ok, de werkelijkheid is natuurlijk wat weerbarstiger maar dat geldt op alle gebieden. Een overheid die zelf de regels niet hoeft te volgen hoort niet bij een rechstaat.

Maar dan moet je eens zoeken op het 'pikmeerarrest'. Het is maar beperkt zo, dat de overheid aansprakelijk is voor haar handelen.

Sinds 1 januari zijn ze inderdaad verplicht, want als er een lek word geconstateerd en blijkt dat er persoonlijke gegevens van mensen op straat zijn gekomen die te koppelen zijn aan echte personen - dan staat ze een boete van geen kleine hoeveelheid te wachten.

beetje jammer dat dat geld dan door gemeentes (en dus belastingbetalers) wordt betaald en niet van het loon van betrokken partijen ... beheerders en verantwoordelijke bestuurders wordt afgetrokken, ik pleit al jaren voor een bestaansminimum voor onverantwoordelijk bestuur, kortom ben je minister bouw je betuwelijnen voor 10x teveel, dan wordt je tot 70% van het minimum loon gekort .. mag je dus werken voor nagenoeg noppes.

Door werknemers, bedrijfsleiding of politici aansprakelijk te stellen, behalve da bij grove, moedwillige fout, valt de economie en innovatie stil. Niemand wil/kan het risico dragen, behalve dan tegen een onrealistisch loon.

Onzin, als je kunt aantonen door middel van een audit trail dat jij gewoon goed je werk gedaan hebt en tijdig defecten aangekaart hebt, maar ondanks jouw signalering een probleem ontstaan is heb je niks te vrezen. Je kunt niet aansprakelijk gehouden worden voor zaken die buiten je macht liggen of die je gewoon goed aangepakt hebt en dat kunt bewijzen.

Klopt, meer nog je hoeft het zelfs niet noodzakelijk (helemaal) goed aanpakken, een goede intentie is meestal zelfs voldoende. Gelukkig maar!
In de situatie die i-chat schetst is dat anders, ik wou het gevaar daarvan toelichten.

Die boete is "slechts" €810.000 voor het lekken van data IIRC.

of 10% van je wereldwijde omzet. Dat zijn overigens wel de harde maximum.

In de trend van onrealistische bedragen. Brussel maakt het nog iets gekker met boetes tot 100.000.000 (100 miljoen).

Microsoft boete aan EU:

nieuws: Neelie Kroes gaat ook uit van extra boete voor Microsoft

meer dan die 100 miljoen euro.

Volledig begrijpelijk. Ik vind het onverantwoordelijk als je met gegevens van derden je server vult die SSLv2 nog ondersteunt alleen maar omdat je of te lui bent om je server aan te passen (of dat nu hardware of softwarematig is) of bang bent dat anders applicaties omvallen. Je bent niet voor niets beheerder en dan dien je je werk juist goed te doen.

Ja precies! SSLv2 en SSLv3 stammen uit 1995 en 1996, bedacht door Netscape. Daar heeft IETF op voort geborduurd en is in 1999 TLSv1 onstaan. Wat hebben die beheerders in de afgelopen 17 jaar gedaan? Netscape 3 hoeft echt niet meer ondersteund te worden!

Zelfde verhaal trouwens met SSH ... versie 1 is nooit volledig uitgerold en zou eigenlijk verboden moeten worden!

[Reactie gewijzigd door slaapkopje op 4 maart 2016 18:01]

De standaard library van Java 6 ondersteunt TLS niet (volledig). Onze klanten werden GEK toen we pas onze servers tegen Logjam beveiligden (door 2048 bit DH parameters te genereren): Java 6 snapt dat niet - dus hebben we maar 1024-bit parameters gemaakt, en ze verteld dat ze echt eens over een upgrade-plan moeten nadenken.

Zelfde met SNI (meerdere certificaten per IP adres, basically). En TLS 1.2(-only). En moderne cipher-suites die forward secrecy ondersteunen.

Is het niet gewoon een kwestie van de unlimited-strength crypto support installeren ?

De standaard library van Java 6 ondersteunt TLS niet (volledig). Onze klanten werden GEK toen we pas onze servers tegen Logjam beveiligden (door 2048 bit DH parameters te genereren): Java 6 snapt dat niet - dus hebben we maar 1024-bit parameters gemaakt, en ze verteld dat ze echt eens over een upgrade-plan moeten nadenken.

Dat klinkt bekend, daar heb ik ook een hoop gedoe mee gehad en het is nog steeds niet helemaal uitgebannen. Als je de leveranciers hoort dan zou je denken dat we de enige zijn die de afgelopen 10 jaar nog iets nieuws heeft gekocht.

Het voelt heel vaak als het verhaal van de blinde en de dove. Iedereen volgt elkaar maar zonder te snappen waarom of waar naar toe. In veel gevallen zijn zowel leverancier als klant zo incompetent dat ze geen idee hebben wat ze nu eigenlijk doen. Als het eenmaal werkt zijn ze zo blij dat ze nooit meer iets durven te veranderen.

"Volgens deze wet hebben organisaties die persoonsgegevens verwerken namelijk een verplichting om deze te beveiligen"
-
Het zal aan mij liggen.
Maar ik winkel toch echt af en toe op websites zonder SSL (of iets gelijkwaardigs): de url begint namelijk met http://
En dan hebben we het over het bestelproces, niet over het winkelmandje vullen.
En dat lijkt me toch echt zonder encryptie.
Maar goed, als je geen encryptie hebt, kan er ook niks mis mee zijn.
Alleen voldoe je dan toch niet aan de wet, lijkt me.
Maar ach wat zou het, ik vul geen bankrekeningnummer en telefoonnummer in, en ik woon niet op een geheim adres, dus veel plezier met mijn naam, adres enzovoort, inclusief het winkelmandje.
De banken wilden het toch al verpatsen. En wie tapt mijn inkoop nu af?
Maar het hoort niet zo, zonder encryptie bestellen. Vreemd dat dit niet wordt gesignaleerd.

Als je wilt kun je ze daarvoor dus rapporteren.

Grappig dit. Op andere plekken waar het ook om je gegevens gaat, wordt simpelweg niet eens van vpn gebruik gemaakt, poorten worden gewoon opengezet. Het gaat dan ook om adres gegevens, persoonlijke gegevens, bsn en verzekering gegevens.

Dat is (afhankelijk van de context) ook mogelijk in strijd met dezelfde wet om dezelfde redenen.

Je bent gewon verplicht om "passende maatregelen" te nemen als je andermans gegevens verwerkt. En een fatsoenlijk geconfigde webserver of een vpn voor thuiswerkers valt daar absoluut onder. Ik kan dit als hobbyist thuis met weinig/geen kosten dus elk bedrijf kan dit ook.

Ja 100% mee eens. Maar dit is wel de realiteit. Praat maar eens met leidinggevende. "We zijn geen bank" en "wat is veilig? We gebruiken toch een alternatieve poort voor RDP?". Dan sta je machteloos

Precies vandaar de boete. Bedrijven jagen winst na, en de boete gaat ten koste van de winst.