Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Meerderheid van Nederlandse scholen gebruikt geen https voor website

Een meerderheid van Nederlandse scholen en onderwijsinstellingen gebruikt geen beveiligde https-verbinding. Dat geldt met name voor websites van scholen in het primair, voortgezet en speciaal onderwijs.

De cijfers blijken uit onderzoek van de Open State Foundation, dat 6431 websites van scholen en onderwijsinstellingen heeft bekeken. Een overzicht van de websites en het https-gebruik is gepubliceerd in het dashboard Pulse. Van alle websites ondersteunt maar een derde een versleutelde verbinding. Onder de 2055 websites die https gebruiken, zijn 590 websites waarbij dat niet afgedwongen wordt.

Het merendeel van de onderzochte domeinen betreft websites van scholen in het primair onderwijs. Het gaat om 5147 domeinen. Daarvan ondersteunt slechts 29 procent https en wordt https bij maar 20 procent afgedwongen. Met de beveiliging van websites van scholen in het middelbaar, hoger en wetenschappelijk onderwijs is het beter gesteld. In deze categorie is 77 tot 82 procent van de websites beveiligd met https.

De Open State Foundation heeft een steekproef uitgevoerd op de onderzochte websites en daaruit blijkt dat verschillende scholen die websites zonder https hebben ook inlogmogelijkheden bieden voor studenten, docenten en ouders. Ook staan er op de websites soms contact- of afmeldformulieren. Als er geen https wordt gebruikt, kan de inhoud van dergelijke formulieren door kwaadwillenden onderschept worden.

De Open State Foundation vestigde eerder de aandacht op het gebruik van https door de overheid en in de zorgsector. In maart ondersteunde 52 procent van de overheidswebsites https, inmiddels is dat volgens het Pulse-dashboard gestegen naar 70 procent. Begin dit jaar werd het gebruik van https voor overheidswebsites verplicht gesteld. Van websites in de zorgsector is nog geen nieuwe scan uitgevoerd. In augustus maakte de Open State Foundation bekend dat 39 procent van zorgwebsites https ondersteunt.

Door

Nieuwsredacteur

175 Linkedin Google+

Submitter: AnonymousWP

Reacties (175)

Wijzig sortering
Interessanter is dit als ze ook daadwerkelijk cijfers hadden genoemd van websites die geen HTTPS afdwingen en wel contactformulieren of loginforms hebben. Het boeit mij namelijk weinig dat een paar statische infopagina's geen HTTPS ondersteunen, dat voegt niks toe. Nu praat men over "verschillende sites" maar daar heb je niks aan.
Het boeit mij namelijk weinig dat een paar statische infopagina's geen HTTPS ondersteunen, dat voegt niks toe.
Het boeit omdat we iedere keer deze discussie voeren. Als al die statische pagina's* wel gebruik maakten van HTTPS dan hoefden we hier niet weer over te praten. Nu moet bij iedere pagina iemand gaan nadenken "moet hier HTTPS gebruikt worden?". Bij iedere verandering moet dat opnieuw worden overwogen. Af en toe zal iemand de verkeerde beslissing nemen, zeker omdat de meeste docenten nu eenmaal geen IT'er zijn.
Als je er een paar tientjes tegenaan gooit verdwijnt het probleem gewoon helemaal. Ik denk dat zelfs de tijd dat iemand er over moet nadenken snel duurder is dan maar gewoon een certificaat installeren. Als je leverancier daar moeilijk over doet of kosten voor rekent is het tijd voor een ander, dat is niet meer van deze tijd.

* niet dat een statische pagina nooit HTTPs nodig heeft, maar dat is een andere discussie.

[Reactie gewijzigd door CAPSLOCK2000 op 6 december 2017 14:11]

Het probleem wat ik met de werkwijze van de Open State Foundation is is dat ze op geen enkele wijze zulke nuance als afwegingen toepassen of discussie aan gaan. En dat is volgens mij waar @The Realone het over heeft.

Het is heel makkelijk om als buitenstaander te eisen wat goede en slechte beveiliging is. Te makkelijk. De Open State Foundation scant een paar websites, schenkt zo min mogelijk aandacht aan beweegredenen of nuances die hierbij van toepassing zijn en roept dan dat anderen slecht bezig zijn. Dat komt op mij heel onprofessioneel over.

Beveiliging is helaas geen kwestie van even een paar tientjes investeren en een simpel HTTP is fout en HTTPS is goed. Beveiliging zijn afweging van voldoen aan verplichtingen (wetgeving etc) en resterende risico's waar je zelf een keuze hebt. Maar daar hebben de personen achter de Open State Foundation geen boodschap aan. En dat heeft weinig meer met beveiliging te maken. Wat de Open State Foundation met de huidige communicatie doet is weinig meer dan het opdringen van een simpele mening als de waarheid. En de media neemt de slecht onderbouwde conclusies zonder kritische blik over. Want probeer de Open State Foundation en die media maar eens uit te leggen wat schijnveiligheid is, wat ook in een serieuze afweging aan bod hoort te komen.

Ik neem de Open State Foundation pas serieus als ze met resultaten komen waarbij ze wel durven in gaan op wat beveiliging in de praktijk is. Ik ben het er mee eens dat HTTPS een prima onderdeel van beveiliging kan zijn maar het is veel te simpel dat HTTP fout is en HTTPS goed. Maar zulke diepgang interesseert de Open State Foundation kennelijk niet. Ik vermoed omdat ze anders geen aandacht krijgen en ze bang zijn dat er anders helemaal geen aandacht is. Liever HTTPS met een groot risico op schijnveiligheid dan een serieuze discussie waar geen publiek voor is. Wat is een roep om beveiliging dan nog waard?
HTTPS is geen garantie voor veiligheid, maar een gebrek aan HTTPS is wel een garantie voor onveiligheid.
Als je zelfs geen HTTPS hebt dan hoef ik niet eens te weten hoe het met de rest staat, dan weet ik nu al dat daar weinig aandacht aan wordt gegeven.

Op hun site staat precies welke sites ze hebben gescand, wat ze hebben gecontroleerd en waarom dat belangrijk is. De resultaten zijn eenvoudig maar duidelijk, daar is voor mij weinig nuance voor nodig. Daarbij komen ze overeen met mijn eigen ervaringen.

Ik zie OSF nergens beweren dat ze een volledige security scan hebben gedaan of dat hun resultaten iets zeggen over de totale veiligheid. Ze hebben geteld hoeveel sites HTTPS gebruiken, niet meer en niet minder. Waarom mag de OSF geen onderzoek doen naar basale beveiligingskenmerken zonder direct het hele spectrum mee te moeten nemen?

Diepgang zou mooi zijn maar de meeste van die websites zijn daar nog helemaal niet klaar voor. Zolang ze nog geen HTTPS gebruiken heeft het geen zin om het over ingewikkeldere dingen te gaan hebben.

Waarom begint iedereen toch steeds weer over schijnveiligheid? Heb jij ooit iemand gezien die iets niet deed omdat er geen groen slotje was? Ik niet.
Nou ja, laten we even eerlijk zijn: voor de meeste basisscholen biedt HTTPS 0,0 meerwaarde, aangezien het veelal gaat om volledig openbare pagina's. Bij de school van mijn zoontje ook: verhaaltje over de school, de lesmethodes, de groepen, wat foto's, het team, etc. 1 formuliertje aanwezig: een zoekveld. Dat is dus eigenlijk de enige informatie die een mogelijke aanvaller zou kunnen onderscheppen: weten waar ik op zoek binnen de site van de school. En zelfs als dat versleuteld zou worden zou het resultaat daarvan ook gewoon af te leiden zijn van mijn vervolgstappen omdat ook met HTTPS gewoon te zien is welke URL ik bezoek.
Voor de rest is zelfs de contactpagina niet boeiend: Adres, telefoonnummer, emailadres, wat PDF formuliertjes en een embedded Google maps kaartje. HTTPS is dan leuk, maar biedt geen enkele beveiliging.

Op het voortgezet en voornamelijk het vervolgonderwijs heb je vaak al wat meer te maken met data die heen en weer gestuurd wordt of die achter inloggegevens zit. Dan heeft SSL wel meerwaarde, al zit veel van dat soort spul nog apart in Magister o.i.d. wat dan ook de complete beveiliging (incl SSL) voor je regelt en volledig buiten je eigen website valt.
Niet zo gek ook MBO, HBO en Universiteit hier het beste scoren.

Wat dat betreft onderschrijf ik @kodak en @The Realone wel met hun kritiek op dit onderzoek.
En zelfs als dat versleuteld zou worden zou het resultaat daarvan ook gewoon af te leiden zijn van mijn vervolgstappen omdat ook met HTTPS gewoon te zien is welke URL ik bezoek.
Kleine correctie: het is met een beveiligde verbinding niet te zien waar je binnen een site heen gaat en welke params er wel/niet in de URL staan. Kijk even naar dit StackOverflow antwoord inclusief plaatje met een wire-capture van een beveiligd request ter illustratie. Ook het pad is afgescherm.

Voorbeeld uit link:
Te bezoeken URL: https://i.stack.imgur.com/path/?some=parameters&go=here
Zichtbaar in request: https://i.stack.imgur.com/

[Reactie gewijzigd door rkeet op 7 december 2017 13:57]

Nou ja, laten we even eerlijk zijn: voor de meeste basisscholen biedt HTTPS 0,0 meerwaarde, aangezien het veelal gaat om volledig openbare pagina's.
Het gaat harde de andere kant op. Alles en iedereen begeeft zich online, ook steeds meer basisscholen. Ik vind het dus helemaal niet gek om te monitoren hoe het staat met elementaire maatregelen als HTTPS. Als iemand me kon overtuigen dat al die scholen een bewuste keuze hebben gemaakt voor HTTP dan zou ik er misschien anders over denken.

Ik zal niet beweren (en OSF ook niet) dat de hemel naar beneden komt als je geen HTTPS op je eenvoudige website hebt. Ik durf wel te beweren dat het wel of niet hebben van HTTPS een goede indicatie is voor hoeveel aandacht er is voor de website. Geen garantie, een indicatie.
Als vlugge inschatting van hoezeer Nederlandse scholen bezig zijn met de veiligheid is het scannen naar HTTPS dus een prima middel.

Ik zou wel willen dat iemand een diepgravend onderzoek doet naar de beveiliging van basisscholen maar dat zit er niet in. Het lijkt me eerlijk gezegd ook nauwelijks de moeite waard. Op grond van dit onderzoek naar HTTPS durf ik al te zeggen dat de meeste basisscholen helemaal niet bezig zijn met digitale veiligheid.

Volgens mij lezen mensen meer in dit onderzoek dan er in staat. Het is een simpele meting, niet meer, de interpretatie mag je er zelf aan geven.
Als uit onderzoek blijkt dat 40% van de fietsen geen werkend licht heeft dan gaan we ook niet in discussie of die fietsen wel gebruikt worden, of er 's nachts op gereden wordt, en of dat licht op je fiets maar schijnveiligheid is omdat de meeste ongelukken overdag gebeuren.
En zelfs als dat versleuteld zou worden zou het resultaat daarvan ook gewoon af te leiden zijn van mijn vervolgstappen omdat ook met HTTPS gewoon te zien is welke URL ik bezoek.
Dat klopt niet. Ze kunnen zien welke webserver je bezoekt. Niet welk URL op die server je bezoekt.
[...]

Het gaat harde de andere kant op. Alles en iedereen begeeft zich online, ook steeds meer basisscholen. Ik vind het dus helemaal niet gek om te monitoren hoe het staat met elementaire maatregelen als HTTPS. Als iemand me kon overtuigen dat al die scholen een bewuste keuze hebben gemaakt voor HTTP dan zou ik er misschien anders over denken.
Dus omdat iemand iets niet versleuteld heeft is jouw aanname dat ze er niet over nagedacht hebben?
Ik zal niet beweren (en OSF ook niet) dat de hemel naar beneden komt als je geen HTTPS op je eenvoudige website hebt.

[...]
Volgens mij lezen mensen meer in dit onderzoek dan er in staat. Het is een simpele meting, niet meer, de interpretatie mag je er zelf aan geven.
Zo wordt het wel gebracht, en ze geven ook een interpretatie mee:
Van de 2.055 unieke websites met een HTTPS-verbinding blijkt dat dit bij 590 niet wordt afgedwongen waardoor bezoekers alsnog onnodig risico’s lopen bij 77% van de scholensites
Dat geeft aan dat ik dus schijnbaar meer risico loop omdat een schoolwebsite geen HTTPS afdwingt. Sorry hoor, maar ik vind het persoonlijk zorgelijker dat een site op Wordpress draait met diverse plugins. OSF zelf draait bijvoorbeeld qTranslate-X 3.4.6.4 terwijl die inmiddels op versie 3.4.6.8. Oh, en daar kan ik wel doneren, dus dat is iets belangrijker dan een openbaar verhaaltje over een school.

Natuurlijk is het heel flauw om nu op een foutje van OSF zelf te wijzen, maar ik vind het net zo flauw om te gaan zeuren over dit soort simpele sites van het kaliber van de bakker om de hoek. Ik denk dat er veel meer te halen valt bij Magister e.d., ook al hebben die toevallig wél een versleutelde verbinding. Of als je dan toch per se naar basisscholen wil kijken, toets dan even hoe zij omgaan met persoonsgegevens en foto's van de kinderen. Want geheid dat dit bij net zo veel scholen mis is, en dat is wél iets wat er toe doet bij scholen.
Dat klopt niet. Ze kunnen zien welke webserver je bezoekt. Niet welk URL op die server je bezoekt.
Nou, whoopie... dan kunnen ze misschien zien dat ik gezocht heb op iets als kalender of de naam van een leerkracht ofzo. Lekker boeiend.
Dus omdat iemand iets niet versleuteld heeft is jouw aanname dat ze er niet over nagedacht hebben?
Ja, dat lijkt me een hele realistische en verstandige aanname. Veruit de meeste sites zijn niet bezig met security. Ik denk dat er maar heel weinig sites op internet zijn waar iemand achter zit die veiligheid belangrijk vindt die nog geen HTTPS hebben. Het kan in theorie, maar dat is niet de praktijk. Aannemen dat er niet over de beveiliging is nagedacht is een verstandige grondhouding.
Dat geeft aan dat ik dus schijnbaar meer risico loop omdat een schoolwebsite geen HTTPS afdwingt. Sorry hoor, maar ik vind het persoonlijk zorgelijker dat een site op Wordpress draait met diverse plugins. OSF zelf draait bijvoorbeeld qTranslate-X 3.4.6.4 terwijl die inmiddels op versie 3.4.6.8. Oh, en daar kan ik wel doneren, dus dat is iets belangrijker dan een openbaar verhaaltje over een school.
Ik vind het ook zorgelijker dat ze een antieke versie van Wordpress draaien, maar de kans dat daar iets aan gedaan wordt is veel kleiner, alleen al omdat het veel duurder is. Sites die zorgen dat hun Wordpress up-to-date is hebben vast ook wel certificaatje voor HTTPS. Hoewel het een strict genomen niks met het ander te maken heeft is HTTPS een goede proxy
[quote]Diepgang zou mooi zijn maar de meeste van die websites zijn daar nog helemaal niet klaar voor. Zolang ze nog geen HTTPS gebruiken heeft het geen zin om het over ingewikkeldere dingen te gaan hebben.[/qoute]
Waarom begint iedereen toch steeds weer over schijnveiligheid? Heb jij ooit iemand gezien die iets niet deed omdat er geen groen slotje was? Ik niet.
Nou bijvoorbeeld omdat heel veel van die website waar wel persoonsgegevens mee verwerkt worden op een shared hosting draaien waarvan niet bekend is hoe veilig dat is, de persoonsgegevens onversleuteld opgeslagen worden en/of de persoonsgegevens met ftp of onversleutelde email worden verzonden naar de school. Zoals gezegd, beveiliging gaat om het geheel en om afwegingen. Schijnveiligheid is de situatie waarbij je als gebruiker het gevoel hebt dat je gegevens veilig verwerkt worden maar dat alleen op gaat voor een klein deel van de verwerking.

Voor beveiliging is diepgang nodig, niet een eigenwijze instelling dat er iets moet gebeuren en als dat niet het geval is het fout is.
Je hoeft er alleen tijd tegen aan te gooien. Let's encrypt is gratis, bij meeste hostingproviders zit het op het controlepaneel en klik het staat aan. Enige wat je dan moet doen in je cms is https instellen of in je htaccess alles ook naar https sturen.
Dat is 1 keer werk en alles zit op https
Of je maakt een gratis Cloudflare accountje aan heb je ook HTTPS en hoef je nooit meer een SSL ceritifcaat te kopen of uberhaupt iets te installeren.
Mag niet in veel gevallen. Is eigenlijk een mitm attack.
Je kan je eigen cert bij cloudflare installeren, dat is the geen man-in-the-middle attack meer 😆😉
En dan heeft Cloudflare je private key. Zelfde verhaal.
Laten we aub niet vergeten dat een website beveiligen geen 1-click-never-look-back-HTTPS-inregel actie is. Het installeren van een certificaat is een van de vele beveiligingsmaatregelen.

Nu lijkt het erop dat wanneer je een certificaatje installeert je website geheel veilig is. Dat is gewoon veel te simpel gedacht.

Als je een website beveiligt zal je altijd een behoorlijke hoeveelheid tijd (of geld; inhuren kennis en kunde) moeten investeren. Doe je dit niet dan zorg je uitsluitend voor een vals gevoel van veiligheid...
Op een info website is een site veilig maken redelijk vaak letterlijk 1 klik (of afhankelijk van je software een aantal klikken, hangt er van af of ze rechtstreeks letsencrypt ondersteunen). Indien je een kant en klare software oplossing gebruikt is het ook vaak letterlijk 1 klik (twee als je 'automatische updates' in het verleden hebt uitgezet).

Natuurlijk, als je custom software gaat schrijven dan moet je dat gewoon goed doen, maar een certificaat geeft nooit een vals gevoel van veiligheid. Het betekend altijd dat je communiceert met wie je denkt te communiceren en dat er niet iemand tussen zit mee te luisteren.
Natuurlijk, als je custom software gaat schrijven dan moet je dat gewoon goed doen, maar een certificaat geeft nooit een vals gevoel van veiligheid. Het betekend altijd dat je communiceert met wie je denkt te communiceren en dat er niet iemand tussen zit mee te luisteren.
Maar ook absoluut niet meer dan dat.
Het certificaat geeft dus absoluut niet aan dat de website 'veilig' is (kan prima vol met lekken zitten), of dat de server 'veilig' is (kan al lang deel zijn van een bot-net) of überhaupt is van de partij waarmee je denkt te communiceren. Het geeft alléén aan dat je met die specifieke server communiceert.

Het certificaat geeft óók niet aan dat de software waarbinnen de website draait (Apache, nginx, IIS etc) up-to-date is. Of dat de gebruikte raamwerken (Apache Struts (Equifax, anyone?), .Net Framework, PHP/Zend) of het gebruikte CMS (Joomla, WordPress, Drupal) up-to-date zijn. Of de plugins die daarbinnen draaien bijgewerkt en zonder lekken (bijv. SQL injectie, XSS (cross-site scripting) of CSRF (Cross-site request forgery)). Of dat de gebruikte Windows, Linux of BSD versie wel recent en bijgewerkt is.
En dan hebben we het nog niet eens over de configuratie gehad.

Dus nee, een website beveiligen is niet met 1 klik mogelijk; zéker niet als je het goed wilt doen.
Het toevoegen van transport-level security (TLS, voor HTTPS) is daarentegen wel kinderlijk eenvoudig, en geen enkele zichzelf respecterende organisatie zou dat vandaag de dag nog achterwege moeten laten.

[Reactie gewijzigd door Raventhorn op 6 december 2017 15:54]

Behalve dan in alle gevallen waarin DPI wordt toegepast. Of als iemand illegaal certificaten aan het minten is. Kleinigheidjes hou je toch.
En tenzij de beheerder een vrijwilliger is kost tijd ook gewoon geld. Als een klant mij vraagt om een ssl certificaat te installeren is in veel gevallen Letsencrypt prima en uiteraard is deze gratis voor de klant. Mijn tijd wordt echter gewoon gefactureerd.
Dat iets technisch niet moeilijk hoeft te zijn betekent niet dat het in de praktijk niet toch moeilijk is. Er komen processen bij kijken, misschien heb je een gefedereerde inlog... Hoe doe je dat met een Let's Encrypt? Kan ik dat ook gebruiken om mijn LDAP verkeer te beveiliging?

Mijn oude school heeft het goed voor elkaar, maar veel zusterscholen missen de kennis, het geld en de tijd om het goed te doen. Beveiligingscertificaten zijn geen kattepis en ik heb mening beheerder zich zien verslikken tijdens een uitrol. Nu wij het beheer aan het centraliseren zijn wordt het wel beter omdat we kundige mensen hebben die dat regelen, maar het blijft een lastig iets.
Leuk, laten we allemaal lets encrypt gebruiken. Mag je vervolgens gaan controleren of je wel op de juiste website zit, aangezien unicode domeinen mogelijk zijn. Criminelen maken hier zeer vaak misbruik van en bouwen websites volop na. Let's encrypt is mijns inziens leuk voor simpel website. maar website voor overheden heb ik liever dat ze die paar tientjes per jaar betalen.
Ja dat is leuk voor de discussie en de statistieken, maar het gevaar wat geschetst wordt in dit artikel is mogelijk lang niet zo groot. Het feit er geen specifieke aantallen genoemd worden van sites waarbij er ook daadwerkelijk potentieel gevoelige data over de lijn gaat doet mij vermoeden dat dit aandeel van sites vele malen kleiner is. Dat stoort mij dan weer.

Er zijn honderden security zaken waar een school aandacht aan moet besteden en dat doen ze echt niet in alle gevallen. Dat heb ik liever dat nu de moeite steken in het aanpakken van reële dreigingen i.p.v. een certificaatje installeren op hun website die enkel een foto van de school toont om maar de statistieken te verbeteren.
Ja dat is leuk voor de discussie en de statistieken, maar het gevaar wat geschetst wordt in dit artikel is mogelijk lang niet zo groot. Het feit er geen specifieke aantallen genoemd worden van sites waarbij er ook daadwerkelijk potentieel gevoelige data over de lijn gaat doet mij vermoeden dat dit aandeel van sites vele malen kleiner is. Dat stoort mij dan weer.
Niet alleen de informatie die jij kunt terugsturen is gevoelig; alle uitgaande informatie is dat ook.
Een niet-beveiligde site kan via MitM aangevallen worden om bijv. een extra nieuwsbericht te tonen dat alle ouders netjes vraagt om "s.v.p. ¤ X,xx over te maken naar $IBAN$ voor het opkomende schoolreisje", om maar eens iets te noemen.
Nee, prut, onzin. ALLES MOET HTTPS.

Geen HTTPS betekent dat een mitm aanval mogelijk is.

De gemiddelde gebruiker is een gigantische idioot. Pak een statische schoolwebsite, gooi er een nep DigiD login op en kijk eens hoeveel data je na een week hebt.

[Reactie gewijzigd door Leo1010 op 6 december 2017 13:23]

Voordat je met termen als 'prut' en 'onzin' gaat smijten, wil je mij eens uitleggen wat HTTPS in de door jou zo zorgvuldig gekozen situatie gaat helpen? Want als een basisschool zijn website "beveiligd" met HTTPS en iemand heeft de mogelijkheid de site inhoudelijk aan te passen met een nep-login form gaat HTTPS jou echt 0,0 helpen.
Als een website geen https ondersteunt, kan iemand een mitm aanval uitvoeren waarmee de data die teruggestuurd wordt naar de client kan worden aangepast. Er kan dan bijvoorbeeld andere informatie worden getoond, of een inlogformulier naar een kwaadwillende website. De bezoeker heeft dat niet door, die denkt dat hij gewoon op de website van de school surft. Daarom zou elke nieuws website ook https moeten ondersteunen.


edit: spelling

[Reactie gewijzigd door cracking cloud op 6 december 2017 14:31]

Apache, nginx, etc zitten nog vol met beveiligingslekken die überhaupt nog niet vrijgegeven zijn, maar al wel exploits voor geschreven zijn. Dit geldt zowel voor HTTP als HTTPS. Of je er nou een certificaat op zet of niet. Om MitM zoveel als mogelijk tegen te gaan, dient de beheerder van de pagina zorg te dragen aan het up-to-date zijn van de hosting omgeving. Een pagina die niet onderhouden wordt is namelijk net zo erg als je voordeur open laten staan.

Verder draagt SSL TLS natuurlijk wel bij aan de veiligheid, maar zal de bezoeker alsnog met common sense het internet op moeten gaan. Zonder dat krijg je gevallen als "Harrie van de overkant" waarbij bestanden ineens niet meer te openen zijn (bijv. cryptolocker), of dat de computer van Harry zo super traag is, dat deze niet meer vooruit te banden is (bijv. een background bitcoin miner).

[Reactie gewijzigd door InjecTioN op 6 december 2017 14:24]

Natuurlijk zijn er bugs en exploits in elke technologie, dat betekend niet dat je dan maar niks hoeft te doen. Laten we ook maar de aivd het leger en de politie afschaffen omdat er af en toe alsnog iets gebeurt. Je auto afsluiten hoeven we dus ook niet te doen omdat er toch auto's gestolen worden? Fiets aan is ook niet nodig, of schrijf je pincode maar in een comment want er wordt soms toch geskimd.

Het gaat erom dat je gemakkelijk te voorkomen zaken oplost en https is daar gewoon een prachtig voorbeeld van. Dat heeft niets met de andere veiligheidsproblemen te maken, die zijn ook belangrijk, maar die maken https niet minder van belang.
Natuurlijk dienen de gemakkelijke zaken zoals afgedwongen HTTPS met een geldig certificaat altijd gewoon als een van de eerste dingen geregeld te zijn. Dat houdt niet in dat alle andere randvoorwaarden ineens irrelevant zijn. Er wordt naar mijn idee gewoon niet hard genoeg getrokken aan de veiligheid van een website als we kijken naar gebruikte ciphers t.b.v. de encryptie van de HTTPS-verbinding, ge-update varianten van apache, nginx en gelijksoortige applicaties, DKIM, DNSSEC, HSTS, etc.

Kort gezegd: Er zijn gewoon veeeeel meer afhankelijkheden om een website veilig te maken dan alleen HTTPS.

Nog een aantal handige pagina's om te testen of een pagina veilig genoeg is:

[Reactie gewijzigd door InjecTioN op 6 december 2017 14:42]

interessante testjes, maar ik stel me toch vragen bij de waarde van een site die google.com een magere 49% en de loginpagina van outlook 52% geeft. Dat moeten zowat 2 van de meest getargette websites ter wereld zijn die voor zover ik weet nooit zijn gekraakt
Je bedoeld TLS, SSL is inmiddels zo lek als een mandje.
Het probleem met HTTPS is dat het een valse gevoel van beveiliging geeft. Het is net zoals de controle voor je een vliegtuig neemt: Stopt het bepaalde aanvallen, Ja ... Maar het zal niet verhinderen dat er veel grotere problemen zijn dan het onderscheppen van je content of mitm aanvallen.

Als iemand dat jaren gewerkt heeft voor Belgische GO onderwijs, als beheerder van hun webhosting ( wij waren niet verantwoordelijk voor hun content, enkel de servers ), kan ik je verzekeren dat het ontbreken van HTTPS werkelijk of toestanden zoals dat niet hun issues zijn. Wordpress, Drupal, enz sites dat niet geupdate worden en waar er dan snel vol zat met spyware en andere toestanden.

Slechte frameworks, niemand dat controleerde, custom websites waar men niet eens de moeite deed voor basis bescherming zoals anti SQL-Injection. De lijst is ellen lang. Hoe vaak dat we ( terwijl het niet ons werk was ) de scholen waarschuwde dat hun content weeral gehacked was en dat ze PVD hun sites code moeten upgraden en cleanen.

Daarom dat ik persoonlijk zeg dat HTTPS echt niets uitmaakt wanneer 30% van de sites draaien op wordpress of andere publieke frameworks dat zo uitgebuit worden, dat men sowieso de data kan onderscheppen.

En dan spreek ik nog niet over het aantal keren dat SSL certificaten gestolen of gehackt zijn. En hoe lang is dat allemaal niet verborgen gehouden ( durf er op wedden dat er meer gehackt is en gestolen dan je echt weet want het is tegen de interesten van de bedrijven om zo een informatie publiekelijk te maken ).

InjecTioN heeft gelijk... Is het goed om HTTPS actief te hebben, sure .. maar sorry dat ik het zeg maar in mijn professionele ervaring met scholen en hun content, is dit nieuw bericht gewoon nutteloos want zelf al draaien ze allemaal 100% op HTTPS, dan nog zal gerust 5 a 10% gehackt zijn omdat ze met publieke framework draaien wat resulteert vaak in 0-day exploits ( waar zelf auto updating frameworks niet tegenop kunnen ). Gratis populaire code / frameworks hebben een kost en dat vergeten ze vaak.
Het probleem met HTTPS is dat het een valse gevoel van beveiliging geeft. Het is net zoals de controle voor je een vliegtuig neemt: Stopt het bepaalde aanvallen, Ja ... Maar het zal niet verhinderen dat er veel grotere problemen zijn dan het onderscheppen van je content of mitm aanvallen.
Slechte analogie; met een vliegtuig heb je maar beperkte dreigingen en 1 soort impact die er toe doet (je stort neer).
Ik hoop dat je begrijpt dat een maatregel op een dreiging past. Het is daarom ook onzin om te verkondigen dat TLS niet helpt tegen "veel grotere problemen dan het onderscheppen van je content of mitm aanvallen".
TLS is een maatregel die de integriteit en vertrouwelijkheid van dataverkeer beschermt. Niets meer, niets minder! Dat kwetsbaarheden optreden in de maatregel is weer een ander verhaal en doet niets af aan nut of noodzaak van een maatregel.
Slechte frameworks, niemand dat controleerde, custom websites waar men niet eens de moeite deed voor basis bescherming zoals anti SQL-Injection. De lijst is ellen lang.
Zoek het nog eens wat simpeler: e-mail met NAW gegevens over onbeveiligde kanalen.

Zo stuurt de Technische Universiteit Eindhoven al enkele jaren mailings rond aan alumni om te verifiëren of hun contact-gegevens up-to-date zijn. Dat doen ze via een publieke mass-mailing provider; over voorheen onbeveiligde mail-servers; en met 'klik hier voor de web-weergave'-toevoeging op publiekelijk toegankelijke URLs.

Saillant detail: volgens de gebruiksvoorwaarden van die mass mailing provider mogen er niet eens mailings met persoonsgegevens over plaatsvinden en garanderen zij de beveiliging van die gegevens niet, indien het toch gebeurt. Nice! :(

Heb de TU/e ondertussen al 3 keer aangeschreven met die ongein te kappen. En 2 incidenten ook aangegeven bij de Autoriteit Persoonsgegevens.

Gebeurt er wat mee? Nee, hoor. Nog steeds dezelfde klerezooi.

Totdat er keihard afgestraft gaat worden zal men met dit soort zaken laks om blijven gaan. Een probleem wat hier alleen nog maar groter wordt door het feit dat ook de controlerende instanties zelf er laks mee omgaan.

[Reactie gewijzigd door R4gnax op 6 december 2017 19:19]

Op het moment dat je een mitm kan doen op dns niveau stuur je gebruikers toch lekker naar een andere server. Je hebt dan echt niks meer te maken met de oorspronkelijke site en het wel of niet hebben van een certificaat.

Tenzij ook daar maatregelen voor zijn getroffen dan (dnssec bijv) dan wordt dat ook wel lastig.

[Reactie gewijzigd door watercoolertje op 6 december 2017 15:12]

Op het moment dat je een mitm kan doen op dns niveau stuur je gebruikers toch lekker naar een andere server. Je hebt dan echt niks meer te maken met de oorspronkelijke site en het wel of niet hebben van een certificaat.

Tenzij ook daar maatregelen voor zijn getroffen dan (dnssec bijv) dan wordt dat ook wel lastig.
HPKP + HSTS helpt daar tegen. Als je één keer de legitieme site bezocht hebt, dan zorgt HPKP er voor dat alleen nog het certificaat wat tijdens dat bezoek gebruikt werd, geaccepteerd wordt door je browser voor dat domein; en zorgt HSTS er voor dat de site enkel over HTTPS (en dus met het via HPKP afgedwongen certificaat) bezocht kan worden.
Nee, prut, onzin.

Koop een random certificaat en dan is je mitm site ook HTTPS. Alsof een gebruiker gaat controleren aan wie het certificaat is uitgegeven.
En dat is nou net waar je compleet te plank mis slaat, maar dat kan, dus hieronder leg ik uit waarom jij precies het tegenovergestelde zegt van hetgeen dat waar is ;)

Het hele doel van HTTPS is om mitm te voorkomen. Dus als jij een mitm aan het uitvoeren bent, dan is het zo goed als onmogelijk om een HTTPS certificaat voor te schotelen voor het gemitm'de domein. Dit betekend dat zolang jij op de website van jouw school bent dat jij, indien HTTPS correct ingestelt is, kan weten dat de content die jij te zien krijgt / de code die jouw browser uitvoerd gemaakt is door de personen die de echte website beheren

Zoals op Wikipedia al staat:
TLS wordt voornamelijk gebruikt in situaties waarin het nodig is te verifiëren of men inderdaad verbonden is met de gewenste server.
Dus een HTTPS certificaat bewijst dat je met de juiste server verbonden bent, en een HTTPS certificaat moet ALTIJD bij ALLE paginas aanwezig zijn, ongeacht of je een statische pagina hebt of een pagina waarin de client ook (gevoelige) data verzend. Om te voorkomen dat Meneer Evil Attacker zich kan voordoen als de website die jij vertrouwd, om te voorkomen dat hij jou kan redirecten naar een andere website (al dan niet met een oh zo mooi groen slotje in de url balk ;) ) en om te voorkomen dat hij gegevens die je verzend via forms kan afkijken.

[Reactie gewijzigd door Helium-3 op 6 december 2017 14:17]

Ik denk dat TheNiker2's extreem verwarrende comment bedoelde dat als je bijv. een MITM kunt doen via bijv. een 'gehackt' DNS record, je redelijk simpel daarna een domain-verified certificaat kunt krijgen voor dat domein. En dat zal dan werken zolang HPKP niet aan staat, en dat is standaard disabled in de meeste gevallen en is nu deprecated. In de plaats daarvan hebben we nu 'Expect-CT' en dat is een stuk beperkter.
Ah, dat kan ook altijd nog. Een DNS record kan bij openbare wifi gespoofd worden*, zeker met de huidge stand van zaken waar een merendeel van de mensen een outdated OS (lees: geen security updates) op zijn telefoon heeft staan. Daar zou HPKP bescherming tegen bieden. Echter is HPKP niet heel gemakkelijk te implementeren, en zodra het gelukt is kan een misconfiguratie je hele website in een keer platgooien voor bezoekers, waarbij dit niet te herstellen is in korte termijn (lees: maanden tot jaren downtime, wat funest is voor je website) Let's encrypt is bijvoorbeeld niet compatible met HPKP wegens de snel verlopende certificaten (wat ook voordelen heeft). Mijn school (HAVO) gebruikt bijvoorbeeld een Let's encrypt certificaat op haar website. (Hier moest ik wel even om gniffelen). Ook ikzelf gebruik op al mijn persoonlijke en hobbymatige websites HTTPS Certificaten van Let's Encrypt. Ik ben ook zeer blij met dit project.

*Het wifisysteem van sommige onderwijsinstellingen, bijvoorbeeld van het Deltion (MBO, VO en VAVO) en dat van Windesheim (HBO), is goed geregeld, dit is namelijk geen openbare wifi spot, maar een waar iedereen met zijn eigen referenties moet inloggen. Dit beperkt de kans op spoofing mitm significant.

[Reactie gewijzigd door Helium-3 op 6 december 2017 15:10]

Die hebben toch gewoon eduroam? Ik kon er vorige week nog op inloggen toen ik langs windesheim fietste. Daar is niets bijzonders aan, heeft tegenwoordig bijna iedere school.
Ja, zij gebruiken Eduroam. Een goede implementatie vind ik eduroam, en het is ook veelgebruikt over de hele wereld. Zelfs in een verre uithoek in Duitsland op het Max-Planck-Institut für Plasmaphysik*, daar was gewoon een eduroam beschikbaar. Ik kon echter met mijn referenties (van een Nederlandse VO school) niet inloggen :+

offtopic:
*Hier staat een waardevolle en zeer interresante experimentele kernfusie reactor, de Wendelstein 7-X
Volgens mij kan HPKP met Letsencrypt echt wel hoor.
Ik dacht zelf eerst dat het helemaal niet kon, maar ik heb nog even geGoogled:
Volgens deze uitleg met veel waarschuwingsteksten kan het, maar is het een risicovolle onderneming.
First, don't use HPKP unless you have read and understood the specifications502, and are extremely careful. Know that if you get something wrong, you can render your domain unusable.
Never pin exclusively to Let's Encrypt (or any single CA). Make sure you have at a couple of backups / alternatives that you can work with if something catastrophic or simply buggy happens to your first choice
If the domain is of any value to you, test a deployment on a less valuable domain, and test your backup CA with it.
Use the -Report-Only header214 and the report-uri field before you actually deploy HPKP, to see how many visitors report breakage.
Pinning works on public keys, not certificates, and a pinned key can occur anywhere in a cert chain: root, intermediate, or leaf.
Now, to attempt to answer the question. Since this advice has not been tested, only try this on domains you don't care about, and are willing to see permanently broken.
Mijn conclusie uit het artikel/de post:
Het is technisch gezien zeker mogelijk, maar je bevind je op glad ijs als je het werkelijk zou proberen.

[Reactie gewijzigd door Helium-3 op 6 december 2017 17:42]

Dat is de hele reden waarom HPKP gedeprecated is, hetzelfde probleem heb je in principe waar dan ook.
Je browser is anders best wel kritisch als het aankomt of het domein en certificaat klopt.
Proficiat voor deze reactie.

Een man in the middle "aanval" van een statische html website, om wat juist te doen? Kan je uitleggen welke stappen daar voor nodig zijn en wat het gevolg is? En hoe zorgt SSL er juist voor dat dit onmogelijk wordt?
Wacht maar tot het volgende bericht op de site van een bassischool verschijnt:
Beste ouder,
volgende week is er een schoolreisje. AUB uw kind afleveren in de Pedosteeg, waar een busje klaar staat om het mee te nemen. Dank voor de medewerking! Groetjes, Elsa!
Zelfs als het maar een grap is heb je een hoop uit te leggen.

[Reactie gewijzigd door CAPSLOCK2000 op 6 december 2017 14:15]

En dat kan natuurlijk niet als de site "beveiligd" is met HTTPS ...

De reacties hierboven zijn juist: ja, je kan makkelijker een MITM uitvoeren via HTTP. Maar er zijn honderden, zo niet duizenden, andere manieren om de content van een website te vervalsen. Laten we vooral al beginnen met het feit dat veel van die sites op Wordpress draaien. Een beetje hacker kan op een half uur het overgrote deel van die sites met gemak aanpassen.

HTTPS geeft vooral een vals gevoel van veiligheid. Wat niet wil zeggen dat het geen must is bij formulieren, betalingen, enz.
HTTPS geeft vooral een vals gevoel van veiligheid. Wat niet wil zeggen dat het geen must is bij formulieren, betalingen, enz.
Ik heb een broertje dood aan het "vals gevoel van veiligheid". Kun je één beveiliging noemen die 100% gegarandeerd altijd werkt en alle risico's wegneemt?
Ik niet. Niks is perfect. In de beveiliging hebben we het daarom altijd over lagen van beveiliging. HTTPS / SSL is een erg belangrijke laag. Niemand zal beweren dat alleen HTTPS genoeg is. HTTPS geeft vooral meer veiligheid dan geen HTTPS. Dat sommigen er een "vals gevoel van veiligheid" aan over houden is jammer, maar ik heb niet de illusie dat die mensen veiliger zouden handelen zonder HTTPS. De mensen die last hebben van dat "valse gevoel van veiligheid" zouden anders precies hetzelfde doen zonder er enig gevoel bij te hebben.
Kun je één beveiliging noemen die 100% gegarandeerd altijd werkt en alle risico's wegneemt?
Neen.
HTTPS / SSL is een erg belangrijke laag
Voor het encrypteren van POSTS en bvb tegengaan van session hijacking: volledig akkoord.
Om er voor te zorgen dat statische websites met enkel een agenda op en wat adresgegevens beveiligd zijn: niet akkoord. Eén van de belangrijkste lagen is daar het CMS, bijna altijd zo lek als een zeef. HTTPS voegt daar naar mijn mening weinig toe. De allerbelangrijkste laag is trouwens de eindgebruiker en zijn toestel.
De mensen die last hebben van dat "valse gevoel van veiligheid" zouden anders precies hetzelfde doen zonder er enig gevoel bij te hebben.
Ik kom vaak niet-technische mensen tegen die er van uitgaan dat een site "met een slotje" per definitie een veilige site is, want dat hebben ze zo gezien op de TV.
Om er voor te zorgen dat statische websites met enkel een agenda op en wat adresgegevens beveiligd zijn: niet akkoord. Eén van de belangrijkste lagen is daar het CMS, bijna altijd zo lek als een zeef. HTTPS voegt daar naar mijn mening weinig toe. De allerbelangrijkste laag is trouwens de eindgebruiker en zijn toestel.
Er is ook zo iets als moeite versus opbrengst. Zelf de bugs in je CMS patchen is de meesten niet gegeven. Zelfs alleen maar zorgen dat je CMS regelmatig wordt bijgewerkt is praktisch gezien voor velen te moeilijk. Een SSL-certificaat (laten) installeren is een stuk makkelijker.

Overigens is voor geen enkele site alleen HTTPS voldoende. Geen HTTPS is echter voor iedere site onvoldoende. Als we dus eens beginnen met overal HTTPS te gebruiken dan maken we een grote stap tegen lage kosten.
Ik kom vaak niet-technische mensen tegen die er van uitgaan dat een site "met een slotje" per definitie een veilige site is, want dat hebben ze zo gezien op de TV.
Voor die reclames dachten ze dat alle sites veilig waren, ik zie dus vooruitgang! Sites zonder dat slotje zijn het in ieder geval niet. Ik denk dat mensen het eigenlijk best snappen. Als je een hek om een vijver zet weet iedereen dat het geen garantie is dat er nooit meer iemand verdrinkt, maar dat het wel degelijk een hoop helpt.
Maar https op een site waarvan het CMS niet up-to-date wordt gehouden is meer iets als een rood-wit lint op struikelhoogte dan een hek om de vijver
Als concept is een vals gevoel van veiligheid veel gevaarlijker dan een goed gevoel van onveiligheid.

Vertaalt zich ook naar een 'false positive' in testscenarios van software (of onderdelen daarvan). Niet alleen schiet je daar niks mee op, want het kost het veel meer tijd om ze op te lossen, doordat deze misleidende conclusies opleveren.

Iemand met verstand van zaken kan het onderscheid tussen 'false positives' en 'positives' wel maken. Maar daar lopen er altijd minder van rond dan wenselijk is.

Hetzelfde geld voor HTTPS. Na het lezen van meerdere door jouw geschreven posts, heb ik wel de indruk dat je weet waarover je het hebt. Maar ik wil personen de kost niet geven, die denken dat HTTPS het redmiddel is.

Vandaar dat er ook zo "fanatiek" gereageerd word. Zelf zit ik meer in het kamp: waarom HTTPS op een statisch html site waar geen enkele vorm van interactiviteit in zit.

Daarnaast vertouwen veel te veel mensen op de betrouwbaarheid van de certificaat uitgevers. Zoveel bedrijven zijn dat niet. Het lijken er alleen een heleboel te zijn, maar het zijn bijna allemaal re-sellers en/of dochter-ondernemingen van een tiental globaal actieve spelers op die markt. En nee, deze zijn niet allemaal even betrouwbaar. DigiNotar alweer vergeten?

Oftewel: "who watches the watchers?"
Als concept is een vals gevoel van veiligheid veel gevaarlijker dan een goed gevoel van onveiligheid.
Dat ligt er maar aan, wat levert uiteindelijk het minste schade op? Motorrijders nemen meer risico's als ze een helm dragen, omdat die helm ze een "vals gevoel van veiligheid" geeft. Toch spaart die helm zoveel schade dat het nog steeds de moeite waard is. Volgens mij kijken de meeste mensen alleen naar "het groene slotje" als ze een betaling doen. Ik denk dat we het er over eens zin dat je bij een betaling altijd https wil gebruiken. De rest van de tijd kijken ze toch niet, voor hun gevoel van veiligheid maakt het dan ook niks uit.
Je kan dan een bijvoorbeeld een (voorheen niet-bestaande) (DigiD?) login pagina tonen en die gegevens opvangen.

Ook zorgt HTTPS er voor dat men niet kan zien welke pagina's je bezoekt op een website, wanneer je bijvoorbeeld gebruik maakt van een commerciële open hotspot.
Zie de reactie van Leo1010 in 'nieuws: Meerderheid van Nederlandse scholen gebruikt geen https v...

Een aanvaller kan de inhoud van een HTTP website met gemak aanpassen en daar kwaadwillende content plaatsen zoals een fake DigiD inlogformulier e.d.

[Reactie gewijzigd door AgamemnonZ op 6 december 2017 13:44]

En het zorgt ervoor dat je 100% zeker weet dat de getoonde informatie juist is. Zeker bij overheids instellingen is het gewoon belangrijk dat je zeker weet dat wat je ziet ook klopt en niet dat er iemand met de informatie aan het klooien is via een MitM aanval.
HSTS?
Op zichzelf staand nutteloos als DNS een man-in-the-middle kan krijgen. Wordt pas nuttig met DNSSEC of andere beschermingen op DNS-niveau. Maar die kun je als hosting partij niet afdwingen.

In combinatie met HPKP werkt het beter; daarmee dwing je af dat enkel en alleen jouw certificaat nog geaccepteerd wordt voor een bepaalde domeinnaam. Maar dat heeft weer andere nadelen: als het certificaat ooit ongeldig wordt verklaard en je HPKP met HSTS gecombineerd hebt, dan is je site gewoon niet meer bereikbaar totdat bezoekers handmatig het gepinde certificaat verwijderd hebben. Jij hebt als hoster geen mogelijkheid meer om die operatie te automatiseren vanaf jouw kant...
(een kopie van een antwoord dat ik al eerder geschreven heb hierboven)

Het hele doel van HTTPS is om mitm te voorkomen. Dus als jij een mitm aan het uitvoeren bent, dan is het zo goed als onmogelijk om een HTTPS certificaat voor te schotelen voor het gemitm'de domein. Dit betekend dat zolang jij op de website van jouw school bent dat jij, indien HTTPS correct ingestelt is, kan weten dat de content die jij te zien krijgt / de code die jouw browser uitvoerd gemaakt is door de personen die de echte website beheren.

Zoals op Wikipedia al staat:
TLS wordt voornamelijk gebruikt in situaties waarin het nodig is te verifiëren of men inderdaad verbonden is met de gewenste server.
Dus een HTTPS certificaat bewijst dat je met de juiste server verbonden bent, en een HTTPS certificaat moet ALTIJD bij ALLE paginas aanwezig zijn, ongeacht of je een statische pagina hebt of een pagina waarin de client ook (gevoelige) data verzend. Om te voorkomen dat Meneer Evil Attacker zich kan voordoen als de website die jij vertrouwd, om te voorkomen dat hij jou kan redirecten naar een andere website (al dan niet met een oh zo mooi groen slotje in de url balk ;) ) en om te voorkomen dat hij gegevens die je verzend via forms kan afkijken.
Pak een statische schoolwebsite, beveiligd met HTTPS, gooi er een nep DigiD login op en kijk eens hoeveel data je na een week hebt.

Gefeliciteerd. Je hebt zojuist inderdaad bewezen dat de gemiddelde gebruiker een gigantische idioot is. Daar gaat HTTPS echter niet zo heel veel aan veranderen. Het gaat er juist om dat er dus scholensites zijn, die wel om valide informatie vragen (zoals usernames/passwords/persoonsgegevens op formulieren), die niet beveiligd zijn zodat deze gevoelige informatie makkelijk onderschept kan worden.

Als er scholensites zijn die alleen statische text en plaatjes weergeven dan is https absoluut geen must. De enige informatie die dan over de lijn gaat is de informatie die toch al voor iedereen inzichtelijk is, namelijk de website. Die verrijking van de informatie zie ik echter nergens terug. Dus de totale omvang van het 'geen https' issue is nog steeds onbekend, en het rapport dus compleet nietszeggend.
Precies dit TagForce.

Zo'n overzicht is makkelijk scoren. De sites inhoudelijk beoordelen op de aanwezige (persoons)informatie kost echter een hoop werk en laten ze voor het gemak achterwege.

Jammer dat ze in zo'n geval niet ook hun kort door de bocht conclusies achterwege laten.

Statische sites met alleen wat contact informatie, overzicht vakantie data en een schoollogo of foto. Daar is helemaal geen SSL voor nodig.
HTTPS is slechts matig beschermend voor phishing. Zolang er OF niet goed op de domeinnaam wordt gelet (rekening houdend met dingen als unicode-karakters die verdraaid veel op gewone letters lijken, OF niet op het slotje wordt gelet, doet HTTPS erg weinig.

Bescherming tegen idiotie is helaas nog niet beschikbaar.
HTTPS zorgt er wel voor dat als het domein en het certificaat kloppen, er vrij weinig met de inhoud gedaan kan zijn, daar gaat het om. Dan kan zelfs een browser filter niet helpen. Terwijl veel fake domeinen op lijsten terecht komen voor phishing.
Als je geen HSTS gebruikt, dan ben je niet beschermd tegen een HTTP variant van de site.

Over fake domeinen op lijsten, zie o.a. https://www.аррӏе.com/. Dit is enkel een testsite. Tegen de tijd dat een Nederlands equivalent gedetecteerd is, geregistreerd is, en de blocklist ge-update is, ben je waarschijnlijk heel wat verder.

Een blocklist is nooit adequate bescherming, zeker als je bedenkt dat er, als je een sitenaam hebt waarvan 5 tekens vervangen kunnen worden door 1 unicode teken (in het apple.com voorbeeld, alle 5) al 32 mogelijke nep-domeinen zijn die niet te onderscheiden zijn door onervaren gebruikers.

[Reactie gewijzigd door Niet Henk op 6 december 2017 13:47]

Het verschil is natuurlijk dit:
https://i.imgur.com/b6aTu7c.png
Real thing:
https://i.imgur.com/YEtfyg6.png

Dat is een best belangrijk verschil. Symantec zijn dan zo nu en dan dwazen maar denk niet dat je super makkelijk een EV cert krijgt voor аррӏе.com
Ja, maar dan wil je dus dat alle scholen een EV certificaat gaan gebruiken. Dan pas is er een relevant verschil. En dan moeten daarnaast mensen weten dat de site een EV-certificaat heeft (of dat herkennen), en hem zonder EV-certificaat niet vertrouwen.

Dit is veel moeite (en geld) voor weinig winst. Je kan alles perfect willen, maar de baten zijn beperkt.
Dan wachten we maar tot het een keer goed fout gaat dan. Want zo werkt het hier natuurlijk.

Er is altijd een middenweg, het is niet zo dat het bestaan van unicode shenenigans dan maar moet betekenen dat wel allemaal op HTTP blijft want TLS is toch onveilig. En ja misschien moet er wel een EV certificaat zijn voor alle onderwijsinstanties. Desnoods regelt een of andere nationale vereniging het voor alle scholen. Dat maakt het technisch niet een slechte oplossing.
HTTPS zorgt er wel voor dat als het domein en het certificaat kloppen, er vrij weinig met de inhoud gedaan kan zijn, daar gaat het om.
Want? :? Wie weet wat bijvoorbeeld een proxy doet, als je via een proxy server naar het internet gaat. Of wat een man in the middle met de gegeven informatie doet. ;) Je kan dus zeker niet blindelings ervan uit gaan dat HTTPS-verbindingen voorkomt dat er iets met de inhoud gebeurd, ook dan kan er wel degelijk nog gerommeld worden.
Je snapt dan toch ook wel dat een proxy niet zomaar TLS/SSL rewrapping kan doen hea? Dan heeft deze een CA nodig die al op jouw systeem staat en geaccepteerd is en dan kan het. Anders klaagt je browser echt steen en been.
Je snapt dan toch ook wel dat een proxy niet zomaar TLS/SSL rewrapping kan doen hea? Dan heeft deze een CA nodig die al op jouw systeem staat en geaccepteerd is en dan kan het. Anders klaagt je browser echt steen en been.
Dat snap ik, maar nogmaals, het betekend niet dat je blindelings kan vertrouwen op de inhoud die over en weer gestuurd wordt, zoals jij het wel laat overkomen in jouw vorige bericht, zeker als er sprake is van een man-in-the-middle.
Maar dat ligt dan meer aan het feit dat je de client (en de set CA certificaten) niet kunt vertrouwen. Dat maakt HTTPS niet meteen onbetrouwbaar, daarbij moet de aanvallen dan eerst malware op de client krijgen en dan hoeft ie de MiTM niet eens meer te doen.
Een MITM hoeft natuurlijk ook niet alleen client-side te zijn he. De kans is kleiner, maar kan ook op een (web)server, al moet je dan weer toegang hebben gehad tot de server in kwestie zelf, maar is zeker niet onmogelijk. ;)
Als je al toegang hebt tot de webserver is dit toch allemaal een moot point. Dan jat je de hele database gewoon en installeer je misschien nog een mooie backdoor.
Maar dat ligt dan meer aan het feit dat je de client (en de set CA certificaten) niet kunt vertrouwen. Dat maakt HTTPS niet meteen onbetrouwbaar, daarbij moet de aanvallen dan eerst malware op de client krijgen en dan hoeft ie de MiTM niet eens meer te doen.
Of je moet te maken hebben met mensen die Lenovo laptops hebben waar nog steeds Superfish op geinstalleerd staat. Of andere services die aan SSL/TLS interceptie doen en bekende statische certificaten hebben.
Dat is allemaal client-side en daar kun je of hoef je als servereigenaar niet zo heel veel om te geven, zolang jij maar je taak hebt gedaan kunnen ze jou de schuld niet geven. En dat is in business toch vaak het belangrijke.
Het zal mij mijn reet roesten als een MITM de openbare info onderschept die van de schoolserver naar mijn browser wordt gestuurd. Die info kan de MITM zelf ook wel raadplagen door het adres in de balk te typen.
SSL is pas van waarde als ik info naar de server zend middels een formulier o.i.d.
Het enige nut van SSL op een eenrichtingswebsite is de eventuele verbeterde Googleranking.
Geen HTTPS betekent dat een mitm aanval mogelijk is.
Want met HTTPS is dat niet zo? Diginotar vergeten? True, de hack zorgde niet direct voor MITM-attacks, maar maakte het wel degelijk mogelijk, doordat certificaten dubbel uitgegeven werden.

[Reactie gewijzigd door CH4OS op 6 december 2017 13:51]

Ja goed maar dan heb je ook mensen die niet een school website als doel hebben...
Ik snap wat je bedoeld, maar het doel van de website maakt daar toch niets voor uit? ;) Zolang de chain in orde is zal het weinig mensen opvallen denk ik zo.

[Reactie gewijzigd door CH4OS op 6 december 2017 15:43]

Wel als het onderwerp van dit artikel schoolwebsites is :+
Die "gemiddelde gebruiker" zal dan ook niet zien dat de "mitm" website helemaal geen https gebruikt, of, als je al een wat beter ontwikkelde hacker hebt, dat het certificaat van de site niet die van de school is.

HTTPS is geen "gouden hamer" die ervoor zorgt dat alles ineens veilig is. Dat eist aandacht van beide zijden, dus van de kant van de school-server, alsmede van de kant van de bezoekers.

Verder kost een certificaat geld, iets waar scholen doorgaans niet al te veel van hebben, en maakt TLS de verbinding trager, niet te cachen (met name via proxy), en verhoogt het de benodigde bandbreedte en serverkosten, en vraagt het extra onderhoud zoals het vernieuwen van de certificaten als die verlopen.

Voor een school die alleen maar statische content heeft valt de kosten-baten analyse nogal snel negatief uit.
Kosten, Lets encrypt en opgelost. Verder helaas geen tijd om inhoudelijk te reageren.
Let's Encrypt is leuk, maar daarmee heb je enkel basis certificaten (geen OV of EV-certificaten dus). Ik zag in een post van EraYaN in 'nieuws: Meerderheid van Nederlandse scholen gebruikt geen https vo... zelfs screenshots van Appple, met het juiste certificaat en een certificaat met een ander, ogenschijnlijk correct certificaat, die beiden door de browser goedgekeurd waren. Dus zo 'en opgelost' hoeft het zeker niet automatisch te zijn. Het maakt HTTPS toegankelijker voor de massa, maar meer dan dat ook niet.

Overigens waren er ook al voordat Let's Encrypt kwam gratis certificaten, via bijvoorbeeld StartSSL kon dat (overigens gaat StartSSL geloof ik stoppen las ik onlangs). :) Voordeel van Let's Encrypt is dat de certificaat (her)uitgifte volledig geautomatiseerd is. ;)

[Reactie gewijzigd door CH4OS op 6 december 2017 15:16]

StartSSL stopt omdat zij of het moederbedrijf nogal onzorgvuldig bezig waren. Zo werden certificaten ook regelmatig gebackdate
Jep, en de rootcertificaten die ingetrokken worden bij browsers. ;) Dus ook al zouden ze doorgaan, dan zouden ze wel foutmeldingen geven op browserniveau.
Zijn ze, in essentie, gereduceert to self-signed certificaten...waar ik voor intern gebruik meer vertouwen in heb dan voor externe cerificaten, maar dat is een andere discussie.
Self signed certificaten maak ik dan liever zelf idd, zodat je niet afhankelijk bent van externe partijen. ;)
De website van de basisschool van onze kinderen ondersteunt inderdaad ook geen HTTPS, maar qua invoer is er alleen maar een algemeen eenvoudig contactformulier op te vinden. En waarschijnlijk een CMS login (de website is gebouwd met Typo3 zo te zien).

Dus tsja, het zou inderdaad waardevol zijn om dat te vermelden bij deze cijfers.
HTTPS is met let's encrypt tegenwoordig gewoon gratis.Bij de meeste hostingproviders zit het al in het controle paneel. Aanklikken, cms op je server naar https zetten en je bent zo klaar.

Er is dus totaal geen reden meer om het niet te doen, het is gratis en kan snel geregeld worden.
Mooi, als jij dan eens kosteloos bij alle scholen langs gaat om het voor ze te regelen....
Dat niet alleen, ook de site moet geforceerd worden enkel via https te lopen. En de site zelf zal afhankelijk van het CMS en de kunde van de bouwer ook nog aangepast/ingesteld moeten worden op https te werken. En niet te vergeten dat alles uit externe bronnen ook nog naar https gezet moeten worden (plaatjes/javascript). Want anders geeft je browser alsnog aan dat het niet veilig is of werkt je site niet zoals bedoeld.

Het stelt allemaal niet enorm voor voor, maar als er geen budget is wat voor scholen helaas het geval is houd het gewoon snel op...

[Reactie gewijzigd door watercoolertje op 6 december 2017 15:01]

Ik geeft aan dat het tegenwoordig stukken eenvoudiger is.
Je hoeft niet ergens een duur certificaat te kopen, via de meeste controle panelen is het klik en ja je site zal ook aangepast moeten worden.

Scholen werken vaak met vrijwilligers of hebben iemand die de ict doet. Er zit vast wel iemand tussen die dat voor elkaar krijgt. Zo niet even zoeken op internet en voor de meeste cms systemen is het zo gevonden.

Dat jij uit dit verhaal de conclusie schijnt te willen trekken dat ik dat maar moet regelen zegt meer iets over jou en de onzin de je uitkraamt
Scholen werken vaak met vrijwilligers
Vrijwilligers verantwoordelijk maken voor de beveiliging van een website? Dat lijkt me geen goed plan.
Dat jij uit dit verhaal de conclusie schijnt te willen trekken dat ik dat maar moet regelen zegt meer iets over jou en de onzin de je uitkraamt
Ik trek geen conclusies, ik twijfel aan jouw conclusie dat het allemaal zo makkelijk is, en maak daar een sarcastische opmerking over.
Net ruim een maand bezig geweest met het omzetten van een http site naar https.
Het technische gedeelte was een koekie, maar door een hoop administratieve rompslomp met verschillende webhostingpakketen, domein-registraties, webdev's die aanpassingen moesten maken, etc duurde het allemaal veel langer dan gewenst.
Andere sites waren binnen minuten geregeld.
Al kost het maar 15 minuten per site, dan is het nog steeds niet gratis.
invoer is er alleen maar een algemeen eenvoudig contactformulier op te vinden.
waar iemand dan zo slim is om wat extra velden aan toe te voegen met gevoelige informatie. Of wil je '' lekker makkelijk" via digID dit formulier laten invullen? Allemaal manieren om je informatie afhandig te maken. De crimineel gebruikt dan de vertrouwdheid van de schoolomgeving om je over te halen deze gegevens in te vullen.
Ah jah dan moeten ze een man in the middle attack uitvoeren en heel specifiek die paar honderd ouders of kinderen op de juiste manier laten verbinden (als de crimineel op de server kan maakt http of https helemaal niet meer uit).

Theoretisch kan dat maar als je zo specifiek bezig bent is phising ook prima te doen en heb je niks met wel of geen https te maken.
Mee eens.

De basisschool van mijn zoon heeft een HTTP website, waar alleen wat algemene informatie op staat (visie, adres, datum van open dag). Als je iets wilt doen (contact, ziek melden, docent lastig vallen, verlof aanvragen), moet je naar een beveiligd gedeelte op een ander domein, waar zelfs SSLLabs tevreden over is. Beetje jammer dat deze school nu (waarschijnlijk) als onveilig is opgenomen in de statistieken.
Door middel van SSLstripping kan een aanvaller voorkomen dat je de HTTPS versie van een pagina krijgt als je op een link klikt vanaf een HTTP site. Daarom is het belangrijk dat alle domeinen en al helemaal het hoofddomein gebruik maken van HTTPS.

[Reactie gewijzigd door AgamemnonZ op 6 december 2017 13:35]

Het is natuurlijk niet moeilijk om dat beveiligde portaal na te bouwen en gewoon te injecteren op de echte website. Niemand die dat zou kunnen zien "want het staat toch op de echte website." Tsja jammer dat het de kerel met de fake wifi spot naast je is.
SSLLabs test echter ook niet alles. Ik krijg met https://securityheaders.io/ een andere score voor dezelfde site dan met SSLLabs. Dus leuk dat SSLLabs "tevreden" is, maar betekend niet per se dat de security optimaal is. SSL/TLS passen we immers ook niet toe om SSLLabs tevreden te houden, toch? ;)
Precies. Juist de contact formulieren, loginforms, of andere invulvelden, zoals bijvoorbeeld nieuwsbrief aanmelding of zelfs een webshop etc... Daar zitten de gevoelige informatie van zo'n site. Daar wil, en negeren is uit ten boze in deze tijd, een beveiliging op hebben. En dat begint met het invoeren van https.
Denk dat het qua inloggen wel op andere beheertools staat. Kan me niet voorstellen dat het op de homepagina staat login of wat dan ook |:(

Bij mijn oude school was het wanneer je wilt aanmelden voor een opleiding je uiteindelijk naar een DigID wordt gestuurd. Buiten dat hebben ze gewoon een https ondersteuning.

Dus lijkt me veilig? Ik heb dit niet meegemaakt, omdat ik jaren terug me had aangemeld via de decaan. Niks website etcetera.

[Reactie gewijzigd door theduke1989 op 6 december 2017 13:32]

Het zijn overigens niet eens altijd de scholen zelf. De scholen maken gebruik van ingekochte pakketten die zo lek zijn als een mandje, en dan bedoel ik niet eens alleen technisch. Ook sociaal. Openbare website waar je een klas aan klikt (krijg netjes een waarschuwing dat de verbinding niet veilig is van mijn browser), dan een lijst van kindernamen krijgt inclusief de eerste letter van de achternaam (!). En een wachtwoord at voor elk kind gelijk is (!).

Gebruiken ze een pakket dat in potentie goed zou moeten zijn (MSOffice/Sharepoint) stellen ze het zo slecht in dat elk kind zelfs de mappen van de andere kinderen kan verplaatsen en verwijderen (!). Ik als vader zonder weinig gedoe open de virtuele prullenbak in het account van mijn kind en vindt letterlijk alles terug. Ik vertrouw het niet en wil dus een backup maken geautomatiseerd, straks is ze haar spreekbeurt kwijt en is het tranen. Blijkt de standaard instelling te zijn dat ik alle bestanden van alle kinderen uit 1 klas backup/ moet koppelen. Dus koppel in potentie mijn system met elke computer van elke ouder. Dat maar even niet gedaan, virusscanner begon beetje tegen te sputteren.

Het is echt gepruts....
Het boeit mij namelijk weinig dat een paar statische infopagina's geen HTTPS ondersteunen, dat voegt niks toe.
Dat boeit jou niet?
Dan zijn we meteen bij de mentaliteit gekomen die dit probleem veroorzaakt.

SSL Encrypteert enerzijds de requests, maar ook de responses.
Je weet wel, die dingen die in jouw browser terechtkomen, en die door jouw browser worden geïnterpreteerd?

Dus als het beveiligen van statische pagina's jou niet boeit, boeit het je ook niet dat ik je responses herschrijf en er een JS redirect insteek? Eentje naar een pagina die zegt dat je browser out of date is en je echt een "update" of plugin nodig hebt om de content te zien?

Dan boeit het je ook niet dat je eigenlijk met een heel andere server communiceert die heel wat exploit kits host en die stuk voor stuk op je loslaat?

Sorry, maar dat is echt een enorm naieve mentaliteit die zich op nog minder baseert dan SSL op statische pagina's.
Overdrijven is ook een vak natuurlijk. Je moet mijn reactie wel in het perspectief van dit bericht plaatsen, al je dat lukt. En het gaat erom dat dit nu al een gigantisch probleem wordt gepresenteerd, maar dat in de praktijk nog wel eens best mee kan vallen. Daarmee wil ik niet zeggen dat er geen probleem is, maar je moet wel realistisch blijven. Ik kan jou ook wel doodgooien met allerlei theoretische argumenten, waar menig techneut overigens erg van houdt, maar daar schiet niemand iets mee op.

MITM attacks bij de website van de basisschool van Schubbekutteveen? Ben even realistisch. Dan heb ik liever dat die ene systeembeheerder zorgt dat hij zijn wireless netwerk voorziet van WPA2 ipv WEP encryptie dan dat hij voorkomt dat Pietje de ziekmelding van Jantje z'n moeder leest via het http-contactform.

Ik ben niet naïef, juist erg realistisch. Je kunt niet alles afdekken en in veel gevallen ben je blij dat je al 10% afgedekt hebt. Het probleem is, in mijn ogen, juist dat er verkeerde prioriteiten gesteld worden en als jij het belangrijker vindt resources te steken om bovenstaand scenario te voorkomen ten koste van andere zaken, dan ben jij wellicht wellicht onderdeel van het probleem. :) Denk daar maar eens over na.
We missen toch ergens een serieus raakvlak, jij en ik.

./certbot-auto apache -d mijndomain.com

Dit zijn ALLE resources die je nodig hebt, als je dat al niet kan opbrengen omdat het te veel werk is...

Security is laag na laag na laag na laag, uiteraard zijn er complexere aanvallen die andere lagen penetreren. Zullen we daarom maar meteen de default creds op admin:admin zetten? (Een password manager die heel de firma kan gebruiken instellen en iedereen trainen is toch wel veel werk en resources verspillen, als ze ten slotte een zero day gebruiken ben je toch genaaid, ookal heb je een pass manager)

En theoretisch? Nee, de reden dat ik hier zo fel op reageer is dat ik dagelijks geconfronteerd wordt met statements zoals "nou, ip restricten in de firewall is toch niet nodig voor rdp portforwarding, ze hebben toch geen credentials?"

Een week later ligt de server plat, bitcoin miner hogt alles, hadden ze het ww op "Welkom" ingesteld.

Sorry dat ik misschien over een bepaalde sociale grens ben gegaan, was niet netjes van me, maar ik erger me ziek aan minimalisme bij netwerk en/of serverbeheerders :)

Edit: sorry, ik vergeet "yum install certbot" nog. Maar je snapt het wel.

[Reactie gewijzigd door DeZwarteLijst op 6 december 2017 18:30]

Tja, dan zet iemand gauw een certificaatje op de website en vervolgens gaat elke browser van de bezoeker over de zeik omdat er een plaatje op een ander domein gehost wordt. Of het certificaat verloopt omdat er geen duidelijk proces is ingericht om dit te bewaken, bezoekers worden ook weer gepresenteerd met een grote waarschuwing. En waarom? Omdat de kans bestaat dat iemand een MITM aanval uitvoerd, iets wat je in de praktijk gewoon erg weinig zult zien voor dit soort websites, omdat het simpelweg niet interessant is voor een aanvaller.

Jij komt vervolgens met allerlei voorbeelden van zaken die ook eenvoudig in te richten zijn, maar waarbij de aanvalsvector juist vele malen groter is en het in de praktijk veel realistischer is dat deze uitgebuit wordt. Dat is veel interessanter om aan te pakken.

Waar ik me juist aan erger zijn "specialisten" die verkeerde prioriteiten geven omdat iets zo spannend klinkt. Dat is mijn praktijkervaring, en dan wil ik er ook best bij vermelden dat ik daar dagelijks in de meest uiteenlopende omgevingen mee geconfronteerd wordt, als dat waarde heeft.

Maar misschien missen wij inderdaad wel een raakvlak...
Ja okay, dat commando en een kwartier werk. Je hebt me.
Oh ja, en dan nog een lijn voor certbot auto-renew in crontab gooien.

Je vergroot het probleem van certifieringsprocedures en verkleint het probleem van MitM vind ik (persoonlijk)?

MitM is inderdaad geen HUGE real-life issue, maar is een halfuur werk dan te veel om het te voorkomen?

Ik vind dat toch echt die kleine investering waard, vooral omdat, wanneer je het goed doet, je het maar 1 keer moet doen (vrijgesteld van exploits/improvements in tls zelf natuurlijk)

En uiteraard zijn er andere dingen die ook met dat halfuur geholpen zijn, maar dat betekent niet dat je het gewoon open moet laten, toch? Is security niet zo iets van "beter (proberen te) voorkomen dan genezen?"

Niemand had het hier over prioriteit, dat heb jij ervan gemaakt. Als je firewall openstaat moet je idd niet beginnen met ssl certificaten aan te leggen. Dan heb je dat halfuur elders nodig. Ik vecht gewoon aan dat statische websites geen ssl certs zouden nodig hebben omdat ze geen risico vormen.

De manier waarop het hier nu uitdraait moet je nooit ssl certs hebben, ook niet als je pagina dynamisch is, MitM is toch niet realistisch volgens dit thread en het gaat bij dynamisch over onderscheppen van oa credentials via MitM, niet?

Tot slot denk ik dat ik nergens mezelf tot specialist heb gekroond, ik deel enkel mijn ervaringen om verschillende inzichten te voorzien en misschien iemand iets te vertellen wat ze niet wisten omdat ze het nooit op die manier hebben bekeken.

Dat jij het naast je neerlegt omdat je andere ervaringen hebt zal mij een zorg wezen. Jouw statische pagina's zullen niet beveiligd zijn tegen MitM (hoe theoretisch ook) en de mijne wel.

That's all.
Het boeit mij namelijk weinig dat een paar statische infopagina's geen HTTPS ondersteunen, dat voegt niks toe.
Dus jij vindt het prima dat mensen informatie voorgeschoteld krijgen die via een eenvoudige MiM attack zijn gewijzigd?
Als leerkracht met ICT-zaken belast onderhoud ik ook de website van onze school. Uiteraard alleen http.
Want enkel statische pagina's. Informatie geven en ouders kunnen niet inloggen. Waarom zou je dan https moeten hebben?
Het klinkt mij een beetje in de oren als Wij van WC-Eend adviseren WC-Eend, terwijl het gaat om het schoonhouden van een raam.
Ik denk dat er een reden waarom velen niet op https gaat: het kost geld.
Waarschijnlijk is er nog veel misverstand op die gebied want https kan namelijk ook gratis met Let's Encrypt. Maar als je goed oplet: veel hosters bieden geen mogelijkheid aan of zijn onduidelijk.

Bij Vimexx kun je bijvoorbeeld gratis en makkelijk aanmaken. Maar zou ik bij grote duurdere hoster kijken, zie je dat optie alleen uit betaalde https bestaat, 3 keuzes uit diverse certificaten. Dat zorgt voor een drempel voor aantal mensen.
En ook blijkt dat niet bij iedere hoster duidelijk is waar je website moet neerzetten zodat https werkt. Dat wil zeggen, men moet hoop instellen voordat het wel werkt. Zeker met eigen servers.

Verder kan ik ook raden dat sommige scholen eigen website programmeur hebben, die niet echt druk maakt over https en gewoon uitvoert wat school zegt. En dus nog steeds gewoon doorgaat op http.
En dat is wel een probleem als website programmeur niet bij school aanklopt en zegt dat jullie website op https moet staan. We weten toch allemaal dat elke website die login heeft, eigenlijk verplicht achter https moet staan... Maar kennelijk wordt er teveel bezuinigd op websites, niet kopen van certificaten, en dus blijven velen nog op "goedkope" http staan. Vergeten velen dat het ook gratis kan.

De oorzaak zal wel zitten in:
- niet elke bestuur op school heeft verstand van websites. Zolang het maar werkt, is het goed.
- angst voor extra kosten om website op https te zetten (inclusief bugs-angst)
- Betrokken website programmeur zegt er niks over en levert gewoon domweg af. Of het kunnen ook paar studenten zijn die aan website mogen werken, en letten niet op veiligheid.
- Leraar op afdeling programmeren zou meer lessen moeten geven op veiligheid websites én directie waarschuwen dat hun website niet veilig is. Maar ik denk dat er te weinig leraren zijn op aantal scholen die beter opletten... anders zouden we heel andere beeld moeten zien.
- En natuurlijk bemoeit overheid te weinig mee... geen regels eigenlijk opgesteld. Veel te laat gaan de ogen open.
- Hoster die hen niet eens adviseert en het is dus gewoon mond dicht-afleveren situatie of geeft te dure certificaat prijzen. Zegt niks over gratis oplossingen.
- Eigen servers: geen goede systeembeheerder

Daardoor gaan er zo weinig alarmbellen af... en doen velen nog op http. Het is om te schamen.
Ook eens een site voor een basisschool gemaakt twee jaar geleden. HSTS en HTTPS.
Ik sta dus in de "top 100" :+ (5000 * 2%)

[ontopic]
Wel een schrikbarend laag aantal https sites. Maar zolang er geen persoonlijke gegevens over de lijn gaan, vind ik het prima, al is het natuurlijk met de komst van Let's Encrypt een kleine moeite https vanaf het begin te verplichten.
Eens dat dit een schrikbarend laag aantal is. Maar laten we niet vergeten dat de meeste basisscholen al niet voorzien zijn van ICT'ers. In de meeste gevallen word de ICT geregeld door leerkrachten die dit erbij doen. Werk zelf als ICT'er op een basisschool en ik ben in onze omgeving de enigste. De rest zijn allemaal leerkrachten die heel goed les kunnen geven maar geen kaas hebben gegeten van ICT en hier te weinig tijd voor krijgen door drukte/ziekte van collega's. En al helemaal geen kaas hebben gegeten van security. Dus voor die mensen is het een grote moeite om Let's Encrypt in te zetten als ze uberhaubt al ooit van https/certificaten gehoord hebben. Niet om het goed te praten dat de sites geen HTTPS hebben, hier sta ik volledig achter. Maar de meeste website's zijn gewoon gebouwd door de vader van pietje die al 3 jaar niet meer op school zit en word onderhouden door klaas die de Pabo heeft gedaan.

Onze eigen website had gelukkig al https doordat xs4all standaard Let's Encrypt aan heeft gezet voor al zijn shared hosting pakketten. Vandaag maar wel even het gebruik geforceerd.
Ik denk dat het overgrote deel van school websites inderdaad gemaakt door goedwillende vrijwilligers. Daar kunnen we dan met z'n allen van vinden dat het beter moet, maar als we er vervolgens geen cent in investeren krijgen we gewoon waar we voor betalen.

Er wordt gestaakt wegens te hoge werkdruk, te grote klassen, teveel administratie, etc...en dan verwachten we dat die juffen en meesters nog even een goede een veilige website bouwen en onderhouden. Dat gaat 'em niet worden...ook niet als het verplicht wordt, omdat eventuele boetes / investeringen ten koste gaan van de primaire functie: kinderen goed onderwijs bieden.
Voor de komst van let's encrypt was het net zo'n kleine moeite om je site te beveiligen, enige is dat het toen wat geld kostte. Maar geld mag geen reden zijn om geen beveiligde site aan te bieden, zeker niet op plekken waar dat wel nodig is.
En, ook al is het discutabel in sommige opzichten, onze overheid heeft al sinds 2005 een eigen root CA, dus de overheid had ook best gratis certificaten aan onderdelen van de overheid kunnen verstrekken om sites mee te laten beveiligen.
https://www.security.nl/p...+wereld+met+eigen+Root+CA
Klopt maar zolang het gewoon openbaar beschikbare informatie is, dus geen logins oid zie ik niet gelijk de gevaren. In die zin dat 'ze' wel kunnen zien DAT je naar die site gaat, maar zolang dat gewoon de info is die toch al voor iedereen daarop staat... och ja. Het natuurlijk wel gemakkelijker eem mitm attack te doen, al zie ik niet gelijk op een basisschool oid met een statische pagina wat je daarmee wil bereiken.

Anderzijds is het inderdaad dermate goedkoop om het wel te beveiligen dat het misschien ook niet eens een vraag moet zijn.

[Reactie gewijzigd door Rataplan_ op 6 december 2017 14:06]

Mee eens, al is het een andere discussie dat met onbeveiligde sites of onbeveiligde delen van sites men via netwerktools inzicht kan krijgen welke siteonderdelen jij bezoekt en dat kan je ook als schending van de privacy zien. Dus dan gaat het niet om bescherming van de informatie op de site, maar om bescherming van de gebruiker en welke siteonderdelen de gebruiker bezoekt.
Mja, op zich eens, alleen het automatisch vernieuwen maakt het toch een stuk makkelijker.
Bovendien kan de Let's Encrypt certbot zelf de Apache configuratie aanmaken / aanpassen, dus een kind kan de was doen :)
Als ik het goed heb, en het tweakers certificaat ook bekijk, zijn let's encrypt certificaten maar 3 maanden geldig, dus automatisch vernieuwen is wenselijk gezien de korte duur van het certificaat. Al heeft een korte levensduur van een certificaat ook weer zijn security voordelen natuurlijk. De overheid kan certificaten met de eigen CA een langere geldigheid geven, dus dat zou dan al minder werk zijn om het handmatig te vernieuwen. En als let's encrypt het vernieuwen van certificaten kan automatiseren, dan moet er voor de overheid ook wel mogelijkheden zijn dit makkelijker te maken of ook te automatiseren. En of je het handmatig moet doen of kan automatiseren, het mag geen excuus zijn.
Het vernieuwen is met certbot volledig te automatiseren, dat in tegenstelling tot vele betaalde varianten. Ook al is dat eens in de 1/2/3 jaar, dan nog moet dat vaak handmatig.
Persoonlijk heb ik dan liever een vol geautomatiseerd systeem dat 4 per jaar moet.
al is het natuurlijk met de komst van Let's Encrypt een kleine moeite https vanaf het begin te verplichten.
Dat zeg je wel makkelijk, maar de laatste keer dat ik keek was Let's Encrypt toepassen op een Windows Server obv IIS nog niet zo eenvoudig. Destijds vereiste dit allerlei niet officieel ondersteunde PowerShell scripts en dergelijke. Daar zit ik als verantwoordelijke ook niet op te wachten.

Neemt niet weg dat het 'handmatig' aanvragen van een certificaat een klusje van niks is dat je eens in de paar jaar moet doen.
Wel een schrikbarend laag aantal https sites. Maar zolang er geen persoonlijke gegevens over de lijn gaan, vind ik het prima, al is het natuurlijk met de komst van Let's Encrypt een kleine moeite https vanaf het begin te verplichten.
Nee, niet mee eens.
Als er geen HTTPS wordt gebruikt, dan is een man in the middle attack mogelijk en kan de info van de website aangepast getoond worden, je weet dan dus niet zeker of datgene wat je leest ook echt op de website staat.
De informatie die ontbreekt is: welk percentage van de websites waarop privé-informatie kan worden ingevuld heeft geen https? Volgens de genoemde steekproef zijn die er, maar zijn het er veel of weinig?
Voor een website zonder formulieren lijkt het me helemaal niet belangrijk dat die https ondersteunt.
Oh? Hack even de school wifi, voer op alle verbonden apparaten een mitm aanval uit waardoor er een nep DigiD login op de website komt te staan en kijk dan eens aan het einde van de week hoeveel data je hebt.

Het maakt niet uit of er privacy gevoelige data op staat of niet. Geen HTTPS is een enorm risico.
Precies. De meeste mensen, zelfs op Tweakers, overzien niet alle risico's die HTTP met zich meebrengt. Vaak wordt bijvoorbeeld vergeten dat HTTPS voorkomt dat iemand de inhoud van een pagina kan aanpassen. Dit betekent dat je niet zeker weet dat de informatie op een pagina echt de informatie is van de school of dat het aangepast is door een aanvaller. @Leo1010 geeft een erg goed voorbeeld van hoe simpel zo'n website van een school die door de kinderen en ouders vertrouwd wordt misbruikt kan worden. HTTPS hoor je gewoon te hebben!
Zou https dan helpen tegen zo'n aanval? Ik denk het niet. De hacker hoeft voor de vervalste website niet ook https te gebruiken, en de meeste bezoekers zal dat helemaal niet opvallen.
Wat ik persoonlijk schrikbarend vind is 't aantal mensen wat (mede door de berichten in de media) die meteen, omdat een website een HTTPS verbinding heeft, denken dat die pagina's 100% veilig en te vertrouwen zijn...

Hoewel 't zeker een begin is qua veiligheid om 'n HTTPS verbinding te gebruiken, is 't zeker niet 't geval dat de veiligheid van je data (lees: de data die je verstuurd naar die site) op dat moment 100% veilig is...
Wat ik persoonlijk schrikbarend vind is 't aantal mensen wat (mede door de berichten in de media) die meteen, omdat een website een HTTPS verbinding heeft, denken dat die pagina's 100% veilig en te vertrouwen zijn...
Nog altijd beter dan vroeger, toen er helemaal niet over wordt nagedacht en alle sites blind werden vertrouwd.
Typisch dat er allemaal percentages genoemd worden, behalve bij het belangrijkste commentaar: sommige scholen hebben een inlog of contact mogelijkheid die onbeveiligd is. Juist dat getal lijkt me het belangrijkst. (De basisscholen zoals ik ze ken hebben niet veel meer dan een foto+adres/telefoon als homepage - daar is https echt niet van belang.)
Ik heb enkele websites van die lijst gecontroleerd, en het viel me op dat foto albums gewoon vaak publiekelijk beschikbaar zijn. Ook zorgwekkend...
Het zou vooral om sites moeten gaan met mogelijkheden tot inloggen of contactformulieren. Puur wat informatie betreft is https totaal overbodig.
Totdat iemand op de school WiFi een mitm aanval uitvoert op alle verbonden apparaten en een nep DiigiD login op de website injecteert.
En met HTTPS valt er geen MITM te doen op die manier? Wat als de school een firewall heeft die DPI op https doet, en dus ook certificaten daarvoor gebruikt en feitelijk een mitm is?
Nou nou, wat een drama. Hebben ze ook de gemiddelde content van een schoolwebsite bekeken? Daar is toch niets te vinden wat via https afgeschermd zou moeten worden?

Het artikel noemt twee kritischere punten, waar ik me deels in kan vinden:
- login / scholieren -> logisch, dit hoort beveiligd te zijn. En al lang.
- contactformulieren -> dit is te onderscheppen inderdaad, maar dat is e-mail net zo goed.

Verder is het dus nogal een storm in een glas water lijkt me. Ja het kan beter, maar nee, belangrijk is het niet.
E-mail is niet net zo goed te onderscheppen als je gebruikt maakt van geforceerde encryptie en moderne ciphers. (Perfect forward secrecy),
Zo goed als niet.
Bij mij in de regio heeft 10% https.. van de 10 scholen, Bizar dat er maar 1 voorzien is van https!
Je zou toch zeggen dat Let's encrypt de drempel tot het halen van een SSL certificaten behoorlijk omlaag heeft gegooid?


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S9 Google Pixel 2 Far Cry 5 Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*