‘Meeste bedrijfssites versturen gevoelige gegevens onveilig’

Honderdduizenden zakelijke websites laten gebruikers gevoelige informatie verzenden zonder dat daarvoor van een beveiligde verbinding gebruik wordt gemaakt, blijkt uit een onderzoek van domeinbeheerder SIDN en MKB Servicedesk dat woensdag wordt gepubliceerd. Dat meldde Nu.nl onlangs. De ‘gevoelige gegevens’ zijn meestal NAWE-gegevens, maar ook inloggegevens en wachtwoorden komen voor. Maar liefst 86% van de onderzochte sites doet dat zonder ‘slotje’, https dus. Maar is dat dan verplicht?

Het laten insturen van persoonsgegevens – ook triviale zoals naam en adres – via een website of andere internetdienst mag alleen als de eigenaar daarvan zorgt voor adequate beveiliging. Dat staat al sinds 2000 in de wet (artikel 13 Wet bescherming persoonsgegevens), maar nergens staat wat dat dan precies inhoudt. Er is dus geen eis dat je beveiliging gecertificeerd moet zijn of zelfs maar aan bepaalde specifieke eisen moet voldoen.

De vraag wat ‘adequaat’ is, is dus een lastige om in het algemeen te beantwoorden. Je moet een afweging maken van de risico’s bij een lek tegenover de kosten en moeite om maatregelen te nemen. Perfectie wordt niet verlangd, en het kan ook prima zo zijn dat je bij formulier A een andere beveiliging hanteert dan bij formulier B. Waar het vooral om gaat, is dat je kunt onderbouwen waaróm je voor die of die maatregelen hebt gekozen (of juist waarom je die hebt weggelaten).

Specifiek bij contactformulieren kun je je afvragen of het echt wel nodig is, een SSL-certificaat. Ik zie het nog steeds niet, dat risico. Daar staat tegenover dat SSL tegenwoordig best goedkoop is (zowel qua cpu als qua prijs) en dus eigenlijk een no-brainer zou moeten zijn om toe te voegen. Dus dan wordt het wel een beetje theoretisch verhaal, er kan weinig misgaan maar hoe moeilijk is de maatregel nou?

Bij een login/wachtwoord voelt dat net anders. Daar is er voor mij geen excuus om zonder ssl te werken. Met dat account kun je allerlei dingen, en daarmee zijn er reële mogelijkheden voor fraude of overlast. Dan is de afweging snel gemaakt: no-brainer ter voorkoming van overlast, dat moet gewoon.

Arnoud

25 reacties

  1. SSL is tegenwoordig ook gratis en betrouwbaar te verkrijgen bij https://letsencrypt.org/ Ik zou SSL, salted goed encrypted passwords in ieder geval als een standaard zien die iedere website minstens moet hanteren. Maar ja, dat die dingen zo simpel zijn en bijna niks extra’s kosten wil nog niet zeggen dat iedereen ze heeft. Om over legacy systemen maar niet te spreken.

      1. Bij Let’s Encrypt zijn de certificaten wel helemaal gratis. Er zijn nog wel kosten doordat een systeembeheerder even aan de slag moet, en doordat je daarna iets meer hardware/elektriciteit nodig hebt om het zelfde aantal bezoekers aan te kunnen, maar dat laatste valt waarschijnlijk weg in de marges die je normaal toch al in bouwt. Wat dat eerste betreft: voor eenvoudige sites zou dat in een halve dag geregeld moeten zijn (en dan reken ik het nog ruim). Ik heb het zelf in mijn vrije tijd gedaan voor een thuis-server, en daarbij heb ik het mezelf extra moeilijk gemaakt door af te wijken van de standaard-procedures (zoals gebruikelijk ben ik eigenwijs en heb ik mijn eigen eisen). Voor ingewikkeldere sites zou het natuurlijk meer werk kunnen zijn, maar ingewikkeldere sites zullen vaak services met een grotere omzet bedienen, dus ook daar zie ik geen groot probleem.

        1. De complexiteit van de site heeft geen invloed op hoe makkelijk of moeilijk implementatie van een TLS beveiliging is.

          De gebruikte techniek daar in tegen wel. (word er enkel gewerkt met een Apache HTTPD/ nginx/lighthttpd server(s) dan is implementatie geen probleem. Als je gebruik maakr van perl / python / java dan is overstappen naar TLS wel wat meer werk.

          TLS werkt op de transport layer dus zit ‘voor’ je de HTTP behandeld. Dit betekend ook dat voor ruim 75% van de websites in nederland ze TLS kunnen implementeren zonder dat de website hier zelf invloed van zou hebben (op aanpassing van wat hyperlinks na dan. maar goede webdesigners maken hun sites’s zo dat het niet uitmaakt of ze onder HTTP of HTTPS worden gehost. En voor site’s waar dit niet in is heb je de mogenlijkheid om een bepaalde header mee te sturen waardoor de browser dit voor je doet.

  2. Ik snap de discussie niet helemaal of je wel of niet een TLS verbinding (en Certificaat) moet hebben voor je website. Ik vind zelf (als IT-professional) namelijk dat er bar weinig plaatsen en redenen zijn om geen Certificaat en TLS te gebruiken. De redenen die ik ken om TLS te gebruiken zijn:

    - TLS maakt integriteit van je data mogelijk (dat is 2 kanten op).
      Dus niet alleen kan jij er van uit gaan dat de data niet beïnvloed word naar jouw toe, 
      de ander kan ook er van uit gaan  dat de data niet beïnvloed word naar jouw toe.
      Dit betekent dus ook dat de data niet te injecteren is met elementen van derde (met goede of kwade zin).
     - TLS maakt autoriteit van je data mogelijk (dat je weet van wie het af komt).
      In een Certificaat staat namelijk door welke entiteit deze is afgegeven, en welke deze heeft aangevraagd. 
    - TLS (voor websites) scoort hoger bij zoekmachine resultaten,
     - Een niet TLS verbinding word steeds vaker aangemerkt als onveilig en ook zo behandeld.
      Dat betekend dat ze vaker worden gestopt met laden of enkel na bevestiging worden getoond.
    
    De redenen die ik ken om geen TLS te gebruiken zijn:
    - TLS boven op een andere encryptie laag kost enkel meer geld en voegt niets toe.
      Dit kan bij eigen geschreven software sprake van zijn, niet bij websites.
    - De verbinding moet kunnen worden ge redirect worden..
      Dit is eigenlijk allen van toepassing op de site neverssl.com.
    - De website is een Repository die door andere technieken word beveiligd.
      Dit is niet altijd van toepassing.
      Maar er zijn Linux Distro's waar dit zo werkt (voor installatie moet de key al bekend zijn op jouw computer, 
      en alle bestanden zijn ondertekend met zo een key). (dit lijkt dus op de eerste situatie)
    

    Kosten vind ik een non argument want: Zakelijk beken zijn de kosten te laag om er al een afweging van te maken (10 minuten er over nadenken kost al meer geld dan het TLS certificaat). De winst voor het bedrijf vooral vertrouwen is dat je uitdraagt. Een ieder die je site bezoekt kan er op vertrouwen dat je jouw best hebt gedaan veilig te werken en dat de data-integriteit word gewaarborgd. (in ieder geval voor zolang de data in transport is)

    1. Dank je voor deze analyse. Ik ben het er hartgrondig mee eens, maar ik weet ook dat veel bedrijven in de praktijk er toch moeite mee hebben. Hun hoster biedt het niet als faciliteit, het neefje dat de website bouwde weet niet hoe dit moet of de hoster/webdeveloper ziet dit als leuke melkkoe en vraagt de hoofdprijs om het in te regelen.

      1. Als je hoster dit niet (goed) aanbied of gewoonweg te veel geld voor vraagt, mischien eens een andere hoster regelen. Ik weet dat het bedrijf waar ik voor werk het grootste deel van de kosten al verwerkt heeft in de hosting kosten. En dat de meer prijs er enkel is voor als het certificaat door ons moet worden aangeschaft worden. Wij helpen klanten met hun keuze voor Certificaat leverancier als zij fit willen en dragen er zorg voor dat de beveiliging op orde is zoals te controleren is met Qualys SSL labs.

  3. Het probleem met SSL is niet zozeer het hosten maar het toepassen ervan op de web server. Zeker als je meerdere domeinnamen binnen dezelfde web server hebt draaien wordt het soms nog lastig om alles goed aan de praat te krijgen. IIS, bijvoorbeeld, gebruikt een IP adres, port en host header als informatie om de juiste site terug te geven. Dan kun je dus 20 domeinnamen en 20 verschillende site op 1 server hebben, wat handig is als je toch niet al te veel verkeer hebt.

    Maar bij HTTPS/SSL werkt dat niet meer. Dat komt omdat de ‘handshake’ uitgevoerd wordt voordat de host header aankomt. En dus weet de server niet welk SSL certificaat gebruikt moet worden. En nu kun je met een wildcard certificaat wel een onbeperkt aantal subdomeinen ondersteunen, maar nog steeds niet twee of meer domeinen. Op deze site wordt het een en ander hierover uitgelegd.

    Je hebt dan een SAN certificaat nodig. Die kosten al snel $99 per domein per jaar maar met allerlei kortingen gaat die prijs nog wel iets omlaag. Voor een bedrijf is dat nog wel te betalen maar het tikt op een gegeven moment snel aan. Of je moet naar een nieuwere IIS versie, wat meestal betekent dat de server software een upgrade moet krijgen. En de kosten daarvan kunnen aardig oplopen. In manuren, wel te verstaan! Plus, je hebt een beheerder nodig die weet hoe dit allemaal werkt en beschikbaar is om de boel te blijven onderhouden.

    Als ontwikkelaar heb ik sowieso een hekel aan SSL omdat het de boel alleen maar moeilijker maakt in de praktijk. Het wordt daarbij lastiger als je niet een site bouwt maar een App die gebruik maakt van een SOAP/REST web service. Afhankelijk van de gebruikte programmeertaal en oplossingen moet je dan zelf ook aan de slag om die beveiligde verbinding te kunnen gebruiken. En ja, daar irriteer ik mij al bijna 15 jaar aan, omdat deze materie lastig uit te leggen is aan minder ervaren ontwikkelaars terwijl er veel mis kan gaan waardoor kwetsbaarheden ontstaan. Plus het probleem dat je certificaten keer op keer moet verlengen en dat wordt soms wel eens vergeten en ligt de site plat tot een nieuw certificaat is geïnstalleerd.

    Ik vind SSL dan ook gewoon een noodzakelijk kwaad. Ja, het is belangrijk voor de bescherming van persoonsgegevens maar volgens mij moet beveiliging veel makkelijker te implementeren zijn. Ik snap de materie maar krijg het niet goed uitgelegd aan beginners en aan opdrachtgevers waarom het zo moeilijk is… Want hoe leg je uiteindelijk uit dat het meer is dan een SSL certificaat gewoon met een knopje binnen IIS aanmaken en direct te gebruiken? Dat je tientallen stappen moet uitvoeren om het werkende te krijgen en hoe gevoelig het is waardoor de site opeens niet meer goed werkt…

    1. Het probleem met SSL is niet zozeer het hosten maar het toepassen ervan op de web server. Zeker als je meerdere domeinnamen binnen dezelfde web server hebt draaien wordt het soms nog lastig om alles goed aan de praat te krijgen. IIS, bijvoorbeeld, gebruikt een IP adres, port en host header als informatie om de juiste site terug te geven. Dan kun je dus 20 domeinnamen en 20 verschillende site op 1 server hebben, wat handig is als je toch niet al te veel verkeer hebt. Maar bij HTTPS/SSL werkt dat niet meer. Dat komt omdat de ‘handshake’ uitgevoerd wordt voordat de host header aankomt. En dus weet de server niet welk SSL certificaat gebruikt moet worden. En nu kun je met een wildcard certificaat wel een onbeperkt aantal subdomeinen ondersteunen, maar nog steeds niet twee of meer domeinen. Op deze site wordt het een en ander hierover uitgelegd.

      Dit is echter alleen met webservers die geen SNI ondersteunen. een zeer kleine subsectie van het internet kan dit inderdaad nog niet gebruiken, is voor Nederland echter niet interessant omdat dit onder de 0.2 % is (bron). Ik zou om dit soort problemen te voorkomen zou ik zo wie zo een Proxy met SSL offloading gebruiken zoals nginx of Apache HTTPD, deze kunnen dan het verkeer doorsturen naar de IIS welke dan enkel met ‘echte’ verkeer hoeft bezig te zijn.

      Overigens wat zij zegt dat de host header pas later aankomt klopt niet meer. de SNI uitbreiding maakt dat de host gewoon word mee gestuurd. waardoor je het verkeer per domein kunt routen voordat de TLS verbinding word opgezet.

        1. Ik snap niet hoe je bij gebruik van een SSL-offloading proxy je IIS server moet updaten. Je gebruikt namelijk een nieuw blokje er tussen die je onafhankelijk kunt onderhouden (ala microservice). niet kunnen upgraden zou voor mij altijd een no-go opleveren vanuit systeem beheers oogpunt. ( maar dat is mijn persoonlijke mening en word wel eens overruled door management, helaas). Overigens heb je (als het goed is) gewoon een test omgeving om de techniek eerst te testen voordat je m live uitrolt. zodat het argument “mogelijk breekt er iets” eigenlijk niet valide is mits er een adequate test strategie is.

          1. Simpel. Ook SSL-Offloading is niet een eenvoudige technieg en dus zul je een redelijk ervaren beheerder nodig hebben om dat uit te kunnen voeren. Sowieso eentje die aan management kan uitleggen wat het is! Het is geen click-installatie waarbij je gewoon next-next-next-finish-close klikt.

            Daarnaast zijn er diverse methodes om dit toe te passen, inclusief het gebruik van een extra kaart voor in een PCI-slot of zelfs een extra server. En dat brengt weer kosten met zich mee, plus extra onderhoud.

            Bovendien, voor ieder domein een eigen SSL Offloader installeren maakt het geheel nog complexer. Het probleem is immers dat je meerdere domeinnamen wilt ondersteunen voor meerdere sites vanaf een enkele server. Waarbij je dus een enkele server gebruikt omdat de verwachte hoeveelheid verkeer per site laag wordt ingeschat. Als iedere site 100 bezoekers per dag trekt hoef je niet een compleet serverpark aan te leggen maar kunnen 20 sites makkelijk op 1 server…

            En dan zijn er natuurlijk de vele hosted web servers. Ik heb er eentje bij TransIP, naast een kleine PC die ik thuis gebruik. De server thuis is mijn test-omgeving terwijl de TransIP versie voor productie is bedoeld. Maar als ik een site echt goed vind stuur ik hem liever door richting de Cloud en ga ik hem op Azure hosten. Maar zover ben ik nog niet met mijn hobby-projecten. (Maar mijn blog dan weer wel.)

            Maar uiteindelijk merk jij ook op dat jij als beheerder veel zou willen en veel eisen kunt stellen, maar uiteindelijk is het management die knopen moet doorhakken. “Management zegt Nee” is een veelgehoord probleem. En vooral de wat kleinere bedrijven (50 medewerkers of minder) hebben vaak problemen met het vinden van ervaren personeel, maar ze hebben wel allemaal een website vol gevoelige gegevens…

            Vandaar dat de techniek toch echt een stuk eenvoudiger moet worden. Jij snapt het wel, ik snap het wel, maar veel kleine bedrijven snappen het niet.

            1. Het idee is juist dat je 1 SSL-offloader hebt die het verkeer proxied naar n-IIS services (kunnen best op 1 host staan, moeten alleen een ander poortje hebben). TLS is inderdaad niet triviaal, maar het vereist tegenwoordig ook zelden nog dedicated hardware die niet aanwezig is. (meeste systemen hebben alles al on-board tegenwoordig). Overigens ken ik meer ‘kleine’ bedrijfjes die hun zaken op orde hebben dan grote. Dus ik vermoed dat de grote van een bedrijf niet uitmaakt. de bedrijfsmentaliteit wel.

    2. Afhankelijk van de gebruikte programmeertaal en oplossingen moet je dan zelf ook aan de slag om die beveiligde verbinding te kunnen gebruiken.
      Op gebied van software zijn velen inderdaad nog steeds erg goed om de impact van veranderingen te onderschatten. Maar zijn in jouw voorbeelden dan niet heel verkeerde architecturen gekozen (door de juridische bril)? De wet is alweer van 2000.

      1. Probleem is meer dat wetgeving en ICT niet erg goed met elkaar samen lijken te gaan. Software is immers pure logica terwijl wetgeving soms enorm onlogisch kan zijn. In de ICT ben je dan ook vaak bezig om een kubus in een rond gat te stoppen, want de wet zegt dat je een rond gat moet gebruiken maar de opdrachtgever wil een kubus…

        En er is vast gekozen voor verkeerde architectuur maar dat gebeurt behoorlijk vaak. Dat komt omdat in de ICT er enorm veel verandert en het lastig blijft om bij te blijven, terwijl er eigenlijk ook veel eigenlijk niet verandert. Zo komen er steeds meer nieuwe talen bij zoals Julia, Go, Rust en noem maar op terwijl oude talen zoals C, C++ eb Java ook nog steeds populair zijn. Of er vinden veranderingen plaats aan een bestaande programmeertaal die juist weer door velen worden afgewezen, zoals by Python 2/3 is gebeurd. Of bij PHP 6, die eigenlijk nooit aansloeg. En nu zitten PHP ontwikkelaars ook weer met de keuze of ze bij versie 5 blijven of toch overgaan naar versie 7.

        De veranderingen worden ook niet onderschat maar worden gewoon niet bijgehouden omdat er al teveel is geinvesteerd in de vooraf gaande technieken. Eindgebruikers willen helemaal niet over naar iets nieuws, maar willen iets dat ze kennen en gewoon oud en bewezen is. Zo ken ik bedrijven die nog steeds met VB6 ontwikkelen simpelweg omdat ze dat altijd al gedaan hebben en ze niet de investering willen maken om alles opnieuw te herschrijven.

        En dan ga ik niet eens beginnen over de vele standaarden en hoeveel sommige oplossingen afwijken van die standaarden! Okay, een beetje dan. Zo werd mij ooit gevraagd om in .NET een site te maken die gebruik moest maken van een SOAP server die in PHP was ontwikkeld. Klinkt eenvoudig, toch? Ze hadden zelfs broncode meegeleverd om die server aan te roepen. In PHP, dat dan weer wel. En nee, geen WSDL dus die SOAP snel importeren in .NET was er niet bij. Ofwel, ik kon alle 75 methode-aanroepen van die SOAP server handmatig gaan zitten programmeren. Niet dus! (Heb uiteindelijk code geschreven die de PHP broncode converteerde naar .NET code en ben die gaan gebruiken om er vervolgens achter te komen dat de SOAP server ondertussen weer was aangepast en de meeste methodes niet eens meer werkten of gewoon niet geimplementeerd waren.)

        Mijn ervaring met diverse ICT-projecten is dat er enorm veel geklungeld wordt en het een wonder is dat er nog zoveel goed gaat. Het is alsof iedereen zijn eigen auto in elkaar zet en daarmee over de A2 van Amsterdam naar Maastricht gaat racen…

  4. Specifiek bij contactformulieren kun je je afvragen of het echt wel nodig is, een SSL-certificaat.

    Jazeker. Om een aantal redenen:

    • 1. Jij kunt als websitebeheerder niet voor je gebruikers beslissen of zij hun informatie als gevoelig beschouwen, en of zij een verbinding gebruiken waar versleuteling zelfs op lokaal niveau noodzakelijk is (denk hierbij aan bijvoorbeeld een publiek WiFi access point).
    • 2. Als een site niet volledig, 100% over TLS geleverd wordt, zijn downgrade attacks mogelijk; ik kan als willekeurige aanvaller bijvoorbeeld op alle niet-TLS-gebruikende pagina’s op actieve wijze de URL van de inlogpagina wijzigen naar mijn eigen phishing-pagina. Dan kun je wel TLS gebruiken voor je inlogpagina, maar dat heeft geen zin als de gebruiker nooit op die pagina komt.
    • 3. Een belangrijke “aanvalsvector” voor het onderscheppen van gevoelige data, is om data te analyseren die an sich niet gevoelig lijkt, maar dat in combinatie met andere data wel is omdat het patronen toont. Ik noem maar even een voorbeeld: als jij een publieke CVE-feed volgt en vervolgens een publieke pagina met EOL-datums opzoekt voor een stukje software dat op die feed genoemd wordt… grote kans dat er wat bij je te halen valt, en dat kan ik weten ondanks dat je enkel “niet-gevoelige” data opgezocht hebt.

    Dus ja, ik zou stellen dat TLS een vereiste is voor iedere hedendaagse site, dat het noodzakelijk is om dit over de gehele site toe te passen (met HSTS bovendien), en dat er echt bar weinig redenen meer bestaan om het niet te doen. Geen TLS gebruiken valt wat mij betreft dan ook gewoon onder nalatigheid.

    EDIT: Je <ol>-stylesheetje is kapot, denk ik. Er staan geen nummers voor.

  5. HTTPS is gewoon een must voor iedere site, geen excuses en hier zijn twee aanvullende redenen: 1) Als je bij een webwinkel met van alles bezig bent en je ziet geen HTTPS, hoe betrouwbaar komt dat dan over? 2) Zeker met openbare WIFI weet je niet of je naar een nepsite gebracht wordt die eruit ziet als een echte site, met HTTPS maak je het weer een heel stap moeilijker.

    Stel, je zoekt een virusscanner…. hahaha, tot van de week was https://www.mcafee.com nog zonder https… maar goed, ik had een melding ervan gemaakt, dus misschien heeft dat geholpen, maar stel je zoekt een virussscanner en de website is geen https, en je download daar wat van, je hebt dan werkelijk geen idee of je een virus download…

    https geeft vertrouwen en dat is al voldoende reden om ssl/tls in te zetten, ik weet in ieder geval dat ik geen zaken doe als een bedrijf de basis van beveiliging niet eens kent, dus mijn handel krijg je niet.

    en https geeft dus meer zekerheid dat je dus ook daadwerkelijk de site voor je hebt die je denkt voor je te hebben, al is het steeds lastiger.

    In dan kader stel ik dit artikel voor… over de line of death… ik vond het leerzaam en hopelijk jij ook: https://textslashplain.com/2017/01/14/the-line-of-death/

    Thank me later…

    1. Nee, die mening deel ik niet en dat komt omdat de veiligheid van HTTPS en SSL mede afhangt van netneutraliteit en de betrouwbaarheid van de internet-provider. Over een publieke WIFI verbinding zou ik sowieso niet graag willen inloggen op een beveiligde site wegens het nog steeds bestaande man-in-the-middle probleem.

      Wat is namelijk het probleem? Sommige providers bieden wel Internet aan maar gebruiken daarbij een eigen certificaat om beveiligde sites om te leiden. Stel, jij maakt gebruik van Arnouds gratis WiFi om met mijn beveiligde site contact te maken. Echter, Arnoud heeft een systeem opgezet die deze beveiligde aanvragen afvangt. Je krijgt dan een certificaat van Arnoud voor je verbinding in plaats van die van mij. Vanaf Arnoud’s router wordt dan een tweede verbinding aangevraagd naar mijn website en zo kan Arnoud jouw web-request doorsturen naar mijn website, met volledige inzage van wat jij opvraagt en ontvangt!

      Hoe je dar voorkomt? Nou, dan moet je doen wat veel mensen nalaten, namelijk controleren of het certificaat door mij is uitgegeven of niet. Zoniet, dan wordt ge verbinding gekaapt!

      Malware op je computer kan diezelfde truc uitvoeren door alle internetverbindingen om te leiden over een eigen certificaat en zo gewoon alles af te luisteren terwijl jij denkt dat je veilig bent. Het enige wat ze moeten doen is gewoon tussen jou en de andere site in zitten. Zelfs mijn provider zou zo al het dataverkeer kunnen lezen wat mijn site ontvangt door gewoon ertussen in te gaan zitten.

      De zekerheid die je dus hebt is een schijnzekerheid. Ja, het is lastiger om HTTPS verkeer te onderscheppen en er zijn methodes voor om dit te detecteren. Sommige browsers zoals Chrome hebben ook enige bescherming hiervoor ingebouwd maar het blijft een bekend risico. Maar de techniek voor deze beveiliging is voor veel gebruikers al veel te ingewikkeld. En daardoor gaan mensen gewoon bepaalde zaken negeren die ze beter niet kunnen negeren…

      Free Wi-Fi and the dangers of mobile Man-in-the-Middle attacks

      95% of HTTPS servers vulnerable to trivial MITM attacks

      Want to Be a “Man in the Middle” of a Mobile Communication? It’s Easier Than You Think

      Detect man-in-the-middle on server side for HTTPS

      Man-in-the-middle attack – Wikipedia

      1. dat komt omdat de veiligheid van HTTPS en SSL mede afhangt van netneutraliteit en de betrouwbaarheid van de internet-provider. […] Nou, dan moet je doen wat veel mensen nalaten, namelijk controleren of het certificaat door mij is uitgegeven of niet.

        Dit is kul. TLS is juist ontworpen om dit probleem te voorkomen. Een router kan helemaal geen TLS-beveiligd verkeer afvangen en MITMen, omdat deze geen CA-gevalideerd certificaat heeft voor het betreffende domein. De gebruiker ziet dan dus een felrode pagina met een waarschuwing. Ook je bewering dat “veel mensen dit nalaten” is onzin; dit gebeurt automatisch door browsers, en daar hoeft de gebruiker verder niets aan te doen.

        Wat betreft de links die je hebt bijgevoegd; dit gaat niet over het onderscheppen van TLS, maar het onderscheppen van onversleuteld HTTP om zo een doorverwijzing naar HTTPS (HTTP + TLS) te voorkomen. Dit is een probleem dat enkel in browsers bestaat, en is gemakkelijk op te lossen door middel van HSTS.

        Malware op je computer kan diezelfde truc uitvoeren door alle internetverbindingen om te leiden over een eigen certificaat en zo gewoon alles af te luisteren terwijl jij denkt dat je veilig bent. Het enige wat ze moeten doen is gewoon tussen jou en de andere site in zitten.

        Als je malware op je computer hebt, dan maakt TLS (transport encryption) niets uit, hoe je het ook implementeert. De malware kan ook gewoon je toetsaanslagen registreren, screenshots maken, enzovoorts – dit is helemaal geen netwerk-gebaseerde aanval, en heeft dus helemaal niets met TLS of de waarde van TLS te maken. Als je malware op je systeem hebt is het sowieso gewoon “game over”.

        Zelfs mijn provider zou zo al het dataverkeer kunnen lezen wat mijn site ontvangt door gewoon ertussen in te gaan zitten.

        Hoe krijgt jouw provider die malware dan op jouw computer? Want ook zij kunnen niet zomaar TLS-verkeer afvangen als ze geen controle hebben over het systeem dat het verifieert.

        1. TLS is juist ontworpen om dit probleem te voorkomen.
          Was dat maar waar… Het kan echter gewoon omzeild worden.
          Een router kan helemaal geen TLS-beveiligd verkeer afvangen en MITMen, omdat deze geen CA-gevalideerd certificaat heeft voor het betreffende domein.
          Ik denk eerder aan providers. Een provider heeft prima mogelijkheden om gevalideerde certificaten aan te maken die op alle websites passen. Zeker voor mobiel Internet kan dit problematisch zijn als mensen de standaard ingebouwde browser gebruiken op het mobieltje dat ze van hun provider ontvingen.
          De gebruiker ziet dan dus een felrode pagina met een waarschuwing.
          Of niet. Een provider kan in principe on-the-fly nieuwe certificaten aanmaken die door jouw mobiel worden geaccepteerd omdat je provider als een veilige CA is ingebouwd. Als een certificaat dan echt een domeinnaam moet hebben dan maken ze er eentje met domeinnaam die ze vervolgens zelf ondertekenen. POEF! Betrouwbaar!
          Wat betreft de links die je hebt bijgevoegd; dit gaat niet over het onderscheppen van TLS, maar het onderscheppen van onversleuteld HTTP om zo een doorverwijzing naar HTTPS (HTTP + TLS) te voorkomen.
          Er staat toc echt HTTPS in de titel 95% of HTTPS servers vulnerable to trivial MITM attacks. Een MITM aanval is erg moeilijk voor hackers, maar niet voor providers. Vandaar dat netneutraliteit zo belangrijk is. Zeker aangezien de mobiele markt steeds verder groeit. Je moet namelijk zorgen dat het certificaat dat wordt gebruikt bij de hack wordt herkend als een geldig certificaat en dat kan als je als trusted CA staat geregistreerd op de computer van de gebruiker. Iets dat iedere mobiele provider is op de mobieltjes van hun klanten.

          Dit artikel geeft ook aan wat het grootste probleem is, namelijk dat browsers standaard eerst HTTP proberen ans de gebruiker geen protocol meegeeft in de URL. En velen doen dat niet! Als de server dan een redirect doet naar HTTPS dan kan de MITM perfect werken maar krijgt de bezoeker nooit een waarschuwing te zien omdat ze over HTTP blijven communiceren. En daarom is inderdaad HSTS nodig om extra beveiliging te bieden. Maar je browser moet het ondersteunen en de web server moet het ook ondersteunen. En de web beheerder moet het gebruiken en dat gebeurt meestal niet!

          Als je malware op je systeem hebt is het sowieso gewoon “game over”.
          Daar zijn wij het over eens. Maar ik focus vooral op de mobiele markt met tablets en mobieltjes omdat die steeds vaker gebruikt worden, zowel in combinatie met diverse apps alsmede via de browser zelf. Alleen, zowel de fabrikant alsmede de provider kan ervoor zorgen dat er extra backdoors op het mobieltje komen waar je als gebruiker niet van af komt. Dit is vooral een groot probleem op Android telefoons, waar providers graag een mobieltje meeleveren omdat ze dan extra software kunnen mee installeren waar je dan niet vanaf komt. Met de iPhone is dat lastiger…
          Hoe krijgt jouw provider die malware dan op jouw computer?
          Simpel. Ik bestel een mobiele telefoon bij mijn abonnement of ik vraag een nieuwe aan bij het verlengen ervan. Vervolgens ontvang ik dan het bestelde apparaat inclusief extra provider-software. Diep ingebouwd binnen Android, overigens. Verwijderen is dus onmogelijk zonder de mobiel te rooten. Maar ja, de meeste mensen met een mobieltje zijn daar niet eens van bewust.

          Op desktops is inderdaad lastiger hoewel dat vroeger met dial-up Internet nog wel te doen was. Je provider leverde dan namelijk diskettes of een CD’tje met software erop om de verbinding te kunnen maken via je PC. Daar kan dus malware bij. Providers kunnen daarnaast hun klanten extra software aanbieden die gratis te installeren is en dus ook malware kan bevatten.

          Maar de desktop markt is niet eens zo interessant meer omdat veel mensen alles via hun mobieltje doen. Daar is de grootste kwetsbaarheid vandaag de dag omdat veel mobiele gebruikers van alles installeren zonder echt op de veiligheid te letten.

          Want ook zij kunnen niet zomaar TLS-verkeer afvangen als ze geen controle hebben over het systeem dat het verifieert.
          Da’s waar. Maar uiteindelijk gaat al het verkeer via hun systemen en dat geeft providers enorm veel mogelijkheden om alsnog het dataverkeer uit te lezen. Dat kan door software op het mobieltje, via de provider van de bezoeker en via de provider van de web host.

          Maar het probleem blijft gewoon dat de techniek dusdanig lastig is dat veel mensen het niet goed begrijpen en erop vertrouwen dat het wel veilig is. De realiteit is dat veiligheid meer een illusie is en dat er altijd kwetsbaarheden zullen zijn die misbruikt kunnen worden. Inderdaad, TLS legt de lat een stuk hoger maar is nog niet hoog genoeg. En daarmee wil ik het volgende uit het NetCraft artikel even uitlichten:

          Some smaller scale attacks can be carried out very easily – for example, if an attacker sets up a rogue Wi-Fi access point to provide internet access to nearby victims, he can easily influence the results of their DNS lookups.

          En daar zit ook een groot risico in. Je gebruikt dan een open WiFi punt maar deze is dan aangepast om je beveiligde verbinding te “ontveiligen”. HSTS is dan ook een must, maar te weinig bedrijven en web beheerders zijn zich hiervan op de hoogte.

          Daarnaast zijn moderne browsers tegenwoordig voorzien van allerlei extra controles. Jammer alleen dat er nog zoveel gebruikers oudere computers en mobieltjes gebruiken. Android 2.2 en 4.0 schijnen nog steeds populair te zijn en niet alle mobieltjes kunnen upgraden naar de nieuwste versie. En door de prijs van de iPhone zijn maar weinig mensen bereid om hun oude iPhone 4/5/6 om te ruilen voor een nieuwere. Hij werkt toch immers nog? En het is dat Microsoft de update van Windows 10 bij zo’n beetje bij iedereen door de strot heeft geduwd want anders zouden er nog steeds veel gebruikers zijn die de kwetsbaardere versies van Windows XP, Vista, 7 en 8 zouden blijven gebruiken. (En nog steeds zijn teveel mensen met oudere besturingssystemen aktief.)

          Het blijft dan ook een schijnveiligheid omdat er nog steeds veel mis kan gaan.

          1. Ik heb het idee dat een paar mensen hier wat specifieke verschillen tussen technieken niet kennen en als gevolg daarvan onzinnige dingen roepen.

            TLS: of Transport Layer Security, is een techniek om een geëncrypte data verbinding op te zetten tussen 2 punten in een netwerk.
            PKI: of public-key infrastructure, is een set van methodieken om Certificaten voor gebruik met asynchrone cryptografie , Deze certificaten kunnen gebruikt worden voor authenticatie.

            Echter, voor TLS is geen certificaat nodig, enkel sleutels zijn nodig. (Er word dan een soort dummy certificaat gebruikt met enkel informatie over de sleutel). Je kunet een Certificaat gebruiken om de TLS verbinding mee te authoriseren (dit kan overigens van beide kanten).

            Een Certificaat gekocht bij een Certificate Authority is te gebruiken (mits op de juiste manier geconfigureerd / gekocht) voor meer dan alleen TLS. het kan bijvoorbeeld ook gebruikt worden voor het signeren van bestanden (zoals vaak bij programma’s gebeurt).

            De “Boom” die gebruikt is om een site te authenticeren is (vaak) simpel te inspecteren en als deze kleiner is dan 3 elementen dan weet je dat er mee gerommeld is ( dit ivm. conventies waar CA’s zich aan ‘moeten’ houden)

            Om een MiTM te doen zoals ‘Wim ten Brink” hier voorstelt is het noodzakelijk om of toegang te hebben tot een van de pre-authorizeerde CA’s (onwaarschijnlijk) of om een nieuwe CA-root toe te voegen aan de Boom van het device dat je wil beïnvloeden. Een actie die niet triviaal is en zelfs bij windows 95 een “vreemd” scherm opleverde om te doorlopen (dat wel te automatiseren was maar niet gemakkelijk).

            Jouw argument over iPhone’s is trouwens helemaal onzin. iOs support HSTS sinds versie 7bron, die tenminste te installeren is op al jouw genoemde toestellen (of hogere versies waar ook het mechanisme in zit)

            Da’s waar. Maar uiteindelijk gaat al het verkeer via hun systemen en dat geeft providers enorm veel mogelijkheden om alsnog het dataverkeer uit te lezen. Dat kan door software op het mobieltje, via de provider van de bezoeker en via de provider van de web host.

            Veel succes met het uitlezen van gencrypte data, zonder de sleutels kun je daar niets anders mee dan proberen te bruteforcen. En als het systeem goed opgezet is met “forward Secrecy” dan moet je ieder pakketje dus onafhankelijk gaan lopen bruteforcen. Niet onmogelijk uiteraard, maar wel zeer kostbaar en kost waarschijnlijk meer computing power dan er op de planeet is om realistisch te zijn.

            Overigens zou het doen wat jij voorstelt zeer waarschijnlijk vallen onder computervrede breuk (maar Arnoud is de jurist hier, niet ik). En ja je moet wat vertrouwen omdat de stof te moeilijk en specialist is om aan ‘Henk en Ingrid” over te laten.

            CA’s vertrouwen we omdat ze ’transparant’ werken (en worden ge audit om dit ook te bewijzen), en als ze er een zooitje van maken worden ze gewoon gedropt (zoals DigiNotar bijvoorbeeld)

            De realiteit is dat veiligheid meer een illusie is en dat er altijd kwetsbaarheden zullen zijn die misbruikt kunnen worden. Inderdaad, TLS legt de lat een stuk hoger maar is nog niet hoog genoeg.

            Ik vraag mij af waar ‘veiligheid’ geen illusie is. Echte veiligheid bestaat namelijk niet (niet als absoluut iets tenminste). Hoe hoog moet de lat dan volgens jouw? iedereen eerst een 16Kb sleutel laten invoeren voordat ze iets met een computer-systeem kunnen doen? zou wel veiliger zijn. maar ik denk dat er dan niet veel gebruikers meer zullen zijn. Computer veiligheid moet altijd afgewogen worden met de situatie waar het in gebruikt word. en gebruiksgemak van een systeem is zeer belangrijk! Kwetsbaarheden zijn van alle tijd en is geen argument om wat dan ook te doen, behalve de bug’s te fixen ;).

            1. Ik heb het idee dat wij gewoon van mening verschillen. Dat is verder prima. Even voor de duidelijkheid, ik heb het niet over een hacker die toegang probeert te verkrijgen maar de provider van je Internetverbinding! En nee, Ziggo en andere grote providers zullen dat niet snel doen maar een open WiFi punt kan hier wel voor misbruikt worden.

              Verder, HSTS is een techniek die pas sinds november 2012 is gepubliceerd dus alle systemen ouder dan dat die niet een meer recente update hebben gehad zijn hiervoor kwetsbaar. En op mobiel gebied zijn dat nog enorm veel apparaten!

              Het MITM probleem bij openbare Wifi-spots blijft dus bestaan hoewel HSTS dit wel kan blokkeren. Maar ja, dan moet je de betreffende site wel eerder hebben bezocht want HSTS is niets meer dan een methode om te zorgen dat de gebruiker altijd eerst naar de HTTPS site gaat, en eigenlijk nooit de HTTP versie.

              En dat het onder computervredebreuk zou vallen? Hackers boeit dat eigenlijk niet. Providers kunnen erdoor worden afgeschrikt maar zolang niemand het bekend maakt kunnen ze eigenlijk hun gang blijven gaan. En providers hebben in het verleden al de nodige misstappen gedaan. En bedenk wel dat je dit wereldwijd moet bekijken en niet alleen binnen nederland of Europa. Vanuit Noord-Korea zou ik niet graag gaan internet-bankieren bij de ING. Of sowieso mijn mobieltje aanzetten…

              En ja, DigiNotar werd hard gedropt. Dat geldt momenteel ook voor StartSSL/StartCom/WoSign die in het verleden gratis SSL-certificaten weggaf. En hoeveel andere CA’s zijn stiekem aan het prutsen zonder dat dit wordt opgemerkt? Ook een audit kan omzeild worden.

              En hoe hoog moet de beveiliging uiteindelijk worden? Dat is lastig, maar de techniek moet wel eenvoudiger in gebruik worden omdat er teveel fouten mee worden gemaakt en te weinig mensen het echt goed snappen. Zelfs experts onderling verschillen van mening over cruciale aandachtspunten. En dat geeft al aan waar de problemen vandaan komen. Het probleem op dit moment blijft de MITM waarbij encryptie het enigszins lastiger maakt maar dit alsnog omzeild kan worden.

               

              En dan is er dit: Gogo caught using fake Google SSL certificates. Opgemerkt omdat er stom toevallig een Google engineer aan boord stapte en het rode kruisje opmerkte.

              En deze methode, die geeneens rode kruisjes oplevert: Maintaining digital certificate security. Voor Google-sites en diverse andere sites is dit eigenlijk al geblokkeerd via public-key pinning maar de meeste sites gebruiken dat niet eens en nogmaals, ook dit is een lastige techniek.

              En Symantec heeft ook zitten klooien met SSL-certificaten voor Google…

              1. Ik heb het idee dat wij gewoon van mening verschillen.

                Nee, dit heeft niets met een meningsverschil te maken. Je hebt simpelweg ongelijk. Het MITMen van een TLS-verbinding is absoluut niet zo gemakkelijk als je het voorstelt.

                Verder, HSTS is een techniek die pas sinds november 2012 is gepubliceerd dus alle systemen ouder dan dat die niet een meer recente update hebben gehad zijn hiervoor kwetsbaar. En op mobiel gebied zijn dat nog enorm veel apparaten!

                Aangezien HSTS iets software-matigs is, betwijfel ik sterk of er nog veel apparaten zijn die serieus gebruikt worden voor browsen en geen HSTS ondersteunen. Ook oudere systemen krijgen updates.

                Even voor de duidelijkheid, ik heb het niet over een hacker die toegang probeert te verkrijgen maar de provider van je Internetverbinding! En nee, Ziggo en andere grote providers zullen dat niet snel doen maar een open WiFi punt kan hier wel voor misbruikt worden.

                Ja, daar heb ik het ook over. Dat kunnen ze dus niet zomaar.

                Maar ja, dan moet je de betreffende site wel eerder hebben bezocht want HSTS is niets meer dan een methode om te zorgen dat de gebruiker altijd eerst naar de HTTPS site gaat, en eigenlijk nooit de HTTP versie.

                Dit is onjuist, want HSTS preloading. En sowieso is het scenario dat jij omschrijft al erg zeldzaam – met iedere poging tot een MITM maak je jezelf als provider namelijk ook verdacht, en dus is het erg onwaarschijnlijk dat een provider constant MITMt. Maar zelfs als ze dat wel zouden doen, lost HSTS preloading dat gewoon op.

                En ja, DigiNotar werd hard gedropt. Dat geldt momenteel ook voor StartSSL/StartCom/WoSign die in het verleden gratis SSL-certificaten weggaf. En hoeveel andere CA’s zijn stiekem aan het prutsen zonder dat dit wordt opgemerkt? Ook een audit kan omzeild worden.

                Hier heb je een lijstje van incidenten dat ik bijhoud. De realiteit is dat het compromitteren van een CA erg duur is, en geen schaalbare aanval is. Hoewel dit dus wel een risico is bij gerichte aanvallen op “high-profile individuals”, is het dat niet voor de gemiddelde gebruiker.

                1. Nee, dit heeft niets met een meningsverschil te maken. Je hebt simpelweg ongelijk.
                  En dat is dus jouw mening. We verschillen dus van mening. Da’s niet moeilijk, toch?

                  Aangezien HSTS iets software-matigs is, betwijfel ik sterk of er nog veel apparaten zijn die serieus gebruikt worden voor browsen en geen HSTS ondersteunen.
                  Oh, zo naief! Natuurlijk, iedere gebruiker weet precies hoe ze updates moeten installeren en doen dat ook braaf iedere keer. Niemand die nog oude Android versies gebruikt of zo.

                  Was dat maar waar…

                  Ook oudere systemen krijgen updates.
                  Mijn ervaring met mobiele gebruikers is dat velen niet precies weten hoe de updates geïnstalleerd worden. En die updates gebeuren niet zo automatisch als je denkt. Je hebt immers een Internetverbinding nodig en dat betekent dat je telefoon mobiele data verbruikt. Maar dat kost weer geld dus is vaak de updates via de mobiele dataverbinding geblokkeerd om onverwachte kosten te vermijden. Blijft over het verbinden via WiFi, wat velen nog wel doen. Als ze thuis zijn, ten minste. Maar ook dan zijn er gebruikers die de updates weten over te slaan.

                  Het hoeven niet veel van dit soort gebruikers te zijn, maar ze zijn er wel.

                  Ja, daar heb ik het ook over. Dat kunnen ze dus niet zomaar.
                  En daarover verschillen wij van mening, omdat er in het verleden al diverse malen is aangetoond dat het wel gebeurt! En het enige wat providers ervan weerhoudt is de NetNeutraliteit wetgeving, want anders zouden ze maar wat graag al die communicatie onderscheppen voor marketingdoeleinden. In China is sowieso al gebleken dat er een levendige handel is in dit soort informatie die veelal via mobieltjes en internet zelf wordt verzameld. En ja, ik kijk ook naar het buitenland in deze discussie…

                  met iedere poging tot een MITM maak je jezelf als provider namelijk ook verdacht, en dus is het erg onwaarschijnlijk dat een provider constant MITMt.
                  Boeit alleen als netneutraliteit wordt ondersteund. Anders willen providers maar al te graag al jouw communicatie doorspitten omdat die informatie geld waard is!

                  Maar zelfs als ze dat wel zouden doen, lost HSTS preloading dat gewoon op.
                  Jouw blinde vertrouwen in deze techniek, die al diverse malen bewezen omzeild is, is wel komisch. Ware het niet dat dit toch echt een serieus probleem is.

                  De realiteit is dat het compromitteren van een CA erg duur is, en geen schaalbare aanval is.
                  Dat is het alleen als de CA wordt betrapt! En als de CA geen mogelijkheid heeft om zichzelf als trusted toe te voegen op jouw apparaat. Daarnaast valt het vooral op bij bepaalde grote domeinnamen de MITM best snel opvalt. Maar ik vraag mij af in hoeverre het ook opvalt bij webwinkels zoals Bol, Coolblue of Amazon of bij de diverse banken-sites zoals de Rabo, Amro en ING.

                  Kijk eens naar StartCom die op jouw lijst al sinds 2008 zit te klooien met certificaten en vandaag de dag nog steeds gewoon zaken doet! En VeriSign is nu onderdeel van Symantec en is onder die naam gewoon door gaan klooien.

                  En in jouw lijst zie je ook diverse overheden die zich hier vrolijk aan schuldig maken! Sterker nog, ik zie dat alleen DigiNotar door zo’n schandaal ten gronde ging. De rest bestaat gewoon nog en doen nog steeds zaken. Ik moet daarbij ook meteen denken aan de huidige situatie in Turkije, waarvan ik vermoed dat daar vroeg of laat fors geknoeid gaat worden binnen het Turkse Internet om de bevolking gewoon via MITM af te kunnen luisteren.

                  En wie weet wat voor gekkigheid Donals Trump in de USA gaat decreten omdat de FBI/CIA best graag allerlei backdoors wil hebben. Dan wordt het wel enorm vervelend, zeker indien die grappen niet worden ontdekt. Okay, het is een scenario die het dragen van een aluminium hoed vereist maar als je met beveiliging bezig bent moet je wel.

                  Leuk ook om te zien dat Symantec zich bezig houdt met het ontwikkelen van MITM oplossingen voor diverse overheden en daarnaast gewoon als CA wordt vertrouwd…

                  Maar om mijn punt kracht bij te zetten: Jij hebt een mooie lijst gemaakt van CA’s die de fout in gaan, en soms wel meerdere malen, en daarbij werden betrapt. En dat is best wel een redelijk grote lijst van hele grote CA’s. Dus hoe vaak komt het in werkelijkheid voor en hoeveel zijn er nog niet betrapt? Het vervelende hierbij is dat 1 corrupte CA al genoeg kan zijn bij een goed opgezette MITM aanval, met of zonder HSLS…

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.