Kwart van de websites in Nederland maakt geen gebruik van beveiligde verbinding

Volgens beveiliger Cybersprint beschikt 27 procent van een groep veelbezochte Nederlandse websites niet over een ssl- of tls-certificaat. Vooral in de zorgsector lijken veel websites nog geen gebruik te maken van de encryptie.

Cybersprint deelde zijn resultaten met Nu.nl en de Telegraaf. Het bedrijf keek naar de top miljoen websites binnen het .nl-domein en nam daar een greep van 6645 websites uit. Bij 4900 van deze websites was https correct geïmplementeerd, maar bij ongeveer 1800 websites was er geen sprake van een beveiligde verbinding. Wanneer er enkel naar de top honderdduizend wordt gekeken, maakt slechts een op de zeven websites geen gebruik van ssl of tls.

Hoewel Cybersprint bij zijn onderzoek geen onderscheid tussen afzonderlijke sectoren heeft gemaakt, geeft Cynthia Schouten, hoofd informatiebeveiliging bij Cybersprint, wel aan dat financiële websites voorop lopen in het toepassen van https en de landelijke overheid ook goed scoort. In de zorgsector is de beveiliging volgens Schouten echter nog zorgwekkend.

Het aantal websites dat gebruikmaakt van een beveiligde verbinding, lijkt gestaag toe te nemen. Vorig jaar maakte SIDN bekend dat 390.000 Nederlandse websites gebruikmaken van ssl of tls, waaronder de helft van alle webwinkels. Veel van deze websites maken gebruik van een gratis certificaat van Let's Encrypt.

Reacties (197)

[DonJunior]

Anderzijds.. is het nodig om een SSL certificaat te gebruiken als men geen formulier hoeft in te vullen? *vraagteken
Noem een informatieve website als Wikipedia.. als je daar alleen leest voegt een SSL weinig toe toch?
Zodra er echter gegevens over een lijntje terug naar de server gaan lijkt me minimaal SSL wel benodigd ja. Of mis ik hier een cruciaal iets? *vraagteken, als in, oprechte vraag

[Jay-v]

Ja dat is nodig. Troy hunt legt het hier prima uit: https://doesmysiteneedhttps.com

HTTPS protects more than just form data! HTTPS keeps the URLs, headers, and contents of all transferred pages confidential.

Zo kan je provider (en heel veel andere) bijvoorbeeld zien dat je Wikipedia bezoekt, maar met https kunnen ze niet zien welke wiki's je bekijkt. Deze informatie staat namelijk in de http headers.

[kodak]

Nodig is een veel te stellige verwoording. HTTPS heeft voor en nadelen.
Troy Hunt 'vergeet' uit te leggen waarom het niet nodig is en wat de negatieve gevolgen zijn.
Als je in het kamp voor of tegen zit lijkt er alleen nog maar te gelden wat het eigen gelijk kan bevestigen. Beveiliging is het maken van afwegingen. En alle mooie woorden van welk kamp ook, als het niet meer gaat om die afweging dan kan het ook niet gaan om wie gelijk heeft en of het nodig is.

[pindab0ter]

Waarom is het niet nodig en wat zijn de negatieve gevolgen? Waar kan ik daar meer over vinden?

[GekkePrutser]

Een van de nadelen zijn extra load voor de servers voor alle crypto. En het omgaan met 'mixed' content als mensen zelf plaatjes deeplinken in bijv. forums, naar niet-HTTPS site (dan krijg je de mixed content warning van je browser)

Daarom heeft Tweakers het ook pas laat gedaan als ik het me goed herinner (het inloggebeuren was al SSL, maar dat heeft alsnog niet zo heel veel zin als je gewoon de sessioncookie in plaintext kan stelen Dus ben wel blij dat ze het nu wel hebben.

Ik heb trouwens nooit meegekregen hoe ze dat met die mixed content opgelost hebben.. Maar ik heb nog nooit zo'n warning gezien. Misschien zelf gecached?

Maar verder ben ik het helemaal eens met hem hoor. Als ik een paar jaar geleden in de trein of een hotel wifi zat te sniffen, zag je echt alles voorbij komen. Nog makkelijk aan mensen te koppelen ook omdat veel mensen hun telefoons "Jan de Boer's iPhone" noemen. Plus dat je dan allerlei shit kan injecteren natuurlijk als je kwaad wil (deed ik zelf niet, ik deed alleen met NetworkMiner een beetje rondsniffen).

De zichtbaarheid van dat dataverkeer is nu een heel stuk minder geworden. En dat is voor iedereen goed.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 23:50]

[Verwijderd]

De extra load is verwaarloosbaar. Alle crypto-protocollen die gebruikt worden zitten ingebakken in de CPU. Kost niks.

Mixed content voor forums is een dingetje, maar hoeveel procent van de website is nou een forum? Tweakers heeft het opgelost door er een proxy tussen te plakken.

[GekkePrutser]

Ja weet ik, dat zei ik hieronder ook al. Maar het is niet helemaal gratis, de handshake (en key exchange bij PFS) kost ook tijd, en er blijft nog werk dat de CPU zelf moet doen, de AES versnelling betreft alleen de 'rounds' van het algoritme maar het geheel omvat meer. Bovendien is het RSA gedeelte vrij zwaar en dat is helemaal niet hardwareversneld. Gebeurt wel maar eenmaal per verbinding, dat wel.

Dus ik vind wel dat het als nadeel gezien mag worden. Ik vind het persoonlijk ook geen reden om het niet te doen. De voordelen zijn veel te groot. Maar als je een website op het randje van je capaciteit runt bij pauperhosting ofzo, dan kan ik me wel voorstellen dat je er problemen mee hebt.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 23:50]

[Verwijderd]

In deze tijd is het echt een compleet non-argument. Zelfs de Apple Watch heeft een dual core processor.

[GeroldM]

Goed dat netwerk I/O (input/Output) door de CPU geregeld word. Oh wacht...dat gebeurt dus niet. En dan merk je wel degelijk dat websites trager worden door HTTPS.

Begrijp me goed, de extra veiligheid is die vertraging wel waard. Maar als je jezelf blindstaart op CPU rekenkracht alleen, dan kom je toch echt bedrogen uit.

Netwerk I/O, bestand I/O, geen enkele vorm van I/O wil je uitvoeren via wat voor model CPU dan ook afhandelen. Heel veel Windows apparatuur maken zich er goedkoop vanaf door dat "trucje" uit te halen.

En zolang alle I/O valide is kan het ook vrij probleemlees via deze manier worden afgehandeld. Wanneer dit niet het geval is, dan kom je er wel achter hoeveel extra CPU resources worden verkwanseld. Dan gaat het met name over interrupts waarvan een CPU er maar een beperkt aantal kan afwerken, ongeacht het aantal kernen in de processor en op welke snelheid deze werken.

Als je in een werelddeel woont waar internettoegang (nog) niet zo goed geregeld is, dan merk je dus echt wel hoe lang het wel kan duren voordat die TLS verbinding eindelijk is opgezet en de gevraagde content daadwerkelijk naar mijn computer word gestuurd.

Om een voorbeeld te geeven: laatst opnieuw een OPNSense router opgezet. Zelfs voor interne LAN toegang tot de web-interface HTTPS geactiveerd. FireFox en Chrome doen er vaak meer dan 15 seconden over om die web-interface te openen.

Opera daarentegn, opent deze HTTPS web-interface in een seconde of minder (niet dat je denkt dat er een probleem in het netwerk zit, WireShark geeft me hierin gelijk). Als test de web-interface even beschikbaar gemaakt via HTTP en alle browsers openen de interface binnen een seconde.

Nogmaals, de extra veiligheid is het wachten wel waard, maar ga nou niet zeggen dat HTTPS niets uitmaakt, zeker als het over minder stabiele internetlijntjes moet via browsers die minder goed met foutafhandelingen kunnen omgaan.

[Reactie gewijzigd door GeroldM op 22 juli 2024 23:50]

[johnkeates]

En toch maakt het geen zak uit, niemand lijkt het te merken, er is vooral steeds zuinigere en krachtigere hardware en de PUE wordt steeds beter. In plaats van HTTPS niet te doen om dat je mischien 0.1% meer cycles gebruikt kan je beter je software optimaliseren en daar 10% winst uit halen waar je 10x HTTPS in kan proppen. HTTPS is wel het minste van je problemen, de kosten en complexiteit is zo laag dat als iemand HTTPS een probleem vind ze misschien eerst even naar hun CMS van merk XYZ moet gaan kijken...

[Sysosmaster]

De mixer content is opgelost door tweakers door een transparency https proxy oplossing te gebruiken. (Als ik het mij goed herinner van de post)

[Jeoh]

Extra load door crypto? In 2012 misschien, AES-NI is tegenwoordig gemeengoed.

[GekkePrutser]

AES-NI betekent niet zonder overhead. Het verlicht het zwaarste gedeelte van AES, niet alles. En bovendien gebruikt SSL ook asymmetrische crypto zoals RSA of Diffie Hellman en dat is helemaal niet versneld.

[.oisyn]

het inloggebeuren was al SSL, maar dat heeft alsnog niet zo heel veel zin als je gewoon de sessioncookie in plaintext kan stelen

Nou nou, dat is wel enorm kort door de bocht. Het kan mij weinig boeien of mijn tweakers sessie wordt gekaapt. Het kan mij meer boeien als mijn wachtwoord wordt gestolen (goed, dat kan mij ook niet boeien want die is toch uniek voor tweakers, maar you get the point). Bovendien kun je de sessie locken aan een ip, wat het gebruik van een gestolen sessie een stuk lastiger maakt.

Ik heb trouwens nooit meegekregen hoe ze dat met die mixed content opgelost hebben.. Maar ik heb nog nooit zo'n warning gezien. Misschien zelf gecached?

Er zit een proxy tussen die non-http content idd fetcht en cachet.

[Reactie gewijzigd door .oisyn op 22 juli 2024 23:50]

[GekkePrutser]

Het maakt jou misschien niets uit maar het is natuurlijk heel makkelijk om met dat cookie even wat flauwe shit op de frontpage te dumpen en jouw account te laten bannen. Zo makkelijk dat het door een scriptkidide met een sniffer of een pineapple gedaan kan worden. Zo makkelijk moet dat gewoon niet zijn.

Locken aan een IP kan bij Tweakers wel, maar werkt juist niet in het scenario waar je vatbaar bent voor dit soort aanvallen. Als je op een open WiFi zit, is de aanvaller namelijk aanwezig op hetzelfde netwerk en dus hetzelfde IP.

Dus ik ben wel blij dat echt alles nu https is.

[Kevinp]

de website van de lokale sportclub dan. Waar vooral informatie op staat.

Tja tuurlijk is HTTPS eigenlijk nodig voor de persoon(en) die inloggen. Maar voor het kijken op we website ga je toch geen geld uitgeven om een SSL certificaat te krijgen. Lijkt mij zwaar overbodig.

[djwice]

Kost niets:
https://certbot.eff.org/

Of je doet het via een CDN die je voor de website hangt, kom je ook nog hoger in google; voor die euro per maand vind ik het raar als een sportclub geen https gebruikt.

[Reactie gewijzigd door djwice op 22 juli 2024 23:50]

[mkools24]

Cloudflare is zelfs gratis.

[Peetz0r]

Cloudflare is inderdaad gratis, maar ook best wel eng.

http://cryto.net/~joepie9...dflare-we-have-a-problem/

https://www.troyhunt.com/...lthy-security-absolutism/

Voor die sportclub wil je gewoon een fatsoenlijk webhostingpakket bij een normale (liefst nederlandse) hostingtoko, met SSL. Dat is wellicht niet gratis maar hallo, je bent een club met betalende leden. Daarnaast heb je ook gewoon de verplichting (AVG, maar daarvoor ook al) om dit goed te regelen.

En sinds Letsecrypt een ding is, is dit goedkoper dan ooit. Tientje per maand en je bent klaar! Als dat buiten je budget valt, want doe je dan als er een voetbal kwijt raakt?

[Eldunari]

Ik ben lid van een studenten vereniging die al hun inkomsten krijgen van de ongeveer 100 betalende leden. Die betalen maar liefst €25 per jaar. Dan is €120 per jaar toch een flinke uitgave.
Bij onze website vul he nergens informatie in, dus kun je mij vertellen dat we deze uitgave toch moeten doen?

[Sysosmaster]

Ik zie de volgende opties voor jullie.

• vraag je onderwijs instelling om een tls certificaat beschikbaar te stellen
• je vraagt sponsoren om een tls certificaat te sponseren
• je stipt met verspreiden van misinformatie en installeer een Lets encrypt certificaat via certbot of gebruik caddy server om het geheel automatisch te laten gaan.

[xDiglett]

Die artikelen zijn wel een beetje outdated. troyhunt.com gebruikt op dit moment zelf Cloudflare.

[djwice]

Troy Hunt lijkt in jou link just aan te bevelen CloudFlare te gebruiken:
https://www.troyhunt.com/...oushouldbeusingcloudflare

En geeft aan dat hij echter vindt dat je nog meer beveiligingsmaatregelen neemt.

Maar waarom een NL-toko? Er zijn diverse bedrijven met aparte EU based entiteit (Microsoft, AWS en vele anderen), die prima binnen de AVG (in engels is dat GDPR) kunnen werken.


Wat ik zie bij cloudflare is dat ze echt snappen waar ze het over hebben, lees hun blog over DNSsec of over TLSv1.3 of gewoon over http/2. Ze zijn vaak de eerste die het implementeren en lopen daarin ver voor op andere partijen: DNSsec bijvoorbeeld staat zelfs bij veel niet Nederlandse providers niet eens aan voor hun eigen domein en TLSv1.3 draaien de meeste niet eens in beta/pre-view modus. En bij een provider heb ik zelfs zelf moeten uitleggen wat HTTP/2 was, hoe ze het konden optimaliseren, wat voor hun het voordeel was én wat het voor mij als klant zou brengen, 9 maanden later kreeg ik het eindelijk, helaas nog zonder HTTP/2 push... en wat dacht je voor ondersteuning voor Brotli compressie? De lijst gaat maar door

[Reactie gewijzigd door djwice op 22 juli 2024 23:50]

[tom.cx]

Geld uitgeven? Daar is rekening mee gehouden. Gewoon Lets Encrypt gebruiken. Gratis SSL. Met certbot kan je dat ook nog eens goed automatiseren. Elke drie maanden automatisch een nieuw certificaat. Helemaal top.

[polthemol]

ik heb gisteren toevallig een servertje thuis op https / certificaat overgezet: 5 hele minuten, kosten waren 10 euro voor 2 jaar (had eigen domein nodig).

[timvisee]

Daarbij word het voor hackers die een man-in-the-middle uitvoeren, op een gedeeld netwerk, bijvoorbeeld niet meer mogelijk malafide content je injecteren in HTTP pagina's die je binnentrekt in je browser.

[Verwijderd]

Met alle respect voor Troy Hunt hoor, maar ik wordt wel een beetje moe van die man. T`is zijn levensmissie geworden terwijl ik denk. Als het allemaal zo erg is laat dan Apache/IIS/Nginx eens wat aan hun webserver software doen en het gewoon in 1 klik uitzetten. Nu moet je url rewrites gaan maken en en moet je mensen gaan vertellen dat het zou kunnen zijn dat niet al hun content https is ( ssl fixers bestaan niet voor niks). Certificaten moet je zetten op de website alhoewel dat makkelijk gaat met letsencrypt. Maar alsnog zet je niet zomaar een ssl website op.

[J0HAN]

Reverse proxy ervoor... klaar...

[djwice]

Eh een bezoekje hier:
https://mozilla.github.io...tls/ssl-config-generator/

paar klikken, copy past en je config is op pijl.
Dan nog de stapjes volgen op https://certbot.eff.org/ en pats je site is veilig geconfigureerd.

Paar minuten klik en copy-past werk.

Je kunt ook kiezen voor een cloud provider, bijvoorbeeld op Amazon kies je dan CloudFront, Certificate Manager & Route 53 met je website content op S3. Als je die goed configureerd heb je voor minder dan een euro per maand een zeer snelle en veilig gehoste website die miljoenen bezoekers aan kan.

[Reactie gewijzigd door djwice op 22 juli 2024 23:50]

[Verwijderd]

Straks krijgen we "xx % aantal websites draait nog met de signature "powered by $cms" en is onveilig!!11"

HTTPS moet een afweging zijn, op alles waar je gegevens verwerkt (contact formulier bijv) gewoon https op. Ik bouw websites ook niet meer in HTTP. HTTPS heeft naast dat stukje veiligheid ook dat stukje performance ten opzichte van HTTP. En de reden waarom een hoop sites buiten de zorg sector om op HTTPS draaien is hoogstwaarschijnlijk ook uit commercieel vlak zoals een paar SEO puntjes meer.

[GekkePrutser]

Performance, hoezo? De crypto kost juist extra server load. Gelukkig heeft alles tegenwoordig AES-NI maar toch.. De hele handshake enzo (zeker bij gebruik van PFS).

Met HTTP kon je al heel lang al je content met gzip aanbieden. Dat is niet speciaal iets van HTTPS. Ik denk meer dat het komt dat het met HTTPS vaker gebruikt wordt omdat degenen die nog HTTP gebruiken duidelijk niet zo veel naar hun website omkijken

Verder ben ik ook absoluut voor HTTPS overal hoor. Maar bij een performancevoordeel heb ik mijn twijfels.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 23:50]

[johnkeates]

En toch blijft HTTPS ook qua cycles en performance wel het minste van je problemen. Als dat soort optimalisaties belangrijk zijn kan je beter je wordpress of joomla of ander 13-in-een-dozijn PHP bende de deur uit doen.

[Verwijderd]

Als je je sites gewoon goed bouwt, dus code technisch en css / design gewoon goed doet, heb je gzip helemaal niet nodig.

[SWINX]

want compressie is overrated?

[GeroldM]

Er zijn extra handelingen nodig om voor elke toegangssessie de juiste vorm van beveiliging vast te stellen tussen de server en de computer die content van deze server opvraagt. Extra handelingen kosten extra tijd. Hoe je het ook wend of keert.

Die extra tijd is goed gespendeerd vanwege de extra veiligheid, maar betere performance aangaande het maximale aantal paginas dat die sever per seconde kan genereren? Nee, dat dus niet.

Het kan wel zo zijn dat het bedrijf de de server beheert, middels een load-balancer HTTP verkeer naar een oudere, tragere webserver dirigeert en HTTPS verkeer naar een (veel) krachtigere server dirigeert. Dan kan het wel zo zijn dat je als eindgebruiker kunt denken dat HTTPS beter "performt". Kijk je echter op de servers zelf naar de traffic load, dan zul je zien dat dit niet het geval is.

[wica]

HTTPS, is een ramp op een bagger verbinding, die er nog genoeg zijn.
Niet de hele wereld heeft een top internet verbinding.

[R4gnax]

HTTPS, is een ramp op een bagger verbinding, die er nog genoeg zijn.
Niet de hele wereld heeft een top internet verbinding.

De overhead van moderne TLS versies is qua netwerk-vereisten een stuk minder dan vroegâh.
De geschatte overhead ten opzichte van een kale onbeveiligde verbinding is minder dan 2%.

Zie o.a. https://istlsfastyet.com/

[Reactie gewijzigd door R4gnax op 22 juli 2024 23:50]

[CyBeRSPiN]

Niet iedereen hoeft te weten weke specifieke wiki artikelen ik lees. Kan in sommige landen nogal een ding zijn ook.

[MrBreaker]

Niet iedereen hoeft te weten weke specifieke wiki artikelen ik lees. Kan in sommige landen nogal een ding zijn ook.

En wat gaat het gebruik van SSL hier tegen doen? De request naar de site zal toch worden geregistreerd.

[kuurtjes]

Maar niet de daadwerkelijke resource op de server.

Als ik je netwerk aan het sniffen ben kan ik zien dat je op tweakers.net zit, maar niet dat je dit artikel leest. Mocht tweakers geen certificaat hebben kon ik beide zien.

[totaalgeenhard]

Doet dat er toe dan?

Immers als jij in iemand zijn logische pad zit en dat kan onderscheppen is SSL (Of niet) niet het grootste probleem.


Ik vind dat pogingsdelicten actief moet worden vervolgd.

Het is raar dat zelfs anno 2018 het men acceptabel vind dat een partij strafbare handeling doet voor marketing doeleinden.

Verder is onderstaande ter informatie.

Cybersprint was founded in 2015 by Pieter Jansen and is an active member of the leading European security cluster, The Hague Security Delta.

https://www.geenstijl.nl/...nepnieuws-wil-bestrijden/

[Blokker_1999]

Ja, dat kan belangrijk zijn en maakt uiteindelijk deel uit van je recht op privacy.

[Luminair]

Het IP adres waarnaar wordt geresolved kan ingezien worden. Maar de aanvraag van de specifieke pagina is onderdeel van de inhoud van je request, en is daardoor versleuteld door SSL.

[Luminair]

Het initiele request voor de pagina zal gewoon onversleuteld over de lijn gaan. Enkel de inhoud/response die terug komt is versleuteld.

Dit is niet helemaal correct. Je maakt de aanname dat de pagina die je aanvraagd meteen in het originele request (of de eerste TCP laag van het request) zit, maar dat is niet zo. Er wordt eerst met de host overlegd, handen geschud en keys/certs uitgewisseld. Pas daarna wordt over die beveiligde verbinden een GET request gedaan (waarbij je aangeeft welke pagina's je wilt hebben).

tl;dr: als je naar https://en.wikipedia.org/wiki/Somerset_Levels gaat, maak je verbinding met en.wikipedia.org. Pas later in het stadium wordt /wiki/Somerset_Levels opgevraagd.

[Reactie gewijzigd door Luminair op 22 juli 2024 23:50]

[kodak]

Dan valt er ook iets voor te zeggen waarom je dan zelf kiest om die websites zonder HTTPS wel te bezoeken. Als het echt zo belangrijk is dat niemand dat hoeft te weten dan zorg je er ook zelf voor dat je die sites zonder HTTPS niet bezoekt.

En laten we dan niet in de discussie verzanden dat jij een keuze hebt en anderen misschien niet. Want dit onderzoek gaat er niet eens op in hoe relevant dat gebrek aan HTTPS voor die websites echt is.

[CH4OS]

Het gaat bijvoorbeeld in de zorg om (privacy)gevoelige informatie. Die wil je zoveel mogelijk afschermen voor mensen die specifieke informatie niet nodig zijn. Een zorgverlener op de kraamafdeling mag dus niet bij de patiëntdossiers kunnen komen van de intensive care of oncologie en vice versa. Dit is dan uiteraard via alle denkbare manieren. Data versleuteld versturen is dan eigenlijk al les 1.

Dat heeft niets te maken met wel of geen vertrouwen hebben in de medewerkers, maar alles met voorkomen is beter dan genezen (zal men in een ziekenhuis vast ook vaak roepen naar patiënten) en dus het voorkomen van lekken van gegevens, waar, dankzij de AVG/GDPR, flinke boetes op staan.

Overigens noemen we het in de volksmond weliswaar SSL, in de praktijk is het intussen al TLS, SSL is al achterhaald en insecure.

[Reactie gewijzigd door CH4OS op 22 juli 2024 23:50]

[Zer0]

Het gaat bijvoorbeeld in de zorg om (privacy)gevoelige informatie.

Er is meer in de zorg, er zijn ook websites met openingstijden, route-beschrijvingen, contact-gegevens, etc allemaal publieke informatie die niet privacy-gevoelig is.
Dat is waar DonJunior op doelt, er zijn zoveel websites waar SSL/TLS geen meerwaarde biedt.

[Blokker_1999]

En zelfs dat kan een schending van je privacy zijn. Simpel voorbeeld: jij zoekt tijdens je werktijd even het adres en telefoonnummer op van een zorgverstrekkers die over zwangerschappen gaat. Heeft je werkgever niets mee te maken dat je die openbare info opzoekt, maar hij zou wel tot de conclusie kunnen komen dat je aan kinderen denkt of er 1 verwacht en dat voor je aankondiging aangrijpen om je te ontslaan.

[Raafz0r]

Behalve dat de gemiddelde (grotere) werkgever wel zorgt dat hij SSL verkeer kan monitoren, door bijvoorbeeld een eigen root CA te hebben en dat certificaat standaard in de trusted store te hebben. Dan wordt op al het SSL verkeer naar buiten een "mitm aanval" gedaan waardoor het verkeer wel zichtbaar is.

Vervolgens heeft de werkgever in de situatie die jij schetst nog steeds geen recht om deze specifieke informatie te gebruiken...

[Tribits]

Behalve dat de gemiddelde (grotere) werkgever wel zorgt dat hij SSL verkeer kan monitoren, door bijvoorbeeld een eigen root CA te hebben en dat certificaat standaard in de trusted store te hebben. Dan wordt op al het SSL verkeer naar buiten een "mitm aanval" gedaan waardoor het verkeer wel zichtbaar is.

Ja, ik ben mij er van bewust dat dit schering en inslag is, maar ik vraag mij wel eens af bedrijven zich bewust zijn van de gevolgen. Het gaat er van uit dat de beheerders in de organisatie vertrouwd kunnen worden met alle SSL en dat staat eigenlijk lijnrecht op het idee van SSL dat alleen de verzender en ontvanger de informatie in moeten kunnen zien.

Los daarvan gaat het er ook nog eens van uit dat er binnen de organisatie voldoende zorgvuldig met de private key omgesprongen wordt. Zodra je die in handen hebt kan iedereen op het netwerk voor google.com gaan spelen zonder dat je nog een certificate error ziet.

Ik sta er wel eens van versteld hoeveel private certificates er op zakelijke systemen aanwezig zijn bij instellingen waar beveiliging de hoogste prioriteit zou moeten hebben. Met een mitm proxy zal je weinig keuze hebben, maar in veel andere gevallen is het volgens mij vaak gewoon omdat makkelijker is dan een echt certificaat aanvragen en iedereen hier is toch wel te vertrouwen.

[Paul]

Niet alleen makkelijker, ook noodzakelijk. Onze AD-joined werkstations gaan echt geen computer-certificaat auto-renewen auto-enrollen bij Digicert, die ziet ons aankomen; dat doen ze maar mooi bij onze interne CA. Idem voor interne websites, waanzin om dat extern te doen.

[bbob]

Dan zul je ook je browser geschiedenis moeten wissen.
Daarnaast werkgever mag je niet zo maar controleren op deze manier, daar zijn ook wettelijke regels voor.

[Zer0]

De werkgever mag het niet weten, maar wel de resources leveren? Misschien moet je je privé zaken dan ook niet doen met de middelen van je werkgever...

[CH4OS]

HTTP gaat in de toekomst zelfs verdwijnen. Maar los van dat, ook dergelijke pagina's verzamelen gegevens van bezoekers (zoals voor statistieken) dat wil je wel degelijk via beveiligde verbindingen doen. Daarnaast is de impact op performance nihil, er is anno 2018 geen reden meer om het nietbte doen.

[Reactie gewijzigd door CH4OS op 22 juli 2024 23:50]

[Zer0]

Http gaat dezelfde weg als telnet..... Niet weg dus.

[CH4OS]

Helemaal weg gaat het nooit, maar Telnet is wel dusdanig 'verdreven', dat het niet veel meer gebruikt wordt tov bijvoorbeeld SSH. HTTP gaat een zelfde lot tegemoet.

[Reactie gewijzigd door CH4OS op 22 juli 2024 23:50]

[Padje]

Ssl geen meerwaarde? HTTP2 en wat extra Google ranking tov zonder. SSL is gratis via Lets encrypt, maar zou zelf nooit Lets encrypt gebruiken. Liever een 2 jarig comodo certificaat ipv het risico lopen dat het vernieuwen bij LE een keer misgaat. (Iedere 90 dagen.)

[bbob]

Liever 2 jarig contract en dan net als veel groter bedrijven oeps vergeten te verlengen website op zwart ?
Waarom zou dat automatisch vernieuwen misgaan, er draait gewoon een script. Ik gebruik het voor veel domeinen al een tijdje zonder problemen net als miljoenen anderen.
Daarnaast heb je als je veel domeinen hebt ook aardig wat kosten als je tig certificaten moet kopen.

[GeroldM]

Dat miljoenen sites 'Let's Encrypt' gebruiken geeft een aantal dingen aan. Zij hebben een betrouwbare dienst die door velen word gebruikt. En daarmee worden ze dus ook meteen een interessant en gewild doelwit voor mensen/bedrijven/natiestaten die naarstig op zoek zijn naar backdoors op hun servers/netwerkomgeving en er hoeft maar 1 medewerker (per ongeluk) op een verkeerd linkje te klikken of mailtje te openen en de social engineering kan echt beginnen.

Veiligheid, daar hangt een kostenplaatje aan, hoe je het ook wend of keert.

Alhoewel ik een probleem heb met het concept, een wild-card certificaat kan je behoorlijk wat kosten schelen, indien je veel domeinen hebt/beheerd.

[bbob]

Ik weet niet wat het klikken van 1 medewerker te maken heeft met let's encrypt ssl. die 1e medewerker als dat de zwakste schakel is kan sowieso veel verkeerd doen.

Maar goed hoe betrouwbaar zijn bedrijven die ssl certificaten uitgeven. Herinner me daar de laatste jaren toch ook hier en daar een probleempje.

[Padje]

Haha ja leuk voor consumenten websites let’s encrypt. Maar waar ik EV op installeer daar loopt men liever geen risico. Tja bedrijven die vergeten hun ssl certificaat niet te verlengen. Daar kan ik niks aan doen gewoon slecht geregeld daar dan.

[bbob]

Tja bedrijven die vergeten hun ssl certificaat niet te verlengen. Daar kan ik niks aan doen gewoon slecht geregeld daar dan.

Je bedoeld bedrijven als MS en Google en nog een paar van dat kaliber. Tja dat is ook bij deze in het verleden gebeurt.

Tja leuk dat naar beneden praten Let's Encrypt voor consumentenwebsites. Begrijp het wel hosters willen liefst lekker duur certificaat verkopen daar verdienen ze zelf ook aan mee.

Maar goed die miljoenen of zelf tiental miljoenen bedrijven die Let's Encrypt gebruiken zijn dus allemaal maar consumenten websites die zeker niet serieus bezig zijn.

Enige doel van Let's Encrypt is een SSL verbinding, niet meer niets minder, dan kan nu gewoon met een gratis tools. De meerwaarde van betaalde certificaten is wat mij betreft erg beperkt. Controle bedrijfsgegevens, zijn vaak een wassen neus, schijnveiligheid, niet standaard certificaten hebben nauwelijks controle, bieden dus niets meer.

Dan weer dat argument je moet na 90 dagen verlengen, tja dat doet een script en dat werkt gewoon.

[SWINX]

Je hoeft ook niet tot de laatste dag te wachten he, bij comodo enzo uiteraard ook niet.
Gewoon alvast een tijdje voordat hij vervalt vernieuwen en je probleem is gecoverd.
Bij comodo krijg je dan je resterende tijd gewoon nog erbij.

[bunnybugs_007]

Ik denk dat SSL simpelweg altijd meerwaarde bied.

Het zou voor de 'domme' consument beter zijn als we overal HTTPS gebruiken, zodat zij zich niet af hoeven vragen of ze veilig zijn.

Heel simpel: mijn partner is redelijk tech savvy voor een vrouw/noob, maar zodra ik over HTTPS/SSL begin kan ze niet eens de link leggen met het groene slotje in de browserbalk.

Juist door SSL als standaard te verplichten maken we het internet stukken veiliger. Je kunt dan simpelweg bijna niet meer op een onveilige pagina terecht komen, en daardoor maak je het internet 'idiot-proof'.

[kodak]

Ik ben het eens dat HTTPS een aanvulling kan zijn. Zeker in gevallen waar persoonsgegevens verwerkt worden en in mindere mate voor privacy in het algemeen. Maar dan moet het wel om de mate gaan waarop het wel of geen aanvulling is. En dat laatste lijkt me het punt van @DonJunior.

Les 1 in beveiliging is voor mij dat het een afweging is van risico's. Als het risico blijft dat gebruikers geen idee hebben waarvoor ze HTTPS gebruiken of hoe dat werk dan kan je blijven argumenteren dat er altijd wel een manier is te vinden om te zorgen dat de gebruiker zo veel mogelijk met 'veilige' HTTPS te maken krijgt maar tegen welke kosten doen we dat dan en voor wie zijn we dan wat aan het beveiligen? Voorkomen is beter dan genezen is niet een op een te vertallen naar HTTPS of privacy. Het eerste onderzoek dat kan aantonen dat HTTPS voorkomt dat gebruikers lui worden en het risico zich niet verplaatst moet ik nog vinden.

[CH4OS]

Afweging van risico's? De hacks laten keer op keer toch wel zien dat het tijdperk om risico's af te wegen simpelweg voorbij is. Zorg je niet dat het op orde is, dwingen anderen je dus wel. Gewoon überhaupt géén risico's nemen. Alle data dat over en weer verstuurd wordt kan afgetapt danwel afgeluisterd worden. Versleutelen is de eerste stap in voorkomen van ongewenst afluisteren of aftappen. Anders zou anno 2018 wachtwoorden in databases ook onversleuteld kunnen zijn, omdat men blindelings ervan uitgaat dat de database alleen intern beschikbaar/bereikbaar is. Maar dan is er haveibeenpwned.com, een database met inloggegevens van miljarden accounts.

De kosten voor TLS encryptie over de data is nihil tegenwoordig, zelfs in termen als performance. Je praat over een marginale overhead anno 2018. De grootste kosten zijn die voor het certificaat en zelfs dat hoeft an sich ook niet, als je bijvoorbeeld Let's Encrypt gebruikt. Voor zorginstellingen geen optie, maar voor dergelijke partijen is een EV-certificaat peanuts.

Zet je de kosten af van de beveiliging tegenover de boete die je anders riskeert, dan is voor dergelijke organisaties een EV-certificaat van laten we zeggen €1500,- per jaar ook in schril contrast met die boete. Voorkomen is altiid beter dan genezen.

[Reactie gewijzigd door CH4OS op 22 juli 2024 23:50]

[kodak]

Als je geen risico bij internetten wil nemen dan is de enige oplossing niet internetten.

HTTPS is geen wondermiddel dat alle risico's weg neemt doordat je communicatie op een klein stukje van je verbinding tussen jou als gebruiker en de andere kant versleuteling heeft. Versleutelen en HTTPS zijn hulpmiddelen maar geen wondermiddelen.

Natuurlijk is een eerste stap beter dan geen stap, maar dat is hier niet het punt.

Eigenlijk zouden we het eens om moeten draaien: gebruikers aan de schandpaal nagelen die nog HTTP gebruiken in plaats van HTTPS. Moet je eens kijken hoe snel het afgelopen is met het beweren dat HTTPS een wondermiddel is en je geen risico meer neemt door het te gebruiken.

[CH4OS]

Probleem is alleen dat internet en netwerken niet meer weg te denken zijn en zo'n beetje alles verbonden moet zijn, tot zelfs de koelkast.

Dat HTTPS geen wondermiddel is snap ik, daarom noem ik het ook les 1.

Die schandpaal maken de hackers toch al? Het gaat niet alleen over HTTP vs HTTPS immers.

[Reactie gewijzigd door CH4OS op 22 juli 2024 23:50]

[Verwijderd]

Een zorgverlener op de kraamafdeling mag dus niet bij de patiëntdossiers kunnen komen van de intensive care of oncologie en vice versa. Dit is dan uiteraard via alle denkbare manieren.

Daar ben ik toch eens even zoet mee geweest maar dit klopt dus totaal niet.

Quote uit het Burgerlijk Wetboek 7, artikel 457;
Lid 1)Onverminderd het in artikel 448 lid 3, tweede volzin, bepaalde draagt de hulpverlener zorg, dat aan anderen dan de patiënt geen inlichtingen over de patiënt dan wel inzage in of afschrift van de bescheiden, bedoeld in artikel 454, worden verstrekt dan met toestemming van de patiënt. Indien verstrekking plaatsvindt, geschiedt deze slechts voor zover daardoor de persoonlijke levenssfeer van een ander niet wordt geschaad. De verstrekking kan geschieden zonder inachtneming van de beperkingen, bedoeld in de voorgaande volzinnen, indien het bij of krachtens de wet bepaalde daartoe verplicht.

Klopt, daar heb je gelijk... ECHTER;
Lid 2) Onder anderen dan de patiënt zijn niet begrepen degenen die rechtstreeks betrokken zijn bij de uitvoering van de behandelingsovereenkomst en degene die optreedt als vervanger van de hulpverlener, voor zover de verstrekking noodzakelijk is voor de door hen in dat kader te verrichten werkzaamheden.


Als (zoals in jou voorbeeld), een vrouw op de kraamafdeling komt vanwege een bevalling en deze vrouw wordt tevens behandeld door een oncoloog. Dan zijn beide specialisten noodzakelijk om gegevens uit te wisselen om de gezondheid van de vrouw te waarborgen.

Zou wel erg mooi zijn zoals je het nu vertelt - een paar maanden zelf ondervonden;
- Spontaan flauwvallen.
- Ambulance komt ter plaatse en wordt afgevoerd naar de SEH.
- Aan ambulance personeel leg je uit wat er gebeurd is.
- Aan de eerste verpleegkundige die je ziet leg je uit wat er gebeurd is.

In de tussentijd wordt je door de molen gehaald, je ziet een neuroloog, een traumaarts (chirurg), afhankelijk van de situatie ook nog eens oncoloog, psycholoog etc. etc. Dacht je echt dat je als patiënt je verhaal tientallen keren moet doen? Als iedere arts/verpleegkundige niet in een dossier zou mogen kijken ben je als patiënt inderdaad gebonden aan je verhaal tientallen keren te doen. Ze kijken gewoon in je dossier ondanks dat iedere arts en verpleegkundige van een aparte afdeling is.

Zodra er een overlapping is binnen een specifiek iets heb je al gauw te maken met gedeelde informatie wat alleen maar in het belang van de patiënt is.

[CH4OS]

Ah, ik was inderdaad niet specifiek genoeg. Maar ik doelde niet op een 'combinatie-situatie' om het zo even te zeggen. Uiteraard dienen alle betrokkenen (en eventuele vervangers) toegang te hebben.

En ja, je verhaal moet je tientallen keren doen. Dat had ik in 2015, dat had mijn ma dit jaar ook.

[Reactie gewijzigd door CH4OS op 22 juli 2024 23:50]

[Verwijderd]

Dit had mijn ma 1 1/2 jaar geleden niet, net zo min als ik dit 2 maanden geleden had.

Zat ik ook pertinent niet op te wachten want het kost tijd, tijd die veel beter besteed had kunnen worden.

[Sysosmaster]

Daar ga je toch echt te kort door de bocht.

Naast dat de verbinding versleuteld is is deze ook beschermd tegen injectie aanvallen (een bad modem kan dan niet eigen reklame toevoegen aan alle sites bijvoorbeeld.)

Ook beschermt het tegen registratie van waarnaar je op zoek was.

(Met SNI is wel bekend bijvoorbeeld dat je bij ziekte.nl bent geweest maar niet dat jij de pagina over SOA’s hebt gelezen)

[totaalgeenhard]

(een bad modem kan dan niet eigen reklame toevoegen aan alle sites bijvoorbeeld.)

Waarom niet?

Als er een valide certificaat tussen zit krijg je geen foutmelding.

[hackerhater]

Omdat het niet het verkeer tussen jouw en de website kan ontsleutelen zonder een SSL-error te veroorzaken?

[totaalgeenhard]

Controller jij het certificaat dan?

Zo ja wie nog meer ?

Clientside certificaat sluit dat uit, maar nogmaals als iemand aan je verbinding kan zitten heb je een groter probleem.

[hackerhater]

Als het cert niet overeen komt met het domein weigert je browser al te connecten.

[totaalgeenhard]

Hoe vaak zijn er CA gehacked of hebben overheid valse certificaat aangemaakt ?

Maar nogmaals je probleem is dat tunnel niet.

Als je in bij verkeer kunt komen heb je in 3 plekken.

1 je netwerk thuis
2 transit
3 serverzijde

Daarbij is transit gezien werking tcp/ip het moeilijkst te onderscheppen omdat je anders al over 1 of 3 hebt.

[kamerplant]

De browser controleert het cert.

[totaalgeenhard]

Zie reactie hierboven.

[R4gnax]

Controller jij het certificaat dan?

Zo ja wie nog meer ?

Alle moderne browsers controleren automatisch of een certificaat geldig is voor een bepaald domein en vertrouwen überhaupt een certificaat alleen als het in de trust-chain van een certificate authority zit die ze vertrouwen.

Certificate authorities en browser makers managen samen een collectie revocation lists met certificaten die verkeerd uitgegeven zijn; waarvan bekend is dat ze misbruikt worden; etc. Browsers controleren die lijsten en weigeren op basis van zulke certificaten een verbinding op te zetten.

Daarnaast hebben o.a. Mozilla en Google een certificate transparancy programma opgericht waar authorities gehoor aan moeten geven en zich verplicht moeten onderwerpen aan allerlei controles; meldplicht moeten hanteren bij lekken; etc. om hun root certificaat aan de vertrouwde lijsten van browsers toe te laten voegen. Als ze niet op die lijst staan, dan kunnen ze simpelweg geen werkende certificaten uitgeven. (Want: trust-chain.)

[totaalgeenhard]

https://nl.m.wikipedia.org/wiki/DigiNotar

Nogmaals controleer jij certificaten?

Want je browser kan je daar niet beschermen.

[R4gnax]

Want je browser kan je daar niet beschermen.

Nogmaals; dat kan 'ie wel.

Zodra het Diginotar debakel bekend werd, werd de stekker er vanuit de browsers uitgetrokken doordat ze patches uitbrachten die het vertrouwen in het rootcertificaat van Diginotar deden opzeggen.

Daarnaast kunnen websites die vaak door een gebruiker bezocht worden - bijv. wanneer een gebruiker daar een e-mail dienst afneemt - tegen het soort valse certificaatuitgiftes zoals bij Diginotar plaats hebben gevonden, wapenen door strict transport security (HSTS) en certificate pinning (HPKP) toe te passen.

Een site zal dan voor een bepaalde periode enkel nog bezocht kunnen worden over een TLS verbinding versleuteld via een vooraf gecommuniceerd en overeengekomen certificaat; bij het eerste bezoek van de gebruiker.

Veel plezier met dat soort hedendaagse maatregelen bijv. nog op iemands Gmail in te breken via een man-in-the-middle aanval op basis van een vals certificaat. Gaat je NIET lukken.

[Reactie gewijzigd door R4gnax op 22 juli 2024 23:50]

[totaalgeenhard]

Diginotar was een voorbeeld er zijn meer root CA waarvan bekend is dat er incidenten mee zijn geweest dan waarvan er nooit iets mee geweest.

Keten kan alleen gesloten zijn als er gewerkt met client side certificaat.

Maar zoals ik herhaaldelijk heb geschreven als je bij verbinding kunt komen is het zeer waarschijnlijk dat je ook fysiek toegang hebt tot client of server en dan is SSL.niet relevant.

https://blog.malwarebytes...trusted-root-certificate/

[R4gnax]

Diginotar was een voorbeeld er zijn meer root CA waarvan bekend is dat er incidenten mee zijn geweest dan waarvan er nooit iets mee geweest.

En dat is dan ook waarom de situatie de laatste jaren aangescherpt is.

Maar goed; doe eens vertellen dan. Wat is dan volgens jou een beter; veiliger systeem dan een trust-chain? Want tot nu toe is het enige wat je doet een beetje hard roepen dat certificaten niets bereiken, maar alternatieven hoor ik nog niet.

Als je het dan zo goed weet; laat maar horen...

[Reactie gewijzigd door R4gnax op 22 juli 2024 23:50]

[svennd]

HTTPS Kan sneller zijn dat HTTP

Wikipedia heeft weinig resources per pagina dus de winst zou wel beperkt zijn, maar er is een login pagina...

Ik zie het nut niet van een website zonder certificaat, tenzij local, of development ...

[Keypunchie]

Anderzijds.. is het nodig om een SSL certificaat te gebruiken als men geen formulier hoeft in te vullen? *vraagteken

Ja. Een goede SSL verbinding garandeert ook dat de informatie die je leest echt van de server komt waarmee je verbind.

Dus dat er geen 3e partij tussen jou en de verbinding dingen injecteert. Of dat nou informatie is, of malafide scripts.

[The-Priest-NL]

Ja dit is nodig, niet voor jou als site eigenaar maar wel als je je bezoeker wil beschermen. Toevallig heeft Troy Hunt hier net een artikel over gemaakt met een video erbij.
Ik zou zeggen kijk hem eens. https://youtu.be/_BNIkw4Ao9w

[kftnl]

Zijn airbags in je auto nodig? Er zijn maar weinig dingen in de beveiligingswereld echt nodig. Of je een formulier hebt is niet echt het hoofdcriteria, het gaat meer om gevoelige informatie. Als er op de e.o.a. manier sprake is van persoonsgegevens (en dat is al snel, bijv. het type pagina dat bezocht wordt i.c.m. het ip adres) is een afdoende beveiliging volgens de AVG vereist. In dat opzicht kun je de wet uitleggen als dat het nodig kan zijn. Als jij een site hebt waarvoor het toevallig heel erg moeilijk is om SSL te gebruiken (om wat voor reden dan ook), dan ben je het in de meeste gevallen niet verplicht.

SSL biedt meerwaarde tegen bepaalde typen aanvallen. Dat gaat natuurlijk om het meelezen met jouw internetgedrag, maar ook om andere dingen. Bijv. zou er iets op een pagina geïnjecteerd kunnen worden als iemand via een onveilige hotspot (of anderszins gecompromiteerde verbinding) verbindt.

Er zijn natuurlijk nog zat andere manieren waarop gegevens kunnen lekken, en SSL doet tegen veel van die issues helemaal niets (in een zeldzaam geval werkt het zelfs tegen). Netto is het gewoon een voordeel voor iedereen als de grote meerderheid van verbindingen via SSL gaat. Daarom zie je steeds meer druk voor iedereen om het te doen. Ook al heeft het feitelijk gezien geen meerwaarde voor de groenteman om de hoek, een browser kan dat niet weten en geeft ook daar straks gewoon een waarschuwing waardoor klanten wellicht worden weggejaagd.

Het is nu zo simpel en goedkoop is om SSL te verkrijgen dat er weinig redenen zijn om het niet te gebruiken. Zeker nu browsers hun waarschuwingen opvoeren voor niet-SSL sites biedt dat al gauw meerwaarde.

[Wim-Bart]

SSL is meer dan alleen een veilige verbinding waarbij data versleutelde wordt. Een certificaat zorgt er ook voor dat je zit te kijken naar een site die daadwerkelijk de site is van de maker/eigenaar. Een voorgeschotelde niet HTTPS site kan je bijvoorbeeld naar een login doorsturen van een malafide site waar een argeloze gebruiker dan in kan loggen met bijvoorbeeld bank gegevens. Door alles in de keten HTTPS te maken met de juiste certificaten is het dan ook moeilijker om nepsites tussen gebruiker en echte site te zetten. In een ideale wereld is het hele WWW voorzien van certificaten.

Daarom is het belangrijk dat je private keys goed afschermt, dat de uitgeef autoriteit goede procedures heeft en dat de hele keten, van aanvraag certificaat, tot uitdelen en gebruik betrouwbaar is.

[GeroldM]

Droom rustig verder. HTTPS zorgt ervoor dat de verbinding tussen twee computers minder makkelijk via MitM kan worden onderschept. Is de site achter de HTTPS verbing malafide of geinfecteerd, dan word hun probleem toch echt ook het jouwe. HTTPS of niet.

Blind vertrouwen op bedrijven die certificaten uitgeven, dat zou ik dus niet doen. Hoe betrouwbaar zijn deze? Het "Who watches the watchers" idee, dus. Je ziet nogal vaak 'Let's Encrypt' terugkomen in de comments hier. Vertrouwen op de kennis, kunde en betrouwbaarheid van 1 certificaat aanbieder, dan leg je nog steeds al je eieren in 1 mandje. Toegegeven, het mandje draag je niet zelf meer, maar als die drager een keer "struikelt", heb je nog steeds hetzelfde resultaat.

Simpel gezegd, je wimpelt het veiligheidsprobleem dus af. Nu zal een certificaatannbieder wel zijn best doen om het allemaal zo goed mogelijk te doen. Daarvan ben ik wel overtuigd. Maar er blind op vertrouwen? Diginotar klinkt nog steeds bekend in de oren?

[Wim-Bart]

Daarom staat er ook:

Daarom is het belangrijk dat je private keys goed afschermt, dat de uitgeef autoriteit goede procedures heeft en dat de hele keten, van aanvraag certificaat, tot uitdelen en gebruik betrouwbaar is.

Niks aannemen dus, altijd controleren en op de hoogte zijn. Want alleen dan voorkom je in grote mate dat iemand met een "schijnbaar valide" certificaat er tussen in gaat zitten.

[Padje]

Daarnaast kun je met SSL gebruik maken van het HTTP2 dat scheelt een behoorlijk stuk qua snelheid van de site.

[ASS-Ware]

Anderzijds.. is het nodig om een SSL certificaat te gebruiken als men geen formulier hoeft in te vullen? *vraagteken
Noem een informatieve website als Wikipedia.. als je daar alleen leest voegt een SSL weinig toe toch?

Dat doet het wel.
Je weet dan als bezoeker dat hetgeen wat je leest ook echt van die website afkomt en niet onderweg is aangepast.

[Tivoler]

SSL is easy to do en niet duur meer vandaag de dag dus beter wel dan niet. Het is niet zo complex (meer) als men deed geloven 10-15 jaar geleden.

[CH4OS]

Toch zie ik graag dat zorginstellingen geen Let's Encrypt of vergelijkbare dienst gebruiken en het liefst dan nog een EV-certificaat, die zijn niet goedkoop.

[Tivoler]

Ja en Nee, een EV is echt niet beter dan LE. De verificatie vindt eenmaal plaats en het is done. Een EV tevens is overdone, gewoon een OV is voldoende dan mocht je verificatie willen, maar ook deze is super simpel te manipuleren, eigenlijk nog makkelijker dan DNS welke je gewoon goed in orde moet hebben.

[Reactie gewijzigd door Tivoler op 22 juli 2024 23:50]

[CH4OS]

Tja, uiteindelijk zijn allen te manipuleren als je er tussen weet te komen. Zie Diginotar.

[ASS-Ware]

Tja, uiteindelijk zijn allen te manipuleren als je er tussen weet te komen. Zie Diginotar.

Bij Diginotar is niets gemanipuleerd, inbrekers hebben er certificaten aangemaakt die door browsers werden vertrouwd.

[CH4OS]

Doordat ze er tussen wisten te komen...

[ASS-Ware]

Doordat ze er tussen wisten te komen...

Nee, ze konden heel simpel inbreken, ze hoefden nergens tussen te komen.
Updates ontbraken op servers, antivirus werd niet geupdate, de root CA stond gewoon aan, niet ideaal, zeg maar.

Sterker nog, de hangjeugd zat ‘s avonds zelfs op het Diginotar wifi netwerk.

[Padje]

100 euro is toch niet duur?

[CH4OS]

Een EV-certificaat is wel wat duurder. Maar voor grote organisaties is ook dat peanuts.

[Padje]

€89,95 voor een EV Comodo certificaat.

[CH4OS]

Ik zou alleen voor zorginstellingen geen Comodo certificaten kopen. Ook kunnen applicaties niet met een dergelijk certificaat ondertekend worden.

[Neko Koneko]

Toch zie ik graag dat zorginstellingen geen Let's Encrypt of vergelijkbare dienst gebruiken en het liefst dan nog een EV-certificaat, die zijn niet goedkoop.

Wat is er mis met Let's Encrypt dan?

[CH4OS]

Let's Encrypt biedt geen validatie op organisatie, een EV-certificaat wel. Ik wil graag 100% zeker zijn dat de info daadwerkelijk van de zorginstelling is. Een validatie op is dan toch niet teveel gevraagd lijkt me?

En niet vergeten dat applicaties er niet mee gesigned kunnen worden.

[Reactie gewijzigd door CH4OS op 22 juli 2024 23:50]

[tormentor1985]

tls is tls een ev of zelfs pkio certificaat is net zo veilig als een self signed certificaat.

[CH4OS]

Klopt, voor het protocol maakt het niets uit, maar voor de echtheid, dus of men is die men zegt dat ze zijn des te meer. Zoiets werkt twee kanten op. Niet zomaar naar elk groene slotje kijken en dat afdoende vinden. Zeker als je met zorginstellingen of overheden te maken hebt wil je zekerheid hebben met wie je te maken hebt / "spreekt".

[Reactie gewijzigd door CH4OS op 22 juli 2024 23:50]

[vczion]

Ja, ik als hacker kan javascript injecteren en jouw browser gebruiken om:
- (D)DoS aanvallen te gebruiken (voorbeeld)
- Fake update popup spawnen die vervolgens een malware executable downloadt
- ...

Kijk maar eens naar beef, wat je allemaal kunt doen met een browser die is gehijacked 😉

[Stoelpoot]

Zonder HTTPS kan ik dat dat form wat toch niet in de pagina zit alsnog injecteren. Stel dat ik een formulier injecteer om accounts aan te maken, dan hark ik wachtwoorden naar binnen.

[DonJunior]

Na de twintigste reactie snapte ik hem ondertussen maar thanks voor de aanvulling.

[Stoelpoot]

Mijn specifieke uitwerking had ik er niet zo snel tussen gezien

[daanb14]

Het is natuurlijk zeer zorgelijk dat men in de zorg nog zo ontzettend vaak onveilige omstandigheden erop na houdt. Ik merk het zelf ook bij de zorginstelling waar een van mijn ouders werkt. Men maakt daar weliswaar gebruik van TLS, maar de hoeveelheid wachtwoorden voor de applicaties rijst zo de pan uit dat alle medewerkers meteen geneigd zijn om gigantisch makkelijke wachtwoorden aan te maken. Het lijkt mij dan ook een stuk verstandiger om in dit soort organisaties gebruik te maken van bijvoorbeeld smartcards of yubikeys. Mijn punt hierbij wat betreft dit onderwerp is dat de overheid zo gigantisch veel op zichzelf staande systemen heeft (zoals in de zorg), wat het erg moeilijk maakt om de veiligheid en het overzicht op al die systemen te bewaren. Wanneer er een gigantische shitload aan versplinterde systemen is, dan is het vaak ook een warboel op het gebied van beveiliging. Hierdoor is niet alleen de beheerder geneigd om de beveiliging niet op orde te hebben, maar de gebruiker wat betreft zijn gegevens vaak ook.

[Speeder]

Deel van die puinhoop wordt ook door de leveranciers van de software veroorzaakt als ze geen Single Signon of smartcards ondersteunen. Dus het probleem ligt niet alleen bij de overheid maar ook bij de ontwikkelaars die zich er makkelijk van af maken door dat soort dingen juist niet te ondersteunen.

[himlims_]

Maar de overheid kan dit afdwingen (bij aanbesteding) of wettelijk verplichten. Niet eens zo heel gek

[Wim-Bart]

Imprivata is een product wat dit zonder Problemen ondersteund, maar als organisatie moet je er wel even tijd in steken. Je kan gewone RFID passen gebruiken en de software ondersteund sso voor applicaties die het niet ondersteunen. Zo kan je met dus een sso ervaring implementeren. Echter moet een beheerder wel even het logon gedeelte van de applicatie definiëren.

Ik zie het eigenlijk meer als laksheid en luiheid dat dergelijke systemen niet worden ingezet om het voor de gebruiker makkelijker te maken en dus ook veiliger.

[Noeandee]

Eens. Wij implementeren veel Imprivata. Het is een prachtige eenvoudige oplossing. En het scheelt enorm veel wachtwoorden onthouden, als je veel interne applicaties en web services hebt draaien. Maar voor externe websites helpt dit niet. Al kan je dan wel weer keepass of iets dergelijks voor gebruikers draaien.

[Reactie gewijzigd door Noeandee op 22 juli 2024 23:50]

[CH4OS]

Leuke is dan nog, dat zorg niet eens zo zeer overheid is. De overheid zelf heeft nog veel meer systemen en programma's, want de overheid zelf behelst veel meer dan de zorg alleen. Dergelijke omgevingen zijn al dusdanig complex dat het best lastig is om nu nog extra beveiliging toe te voegen. Dan kunnen ze beter over security nadenken bij een migratue, als de omgeving dus toch al open ligt.

[ajolla]

Ik vrees dat als je massaal Yubikeys gaat gebruiken een hoop mensen problemen met inloggen gaan krijgen omdat de USB aansluiting uigelubberd (wat een mooi woord trouwens) raakt.

[bunnybugs_007]

Een RSA key zou ook al een uitkomst zijn.

[GeroldM]

OAuth? OpenID? Een Radius server? Er bestaan allang een boel (on-premise/cloud) oplossingen om middels 1 login gebruikers toegang te geven tot praktisch alle (lokaal draaiende/cloud) sites die je gebruikers nodig hebben om hun werk uit te voeren.

[uiltje]

Het aantal mislukte smart card en gerelateerde pilots in de zorgsector is niet te tellen. Je hebt daar te maken met veel managers die echt niet in de IT zitten, enorm heterogene producten - zoals je al geconstateerd hebt, vaak weinig budget, ingewikkelde omstandigheden mbt hygiene, ga zo maar door.

[pim]

Ik heb een tamelijk grote Nederlandse website zonder ssl.
In eerste instantie ssl aangezet. Maar meerdere keren stopte het met werken, omdat het certificaat niet automatisch verlengt werd. Met als gevolg dat mijn complete website down was.
Had een server beheerder ingehuurd die zei dat het niet verlengt werd omdat "apache hield poort 443 onnodig bezet waardoor verlengen niet werkte"..
Ik weet niet wat ik moet doen als automatische verlenging niet werkt.
Daarom laat ik het liever uit staan.

[LodanMax]

In dat geval zou ik persoonlijk terugvallen op een betaald SSL certificaat.
Het importeren is meer werk, minder automatisch, maar ze gaan wel normaal 1 jaar of langer mee.

Dan heb je zowel de SSL, als weinig omkijken naar de beveiliging. Enkel een herhalende reminder in je agenda zetten een maand van tevoren zodat je tijdig je SSL cert kan verlengen.

[vali]

Of het opnemen bij je monitoring zoals Zabbix of Nagios. Genoeg plugins hiervoor te vinden.

[Wim-Bart]

Als je niet weet wat je moet doen dan moet je een professional inhuren. Maar straks ben je gewoon de pineut wanneer Chrome, Safari, Firefox en dergelijke bij iedere click en navigatie een popup geven met "Deze site is mogelijk onveilig...." zoals nu in de planning staat.

Overigens werkt Letsencrypt gewoon zonder enig issue, je moet alleen even de tijd er in steken. Heb nog geen enkele Apache en IIS implementatie gezien waar Letsencrypt niet werkte met automatische verlenging.

[R4gnax]

Als je niet weet wat je moet doen dan moet je een professional inhuren. Maar straks ben je gewoon de pineut wanneer Chrome, Safari, Firefox en dergelijke bij iedere click en navigatie een popup geven met "Deze site is mogelijk onveilig...." zoals nu in de planning staat.

Chrome 68 zou het al moeten doen en die komt deze maand uit op stable. Het is niet meer een what if; het is realiteit en als je er als commerciële website nu nog iets aan moet gaan doen om je site er voor in orde te krijgen, ben je wss. dik te laat.

Helaas pindakaas; ruimschoots een jaar geleden is iedereen al gewaarschuwd.

[Reactie gewijzigd door R4gnax op 22 juli 2024 23:50]

[Tribits]

Ik heb een tamelijk grote Nederlandse website zonder ssl.

Zeker als je een wat grotere site draait horen dergelijke maatregelen er gewoon bij. Je schiet er ook weinig mee op als je site op een bepaald moment in het nieuws komt doordat er via een mitm attack malware naar de gebruikers wordt gestuurd. Niet geheel vergelijkbaar, maar ik kan me nog een tafeltennisvereniging uit het zuiden des lands herinneren die opeens de payload van een bekend botnet hoste. Dan is de schade toch wel wat groter dan de kosten die je bespaart door geen SSL te draaien.

[mvd64]

Misschien iemand inhuren die het probleem wel kan oplossen. Want een probleem is het. Nog afgezien van het feit dat Google het nu ook gebruikt voor ranking, zodat het ook belangrijk is geworden vanuit SEO oogpunt...

[Sleepkever]

Als je een tamelijk grote site hebt, dan heb je daar neem ik aan ook monitoring op? Dingen zoals offline, trage response, etc? Als je bijvoorbeeld lets-encrypt neemt, die hebben certificaten van 90 dagen die bij minder dan 30 dagen validiteit vernieuwd worden. Stel wat monitoring in dat je certificaten meer dan 29 dagen geldig zijn en je krijgt een maand van te voren een mailtje dat er iets is mis gegaan... Dan heb je nog een maand om het op te lossen!

Ja SSL is ietsje meer werk maar het is echt minder dramatisch als je nu schetst.

[ewoutw]

Ik snap deze drukte nooit om certificaten nooit. Veel websites tonen alleen data gegevens en zijn publiekelijk toegankelijk. Daar encerptie overheen doen lijk me niet interessant. Zolang er geen formulier data naar de webserver gestuurd wordt zie ik het probleem niet zo. Ik heb niet speciefiek veel verstand van https, maar neem aan dat de ip-headers niet versleuteld raken. Anders weten routers niet waar het naar naar tot moet.

Met https kan je mischien het reqeust zelf niet zien maar je ziet wel nog voor welke ip-adres het pakketje bedoeld is. Dan weet je Meschien wel dat ik op Wikipedia heb gezeten maar weet niet wat ik daar heb gelezen....

[RGAT]

En daar geef je dus de reden al, waarom zou je onnodig informatie weggeven aan een MITM als het ook gewoon door HTTPS beschermd kan worden? Waarom bewust kiezen voor onveilig vs veilig...

[kodak]

Omdat het geen kwestie van veilig vs onveilig is maar een afweging van risico.

15 jaar lang zijn n00bs bestookt met het idee dat een slotje en ssl zouden betekenen dat het veilig was. Als jou site de uitstraling moet hebben dat het niet om veiligheid gaat en de inhoud niet belangrijk is, dan kan dat een overweging zijn om geen ssl te gebruiken. Als de gebruiker de site dan niet wil bezoeken of dat een ander dan van mening is dat het bij mitm toch een risico is dan is dat aan hun.

[Reactie gewijzigd door kodak op 22 juli 2024 23:50]

[djiwie]

Wat dacht je van MITM attacks? Er zijn genoeg providers (niet in NL voor zover ik weet) die bijvoorbeeld eigen advertenties injecteren bij HTTP verbindingen. En een ander punt: het is veel gemakkelijker en veiliger om alles op HTTPS te hebben. Aan gebruikers is dat beter aan te leren (http = geen slotje = onveilig).

[kodak]

Ik zoek toch wat meer nuance en afweging, dus ben benieuwd wat die zijn na de volgende afwegingen:

Dat het makkelijker is om HTTPS te hebben om gebruikers te leren dat HTTP onveilig is heeft er de afgelopen jaren niet aan bijgedragen dat gebruikers snappen dat een HTTPS site niet veiliger (en in toenemende mate zelfs onveiliger) hoeft te zijn dan een HTTP site.
En over het gemak op zich is er geen conclusie of HTTPS er echt voor zorgt dat gebruikers veiliger zijn omdat onduidelijk is of ze wel snappen wat HTTPS is en waarom ze het vertrouwen.
Dus ik vraag me af hoe HTTPS dan een oplossing is en niet slechts een goed gevoel geeft want HTTPS.

Het punt van de bescherming tegen MITM attacks kan ik nog een eind in mee gaan, maar ik kom toch op de conclusie dat als je als gebruiker last hebt van een MITM attack je wel meer zorgen aan je hoofd hebt. En die vallen allemaal terug te voeren op de gebruiker die de eindverantwoordelijke is om te bepalen wat die wel of niet bezoekt en waarmee. Als het MITM een serieus probleem voor de gebruikers is dan zijn er maatregelen die veel effectiever en doeltreffender zijn dan het te laten afhangen dat websites ieder voor zich maar HTTPS moeten toepassen. Zowel op het niveau van een landelijk probleem, een probleem met je telecombedrijf of op je eigen computer. En dan is het nog de vraag hoe dat in relatie staat tussen de eerste opmerkingen dat gebruikers nog steeds niet weten wat ze waarom aan het doen zijn en of het niet meer is om een goed gevoel te hebben.

[djiwie]

Heeft iemand het onderzoek zelf gevonden? Ik kan het onderzoek niet vinden op de website van cybersprint, alleen een (vrij algemeen) nieuwsbericht over SSL maar ik zie nergens de verantwoording of onderzoeksmethode uitgelegd... Valt me eerlijk gezegd ook wel tegen van Tweakers om dat zo klakkeloos over te nemen.

[kodak]

Ik zocht er ook al naar. Zoals de media het weergeven heb ik weinig vertrouwen in. Het lijkt over te zijn genomen van een persbericht van het bedrijf dat via het ANP bij de redacties is aangekomen en vervolgens bijna letterlijk is overgenomen. Het lijkt een interview maar bij geen enkel artikel staat wie het geschreven heeft. Alleen RTL nieuws zet er bij dat het via ANP komt. En bij dat soort nieuws mag je al snel denken in de richting van een marketingstunt waarbij het bedrijf reclame maakt door zogenaamd een interview te plaatsen over een onderwerp dat geen redactie kritisch heeft geverifieerd op inhoud.

Misschien zijn de tech redacties in een zomerse bui, maar ik had toch echt voor plaatsing wel willen weten hoe deugdelijk dat onderzoek is als het lijkt alsof iedere student met toegang tot de top-10000 websites van Nederland en een scan scriptje ook deze resultaten kan produceren. Nu weet niemand hoe representatief die websites waren en of het beeld van dat HTTPS gebruik wel klopt (veel sites gebruiken namelijk ook gewoon HTTP naast HTTPS).

[Tribits]

Heeft iemand het onderzoek zelf gevonden? Ik kan het onderzoek niet vinden op de website van cybersprint, alleen een (vrij algemeen) nieuwsbericht over SSL maar ik zie nergens de verantwoording of onderzoeksmethode uitgelegd...

Heb er even kort naar gezocht, maar ik krijg toch nog al sterk het vermoeden dat het gewoon een statistiek betreft, mogelijk door een geautomatiseerd systeem vastgesteld. Tsja, je kan het onderzoek noemen maar het is nu niet bepaald wat er in wetenschappelijke kringen onder onderzoek wordt verstaan. Dit zou dan hooguit een klein onderdeeltje vormen. Daarnaast krijg ik ook het idee dat Cybersprint dit soort berichten vooral de wereld in slingert vanuit commercieel oogpunt en dat roept dan natuurlijk nog wat extra vraagtekens op als er sprake is van een onderzoek.

[SiGNe]

Terwijl 't aanvragen met Certify voor IIS een stuk makkelijker is geworden: https://certifytheweb.com/
Binnenkort komt versie 4 uit, incl support voor wildcarddomeinen https://github.com/webprofusion/certify/issues/270
Tweakers.net lijkt 't ook niet zo interessant of nodig te vinden waarschijnlijk want ondanks dat ik de redactie meerdere malen getipt heb hebben ze het nooit in de software updates gezet.

[WimTenBrink]

Het probleem van Certify the Web is dat het een commerciële club is en je beperkt bent tot maximaal 5 sites binnen IIS met de gratis versie. Ook al is de broncode van de GUI app open source, die beperking blijft enigszins vervelend.
Zeker voor mij als web developer en mijn testomgeving met Windows 2012/IIS waarop ik mijn projecten host voor testdoeleinden. Ieder project een eigen site is leuk maar ik kom dan al snel over die 5 sites heen. En die licentie die ze vragen is veel te prijzig.
Maar ik geef toe, ik gebruik het wel. Alleen ben ik nu aan een combi-project aan het werken waardoor ik meerdere projecten vanuit dezelfde site kan draaien. Nu LE wildcards toestaat is dat opeens een goed alternatief.

[Tivoler]

Waar zie jij non-ssl bij tweakers dan ? Ik doe hier alles via SSL hoor.

[SiGNe]

Het gaat niet of Tweakers zelf SSL gebruikt maar dat ze een programmaatje waarmee je Let's Encrypt SSL certificaten voor IIS kan aanvragen niet bij de software updates zetten (ondanks meerdere submits).
Vroeger moest je die Let's encrypt certificaten via shell commando's aanvragen maar met Certify hoeft dat dus niet meer, heb je een mooie handige GUI.

[royduin]

Misschien omdat ze een selectie maken? Anders kunnen ze alle projecten op Github wel in de meuktracker gooien.

[Wim-Bart]

Draai al een jaar Exchange 2016 via Letsencrypt en de tools er voor zijn zo eenvoudig dat een kind de was kan doen. Eenmaal ingericht (15 minuten??) en dan geen omkijken meer.

[Tivoler]

Ja mooi tooltje. Opzich heb je geen gui nodig natuurlijk maar het ziet er goed uit

[Verwijderd]

Misschien omdat niemand IIS gebruikt?

[royduin]

Goed verhaal, Tweakers heeft toch gewoon een SSL certificaat? Lekker in-relevante linkjes ook, Tweakers gebruikt geen IIS.

[Aardedraadje]

SiGNe heeft het over een aanvulling voor de software-updates / andere downloads sectie.

[svennd]

Is dat niet gewoon een van de vele let's encrypt clients voor o.a. ISS.

Er zijn er veel, en nog veel meer voor populaire webservers.

[Username3457829]

Ik las alweer bijna 4 maanden geleden dat TLS 1.3 gereleased was, maar hoe lang gaat het duren voordat we daar wat van gaan zien?

[Verwijderd]

Cloudflare en Google gebruiken al TLS1.3

[Username3457829]

Hoe kan ik dat zien in Chrome en Firefox?

[Verwijderd]

Als je doorklinkt op het groene slotje krijg je het ergens (in firefox iig) wel te zien, onder 'more information'. Probeer hier maar op tweakers

[Username3457829]

Oja nice. En in Chrome?

[Demonitzu]

Verstopt in de Dev Tools (F12), tabblad Security

[Demonitzu]

Het "probleem" is dat de meeste server software (zoals openssl) nog niet klaar is voor TLS 1.3.

Stable release voor openssl met TLS 1.3 wordt eind van het jaar verwacht. Boringssl (gebruikt door Cloudfare en Google) heeft dit wel al.

[WokeBroke]

Ik snap het niet helemaal, providers en overheid instanties kunnen toch gewoon zien dat ik op deze https pagina ben geweest? $_POST formulieren zijn dan misschien veilig maar $_GET formulieren zijn toch gewoon te zien? En laat nou net het meeste op internet via $_GET werken. Ik ben niet op dit artikel gekomen via een post formulier. Ik moet de eerste website nog tegen komen die zo werkt.

[royduin]

Juist een pagina bezoeken is inderdaad een GET request. Een formulier submitten (contact formulier, login pagina, etc) is 9 van de 10 gevallen een POST request. Die data is met een SSL certificaat versleuteld. Geen idee waar je precies op doelt? Dat een provider / MITM-aanval een url ziet, so what? Zolang ze de data maar niet zien toch?

[WokeBroke]

Ik bedoel als je op de hoofdpagina inplaats van links postformulieren maakt. En die via CSS gewoon op links laat lijken. Zou je alle pagina’s(informatie) kunnen openen zonder GET request. Dan zou SSL meer zin hebben. Maar dit gaat natuurlijk bijna niemand doen omdat het niet seo en deel vriendelijk is.

[royduin]

Maar waarom zou je dat doen? Ook GET is gewoon encrypted (mits TLS gebruikt wordt, geen idee waar SSL certificaten te krijgen zijn zonder TLS trouwens), alleen de host niet. Dus stel je bent dit artikel aan het lezen kan een provider / MITM-aanval alleen "tweakers.net" zien. Leesvoer: https://stackoverflow.com.../are-https-urls-encrypted

[Reactie gewijzigd door royduin op 22 juli 2024 23:50]

[WokeBroke]

Aha, dat was mij dus niet duidelijk ik dacht dat de gehele url aanvraag gewoon te zien was.

[djwice]

Nee, klopt niet.
Onder HTTP is zowel het PATH, de GET en POST te lezen.
Onder HTTPS is alleen de domeinnaam te lezen.

Verschil is dus zoals @djiwie hier aangeeft:

Voor het zelfde bezoek kan iedereen zien onder HTTP:
http://google.nl/?q=soa+onveilige+seks
http://huisarts.nl/soa/help-ik-heb-er-een/
http://huisarts.nl/soa/?c...es&vraag=pijn+bij+plassen

Onder HTTPS:
https://google.nl/
https://huisarts.nl/
https://huisarts.nl/

[Reactie gewijzigd door djwice op 22 juli 2024 23:50]

[Sysosmaster]

Als er TLS word gebruikt (SSL is broken beyond repair) dan word ook de url encrypten. Enkel het domain niet (om SNI te laten werken).

Dit betekent effectief dat voordat de HTTP verbinding word gemaakt eerst een TLS verbinding word gemaakt waarover 1 extra detail (het domein) word verstuurd. De rest word pas verstuurd via de TLS verbinding nadat deze cryptografisch is afgeschermd.

[CH4OS]

Volgens mij alleen in de access logs tegenwoordig. Maar formulieren via GET-methodes (is namelijk niet afhankelijk van een taal ) is sowieso al niet handig meer.

[Reactie gewijzigd door CH4OS op 22 juli 2024 23:50]

[djiwie]

Je hebt helaas een verkeerd beeld van HTTPS :-)

Bij HTTPS wordt de hele verbinding versleuteld, inclusief de URL. Het maakt dus niet uit of je een GET, een POST of een andere method gebruikt. Alles is versleuteld, de URL, de method (GET/POST/etc.), je headers, cookies, alles. Het enige dat een provider/overheid zou kunnen zien is het ip-adres waarmee je verbindt en de hostname van de website. Maar het maakt nogal uit of je huisarts.nl/soa zit of huisarts.nl/hoofdpijn (bij wijze van spreken), en dat deel kunnen andere partijen dus niet zien.

Het verschil tussen GET en POST is overigens dat je een POST moet zien als een actie die je maar één keer uit zou moeten voeren (zoals het plaatsen van een reactie op tweakers bijvoorbeeld). Een GET is dan weer bedoeld voor acties die veilig herhaald kunnen worden en die gecached kunnen worden (zoals het opvragen van een nieuwsbericht).

[svennd]

Verzenden van gegevens werkt vrijwel steeds met post. Get is enkel in gebruik voor navigatie. Https gaat ook niet over de URL, maar de inhoud.

[EraYaN]

HTTPS gaat wel degelijk over de URL. Eigenlijk over iedere byte die er uitgewisseld wordt nadat de TLS tunnel is opgezet, dus het hele HTTP verzoek. NU is het zo dat het domein wordt meegestuurd met de eerst connectie poging om SNI (meerdere domeinen voor TLS op 1 IP adres) te laten werken.

[Panoroma]

Vooral in overheidssectoren is het vaak een compatibiliteitsprobleem. Je werkt met een hoop systemen die met elkaar samenwerken, maar die vaak ook best verouderd zijn en een beveiligde verbinding via bijvoorbeeld poort 443 simpelweg niet ondersteunen. Op zijn minst is er een beetje vooruitgang, maar ik hoop wel dat er snel verandering komt in de manier hoe zorginstellingen informatie opslaan en beveiligen.

[CH4OS]

SSL/TLS verkeer is dan ook nog eens niet per se gebonden aan poort 443, hoewel dat in principe de standaard is, maar een applicatie kan en soms zelfs moet daarvan afwijken.

[kodak]

Ik denk dat het echte nieuws niet is dat een kwart van de websites geen ssl gebuikt maar dat een security bedrijfje met een amateuristisch onderzoek al aandacht kan genereren voor een probleem waar ze niet over uitleggen of dat echt een probleem is.

De Telegraaf schreeuwt dat dus een kwart van de websites onveilig is en beide media outlets wijzen gelukkig nog op de nuance dat dit niets zegt of een website veilig is.

Je zal mij niet horen zeggen dat een veilige verbinding niet belangrijk is. Maar het niveau van dit soort onderzoeken, hoe het in de media komt en welke amateuristische conclusies er bij worden getrokken stoort me.

Berichten over een specifieke beveiliging of gebrek er aan doen beveiliging niet alleen goed. Het brengt ook schade toe. Beveiliging is zelden een kwestie van 1 ding doen en je bent klaar. Maar ook nu weer gaan de berichten er nauwelijks over wat het echt betekent dat ssl ontbreekt of is toegevoegd. Ik denk dat de meeste mensen geen flauw benul hebben dat dit niet gaat om ssl of veiligheid maar om vertrouwen en kans. En dat bijna niemand kan uitleggen waarom ze vertrouwen hebben of waar die kans vanaf hangt, dat lijkt bijzaak. Dan vraag ik me toch af of het dat bedrijf of de media om de resultaten ging of om het genereren van inkomsten.

[mocean]

Klopt, door slechte campagnes en slechte voorlichting wordt nu elke site met SSL en slotje gezien als 'veilig', dus alle fishers hebben nu SSL en men trapt er weer in....