'Https ontbreekt bij 85 procent bedrijfswebsites die gevoelige data verwerken'

Uit onderzoek van SIDN en MKB Servicedesk blijkt dat 85,6 procent van de Nederlandse bedrijfswebsites die gevoelige gegevens verwerken geen gebruik maken van https. De organisaties hebben webshops uitgesloten van het onderzoek.

SIDN, de beheerder van het nl-domein, meldt dat er in totaal 780.000 zakelijke websites zijn onderzocht. Daarvan verwerkten 429.000 websites gevoelige gegevens, zoals wachtwoorden en betaalinformatie. Bij 367.000 sites worden deze gegevens niet via een beveiligde verbinding verzonden, aldus de organisaties. Bovendien maakt minder dan één procent van de websites gebruik van extended validation, waarmee de bedrijfsnaam in de adresbalk zichtbaar is.

De organisaties wijzen erop dat de Wbp een wettelijke plicht oplegt om persoonsgegevens van degelijke beveiliging te voorzien. Doen bedrijven dat niet, dan kunnen ze een boete krijgen tot 4500 euro. Door geen beveiligde verbinding toe te passen bij gevoelige gegevens is het mogelijk dat deze worden onderschept. Daarnaast stelt een geldig certificaat de gebruiker in staat om de identiteit van de website te controleren. Nederlandse webshops, waarvan er meer dan 80.000 zijn, gebruiken wel allemaal een beveiligde verbinding op hun betaalpagina, maar ook hier is het gebruik van extended validation beperkt tot 3,3 procent.

Google voerde in 2014 een maatregel in, waardoor sites zonder https lager in de zoekresultaten verschijnen. SIDN schrijft dat zakelijke websites daarom mogelijk inkomsten mislopen doordat zij hun beveiliging niet op orde hebben. Daarnaast waarschuwen verschillende browsers als gebruikers zich op een onbeveiligde inlogpagina bevinden. Het aantal beveiligde zakelijke websites is lager dan het aantal overheidswebsites dat is voorzien van https. Uit een onderzoek bleek dat ongeveer de helft van de websites is beveiligd. Minister Plasterk van Binnenlandse Zaken zei onlangs dat in de toekomst alle overheidssites van https voorzien worden, ongeacht of zij gevoelige gegevens verwerken.

Reacties (108)

Naar mijn mening is dit probleem voornamelijk omdat Harrie die op de hoek spijkers verkoopt geen idee heeft wat HTTP is, laat staan HTTPS. Hij heeft een website met een contact formulier (wat al gevoelige informatie is) om "modern" te zijn.

Ik vind dat dit een heel moeilijk probleem om op te lossen. Hoe ga je iets oplossen waarvan het merendeel geen weet heeft. Ik denk dat hier een mooie taak ligt voor de KvK die naar ALLE leden een brief zou kunnen sturen met informatie over de problemen van geen https gebruiken en wat mensen kunnen verwachten in de toekomt qua boetes. (dus niet gericht naar eigenaren van websites waar dit probleem is). Gooi er een service desk bij waar ze naartoe kunnen bellen en je hebt een leuk projectje voor een aantal jaar waar (naar mijn mening) belastinggeld goed gebruikt wordt.

Als Harrie er geen verstand van heeft, moet ie zijn site laten onderhouden door een echte website-bouwer en niet het "neefje van".
Die bouwer zal hem dan waarschuwen dat een certificaat nodig is.

Ik snap die houding echt niet. Iemand die geen verstand van auto's heeft gaat toch ook naar de garage voor onderhoud ipv zelf te prutsen?

[Reactie gewijzigd door hackerhater op 25 januari 2017 11:41]

Mijn ervaring is echter dat veel website bouwers wel weten hoe ze wat WordPress thema's e.d. kunnen maken maar verder niks weten van certificaten en https.

Sowieso is https niet zo eenvoudig als even 1 schakelaar omzetten, de standaard Apache instellingen zijn namelijk helemaal niet veilig, bijvoorbeeld. Als je het goed wil doen moet je even een filtertje toevoegen met toegestane protocollen. Verder is het ook belangrijk om dingen als openssl up to date te houden. Bij verschillende certificaat boeren worden de certificaten trouwens ook nog op verkeerde volgorde geleverd (in een bestand) waardoor browsers weer kunnen gaan klagen of langzaam verbinding maken.
En als je het dan echt goed wilt doen kijk je ook nog naar Strict Transport Security (HSTS), HSTS preloading en Public Key Pinning (HPKP).

Dus onze Harrie kan wel een mooie website geleverd krijgen van een website bouwer en dan denken dat alles wel snor zit, maar ondertussen hoeft het helemaal niet snor te zitten. Wat mij betreft mag er wel een keurmerk komen voor website bouwers die ook van security afweten en die ook juist toepassen.

[Reactie gewijzigd door wootah op 25 januari 2017 12:52]

Goed idee dat keurmerk. Kan ik het direct op mijn site zetten
De nieuwe versie van mijn framework gaat al tijdens installeren proben naar https en er een melding over geven.

Eerder omdat harrie's wordpress website meer bots dan bezoekers ontvangt en het verkopen van een extended ssl + marge een beetje onzinnig is. Daar moet harrie aardig wat spijkers voor verkopen. Voor dit soort spul is juist 'lets encrypt' een mooie oplossing omdat de load niet overeenkomt met de gemiddelde vraagprijs voor certificaten. De verantwoordelijkheid voor een veilige hostomgeving en de juiste (gebruiksvriendelijke) implementatie van ssl ligt natuurlijk bij de hostingpartij. Een site die dan geen https links gebruikt of geen input sanitized kan je de bouwer wel kwalijk nemen.

Daarbij doen de meeste webbouwers zelf niets met hosting en zijn dus afhankelijk van die derde partij. Onze hostingpartij heeft onlangs besloten zelf een controlpanel te schrijven. Dat betekend dat ze zelf Lets Encrypt moeten implementeren. Eerst werd gezegd: dat kan niet, dan moeten we alles handmatig verlengen.. Na zes artikelen gestuurd te hebben zien ze eindelijk dat het kan. Maarja, wat is de planning? Het gaat nog maanden duren. Sterker nog, die nieuwe omgeving faalt waardoor ze nog veel meer tijd kwijt zijn.

Nu kan ik twee dingen doen: iedere klant ssl aanbieden van een bekende partij tegen een bepaalde prijs (is ook gedaan). Of weggaan en een andere partij kiezen die wel Lets Encrypt ondersteunt. Klanten hebben veelal geen idee wat het precies is, en wanneer zij extra moeten betalen is dat lastig uit te leggen. Veiligheid heeft een prijs, maar niet iedereen wordt blij van extra kosten. Zelfs als het verplicht is.

Weggaan bij de hostingpartij kost echter ook heel veel tijd en geld. Daarnaast verliezen we vrijheid op andere gebieden.

Het lijkt allemaal zo makkelijk: gewoon Lets Encrypt gebruiken! Maar zoals je zegt is dat niet altijd het geval.

Overigens draaien de grote projecten op EV en enkele andere op standaard SSL certificaten. Maar de site van mijn moeder waar zij kattenfilmpjes op zet heeft dat natuurlijk niet (geen geintje). Echter ontkom je er niet aan om toch https te gebruiken, al is het alleen maar om de melding.

[Reactie gewijzigd door Zenomyscus op 25 januari 2017 16:12]

No offense, maar heeft jouw hostingpartij onder een steen gelegen? Eind 2014 was er al een public beta van Let's Encrypt, afgelopen jaar zijn er miljoenen certificaten uitgegeven. Als je begint een eigen controlpanel te ontwikkelen bouw je zoiets toch in?

Ik snap dat SSL niet altijd 1-2-3-klik is, maar dit jaar zal toch echt iedereen naar HTTPS moeten, al is het maar vanwege browsermeldingen en Google. Het kost misschien tijd en geld, maar op de lange termijn is het echt beter voor de veiligheid op het net.

De keuze voor welke webserver hangt van meer zaken af dan alleen efficiëntie. Als de klant bijvoorbeeld WordPress wil draaien, die veel gebruik maakt van .htaccess bestanden, integreert dat veel en veel makkelijker met Apache dan met lighttpd of nginx. Bovendien heb je bij die servers exact het zelfde probleem, de out of de box configuratie is niet genoeg voor veilige https!

Outof the box "Juiste SSL" configuratie is dan ook een moving target.
De te gebruiken encrypties en protocollen moeten zo wie zo ingesteld worden.
maar de defaults in nginx zijn een stuk beter dan elders.

en over .htaccess: tja... dat is een van de redenen waarom apache niet zo efficient is... https://wiki.nginx.org/re...ples/likeapache-htaccess/

Wij van WCeend adviseren WCeend

Dan de andere WC-Eend: https://codex.wordpress.org/Nginx
In het midden van het artikel ook iets over SSL aanzetten.

Het zijn gewoon meetbare statistieken, YYMV...
Maar ze komen wel overeen met mijn ervaringen met Apache, Lighttpd en NginX. Ik heb daarom Apache al enige tijd niet meer actief.

Ik moet zeggen dat ik hier niet heel gespecialiseerd in ben, maar er zijn nogal wat andere factoren die een keuze voor Apache of Nginx rechtvaardigen. Per geval zal de ene of de andere configuratie beter functioneren.

Enig idee wat dat mag kosten? ICT bedrijven staan nu al te springen om top uurtarieven hier voor te gaan gebruiken, immers het is verplicht. Harrie met z'n kleine bedrijf die 'marktmatig' wel mee moet op internet, mag hier meteen de hoofdprijs voor betalen, omdat het moet.

Nog altijd stukken minder dan een flinke boete omdat je persoonsgegevens hebt gelekt.
Ik reken zelf altijd 50/uur exclusief BTW, daarentegen ben ik verzekerd voor gedoe en geef ik garantie.
Dat doet "het neefje van" niet.

Als harry eerder naar zn managed hosting partner had geluisterd had hij allang een degelijk certificaat gehad. Enkel een issue voor dubbelknijperds

Maar als de site van Harrie gebouwd is door een prof, en hij is af, er is afgerekend en mensen kunnen Harrie vinden en wat hij verkoopt dan is het toch klaar?

Waarom zou Harrie dan nog omkijken naar zijn site?

In auto-taal, als jij je auto koopt en APK was niet verplicht zou je dan ook jaarlijks naar de garage gaan?

Gezien ik 25K per jaar rij : ja.
De APK is maar een moment-opname, de auto moet het gewoon blijven doen en dat vereist onderhoud.
Ik kom er liever op tijd achter dat bijvoorbeeld de remmen aan vervanging toe zijn dan ze een keer weigeren als ik ze nodig heb.

Alles heeft onderhoud nodig, software is geen uitzondering al schijnen veel mensen dat te denken.

Ik weet dat software onderhoud nodig heeft, jij weet dat software onderhoud nodig heeft, Harrie is een simpele man die niets meer weet dan dat die z'n computer aanzet en dat er mail binnen komt.

Harrie heeft niet gestudeerd hiervoor, en dan kun je ook niet verwachten dat zijn website, waar mensen over het algemeen zijn adres vinden, gemaakt is door een top bedrijf die alle beveiligingen heeft geïmplementeerd. Dat dit eigenlijk wel zo zou moeten zijn is een heel ander verhaal. Op dit moment kan dit alleen niet verwacht worden, met de snelheid dat het internet gegroeid is.

PS: Mag ik je er op attenderen dat jouw website op je profiel geen HTTPS heeft?

[Reactie gewijzigd door Lagonas op 25 januari 2017 12:17]

PS: Mag ik je er op attenderen dat jouw website op je profiel geen HTTPS heeft?

De contactpagina komt zelf bij een 404 uit.

Als we toch aan het bashen zijn, niet up-to-date versie van Joomla en site is bereikbaar via www en non-www. Kleine aanpassingkjes, zo geregeld.

[Reactie gewijzigd door MrMarcie op 25 januari 2017 17:58]

offtopic:
Ook leuk:

[quote]kwaliteit staat bij ons hoog in het vandaal[/quote]

Een 404 wat eigenlijk een 500 in vermomming is.

Ik weet dat software onderhoud nodig heeft, jij weet dat software onderhoud nodig heeft, Harrie is een simpele man die niets meer weet dan dat die z'n computer aanzet en dat er mail binnen komt.

Harry is een ondernemer. Ondernemen is risico's nemen. Als Harry geen risicoanalyse wilt doen en dit niet wilt uitbesteden, dan draagt hij zelf de gevolgen.

Als -voorbeeldje- Strato adverteert voor weinig eigen siteje opzetten bijvoorbeeld en zo zijn er meer dan heeft Harrie geen zin om meer te betalen voor SSL, hosting e.d. omdat ie denkt dat het dan duur is.

Maar misschien moet je Harrie ook niet als klant willen

Linkje wees alleen niet auto door
Site is gewoon via https bereikbaar.

Plus Kudos voor het direct oplossen van dat probleem.

Zo zou het ook moeten zijn, en je houdt in de gaten wat je belangrijk vindt.
Maar het gaat je niet lukken om overal van op de hoogte te blijven en wat belangrijk is om bij te houden.
Je houdt je software en auto goed in de gaten, maar misschien niet je verzekeringen, of je wasmachine, je CV, of het schilderwerk van je huis.

Harrie houdt zijn site misschien niet in de gaten, maar laat wel ieder jaar zijn schoorsteen vegen (ik noem maar iets hè) daar het bij een IT'er andersom zal zijn.
Dat is wat hackerhater probeert te vertellen denk ik.

100% weet je dat niet, maar de kans is stukken groter dat een garage, laat staan een garage met keurmerken, het correct doet dan een beunhaas die het zwart doet.

Zolang z'n site gewoon werkt zal Harrie het waarschijnlijk aan z'n reet roesten wie de website beheert. Het "neefje van" is een stuk goedkoper dan een professionele bouwer, en ja het werkt toch? Dus waarom zou Harrie verder moeten kijken?

Maar dan moet Harrie ook niet zeuren als er een envelop met verplichting op de mat valt.

Zodra er gezeik van komt zal dat wel veranderen.
Ik neem aan dat Harry toch gewoon de monteur belt als er iets aan z'n gasleiding gedaan moet worden, en z'n auto z'n APK heeft van een erkende garage. Het kan Harry zelf niet interesseren, maar de gevolgen als je gepakt wordt zijn gewoon te groot.

Daarom tijd dat er wat druk op komt te staan.

Waar Harrie geen weet van heeft kan Harrie ook niet aan zien komen. Natuurlijk ben ik ook pro-https, maar ik vind dat je het Jan met de pet moeilijk kwalijk kunt nemen.

Ik geef je aan de ene kant gelijk. Echter weet Harrie niets van websites, en in zijn beleving is zijn neefje die dit gebouwd heeft de technische superman. Hoe kan hij dan weten wat die iets verkeerd doet? Hij heeft zijn neefje ingehuurd omdat deze wel dingen weet van websites en daardoor deze website gebouwd heeft. Dat zijn neefje echter veel minder weet dan dat Harrie denkt is een heel ander verhaal.

[Reactie gewijzigd door Lagonas op 25 januari 2017 11:54]

Dat is voor Harry met spijkers niet te betalen. Het maken van een website is van redelijk eenvoudig naar ingewikkeld gegaan: je moet met veel dingen rekening houden die je niet zo maar kan overzien.

Iemand die geen verstand van auto's heeft gaat toch ook naar de garage voor onderhoud ipv zelf te prutsen?

Nee, maar hij gaat er wel vanuit dat de fabrikant / garage goed werk heeft afgeleverd. En hij kan ook weinig anders, want hij heeft er geen verstand van, dus hij kan het ook niet controleren.

Als Harrie er geen verstand van heeft, moet ie zijn site laten onderhouden door een echte website-bouwer en niet het "neefje van".

Maar hoe moet Harrie nou beoordelen of die echte websitebouwer wel weet waar 'ie mee bezig is? En dat het 'neefje van' dat niet weet? Als de een zegt 'voor een webshop heb je een certificaat nodig, dat kost je een x-bedrag', en de ander zegt 'welnee, dat is helemaal niet nodig, het kan best zonder en dat is veel goedkoper', wat moet Harrie dan doen, nog afgezien van het feit dat hij bij 'certificaat' waarschijnlijk denkt aan 'diploma'?

Voor veel mensen is IT hogere magie, die kunnen daar echt niks mee. Ik kan ook niet controleren of de automonteur zijn werk goed gedaan heeft, want daar heb ik geen verstand van. Je mag natuurlijk verwachten dat Harrie even wat verder kijkt dan zijn neus lang is, maar er zijn zo veel malafide en onkundige websitebouwers op de markt die een mooi en overtuigend verhaal kunnen houden dat het niet verwonderlijk is dat mensen daarmee in zee gaan. Het is per slot van rekening niet voor niets dat die mensen expertise inkopen, dat doen ze vaak omdat ze er zelf geen verstand van hebben.

Ik vind eerlijk gezegd ook dat je niet kunt verwachten dat iedereen alles weet van de produkten en diensten waar hij gebruik van maakt. Daarom is er ook regulering, bijvoorbeeld op het gebied van gezondheidszorg of financiële dienstverlening. Die diensten zijn zo complex dat mensen vaak gewoon niet zelf de kwaliteit kunnen beoordelen, dat moet door onafhankelijke experts gebeuren, dat zou dan dus ook bij internet-diensten moeten gebeuren als we de veiligheid daarvan met z'n allen belangrijk vinden.

Als ze opgelicht worden door prutsers die wel netjes een bedrijf hebben e.d., daar heb ik nog wel begrip voor.
Die prutsers moeten hard aangepakt worden, maar deze situatie is niet verwijtbaar voor de website eigenaar.

Maar als ze het door het neefje (zonder KVK, zonder opleiding, etc) laten doen omdat een echte bouwer te duur is. Dan mogen ze op de blaren zitten.

Maar eens dat er rustig keurmerken e.d. mogen komen voor software bouwers.

Het is toch ook kolder om voor het contactformulier van Harrie https te eisen? 99 van de honderd keer is zo'n formulier een frontje om een mail te versturen. Juist... over het super goed beveiligde smtp-protocol.

Eigenlijk zou er een oplossing moeten komen om een versleutelde verbinding mogelijk te maken zonder gehannes met certificaten op de server. Als het met WhatsApp mogelijk is, waarom dan niet met een web browser en -server? Dan hou je alleen "gedoe" (ik vind het met letsencrypt/certbot nog wel meevallen, eerlijk gezegd) voor de gevallen waar je niet alleen encryptie wil, maar ook een bevestigde identiteit (EV-certificaten).

Je hebt ongelijk. IEDERE website moet HTTPS gaan bieden. Ik knip en plak een eerdere reactie:

Je argument wordt veel gegeven, maar is niet waar en achterhaald. Ook op die read-only restaurant website dient TLS gebruikt te worden.

Zonder TLS is niet te vertrouwen dat wat er terugkomt van de server niet beinvloed is. Een IPS (of bijvoorbeeld een hotel) kan zomaar scriptjes includen in de pagina als middle man attack. Indien er echt kwaad in de zin zou zijn dmv een hacker, kan die je makkelijk naar een exploit website leiden, zelfs geheel onzichtbaar. En dan ben je dus onderdeel van een botnet.

Dit is geen fictie. Het is de nieuwe werkelijkheid van cyber security heden ten dage. HTTPS is een MINIMUM eis voor IEDERE website, de nieuwe norm.

Volgens mij is de praktijk zo dat voor veel bedrijven €4500 boete het risico waard is: geen controle en de implementatie is veel duurder door dure IT bedrijven.

Zelf heb ik een off-site backup oplossing willen aanbieden bij zorgverleners (tandartsen etc.) in het buitenland. In bijv. Oostenrijk zijn ze verplicht om off-site backups te hebben van hun data. Dit moet omdat ze 10 jaar lang moeten kunnen aantonen bij verzekeraars dat er daadwerkelijk zorg is verleend.

Bij iedere arts was het antwoord: "Ze klagen me maar aan, is nog altijd goedkoper dan de implementatie". Zelfs de vereniging van tandartsen weigerde hun leden te adviseren toch voor een backup te zorgen want: "Ze hebben al genoeg aan hun hoofd en de boete is een lachertje".

Dus ik denk dat het niet pijn genoeg doet voor bedrijven en instellingen wanneer er data lekt. Niet ik dat ik wil dat bedrijven lijden, maar wanneer de overheid dit serieus neemt moeten ze het wel afdwingen en niet met dit soort nano-boetes komen en misschien eens gaan controleren.

Ik denk dat beperkte handhaving een nog veel groter probleem is dan de boete. Als deze bedrijven allemaal morgen een boete van 4500E op de mat hebben liggen, met daarbij de mededeling dat een nieuwe boete volgt als het probleem niet binnen X tijd is opgelost (ik neem aan dat een nieuwe boete opgelegd kan worden als de oplossing uitblijft), dan zal er echt wel actie komen.

De handhaving laat gewoon te wensen over. Ik had een tijdje terug ook een reisbureau die mij vroeg per mail even een 'kopietje paspoort' te sturen. Toen ik haar vertelde dat ze daar niet eens om mag vragen en dat daar een bestuurlijke boete op staat, was haar reactie 'oh, dat wist ik niet. Ja, we doen dat altijd zo...'. Probleem is ook dat mensen er zélf te weinig een probleem van maken, ik was dus de eerste van haar klanten die dit aankaartte - vreemd, maar veelzeggend. Als we het écht willen aanpakken zal het niet van de oplettende klant, maar vanuit structurele handhaving door de overheid moeten komen...

Ik heb gehad dat ze vroegen om paspoort en mijn cc gegevens in een enkele email bij een of ander reisbureau

Ik was toen ook de eerste die daar "moeilijk" overdeed. Heel apart!

Ik denk dat de controle dagelijks kan worden gedaan en de gebeurtenis per dag beboet kan worden.
Als je 10 langs een flitser rijdt met te hoge snelheid krijg je immers ook 10 maal een boete.
Voor de ECHT onwilligen kan het interval steeds gehalveerd worden.

Aanvulling:
Boetes kunnen ook voorwaardelijk worden opgelegd...
Als over xx dagen de beveiliging niet adequaat geregeld is dan wordt een boete opgelegd van EUR 4500,-... Vervolgens wordt deze controle maandelijks uitgevoerd.

[Reactie gewijzigd door tweaknico op 25 januari 2017 13:58]

Dat is hetzelfde met verkeersboetes voor mensen die bijv. 5k+ per maand verdienen. Laat de boete afhankelijk zijn van je inkomen dan zullen ze wel hun best doen.
Toen ik met 1600 euro per maand nog thuis woonde was 150 euro voor per ongeluk te hard rijden ook een lachertje.

Bovenstaande is blijkbaar niet duidelijk genoeg als metafoor voor dit artikel?
4500 euro is voor veel webshops peanuts terwijl het voor de kleinere ondernemer de kop kan kosten.

[Reactie gewijzigd door Anoniem: 705078 op 26 januari 2017 08:35]

Waarom moet iemand met een hoger salaris harder gestraft worden terwijl ze precies hetzelfde strafbare feit plegen?

Dit lijkt me echt een heel slecht plan. Hard werken wordt dan (nog) onaantrekkelijk(er) gemaakt.

Je hebt gelijkheid, en gelijkheid

http://interactioninstitu...1/IISC_EqualityEquity.png

Tuurlijk als de boete 100 euro is, is dat voor iedereen gelijk, maar een bijstandsmoeder die 100 euro moet missen is 3 maanden bezig die weer terug te sprokkelen. Voor iemand die 5000 euro per maand verdiend stelt het nauwelijks iets voor.

Ik geloof dat er meer landen zijn waar een boete gerelateerd is aan het jaar inkomen. In ieder geval Zwitserland, en zo raar is dat eigenlijk niet.

[Reactie gewijzigd door tweaknico op 25 januari 2017 13:40]

Maar GOED (hard) werken met respect voor data van / over anderen wordt dan niet bestraft... en blijft gratis of relatief laag beprijsd.
En goodwill kweken mag best wat waard zijn toch?
Mogelijk de schandpaal weer invoeren, dan sta je gewoon een dag stil, dat is een gelijkwaardige straf ongeacht het inkomen. gewoon een of twee dagen verlies... (+ strafblad)

Niet harder gestraft, procentueel gezien gelijk gestraft. Of ik het er mee eens ben is iets anders.

Daarnaast staat hard werken niet gelijk aan een hoger salaris.

Doen bedrijven die niet, dan kunnen zij een boete krijgen tot 4500 euro.

De maximumboete is 4500€. Dus het kan ook minder zijn. Een van de factoren is misschien de omzet van de webwinkel?

4500 euro voor bol.com is niks..

SSL duur?
wat is dat voor onzin... ik run zelf een webshop met SSL en kost me 20 euro per jaar voor het certificaat. En veel webshop systemen zijn erop voorbereid dus het niet hebben is eigenlijk al stom.

De extended validation daar in tegen vind ik wel zwaar overtrokken en veel grote webshops hebben dat nog niet eens. Zelfs conrad en bol.com doen dat niet.

Het is veelal ontwetendheid en onkunde. En een boete van 4500 euro voor een kleine ondernemer doet echt wel even goed zeer hoor. Wij draaien geen miljoenen omzet zoals bol.com etc.

Overigens zouden boetes wel degelijk naar ratio moeten gaan mijn inziens. Een boete is een afschrikmiddel. Iemand die 5000 netto per maand verdient ligt niet wakker van 200 euro boete. Iemand in de bijstand zit gelijk maanden op droog brood.

De implementatie is het dure aspect, gros is in zee gegaan met een random website builder, levert een CMS voor paar duizend euro op, maar kom je nu dat er er een ssl op wil hebben, rekenen ze natuurlijk ook meteen de hoofdprijs.

99% is prima te doen met settings in het admin paneel en ftp toegang. Het probleem zit meer in de groep die wel webshop willen spelen maar zich er niet in willen verdiepen. En dit is niet alleen op ssl gebied maar ook op andere aspecten.

Sterker nog: Let's Encrypt is gratis. Nadeel is wel dat de certificaten maximaal 90 dagen geldig zijn, en je ze dus vrij regelmatig moet vernieuwen. Een ander nadeel is dat het geen EV ondersteunt. En het ondersteund géén wildcards voor subdomeinen. Al met al lijkt Let's Encrypt de beste oplossing als gratis alternatief.

Bij Let's Encrypt is verlengen volledig te automatiseren, als je dat goed doet is het zelfs minder werk dan bij normale certificaten.

Bol en Conrad doen wel degelijk EV..

I stand corrected...
Alleen chrome geeft het niet meer weer
Die zegt alleen nog veilig of niet veilig.
Dus niet de gehele bedrijfsnaam voor de url.

Firefox laat het wel keurig zien.

Chrome laat ook gewoon de bedrijfsnaam zien bij een EV certificaat

Hier anders niet.. zal wel weer een onder water bugje zijn dan

Ik schrik opzich niet van dit bericht. Ik zit in de webdev richting en zie toch ook vaak dat mensen bij hun site liever geen Comodo certificaat van +/- 40 euro willen kopen. Al snel vinden ze dit te duur, kunnen het vaak moeilijk plaatsen in hun hoofd, je moet echt met voorbeelden werken en een MITM attack uitleggen. Vervolgens zal de klant zeggen: "Oh, onze data is nou ook weer niet zó speciaal, dus dan moet dat een vreemde hacker zijn die achter ons aanzit" .

. Een tijdje gratis aanbieden werkt ook niet, want binnen no-time kom je erachter dat de website in kwestie ook nog 10 subsites heeft, of die ook allemaal kunnen forwarden, maar dan wel met hun eigen content. Multi-domain dus.

Dan ga je al de richting in van de gratis certificaten van LetsEncrypt, dit werkt (nog) niet lekker genoeg in onze productieomgeving om volledig uit te kunnen rollen, erg jammer, anders kunnen we het gratis aanbieden (het certificaat, niet de dienstverlening).

Ook een ding; er is bij ons eigenlijk áltijd setup tijd bij gemoeid. Vaak zie je namelijk dat veel sites met een WYSIWYG systeem ook afbeeldingen bevatten die handmatig erin zijn gezet en met een harde link staan gelinkt door een redactie of eigenaar; dus HTTP / HTTPS door elkaar, ondanks dat we altijd zorgen voor statische uploadvelden (Drupal), zie je gewoon dat mensen hier mee door blijven gaan. Hier moeten we dus bijna een harde find/replace voor doen.

Ben blij dat het eraan komt, maar huiverig voor reacties van klanten .

Ik vraag me dan af wat jouw problemen met LetsEncrypt zijn? Wij hebben zelf DirectAdmin waar je een module voor kan installeren voor LetsEncrypt en dat werkt prachtig! Ik klik het aan, LE doet zelf alles wat nodig is voor de certificaten en enkele momenten later is het gewoon helemaal klaar. *

We hebben ook de renewal met een crontab ingesteld op elke 2.5 maand (dus in geval van problemen heb je nog 2 weken om het te fixen) welke we voor diverse domeinen al gepasseerd zijn; Ook het renewen van het certificaat gaat zonder enig moeite.

Het gaat zo makkelijk dat we ondertussen de sites standaard opleveren als https, met nagenoeg hetzelfde gemak als de http versie. En het kleine beetje verschil dat het meer kost, vinden wij vallen onder "wij zijn de experts op dit gebied, wij mogen best een beetje moeite steken in de onbekenden te beschermen".

*Om het dan wel te relativeren, de meeste klanten posten hun eigen content naar een eigen systeem, niet van derden. Maar als https de norm wordt, lost het externe http resources probleem zichzelf op. Je moet ergens beginnen.

[Reactie gewijzigd door Martijn.C.V op 25 januari 2017 13:05]

Ik wil niet dit hele nieuwsbericht hijacken door de problemen die wij hebben, maar ik zou de tickets erop na moeten slaan. Zo even uit mijn hoofd hebben we problemen met überhaubt ophalen van een license. Dit probleem is aangegeven bij LetsEncrypt en staat als het goed is op hun bugtracker. Voorbeeldje van een run die ik zojuist deed:

Generating 4096 bit RSA key for let's encrypt account...
openssl genrsa 4096 > "/usr/local/directadmin/data/users/******/letsencrypt.key"
Generating RSA private key, 4096 bit long modulus
.............................................................++
.....................................++
e is 65537 (0x10001)
Account registration error. Response: HTTP/1.1 100 Continue
Expires: Wed, 25 Jan 2017 11:49:34 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

[Reactie gewijzigd door Kecin op 25 januari 2017 12:51]

Direct admin probleempje, niet letsencrypt?

https://forum.directadmin.com/showthread.php?t=53567

Same here, werkt prachtig.
Bij mij is de crontab @daily, letsencrypt raad 2x per dag aan.

Zou de consument tegenwoordig nog steeds niet checken of ze met een beveiligde verbinding werken wanneer men betalingsinformatie invult? Browsers ondersteunen het goed tegenwoordig en laten duidelijk zien waar men mee te maken heeft.

Het lijkt me dat deze sites op termijn dus geen bestaansrecht hebben? Of zou echt nog steeds iedereen klakkeloos alles invullen?

Zou de consument tegenwoordig nog steeds niet checken of ze met een beveiligde verbinding werken wanneer men betalingsinformatie invult? Browsers ondersteunen het goed tegenwoordig en laten duidelijk zien waar men mee te maken heeft.

Gezien het aantal geslaagde phishing mails zou ik zeggen van niet. Ik bedoel dus mails in de trand van "U heeft een saldo tekort. Click hier om dit zo snel mogelijk op te lossen"

Het is heel goed dat bedrijven https gebruiken, en dat de communicatie versleuteld wordt, maar als de site er net zo uitziet als gewoonlijk, kijkt met niet of het wel een versleutelde verbinding heeft, en of men wel verbinding heeft met de site die men voor ogen had.

Zoals onlangs ook al naar voren kwam, in theorie kan iemand een site polite.nl maken, en daar een certificaat voor krijgen (Doel van de site: vriendelijkheid).. Als dat lukt, krijg je gewoon een groen slotje.

niet politie.nl, maar politierijnmond.nl, politie-brabant.nl etc. en die honderden andere politie-xxx.nl domeinen die met de invoering van politie.nl bij het grof vuil geplaatst zijn.

Wat dat betreft heeft de overheid (of overheids functionaissen) nog steeds niet of bijster weinig bij geleerd sinds de PC's van officieren van Justitie PC's bij het huisvuil plaatsten.

Klopt, alleen gezien je reactie heb je ook automatisch het dichtsbij liggende woord gelezen.

Ik had het over: p o l i t e (.nl) Spel dit, als je nog steeds politie leest.

Die is overigens al geclaimed, maar goed, het ging om het principe: Het gebruik van veel gemaakte typefouten. In theorie kun je zo'n domein registreren, en er een website met ssl opzetten

edit:
Toegevoegd dat je op zo'n domein nog steeds https kunt hebben

[Reactie gewijzigd door kzin op 25 januari 2017 14:24]

Er is absoluut niets onveilig of onterecht aan het verkrijgen van een oud domein met TLS. De TLS en het groene slotje zijn volledig terecht. Het probleem bij de politie was dat mensen uit gewoonte nog steeds emailen naar die oude domeinen. Dat is meer een sociaal lek, geen technisch lek.

In het artikel staat dat het bij webshops wel allemaal geregeld is. In dit onderzoek gaat het dus niet om websites waar betaalinformatie wordt verstuurd, maar andere gevoelige informatie zoals persoonsgegevens. De meeste sites hebben namelijk wel een contactformulier o.i.d.

de betaal omgeving van webshops zijn in 99% van de gevallen goed geregeld want: ideal, paypal, etc etc is allemaal van de banken zelf die het gelukkig wel serieus nemen.

De registratie formulieren zijn bij veel kleine webshops gewoon http.
Dus zo goed is het daar ook allemaal niet geregeld.

Tja Firefox is als het goed is (Chrome enz. ook dacht ik) ermee begonnen om inlogformulieren op non-https websites een waarschuwing te laten tonen aan de gebruiker, misschien dat daarmee bewustzijn gekweekt wordt en inderdaad dat soort bedrijven wel moeten beveiligen.

Maar komen we met die enorme gehamer niet langzaam in een psuedo veiligheid?

Als de gedachte is, https is goed, https is veilig, simpel om een phisingsite van https te voorzien, mensen denken meteen dat het goed is, immers https.

Secondair, als ik nu kijk naar de gemelde datalekken, was dit nu allemaal te voorkomen door https te gebruiken? Nee, oude CMS, zwakke wachtwoorden, usb sticks, noem het maar op.

Nee maar je hebt het nu over andere aanvalsvectoren. SSL dicht slechts een deel van de mogelijke vectoren. De door jouw genoemden vallen ook gewoonweg niet in de scope.

Geen SSL maar wel andere beveiliging is alsof je je ramen allemaal van tralies voorziet tegen inbrekers maar vervolgens dus wel je sleutel onder de deurmat laat liggen. Iemand die erop uit is om in te breken observeert je een keer en kan zo binnenkomen.

Snap wel dat het onderdeel is van totaal pakket, maar het blijft een psuedo veiligheid. Zoals je zelf zegt, tralies met sleutel onder de mat gaat niet werken, maar in het nieuws wordt tralies wel als dé standaard voor een veilig huis gepromoot.

In mijn voorbeeld waren tralies echter als alles behalve SSL bedoeld.

Punt is inderdaad wel, als je zulke gaten open laat hebt is het allemaal pseudoveiligheid. SSL is geen silver bullet voor veiligheid. Het is wel een van de eerste stappen die je kan nemen door je sleutel niet meer onder de deurmat te laten liggen voor je tralies voor de ramen gaat hangen omdat je huis telkens wordt leeggeroofd.

Zoals zoveel dingen is beveiliging niet 1 laag/1 ding. Het is geen kwestie van Norton installeren en dan kan je niet gehackt worden.
Https beveiligt op 1 laag tegen een aantal zaken, voor de normale gebruiker beveiligt het tegen de eavesdropper in de McDonalds die het public wifi zit te scannen voor wachtwoorden enz. en voor de gevorderde gebruiker kan het ook bevestigen dat het certificaat klopt en je met de echte server verbonden bent en niet een MITM.
Gevoelige gegevens over https staat niet gelijk aan veiligheid, over http staat het echter wel gelijk aan een onveilige situatie. Die laag moet beveiligt worden tegen de risico's die op die laag spelen.
Zo gaat niemand Norton installeren om te beschermen tegen het per ongeluk verwijderen van data, daar is de backup weer voor enz. enz.

Maar komen we met die enorme gehamer niet langzaam in een psuedo veiligheid?

Als de gedachte is, https is goed, https is veilig, simpel om een phisingsite van https te voorzien, mensen denken meteen dat het goed is, immers https.

De meeste mensen denken daar niet over na, die bestellen gewoon, of het nu HTTPS is of niet. Veiligheid is niet absoluut en een site met HTTPS is in het algemeen veiliger dan een site zonder. Enige druk om te zorgen dat iedereen HTTPS gebruikt is dan wel welkom.
De vraag is welk effect het sterkste is; levert het meer op om overal HTTPS te gebruiken dan het kost of niet?

Van motorrijders weten we ook dat ze meer risico's nemen als ze een helm dragen. Toch zijn de voordelen van een helm zo groot dat het nog steeds de moeite waard is. Er komen iets meer ongelukken van, maar de gevolgen van die ongelukken zijn een stuk kleiner.

Dat denk ik ook. Door de enorme focus op SSL, wat relatief gemakkelijk en goedkoop is te implementeren zou bij de opdrachtgevers de indruk kunnen ontstaan dat ze daarmee veilig zijn. Terwijl de veiligheidsproblemen eigenlijk hoofdzakelijk ergens anders liggen.
Ik zeg niet dat we SSL overal niet moeten doen, maar het is zeker niet het belangrijkste en dat wat als eerste gedaan moet worden.

Je hebt absoluut gelijk. Dat groene slotje moet gewoon een slotje worden, en niet groen worden.
Een leek zal dat groene zien als een soort van bevestiging dat de boel veilig is.

In werkelijkheid is er maar een ding waar: de aanvrager van het certificaat had op een moment controle over het domein. Meer toont het niet aan.

De organisaties wijzen erop dat de Wbp een wettelijke plicht oplegt om persoonsgegevens van degelijke beveiliging te voorzien. Doen bedrijven die niet, dan kunnen zij een boete krijgen tot 4500 euro.

Dat klinkt als een goudmijntje, als je leest dat veel van zulke sites geen SSL gebruiken.

Waarom worden er nog geen boetes opgelegd? Daar kan je gewoon een template voor maken om het te automatiseren. Laat die bedrijven hun nalatigheid maar voelen.

Dat doet die bedrijven geen pijn
Voor de meeste bedrijven is het implementeren van HTTPS duurder dan die 4500,-
Als ze dat bedrag gaan berekenen als x% van de omzet dan zullen een hoop bedrijven wel moeten, maar tot nu toe is er geen controlle en dus geen pakkans en zelfs als die er komt is het goedkoper om de boete eens in de zoveel tijd te krijgen dan om het goed te doen
Goed idee deze wet, slecht uitgevoerd tot nu toe...

[Reactie gewijzigd door RGAT op 25 januari 2017 11:25]

Dat doet die bedrijven geen pijn
Voor de meeste bedrijven is het implementeren van HTTPS duurder dan die 4500,-

Die boete kan gegeven worden per tijdseenheid. 4500 per constatering (bijvoorbeeld per dag) loopt gauw ook.

Daarom spreek ik over automatisering om deze boete uit te delen. 85% van sites, 4500 euro boete per dag... Dat maakt het percentage wel lager.

Als je er een template van maakt, dan houdt de boete geen stand bij de rechter. Een bevoegd persoon moet vaststellen dat persoonsgegevens onveilig worden verstuurd.

Als je er een template van maakt, dan houdt de boete geen stand bij de rechter.

Het is een schikking. Dat werkt ook voor verkeers'boetes'.

Als iemand het voor de rechter wilt slepen, pas dan gaat een bevoegd persoon kijken naar het automatisch verkregen bewijs.

geen één site gebruikt SSL mag ik hopen , je bedoelt denk ik TLS

Hele slechte zaak dat er zoveel nog niet via https loopt. Ik denk ook dat de consument heel weinig kijkt naar de URL (voor zover die in sommige browsers al helemaal zichtbaar is.
En nu ik er over nadenk hoevaak kijk ik naar de URL? Ik besteed meer aandacht aan de reputatie van een webwinkel door de reviews te lezen dan dat ik naar de URL kijk.
Dat de kruidenier op de hoek zijn winkel nog niet via HTTPS heeft lopen is 1 ding maar dat de overheid zelf zijn zaken niet op orde heeft is natuurlijk nog veel triester.

Ik denk dat er eerst boetes moeten worden opgelegd voordat mensen echt actie gaan ondernemen. Mensen hebben toch een trigger nodig om het te doen.

Firefox en Chrome tonen al een waarschuwing bij sites die nog geen https hebben. Nu is die waarschuwing nog niet echt heel duidelijk in beeld of afschrikwekkend, maar ik vermoed dat dit in de toekomst wel het geval gaat worden. Als de bezoekers dan een grote waarschuwing voor hun kiezen krijgen zal iedereen sneller actie gaan ondernemen om dat certificaat te gaan regelen.

Firefox en Chrome tonen al een waarschuwing bij sites die nog geen https hebben. Nu is die waarschuwing nog niet echt heel duidelijk in beeld of afschrikwekkend, maar ik vermoed dat dit in de toekomst wel het geval gaat worden. Als de bezoekers dan een grote waarschuwing voor hun kiezen krijgen zal iedereen sneller actie gaan ondernemen om dat certificaat te gaan regelen.

Let wel op dat Chrome dat in versie 56 'pas' heeft. Bovendien is dat nu alleen voor inloggen en niet voor 'gewone' pagina's.

Over die waarschuwingen: of ze klikken gewoon lekker al die meldingen weg, zoals ze nu ook al doen met andere meldingen. Niet lezen, maar meteen weg met dat venster/de melding.

[Reactie gewijzigd door AnonymousWP op 25 januari 2017 12:13]

Zeer slecht. Je hebt tegenwoordig ook zoiets als Let's Encrypt. Ik snap dat veel bedrijven hier niet van afweten, maar een simpel SSL certificaatje van een ander bedrijf kost ook niet veel. Je webserver(s) er voor instellen is tegenwoordig ook geen probleem meer. Is dat wel zo, dan wordt het ook hoog tijd om die bij te werken.

Zo wilde ik een tijd geleden busververvoer naar een discotheek boeken via nightrider.nl, maar alles gaat over HTTP..... man man man...

Het is vaak bureaucratie, managers die het niet weten, luie ITers, ITers die niet assertief zijn en andere dingen. Kosten van SSL zijn niet het probleem. Je koopt een certificaat al voor 10 euro per jaar. En een uitgebreide validatie voor 100 euro per jaar.

Kleine moeite om https aan te zetten

Ik neem aan dat je zelf een website beheert dat je dat zo stellig zegt?
Het is nogal tegenstrijdig met wat ik hierboven lees.

Ik heb zelf even gekeken wat ik voor mijn hobbymatige website moet doen. De website hoster doet het meeste werk. Ik moet een formulier invullen (inclusief bedrijfsnaam?), en een legitimatiebewijs opsturen. Ik verwacht dat ik dan een formulier thuisgestuurd krijg, dat ik moet ondertekenen en terugsturen. Er moet immers geverifieerd worden dat ik daadwerkelijk ben wie ik zeg, en dat ik ook de eigenaar van de website ben.

Geen rocket science, maar het is ook niet een kwestie van een vinkje aanzetten.

Hangt van je hoster af. Bij Dreamhost is het namelijk wél een kwestie van een vinkje aanzetten

Dat maakt het wel makkelijker ja.
Ik zag laatst dat er hosters zijn die standaard https bieden bij hun pakket.
Het is waarschijnlijk net als met veel andere zaken: Als je er vooraf rekening mee houdt, kan het eenvoudig. Anders kan het wat meer werk zijn.

Geen kleine moeite. Bij grotere websites zijn het klussen die maanden duren. Het certificaat stelt niets voor. Het gaat om alle content, firts party APIs, en 3rd party dependencies geschikt maken.