Bijna 90 procent van overheidswebsites maakt gebruik van https

Volgens de Open State Foundation gebruikt 88 procent van de overheidswebsites een beveiligde https-verbinding. Dat is een flinke groei ten opzichte van een eerder percentage. Ook de onderzochte websites in de zorg en het onderwijs ondersteunen in de meeste gevallen https.

Volgens de organisatie is gaat het de goede kant op met de implementatie van https bij websites van publieke organisaties, waarbij 88 procent van de sites van de overheid daar nu gebruik van maken. Bij het onderwijs en de zorg is dat met 70 procent wat lager; de Open State Foundation stelt dan ook dat nog altijd een op de drie zorg- en onderwijswebsites niet goed beveiligd zijn.

De websites in deze twee laatstgenoemde sectoren laten wel de sterkste groei zien. Bij een eerdere telling in december 2017 bleek dat in het onderwijs slechts een derde gebruikmaakte van https en bij de de zorg was dat 39 procent in augustus 2017. In december 2016 maakte nog maar 44 procent van de overheidswebsites gebruik van https, wat een jaar later al was gegroeid naar 72 procent.

De Open State Foundation stelt dat het meer dan 30.000 domeinen heeft onderzocht in de sectoren zorg, onderwijs en overheid, waarbij de webpoints van de urls zijn geanalyseerd. Daarbij is gebruikgemaakt van meerdere opensourcetools en een api van SSL Labs. Een overzicht van de websites en het https-gebruik is gepubliceerd in het dashboard Pulse.

Overigens benadrukt de Open State Foundation dat de aanduiding dat een website https ondersteunt, niet betekent dat de website dit ook daadwerkelijk afdwingt. 'Slechts 61 procent van de zorgdomeinen dwingt https echt af', aldus de organisatie.

Dat de overheidssites het op het punt van de ondersteuning van https het beste doen, hangt waarschijnlijk deels samen met het feit dat dit in de loop van dit jaar verplicht wordt. Staatssecretaris Knops liet de Tweede Kamer vorig jaar weten dat die verplichting ergens 'medio 2019' ingaat.

Reacties (135)

[sambalbaj]

Blijft toch ook hameren op een gevoel van schijnveiligheid. Het voegt pas wat toe als er informatie op wordt uitgewisseld, voor gewone statische sites is het enkel om een groen slotje te halen.

[MadEgg]

Informatie opvragen is al genoeg reden. Zonder HTTPS kan al je verkeer eenvoudig getracked worden en is het dus triviaal voor anderen om te zien wat voor informatie jij opzoekt. Ook daarvoor is HTTPS dus geschikt, het voegt op zeer eenvoudige manier wat privacy toe. Die acuut teniet wordt gedaan als de betreffende site Google Analytics, een Facebook like-box of Facebook-pixel gebruikt, maar dat terzijde. Alle beetjes helpen.

[The Zep Man]

Blijft toch ook hameren op een gevoel van schijnveiligheid. Het voegt pas wat toe als er informatie op wordt uitgewisseld, voor gewone statische sites is het enkel om een groen slotje te halen.

Gelaagde beveiliging is het beste. HTTPS zorgt voor een extra laag beveiliging, ook voor de client die kwetsbaar kan zijn voor een MitM-aanval. HTTPS kan bijvoorbeeld beschermen tegen een kwetsbaarheid op applicatieniveau.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:56]

[bartje]

Vind het nog steeds schrikbarend weinig

[burne]

En hoeveel van de “zakelijke” websites gebruikt ssl tls? Veel en veel minder. Geen dwang, kost geld en de aandeelhouders krijgen er niets voor terug.

[jrswgtr]

Aandeelhouders? SSL kost je een tientje per jaar per domein. Daar zul je de aandeelhouders niet over horen. Overigens ligt het percentage SSL bij onze klanten (bedrijven) hoger dan 88%.

[burne]

Waarom staan er certificaten van 3000 euro ex op mijn prijslijst?

[thomas1907]

Omdat dat een keuze is.. Er is ook melk van 10 euro per pak maar je kan ook die van 2 euro nemen
SSL is helemaal gratis met Let's Encrypt en is bij elke webhost wel gratis te installeren: https://letsencrypt.org/

[The Zep Man]

SSL is helemaal gratis met Let's Encrypt en is bij elke webhost wel gratis te installeren: https://letsencrypt.org/

Correctie: een TLS certificaat is gratis. Een (duurzame) implementatie kost tijd, geld en energie. Er zijn veel amateurorganisaties die niets met IT zouden moeten doen, die dit niet op kunnen brengen voor hun verouderde sites.

[burne]

Correctie: een TLS-certificaat kan gratis zijn. Die certificaten van 3000 euro komen met een uitgebreide validatie van de organisatie en de website, en met een forse verzekering voor schade als er toch iets mis blijkt met de validatie.

Verder heb je gelijk

[Reactie gewijzigd door burne op 23 juli 2024 01:56]

[kozue]

https://www.troyhunt.com/...on-certificates-are-dead/

[Zebby]

Buiten dat o.a. Logius (DigiD) nog vereist dat je een hoog niveau certificaat moet gebruiken. Dat zie ik voorlopig niet veranderen.

[lappro]

Het enige wat Logius vereist is een PKI overheids certificaat. Dat hoeft dus helemaal geen EV certificaat te zijn (en is het ook meestal niet, wel OV). Die certificaten worden in opdracht van de overheid verstrekt door KPN. Vermoed dat die voor ongeveer kostprijs dus verkocht worden.

Lijkt me ook wel goed als daar een wat strictere controle opzit, je wilt niet dat iedereen zomaar een DigiD login kan aanbieden (en dus achter je bsn e.d. komen).

[Reactie gewijzigd door lappro op 23 juli 2024 01:56]

[Zebby]

Zover ik weet moet het inderdaad een hoger niveau qualified zijn, en vereist het o.a. dat er minimaal 1x een face-to-face afspraak is geweest ter bevestiging. Dus dat zit wel goed

[Blokker_1999]

Ik ga daar niet helemaal akkoord mee. Wanneer ik naar de site van mijn bank ga kijk ik wel degelijk na dat het juiste EV certificaat er staat. Klopt dat niet, dan trek ik aan de alarmbel. Als ik dat op het werk zie dan gaat er onmiddelijk een mailtje naar het security team om te melden dat er een fout in de config van de proxy zit.

En dat mobiele browsers het niet meer weergeven is dan ook zeer betreurenswaardig, maar daarom stellen dat EVs dood zijn gaat mij veel te ver en toont imho aan dat men het nut van een EV niet begrijpt. Een DV certificaat dient om de verbinding te beveiligen, een EV dient daarnaast ook om de identiteit van de andere kant vast te stellen. Iets wat je met een DV cert nooit kunt doen.

[siteoptimo]

Je beseft dat partijen als gogetssl diverse ev certificaten voor dezelfde condities wat garanties betreft geeft? Een certificaat van 3k is waanzin. 100-600 euro is meer common (afhankelijk van de issuer en de waarborg).

[The Zep Man]

Die certificaten van 3000 euro komen met een uitgebreide validatie van de organisatie en de website, en met een forse verzekering voor schade als er toch iets mis blijkt met de validatie.

Schade voor wie? En hoe vaak heeft zo'n verzekering daadwerkelijk uitgekeerd?

Zoals de link van kozue aangeeft: extended validation is dood. Eindgebruikers boeit het helemaal niets of het een gratis DV certificaat is of een EV certificaat.

[Yggdrasil]

Tja, ook die prijzen hoeven niet zo hoog te zijn. EV certificaten en hun verzekeringen zijn een wassen neus, maar als een bedrijf dat echt wil dan zijn EV certificaten mét uitgebreide validatie en verzekering al te koop vanaf zo'n €100-200 ex. BTW: https://www.sslcertificaten.nl/certificaten#EV_Standaard_1.

Dit zijn bekende namen zoals Thawte en Geotrust. In diezelfde prijslijst zie je er ook van Symantec à €800, maar die zijn op geen enkele manier beter of veiliger dan die goedkopere. Waarom betalen mensen daar dan toch voor? Geen idee, misschien onwetendheid of moeten kopen bij een Preferred Supplier.

Zoals @kozue al aangeeft in kozue in 'nieuws: Bijna 90 procent van overheidswebsites maakt gebruik van ht... is EV voor de eindgebruiker niet meer relevant. SSL/TLS dient voor het beveiligen van een verbinding, niet om een hele vertrouwensrelatie met een bedrijf op te baseren.

[m4ikel]

De kans dat die verzekering uitkeert is echter kleiner dan de kans dat je de loterij wint.

[svenslootweg]

Dit lijkt me onzin. Die organisaties draaien doorgaans gewoon een standaard webserver zoals Apache, waarvoor kant-en-klare integratie met Let's Encrypt bestaat. Dat is een kwestie van een tooltje installeren en niet meer naar omkijken.

Het idee dat TLS heel veel werk is om te implementeren op een site, is in 99.99% van de gevallen echt totale kul.

[mrmrmr]

Je zult toch je DNS server moeten aanpassen als je TLSA of CAA wilt benutten.

Het klopt wel dat let's encrypt te automatiseren is als daar geen gebruik van wordt gemaakt. Het veiligheidsniveau is dan niet om naar huis te schrijven, maar zeker beter dan helemaal geen encryptie.

Iedereen kan zijn web en mail server testen opt https://internet.nl

[Blokker_1999]

En dan gaan we even intern in een bedrijf. Domeinen die niet op het internet toegankelijk zijn en dus ook niet in de publieke DNS zitten. Software wat geen webserver is maar ook certs nodig heeft. En dan sta je daar weer met je CSRs die je bij LE net niet kunt gebruiken. In een enterprise omgeving is er veel meer beveiligd dan enkel wat webservertjes. En om dan ineens een project op te zetten om voor die enkele webcerts een nieuwe infrastructuur in dienst te nemen? Neen, dan kan je dat geld dat in zo een project kruipt beter besteden aan het blijven gebruiken van je huidige CA.

En wat als het misgaat? Heb jij ergens een support contract dat er voor zorgt dat problemen snel opgelost worden? Ook dat lukt niet met LE. Of ga je voor digitaal ondertekende of versleutelde emails? Dan heb je aan de certs van LE al helemaal niets.

De wereld van certs is zoveel meer dan enkel die HTTPS in de browser.

[proditaki]

Ik denk dat hierop het enige goede antwoord is: omdat het kan

[equit1986]

dat is echt onzin pur sang(niet tegen jou, maar tegen de bedrijven).
Het is gewoon laksheid. Het gaat er echt niet om hoe groener het slotje hoe beter, maar IEDEREEN kan gratis via OpenSSL/LetsEncrypt SSL-certificaten krijgen.
Dan heb je het alleen nog over de implementatie, wat serieus voor de meeste websites binnen een half uurtje geregeld kan zijn als je een redelijk modern CRM hebt....

[_Erikje_]

voor een marketing site is het nutteloos om HTTPS te gebruiken. Alleen voor performance (Http2) zou je het kunnen doen, maar ja, als het > 1000 euro kost om het te implementeren door een consultant, krabben de meeste bedrijven toch wel even achter de oren.

[kozue]

Het is *nooit* nutteloos om https te gebruiken. Https is niet alleen voor privacy (om meeluisteren tegen te gaan), maar ook tegen man-in-the-middle attacks, waarbij kwaadwillenden scripts injecteren in je code. Dat is triviaal met http wanneer je het verkeer kan onderscheppen (zoals met een fake wifi access point), maar kan met https niet meer.

[Verwijderd]

Ook met https kan je mitm uitvoeren met een fake wifi access point, want vaak is HSTS niet of nauwelijks correct geimplementeerd.

waarbij kwaadwillenden scripts injecteren in je code.

Alleen naar de verbinding via de fake AP met het slachtoffer.

Edit voor @kozue en @borft :

De MITM-aanval kan via een https-verbinding worden uitgevoerd met dezelfde techniek als bij http verbinding. Het verschil is het opzetten van twee SSL-sessies, één over elke TCP-verbinding. De browser maakt een SSL-verbinding met de aanvaller en de aanvaller maakt een SSL-verbinding met de webserver.

Een server met HTTPS, maar geen HSTS kan eenvoudig aangevallen worden middels MITM , omdat je hiermee een insecure HTTP-verbinding kan op zetten, die vervolgens hijacken. Ongeveer 15% van de https servers maakt gebruikt van HSTS, oftewel 85-90% kan je middels mitm aanvallen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 01:56]

[kozue]

Hoezo? Dat AP heeft toch geen certificaat van het domein dat je bezoekt?

[mrmrmr]

Als je ertussen zit (MitM) kan je ook een certificaat laten aanmaken, bijvoorbeeld via Letsencrypt.

Een gedeeltelijke beveiliging hiertegen is zoals @Emin3m schrijft HSTS. Er zijn meer technieken die onvoldoende worden toegepast en gebruikt aan de clientzijde, zoals controle van CAA en TLSA (DANE) records.

Firefox bijvoorbeeld geeft dat niet aan en ze hebben plugins die dat wel deden omzeep geholpen door niet de middelen te bieden om die controle uit te voeren alvorens de nieuwe plugin API te forceren. Natuurlijk begrijpt 99,99% van het publiek sowieso al niet wat er aan de hand is. Maar goed, het begint bij het aanbieden van de controlemogelijkheden.

TL;DR HTTPS op zich is geen afdoende beveiliging tegen MitM.

[Reactie gewijzigd door mrmrmr op 23 juli 2024 01:56]

[borft]

Dat klopt ook niet. Je kunt niet zomaar een letsencrypt certificaat voor elk domein laten aanmaken. Let's encrypt verifieert eerst of je controle over het domein hebt, op basis van DNS.

[mrmrmr]

Het werkt ook via een bestand op de website.

[mrmrmr]

Begrijp je het principe van MitM? Je zit er tussen en dus bepaal je wat "men" ziet.

[svenslootweg]

Bovendien worden de uitgegeven certificaten ook nog eens gepubliceerd via Certificate Transparency, en is het dus vrij gemakkelijk om erachter te komen wanneer iemand een MITM uitvoert tussen jouw server en Let's Encrypt (als ze dat uberhaupt al lukt).

[mrmrmr]

Als MitM wordt gepleegd op de lijn naar de server beslissen de aanvallers wat letsencrypt ziet op die server.

[mrmrmr]

Een MitM aanval aan de gebruikerskant maakt het iets moeilijker, maar ook dat is realiseerbaar als je zelf de beschikking hebt over een intermediate certificaat, een ingang bij een erkende CA, DNS of het aanvraagproces onderschept.

VOIP is bijvoorbeeld vaak onversleuteld, een terugbelcontrole van een CA kan zo worden gefaked.

MitM aanvallen worden vaak gepleegd door overheden en inlichtingendiensten. Er wordt kant en klare apparatuur voor aangeboden.

[Reactie gewijzigd door mrmrmr op 23 juli 2024 01:56]

[borft]

nee, dat kan niet. Je valideert namelijk of het certificaat valide is, door te checken of het gesigned is door een CA. dat werkt dus niet met een mitm.

@Verwijderd dat klopt dus niet. Wat jij beschrijft is een mitm op een http verbinding. Op een met TLS versleutelde verbinding kan je geen mitm doen, simpelweg omdat je het verkeer niet kunt decrypten. Je kunt ook niet doen alsof je de web server bent, omdat je zelf het certificaat niet hebt. Als jij tussen de browser en de server gaat zitten, zal je alleen versleuteld verkeer zien, waar je niets mee kunt. Als de browser probeert een verbinding met de aanvaller op te zetten, zal ie een dikke waarschuwing geven, omdat de aanvaller geen geldig certificaat heeft voor het domijn waarmee vebinden wordt.

@CyBeR daar heb je gedeeltelijk gelijk in. Je kunt niet zomaar een redirect naar http sturen, want je heb immers geen geldig certificaat. Echter in de gevallen waar een gebruiker zelf naar http gaan, en er geen hsts header is (of de gebruiker is er nog niet eerder geweest), dan zou je dat wel kunnen doen inderdaad. De gebruiker kan dan dus wel zien dat ie op http zit.

[Reactie gewijzigd door borft op 23 juli 2024 01:56]

[CyBeR]

Dat gezegd hebbende levert het gebrek aan HSTS je wel de mogelijkheid tot een downgrade attack op. Dwz een aanvaller die je een site over http laat browsen terwijl die zelf https met de site praat.

[Verwijderd]

Dat jij niet weet hoe het moet en niet heb ingelezen over de mogelijkheden wil dat niet zeggen dat het niet klopt.

Ik reageerde op kozue, die beweert dat https nodig is tegen mitm, waarbij attacker script kan injecteren wanneer je het verkeer kan onderscheppen met een fake AP. MITM attack kan je uitvoeren als je fake AP heb zowel met HTTPS als HTTP verkeer.

[borft]

OK, kan jij dan even uitleggen (of een linkje posten) hoe jij een geldig certificaat kunt genereren voor een domein waar je geen controle over hebt?

[Verwijderd]

Ik ga jou eerst even uitleg geven wat een mitm attack is.
https://nl.wikipedia.org/wiki/Man-in-the-middle-aanval
https://us.norton.com/int...in-the-middle-attack.html

Bypass
https://null-byte.wonderh...hanges-and-mitmf-0162322/
https://security.stackexc...e-attacks-by-proxy-server
https://www.quora.com/Is-MITM-attack-possible-when-on-HTTPS
https://news.netcraft.com...trivial-mitm-attacks.html
https://lucideustech.blog...-in-middle-attack-on.html

POC

Het gaat niet om een geldig certificaat generen voor een domein waar je geen controle op heb. dit beweer ik ook nergens.

[borft]

Prima, dan zijn we het denk ik gewoon eens. Zonder geldig certificaat kan je https niet mitm-en. Je kunt een downgrade attack doen naar http, je kunt een ongeldige ca installeren op een client, maar je kunt niet met een mitm aanval https verkeer onderscheppen en decrypten (zie ook de bronnen die je zelf aandraagt, dank voor de mooie lijst trouwens!).

[bbob]

voor een marketing site is https nodig omdat google je straft met ranking voor niet hebben daarvan.
Bij de meeste goede hosters kun je gewoon let's encrypt gebruiken. Dat kost verder niets en werkt gewoon vanzelf. Grote voordeel je vergeet ook niet te betlaen voor je betaalde certificaat en ja zelfs bedrijven als Microsoft hebben wel eens vergeten te verlengen. Dus gratis is eenvoudig en snel en doel is een beveiligde verbinding.

[equit1986]

voor alle zzp'ers die ik host verplicht ik ze HTTPS te gebruiken. Als ze niet weten hoe, dan help ik ze daarbij gewoon.
Kost geen drol.

[Kafka]

Verplichten? Want?

[Verwijderd]

Nou een goede dev-ops kan dit in 2 uur instellen en is gratis met lets encrypt en meteen te automatiseren met lets encrypt middels een cronjob. Dus als je code niet geschikt is tsja dan heb je werk te doen, maar doet de programmeur het al 10 jaar fout en zou een opfris cursus niet mistaan

[Johan9711]

Voor veel statische websites die geen client-server communicatie hebben behalve de statische content is het vaak niet superspannend. Overheidswebsites moeten altijd de goede content tonen, maar voor een normaal bedrijf is dat al gauw minder spannend.

[Kevinp]

Plus waarom zou je als bv kleine sportclub of stichting € 50 per jaar uitgeven om wat statische data te tonen?

Ik ben voor HTTPS hoor. Maar dan moeten deze bedragen veel lager worden. Hosting heb je nu al voor 2 euro per maand. En dan moet je het dubbele betalen voor iets wat eigenlijk geen of heel weinig meerwaarde bied.

[Shamalamadindon]

Let's Encrypt is gratis

[burne]

En de systeembeheerder die het moet installeren, liefst ook nog veilig enzo? Is die ook gratis? En wat heb je liever: een statische site zonder tls of een superdeluxe EV-certificaat bovenop een Joomla!-site vol met malware?

[GLaDTheresCake]

Ik zie het probleem echt niet, het is absoluut niet moeilijker om een ssl certificaat te installeren tegenwoordig dan het live zetten van een statische webpagina. Een hoop web hosting services, zoals ik laatst transip heb gebruikt, hebben gewoon standaard een let's encrypt certificaat geïnstalleerd.

[gammuts]

En het veilig configureren van TLS dan?

Weet jij alles van key exchanges met Diffie-Hellman, Elliptic Cruve Diffie-Hellman, RSA, welke bitgrootte je nodig bij welke exchange om aan je minimum te komen, welk type sneller is, welk type ondersteuning heeft in welke browser, waarom je waarschijnlijk geen RSA voor KX will gebruiken?

Weet jij alles van encryptie? Waarom doen velen AES256 terwijl AES128 meer dan genoeg is? Wat is het verschil tussen AES_CBC en AES_GCM? Waarom wil je waarschijnlijk geen CBC meer gebruiken?

Weet jij alles van digest/hashes/signing? Wat is er mis met MD2/MD5/SHA1? Hoeveel zekerheid krijg je met SHA384 t.o.v. SHA512?

Weet jij alles van SSL2/SSL3/TLSv1.0/TLSv1.1/TLSv1.2/TLSv1.3? Welke wil je absoluut vermijden, welke zijn nog veilig te gebruiken onder welke voorwaarden, welke zijn sowieso veilig? Welke browsers/mensen sluit je buiten als je alleen voor, zeg, TLSv1.3 kies?

Weet jij alles van DNS CAA, OCSP-stapling en andere mogelijkheden om wat meer te doen aan de wildgroei (en het vertrouwen in) CA's?

Ik ben het met je eens dat het an sich verkrijgen/hebben van zo'n certificaat niet zo moeilijk is. Maar een veilige configuratie voor je webserver, dat is mijns inziens absoluut geen sinecure. SSLlabs helpt goed, zeker, goede startplek om te weten wat er zoal bij komt kijken en steekwoorden te vinden om meer informatie te vinden waarom SSLlabs over iets moppert. Maar wil/moet je dan niet weten __waarom__ SSLlabs moppert? Als in: ik wil begrijpen wat de moppers zijn, zodat ik er zelf over kan oordelen. En, ja, dat moet je heel veel leren over de technieken en wiskunde erachter. Je moet een halve crypto-expert worden... En dat staat wel in schril contrast met jouw mening/zienswijze "Ik zie het probleem niet (...)

[Shamalamadindon]

Absoluut niet relevant tenzij je zelf je server draait en dan hoor je het te weten of in ieder geval te weten hoe je het op niet zoeken.

Daarnaast heeft Mozilla bijvoorbeeld een NGINX config generator.

[Belgar]

Dit alles is compleet niet relevant voor de basisvoorziening voor normaal gebruik. In het geval je een hoster gebruikt is deze vaak 100% verantwoordelijk voor bovenstaande. het is namelijk hun webserver. Als je onveilige score krijgt stuur je een mailtje en vraag je je hoster het op te lossen en als ze het niet serieus nemen, ga je naar een andere.

Voor meer geavanceerde gebruikers lees je je een uurtje in, zet je de recommended safe defaults en ben je ook klaar.

Van de experts kun je gewoon verwachten dat ze bovenstaande gewoon meenemen. Het is allemaal niet zo ingewikkeld.

[YoMarK]

Kolder. Als jij een site ergens laat hosten(bij 3-2-1degoedkoopstehostervannederlandtoppietoppie.nl) ben jij ZELF nog steeds de verantwoordelijkheid voor de(gelekte) data.

[HDoc]

Voor Let's Encrypt heb je echt geen systeembeheerder nodig. Tegenwoordig is niet veel moeilijker dan een vinkje in je backend aanklikken.

En dan nog: Google heeft een push richting HTTPS, dus als je de gebruikers van je site niet wil afschrikken en ook er voor zorgen dat je website vindbaar blijft lijkt het onontkoombaar je statische website onder HTTPS onder te brengen.

[Reactie gewijzigd door HDoc op 23 juli 2024 01:56]

[burne]

De penningmeester van de voetbalvereniging die ook de lijst met wedstrijdtijden op de site bijhoudt heeft wel degelijk een systeembeheerder nodig voor dat soort zaken. Je overschat de gemiddelde burger serieus als je denkt dat iedereen dat kan.

[jurri@n]

De penningmeester van de voetbalvereniging doet ook de hosting niet zelf, maar besteed dat uit aan een hostingprovider die ook dat certificaat voor hem kan regelen. Veel hosters hebben tegenwoordig ook Let's Encrypt als gratis dienstverlening bij hun hostingpakketten.

[Verwijderd]

Er zijn zelfs hostingproviders waarbij default lets encrypt aan staat.

[kozue]

Die penningmeester bouwt ook zelf z’n eigen statische pagina’s niet. Je hebt voor een eigen website altijd iemand nodig met verstand van zaken. En die kan best een vinkje bij z’n hoster aanvinken.

De enige manier om websites te bouwen zonder enige kennis van zaken zijn van die pakketten waarbij je de site gewoon via een cms bouwt, zoals wordpress. En die regelen dan ook de https wel voor je.

[bbob]

Een systeembeheerder dat klinkt zo mooi. Mijn vrouw lukt het ook een joomla website te updaten en ze is geen systeembeheerder. Daarnaast in die voetbalvereniging zal als ik mag gokken vast wel iemand zitten die het wel kan. Het is van een mug een olifant maken, eenmalig werk van minder dan 30 minuten, eerder 10 minuten, vinkjes aan, cms misschien op https zetten en klaar.

[Yggdrasil]

Ik vind dat je overdrijft. Vrijwel elke budgethoster activeert tegenwoordig SSL met een vinkje in cPanel o.i.d. Die penningmeester heeft ook zelf uitgezocht hoe hij zijn Excel of Google Docs bestand op de site kan zetten en het is echt niet moeilijker om dat vinkje te vinden.

Tuurlijk zijn er uitzonderingen en zijn er nog hosters die het niet aanbieden, maar dat aantal krimpt sterk en over enkele jaren heeft de marktwerking zijn werk gedaan.

[burne]

De originele vraag was anders:

wat heb je liever: een Joomla! vol malware met een EV-cert of een statische site zonder TLS?

Net op BNR: als er https voor staat kunnen hackers er niet bij

Dat soort onzin-uitspraken ga je dus krijgen.

[bbob]

Die systeembeheerder kost idd geld net als het onderhoud van een website en het update. Maar waar hebben we het hier over, paar tientjes per jaar. Bij sommige hosters is het een service en doen ze het voor je.

[pookie79]

Gratis is soms erg relatief. Ik ben bij mijndomein weggegaan want hosting werd 2x zo duur, maar voor dat geld dan kreeg ik dan 'gratis' https. (Letterlijk zoals ze bij mij de prijsverhoging goed praatte)

[Reactie gewijzigd door pookie79 op 23 juli 2024 01:56]

[Rex]

Iedereen noemt Let's Encrypt, maar je hebt ook StartCom, CloudFlare en WoSign.

Let's Encrypt is misschien wat moeilijk om zelf te regelen, maar je hebt allemaal sites zoals SSL For Free die je met behulp van tutorials helpt om een SSL certificaat werkend te krijgen.

Er is eigenlijk geen excuus meer om geen SSL certificaten meer te hebben. En al helemaal niet bij overheidswebsites.

[Reactie gewijzigd door Rex op 23 juli 2024 01:56]

[Yggdrasil]

Er is inderdaad meer keuze. Naast Let's Encrypt heb je inderdaad gratis certs bij CloudFlare (als je hun product gebruikt) en cPanel (als je hun product gebruikt). LE is voor zover ik weet wel de enige die onafhankelijk is van gebruikte software/platform.

WoSign and StartCom doen echter niet meer mee. Die certificaten worden niet meer vertrouwd wegens grove fouten:
https://arstechnica.com/i...-startcom-certs-for-good/
https://arstechnica.com/i...-threatened-web-security/

De voornaamste hindernissen lijken momenteel vooral politiek (bedrijven die denken dat EV nog meerwaarde heeft of zelfs dat SSL niet nodig is) en automatisering ("behind-the-firewall" implementaties waar geen automatische validatie mogelijk is).

[CyBeR]

Iedereen noemt Let's Encrypt, maar je hebt ook StartCom, [...] en WoSign.

Die sites recent nog bezocht?

[Verwijderd]

Zolang er geen formulier of input veld of persoonlijke url wordt gebruikt is het onzin (overkill) om https te tonen voor iets wat openbaar is. Maar het hoeft niets te kosten...

[Rex]

Zelfs als een website geheel statisch is, kan het goed zijn om HTTPS te implementeren. Een provider of overheid kan HTTP paginas aanpassen (om bijv. andere advertenties te tonen), dus zelfs daar kan HTTPS ervoor zorgen dat er geen MITM-attack voorkomt.

Het is een beetje ver gezocht, maar ja die "statische websites" waar jij het over had zijn ook best ver gezocht. Die bestaan al nauwelijks meer. Elke website heeft wel een zoekveld of contactformulier.

[Reactie gewijzigd door Rex op 23 juli 2024 01:56]

[mrmrmr]

Niet vergeten dat op sites ook bankrekeningnummers staan. Als je een rekening per email ontvang controleer je natuurlijk altijd of het rekeningnummer klopt. Toch?

[The-Priest-NL]

Onzin zie deze link
Voor de bescherming van je gebruikers is het inmiddels eigenlijk verplicht kost om https te hebben.

[Johan9711]

Ik ken dat artikel inderdaad.
Het enige wat je er potentieel mee voorkomt is een MITM attack, maar ik zie nog steeds niet wat hierbij een potentieel nadeel kan zijn voor een simpele statische website zonder kritisiche info

Ik moet er wel de kanttekening bij maken dat dit soort sites vandaag de dag erg zeldzaam zijn. Bijna elke site heeft tegenwoordig een contact form òf kritische info

[Yggdrasil]

Zonder HTTPS kan die statische website opeens stiekem toch dynamisch zijn zonder dat de bouwer dit weet. Er zijn zat voorbeelden van ISP's en luchtvaartmaatschappijen die reclames of trackers injecteren in alle niet-HTTPS verkeer. Dat vind ik volstrekt onacceptabel.

Daarnaast gaat om privacy. Degene die mijn netwerkpakketjes vervoert (ISP, gratis WiFi bij McDonalds of bijv. luchtvaartmaatschappij met in-air WiFi) hoeft niet te weten welke sites ik bezoek en wat mijn interesses zijn.

[The Zep Man]

Het enige wat je er potentieel mee voorkomt is een MITM attack, maar ik zie nog steeds niet wat hierbij een potentieel nadeel kan zijn voor een simpele statische website zonder kritisiche info

Het gaat niet om de site, maar om de client (in dit geval de browser). Die is kwetsbaar voor aanvallen zodra een verbinding wordt opgezet.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:56]

[Johan9711]

In jouw link lees ik enkel iets over gebruik van HTTP in Apt, niet op websites. Apt is natuurlijk een ander verhaal omdat de gedownloade content direct word uitgevoerd/geinstalleerd op de client.
Ik doelde uiteraard op statische website content in de vorm van bijv. tekst of een simpele afbeelding.

[Verwijderd]

dan ken je stegosploit waarschijnlijk niet. Is een exploit waarmee je virussen in foto's kan embedden.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 01:56]

[dehardstyler]

Dat is inderdaad een hele mooie en interessante tool, maar dat heeft verder natuurlijk niks te maken met wel of geen HTTPS.

[kozue]

Natuurlijk wel. Als je de foto via https ophaalt kun je er zeker van zijn dat er niet mee gerommeld is, terwijl met http een MITM gewoon die foto tijdens het ophalen aan kan passen. Scripts toevoegen in de html is ook triviaal. Aangezien de meeste mensen dom genoeg zijn om met allemaal onveilige wifi access points te verbinden (die door een hacker heel makkelijk op te zetten zijn) is https geen overbodige luxe meer voor zelfs de meest simpele statische pagina.

[dehardstyler]

Ahh jij hebt het hier over de overheidswebsites natuurlijk, dan heb je gelijk. Ik doelde meer op een malifide website, met die foto. Of bijvoorbeeld een embed naar een externe ( malafide ) website.

[kozue]

Malafide websites ga je niet oplossen met https. Je kunt ze zelfs voorzien van een EV certificaat als je wilt. Https is niet bedoeld om alle problemen om het web op te lossen maar om er voor te zorgen dat je een veilige verbinding met de server hebt waar niemand aan kan rommelen.

[Verwijderd]

nee klopt, was meer een reactie op "Ik doelde uiteraard op statische website content in de vorm van bijv. tekst of een simpele afbeelding." van @Johan9711. Ook statische content kan virussen bevatten. Voordeel van HTTPS is dat je al geen MITM via statische content kan initieren. Maar hoevaak dat zal is denk ik wel nihiel.

Als je googlet zie je dat er wel veel topics over MITM in combinatie met een foto over HTTP. Dus zo ongebruikelijk zou het waarschijnlijk ook niet zijn.

[The Zep Man]

In jouw link lees ik enkel iets over gebruik van HTTP in Apt, niet op websites. Apt is natuurlijk een ander verhaal omdat de gedownloade content direct word uitgevoerd/geinstalleerd op de client.

Je leest niet goed genoeg. Er zat een kwetsbaarheid in het redirectmechanisme van apt. Niet in de integriteitsverificatie van packages. Apt zal geen packages installeren zonder cryptografisch kloppende handtekening.

Verder is het principe hetzelfde. Browsers kunnen ook kwetsbaarheden bevatten die een MitM kan misbruiken. Het maakt hierbij niet uit wat voor site over HTTP bezocht wordt.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:56]

[Shamalamadindon]

Omdat men middels een MITM aanval makkelijk een formuliertje kan embedden waarmee om prive info gevraagd word bijvoorbeeld.

[xDinql3umz]

Ik ben een aantal jaar geleden de database van mijn MBO-school binnengekomen door zoiets. MITM met een onbeveiligde site (die overgens op een andere server stond dan de database). Deze eerste server had echter om de zoveel minuten contact met de database op server 2, en jawel met een account die zowat overal recht op had. Misconfiguratie? Dat zeker, maar met een Https cert had ik dit niet kunnen doen.

[xDinql3umz]

Er word ook wel eens in een database ingelogt, dus dit is dan mogelijk met een sinpele MITM. ik snap je link met een SQL injectie daarom niet echt.

Overgens wel handig om te melden: ik heb dit lek uiteraard gemeld en heb hier verder niks mee gedaan.

[Reactie gewijzigd door xDinql3umz op 23 juli 2024 01:56]

[jozuf]

de snelheidswinst die http/2 met zich meebrengt kan ook een goede reden zijn. Http/2 vereist een beveiligde verbinding

[CH4OS]

Toch is het makkelijker om eerst TLS/SSL uit te rollen en daarna zaken als HTTP/2 pas uitrollen. Beiden tezamen uitrollen hebben een te grote impact. Kun je het beste eerst TLS/SSL uitrollen, om de uitrol van HTTP/2 te vergemakkelijken, dan heb je immers ook de certificate chain op orde.

[Reactie gewijzigd door CH4OS op 23 juli 2024 01:56]

[Blokker_1999]

moet je de spec van HTTP/2 eens lezen. HTTPS is daarin geen vereiste. Deze kan dus perfect zonder werken. Wel hebben de grote browserbouwers, Google, Mozilla, Microsoft en Apple, beslist om HTTP/2 alleen te ondersteunen in combinatie met HTTPS.

[jozuf]

Thx, dat wist ik niet! Maar goed betekent dus dat het effectief gezien wel nodig is.

[CH4OS]

Ik wens je veel succes met het installeren van TLS/SSL op 185 websites. Heb je het vanavond klaar?

[MadEgg]

Nou, dat moet niet zo'n probleem zijn nee. Een minuut of 2 per website is ruim voldoende, dus met 6 uur ben je er wel doorheen.

[laptopleon]

Ik ben het met iedereen hier eens dat een certificaat zó geïnstalleerd is, maar ik ben vaak toch nog wel even zoet met het aanpassen van url’s van CSS bestandjes, afbeeldingen die niet in de database maar daarbuiten staan, goochel analytics bijwerken en dergelijke.

[MadEgg]

De oplossing: relatieve URL's gebruiken. Ik gebruik nóóit de domeinnaam, protocol oid van de website in links naar assets. Dat maakt je website veel te fragiel voor bijvoorbeeld dit soort wijzigingen. Is de domeinnaam wel noodzakelijk dan kun je altijd nog :// ipv http:// gebruiken, dan houdt de browser hetzelfde protocol aan als voor de content gebruikt is.

[laptopleon]

Ja, dat begrijp ik, in een ideale wereld werkt het meteen goed maar daar heb je nu weinig aan bij, een bestaande website die jaren geleden door een of andere handige Harry niet te moeilijk bij elkaar gesprokkeld is

[Blokker_1999]

Grapjas. Heb zelf vorig jaar ofzo terug de infra van 1 van mijn hobbyprojecten omgezet naar LE. Die infra, niet door mij opgezet, heeft iets van een 70 tal subdomeinen. Ben daar toch echt een dag mee bezig geweest door de complexe setup.

En achter sommige domeinen steekt dan wel een webapp die niet door een webserver wordt geserveerd. Mag je in de proxy gaan afvangen dat de .acme folder geredirect moet worden naar een andere locatie. Uiteindelijk ben je op zovele servers en locaties bezig dat de tijd gewoon lijkt weg te vliegen.

Vandaag zou ik gewoon met wat wildcard certs inderdaad op een uurtje klaar zijn, maar die bestonden toen nog niet.

[MadEgg]

Voor het grootste deel van de websites is het zo simpel als het vinkje 'SSL' en 'Lets Encrypt' aanzetten.

Aangezien de meest kritische overheidswebsites al overgezet zijn is de rest de restanten van kleine projectjes en daarmee voor het overgrote deel statische websites in plaats van complexe webapplicaties. Dat zou dus echt niet meer tijd mogen kosten.

Je kunt het zo complex maken als je zelf wilt, maar voor de meeste geavanceerdere applicaties, mits goed opgezet, kun je ook gewoon een HTTPS-proxy hangen die de SSL voor je regelt. En ook dan is het dus weer een paar klikken of commando's. Als de basis al brak is, tsja. Maar dan heb je sowieso technical debt die je dan wel langs de ene route danwel langs de andere route een keer tegenkomt en een hoop tijd kost.

[CH4OS]

Wanneer het geautomatiseerd is wel. Echter gebruikt de overheid geen tools of diensten zoals Let's Encrypt (en dat is maar goed ook in dit geval). Dan is het niet in twee minuten gefixed.

Let's Encrypt is een toffe en leuke dienst, maar niet voor (semi-)overheden, wat toch met nog veel (privacy) gevoeligere informatie van doen heeft.

[Reactie gewijzigd door CH4OS op 23 juli 2024 01:56]

[MadEgg]

Nee, zouden ze moeten doen. In plaats van een eigen certificaat-authoriteit eenhouden. Ik vind het maar niets dat de overheid zelf certificaten kan uitgeven, dat haalt het hele idee van de certificaat-gebeuren sowieso onderuit.

[CH4OS]

Je vindt dat ze dat zouden moeten doen. Ik ben het daar niet mee eens, puur vanwege het feit dat een derde partij wat verder niets van doen heeft met onze overheid zomaar de geldigheid van die certificaten in kan trekken. Aan de andere kant zit Diginotar nog vers in het geheugen, dus op zich is het ook weer iets wat je niet moet willen inderdaad. Maar beiden hebben voor- en nadelen.

In TLS / SSL is de beveiliging ook maar zo sterk als de zwakste schakel en sterk gestoeld op vertrouwen, dat zul je altijd hebben en houden, welke Certificate Authority er ook achter zit. Helemaal 100% waterdicht krijg je het nooit.

[Power2All]

Allemaal op HTTPS met Wordpress

Maar serieus, ik heb wat overheids website code gezien, en dat was op zijn allerminst gezegd, best wel, mja, zal ik het zo maar zeggen, niet "geweldig".
Er zitten een paar tussen die Wordpress gebruiken met weet ik wat al niet aan 3rd party modules.
Ben dus beetje huiverig hoe met belangrijke zaken omgegaan wordt.

Al met al, er zijn overheids organisaties die het helemaal omgegooid hebben, en gebruik maken van degelijke en moderne toepassingen, waarvan ik wel een duimpje omhoog kan geven, maar goed, het is nog steeds zo dat iedere gemeente hun eigen website hebben en beheren, waar de een toppie is en de andere ronduit belachelijk slecht is.
Hoop dat dit ooit in de toekomst tot een geheel gaan worden in een groot netwerk waar er 1 organisatie over de website gaat, maar dat zal nog wel lang duren.

[Reactie gewijzigd door Power2All op 23 juli 2024 01:56]

[Verwijderd]

"Maar serieus, ik heb wat overheids website code gezien, en dat was op zijn allerminst gezegd, best wel, mja, zal ik het zo maar zeggen, niet "geweldig"."

Ik zwerf al 20 jaar in het bedrijfsleven rond en ik kan je zonder overdrijven melden dat ik nog nooit ook maar een gezonde, normale codebase heb gevonden.

[Power2All]

Yep, het is een zeldzaam iets, vooral omdat er net zoals bij banken bijvoorbeeld, er weinig was uitgegeven voor de IT afdeling. Gelukkig veranderd dat langzaam nu, maar ja, het heeft vooral te maken met de budget die is apart gezet hiervoor, en welke mensen ze erop ingezet hebben.

[djiwie]

Al met al, er zijn overheids organisaties die het helemaal omgegooid hebben, en gebruik maken van degelijke en moderne toepassingen, waarvan ik wel een duimpje omhoog kan geven, maar goed, het is nog steeds zo dat iedere gemeente hun eigen website hebben en beheren, waar de een toppie is en de andere ronduit belachelijk slecht is.

Net als in het bedrijfsleven dus.

[red123nax]

Ik vind dat HTTPS wel een beetje overrated is in dit bericht. Ze hebben dan https, maar dat betekent niet dat ze niet vol bugs zijn of dat ze goed getest zijn.

[Znorkus]

Dat is inderdaad jammer. Onderscheid tussen middelen en doel is komen te vervallen: het doel is dat overheidswebsites volgens best common practice / best informed practice veilig gehouden worden maar wat er nu gebeurt is 'oh we moeten https installeren van hun'. En de rest blijft liggen.

[MvGroenigen]

Vanmorgen op de radio "90% van de overheidswebsites is nu veilig omdat ze https gebruiken"
Onzin ten top.

https zorgt ervoor dat je heel heel heel moeilijk afgeluisterd kan worden. meer niet

Als 2 Hollanders in een oorlogsgebied lopen waar niemand anders nederlands spreekt, dan kan niemand ze daar misschien afluisteren. Maar om dan te zeggen dat ze hierdoor beschermt zijn tegen kogels, messen en bommen is natuurlijk totaal idioot. Maar dit is wel wat overheid en veel pers op dit moment als verhaal vertellen.

[The Zep Man]

"Bijna 90 procent van overheidswebsites maakt gebruik van https"

Kan je ook uitleggen als:
"Meer dan 10 procent van overheidswebsites maakt geen gebruik van https"

Ik heb even de HTTP-only lijst doorgenomen. Het gros betreft prutsites die gewoon offline gehaald kunnen worden zonder dat iemand ze zal missen. Op deze lijst staat overigens effectiefarmoedebeleid.nl. Ironisch.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:56]

[burne]

Op deze lijst staat overigens effectiefarmoedebeleid.nl. Ironisch.

Een of ander verlaten project uit 2016. Wellicht geen budget meer voor om naar de platformsite van AZ te verhuizen.

[DJMaze]

Valt onder overheid ook alle gemeentes?
Want vorig jaar (ook al was het https) was het goed mis bij een gemeente.
De DPO was al helemaal een hopeloos persoon zonder kennis en maar 1 dag per week aanspreekbaar.

Dan is alleen een controle voor https of niet maar een zinloos rapport in mijn opinie

[InjecTioN]

Wauw, dat voldoet dus ook echt absoluut nog niet aan een simpele veiligheids-standaard. De overheid heeft voor overheids-instanties een nieuwe certificate authority vanuit KPN in het leven geroepen om dergelijke beveiliging mogelijk te maken (bijvoorbeeld KPN PKIoverheid Organisatie CA - G2). Het is dus ook schrikbarend dat, na de relatief lange periode dat zoiets in het leven geroepen is, een simpele omzetting naar HTTPS nog niet gerealiseerd is. Dit is een zeer kwalijke zaak.

Wanneer men op https://internet.nl of bij SSLlabs een check laat doen, kan men simpelweg zien waar de beveiliging van alleen al de domeinnaam en de connectie tussen browser en server tekortkomingen bevat.

Zo moeilijk kan het toch niet zijn wanneer de ICT binnen een bedrijf zoals Nederland miljarden aan euro's blijkt te verbranden? Vooral wanneer de Certificate Authority in directe verbinding zou zijn en tevens alleen voor overheid-gerelateerde zaken in het leven geroepen zou zijn.

@burne correct. Het was slechts een voorbeeld.

[Reactie gewijzigd door InjecTioN op 23 juli 2024 01:56]

[burne]

KPN is niet de enige die onder de Staat der Nederlanden-root hangt. Een lijst met alle PKIoverheid-CA's vindt je op https://cert.pkioverheid.nl/ (Ja, dat is de lijst waar ook ooit Diginotar op stond..)

[CAPSLOCK2000]

Laat ik van de gelegenheid gebruik maken om de overheid een compliment te maken. Ondanks alle horrorverhalen doet de overheid het relatief goed wat ICT betreft. Ik denk niet dat er veel andere sectoren zijn die 90% HTTPS halen, terwijl er maar weinig zijn die zoveel eisen en zo'n grote schaal hebben als de overheid.

(Niet dat er niet nog een hoop te verbeteren is en er veel fout gaat, maar elders is het nog erger).

[raiders]

12% te weinig...

[FireDrunk]

Onzin, het is echt niet voor elke site _nodig_ dat er gebruik gemaakt wordt van HTTPS. Genoeg use-cases waar het niet handig is, en zelfs performance kost. Daarom zegt zo'n percentage ook geen reet.

Het gaat er om of alle site die vertrouwelijke content bevatten met HTTPS beveiligd zijn. Maar dat is niet mooi in 1 getalletje uit te drukken, dus dan doen we dat in NL maar niet..

[InjecTioN]

HTTPS is nodig voor de beveiliging tussen server en client. De graad van het certificaat geeft aan dat de aanvrager op het moment van aanvraag toegang heeft tot de webserver, email-adres uit de whois, dns-records (kunnen wijzigen), telefoonnummer uit de whois wordt opgebeld om te controleren dat de aanvrager legitiem is, en de bedrijfsnaam wordt gecontroleerd.

Het is dus feitelijk een certificaat van vertrouwen, waarmee men kan aantonen dat er tijdens een moment in het verleden (ten tijde van het verschaffen van het certificaat) bovenstaande gevalideerd is.

Er valt dus zeker wel te zeggen dat een pagina mèt een geforceerde HTTPS-verbinding EN mèt certificaat dat uitgegeven is door een gerenommeerde Certificate Authority, mogelijk een stuk veiliger is dan een pagina zonder HTTPS.

De afkomst van het certificaat zegt ook zeker iets over de legitimiteit van de bron (website), wat ook zeker telt.

Dus nee, zeker geen onzin.

[jrswgtr]

De afkomst van het certificaat zegt ook zeker iets over de legitimiteit van de bron (website), wat ook zeker telt.

Een niet-legitieme bron kan toch ook een "gerenommeerd" certificaat kopen? En een legitieme bron kan ook een self-signed certificaat hebben.

Zegt helemaal niks

[InjecTioN]

Een overheidsinstantie dient geen self-signed certificaat te hebben. Dat wordt namelijk afgevangen door hun eigen Certificate Authority die door bijvoorbeeld KPN opgezet is.

Een niet-legitieme bron kan deze certificaten niet aanschaffen omdat zij hier gewoon niet de juiste validatie-route voor kunnen doorlopen.

Kortom:
Wanneer een niet-legitieme bron (website) een certificaat bevat dat uitgegeven is door een Certificate Authority dat opereert in opdracht van de overheid, dan is de Certificate Authority gecompromitteerd en is de Certificate Authority niet meer legitiem. Alle pagina's zullen vervolgens (zeer rigoreus) down gebracht moeten worden omdat de inhoud van die pagina's mogelijk gecompromitteerd kan zijn.

Er zal een nieuwe Certificate Authority opgezet moeten worden, met nieuwe certificaat-uitgiftes van dien.

Het zegt dus beduidend wel wat.

Een Let's Encrypt certificaat heeft overigens ook validatiemethodes. En een self-signed certificaat wordt niet standaard vertrouwd door browsers, waardoor het issue afgevangen is.

[Reactie gewijzigd door InjecTioN op 23 juli 2024 01:56]

[Niemand_Anders]

Helaas zijn er voldoende SSL certificaat resellers welke de controle taak niet goed uitvoeren. Zo zijn er resellers waarbij je in plaats van een email (vaak uit een vaste lijst) ook voor een telefonische bevestiging kunt zorgen in combinatie met een afwijkend emailadres..

Deze partijen 'verkopen' de certificaten voor voor het versleutelen van de informatie en niet zozeer om de identiteit van de website te garanderen. Juist omdat die laatste taak steeds vaker wordt verzuimd is met met de EV-ssl certificaten gekomen.

Met dergelijke constructies is het mogelijk een certificaat aan te vragen voor een domein welke je niet in bezit hebt of waarvoor je het beheer moet uitvoeren. In principe kun je met alleen zo'n certificaat erg weinig.

Echter als jij een phishing website opzet voor www.ing.nl, moet je ook nog zorgen dat verkeer ook nog naar jouw server wordt doorgestuurd. Het enige wat daarvoor nodig is, is dat de criminele organisatie een eigen open DNS server gaat draaien (vergelijkbaar met Google - 8.8.8.8/8.8.4.4) en dat je middels malware de DNS settings van (Windows) computers aanpast zodat ze voortaan van jouw DNS servers gebruik maken..

DNS wordt allang niet meer alleen gebruikt voor het opzoeken van een IP bij een hostname. DNS wordt ook gebruikt voor bijvoorbeeld DNSSEC, DKIM, SPF, ARC, PKI infrastructures (pubkey rr's) en service discovery. Door het overnemen van de DNS server kun je veel moderne beveiligingstechnieken omzeilen en 99% van de mensen zal niet regelmatig de settings van hun netwerkkaart controleren. Dat gebeurt in de regel alleen als met problemen heeft met internet..

Let's encrypt controleert overigens NIET de identiteit van de aanvrager van het certificaat. HTTP validatie voor servers met SN (meerdere certificaten op een enkel IP) is sinds begin dit jaar disabled. Daardoor zijn veel aanvragers beperkt tot 'validatie' via DNS. Daarmee controleren zij niet jouw identiteit, maar slechts of jij toegang hebt tot de DNS en opdracht kan geven om de DNS te laten aanpassen..

Let's Encrypt (maar ook veel andere ssl resellers) weerhoud mij niet om een certificaat aan te vragen voor www-ingbank.nl (phishing url), terwijl ik geen enkele relatie heb met de ING bank. Daarom tonen browsers ook geen (groen) slotje meer bij een SSL (TLS) verbinding met een standaard certificaat, maar doen ze dat eigenlijk alleen nog bij een EV-SSL certificaat..

Daarom kan HTTPS ook voor een schijnveiligheid zorgen. Het certificaat zorgt alleen voor de encryptie, maar je weet niet naar WIE jij de informatie encrypted stuurt..

[InjecTioN]

Correct. Een Extended Validation Certificate is inderdaad de enige manier waarop identiteit van een website gevalideerd kan worden. De naam zegt het ook al. De rest van de certificaten met een mindere mate van validatie (enkelvoudig en puur gebaseerd op beheer van de website) hebben eigenlijk een gelijk "gewicht" van certificering als een Let's Encrypt. Dat dient puur als encryptie tussen server en client.

[FireDrunk]

Zucht, ik zeg helemaal niet dat HTTPS onzin is, ik zeg dat 100% HTTPS onzin is. HTTPS is echt heel belangrijk, zeer zeker, maar niet krampachtig voor alles. Er zijn echt wel use-cases te verzinnen waar voor een specifieke API of specifieke applicatie, het leveren van grote bulk data over HTTP een prima oplossing kan zijn.

Krampachtig 100% willen is onzin, HTTPS zelf is zeker belangrijk.

[InjecTioN]

In een tijd als deze, waarin fake-news een ding is, zullen bronnen aantoonbaar moeten zijn. Overheidsinstanties zullen aan moeten kunnen tonen dat hun websites de juiste bronnen van informatie zijn. Dat kan alleen met behulp van een certificaat van een overheids-CA, zoals KPN deze nu verschaft voor overheidsinstanties.

De "use-cases" die je noemt gelden alleen wanneer bijvoorbeeld "Jannie van de overkant" een persoonlijke website opzet om te praten over d'r poezen en wat die de hele dag uitvreten. Dan hoeft er inderdaad geen HTTPS-verbinding te zijn, laat staan een certificaat van een gerenommeerde CA. Wanneer er echter informatie verschaft wordt vanuit een overheidsinstantie, die betrekking heeft tot de maatschappij, en die op waarheid berust moet zijn, dan lijkt mij een HTTPS verbinding met een door overheids-CA uitgegeven certificaat een minimale vereiste voor een dergelijke pagina.

[FireDrunk]

En daar ben ik het gewoon 100% mee eens (pun intended ).
Jij noemt zelf al 'mitsen en maren' zoals 'betrekking heeft tot de maatschappij'. Laat nou niet elke overheidswebsite voor de maatschappij zijn. Sommige zijn namelijk voor hun zelf

Het enige wat ik probeerde te zeggen is dat krampachtig 100% halen niet handig is. Er is altijd nuance nodig. Voor de rest ben ik het grondig met je eens

[burne]

In een tijd als deze, waarin fake-news een ding is, zullen bronnen aantoonbaar moeten zijn.

In dat geval ben je vast tegen Let's Encrypt-certificaten. Die geven bezoekers de schijn van legitimiteit want er staat een groen slotje boven maar zeggen helemaal niets over de bron van de informatie.

[InjecTioN]

@burne, Zie de 2e alinea in mijn reactie. It's all about the use case.

Ook bij Let's Encrypt wordt er overigens gebruik gemaakt van validatie methodes. Een dergelijk certificaat wordt dus ook pas uitgegeven wanneer domeinnaam voldoet aan bepaalde eisen. Dat wilt niet zeggen dat mijn.overhied.nl niet gevalideerd kan worden. Maar dat wilt wel zeggen dat, wanneer je het certificaat controleert door op het slotje te klikken, en men ziet dat het een gratis Let's Encrypt certificaat is, dat de afkomst van informatie dan beduidend twijfelachtig is. Inloggen is dan dus ook niet aan te raden.

En zoals @FireDrunk overigens ook al aangeeft:

Er is altijd nuance nodig.

[djiwie]

Die use cases van jou kunnen nooit in dit onderzoek gezeten hebben lijkt me. Het ging om _overheidssites_ die gemeten zijn. Geen API's of applicaties.

[Blokker_1999]

Dan zou ik zeggen: noem eens wat situaties op waarin, volgens jou, http voldoende is en dan zullen we eens kijken of er tegenargumenten zijn.

[YoMarK]

HTTPS is zeker wenselijk, maar echt niet noodzakelijk in alle gevallen. HTTPS is zeker in de huidige tijd geen verklaring/verzekering van legitimiteit van bron.

Eerst wat feiten:
- PKI overheid zijn EV, en stervensduur. Ze zijn nog duurder dat EV certificaten van de grote root CA's. Ja, voor de overheid zelf ook. Ze dienen zeker een doel, maar voor een simpele tijdelijke site zijn ze overkill.
- Webbrowsers en daarmee de mensen die ze gebruiken maken al nauwelijks meer onderscheid tussen EV en normale certificaten(kleur/vorm van slotje in de adresbalk etc..). Volgens zie je in Chrome helemaal geen verschil meer tussen een EV en een lets encrypt certificaat. De "burger" zonder technische know-how heeft er niets aan.
- Lets encrypt is gratis. Kosten zijn geen reden meer voor "the bad guys" geen HTTPS te gebruiken
- Lets encrypten validatie is zeer basaal. Makkelijk te regelen als je als hacker al toegang hebt tot een webserver en/of DNS.

De praktijk(ik werk zelf bij de overheid) is dat er b.v. ergens een viaduct wordt gebouwd. Ze willen voor burgers/bedrijven/... een site maken(waarom dat niet op de hoofd site van de organisatie kan, geen idee, maar ik ben ook geen Communicatie-medewerker), maar er moet dus een site komen. We hebben het hier over een site die een paar jaar blijft bestaan, waar statische content op staat(dus HTML). Geen formulieren(kunnen b.v. persoonsgegevens verstuurd worden), geen gevoelige gegevens, geen backend, niets dynamisch, gewoon een site met het projectplan en contactgegevens. Wij kiezen er altijd voor om voor een paar tientjes een certificaat te kopen(ipv duizenden euro's en weken wachttijden werk voor een PKI overheid certificaat), maar HTTPS heeft in dit geval vrijwel geen toegevoegde waarde. Als er goed over nagedacht is: geen issue.
Die 10% betreft vaak van dit soort sites. Al zitten er vast tussen die echt gewoon veel beter geregeld hadden moeten worden.

[WokeBroke]

Toch ga ik er bij die 88% ook van uit, dat de overheid precies kan zien op welke pagina ik zit.

[IStealYourGun]

Uiteraard, dit is ook totaal niet het doel van https. Het doel is dat je op een veilige manier gevoelige gegevens kan uitwisselen met die overheid zodat dit niet kan worden afgeluisterd op, bijvoorbeeld, een onbeveiligd netwerk.

[equit1986]

maar dat is toch logisch? Tweakers weet dat ook. Jij logt in met je account en ze kunnen je gewoon tracken hoor. Daar zijn tools voor die dat heel mooi kunnen, ze kunnen zelfs je browsesessie RECORDEN en afspelen!(https://mopinion.com/11-v...replay-tools-an-overview/)

[batjes]

Natuurlijk, want de webserver moet wel weten welke pagina jij bezoekt.