Security Professionals
- ipfw add deny all from eindgebruikers to any
Website naar https? (voorbeeld: Tweakers.net)
Onderbouwde argumenten om over te stappen op https
Hoewel de grootste onthullingen over de praktijken van geheime diensten al weer enige tijd achter ons liggen, is de discussie over authenticatie en versleuteling nog niet afgezwakt: integendeel, zo lijkt het.
Steeds meer websites die eerst uitsluitend via http te benaderen waren, overwegen om hun website ook (of zelfs uitsluitend) toegankelijk maken via https.
Dat die afweging lastig is blijkt bijvoorbeeld uit Tweakers.net, die vandaag aan hun lezers vraagt [1] wat zij daarvan vinden; daarover later meer.
[1]: http://tweakers.net/plan/790/dilemma-moet-tweakers-https-inzetten.html
In dit artikel noem ik een aantal concrete voor- en nadelen die een rol zouden moeten spelen bij de overweging om over te stappen op https. D.w.z. in elk geval die aspecten die tijdens een, m.i. noodzakelijke, risico-analyse aan de orde horen te komen. Ik hoop dat andere Security.nl lezers mij middels reacties -waar nodig- corrigeren, en vooral aanvullen zodat geïnteresseerden een goed beeld krijgen van aspecten waarmee zij rekening mee moeten houden.
Risico-analyse
Belangrijk is dat je, voordat je een "beveiligingsmaatregel" neemt, een risico-analyse uitvoert. Daarmee probeer je vast te stellen wat de organisatie er uiteindelijk mee "opschiet".
De reden dat ik "beveiligingsmaatregel" tussen dubbele aanhalingstekens schrijf, is dat je bij een risico-analyse verder kijkt dan naar de vertrouwelijkheid van gegevens: ook de beschikbaarheid (en integriteit) van informatie zijn van belang. Immers, als jouw website de helft van de tijd down is omdat er beveiligingsupdates moeten worden geïnstalleerd en/of de site veel gevoeliger voor DoS (Deinal of Service) attacks is geworden, is de site welliswaar veiliger, maar kunnen de maatregelen er ook toe leiden dat klanten weglopen.
Anderzijds, het feit dat Tweakers.net geen fatsoenlijke beveiliging biedt, resulteert erin dat ik persoonlijk daar al twee jaar niet meer heb ingelogd (tot vandaag, om te testen).
Ook "opschiet" schreef ik tussen dubbele aanhalingstekens: een risico-analyse uitgevoerd door beveiligers is vaak incompleet. Als er al concrete te nemen maatregelen uit volgen, is de kans groot dat de financiële consequenties daarvan nog nader moeten worden onderzocht. En dan bedoel ik niet alleen qua aanschaf van hard- en software, maar ook de menskracht die je initieel, maar ook daarna, nodig hebt om de nieuwe configuratie goed te kunnen blijven ondersteunen.
Als je een risico-analyse laat uitvoeren, zorg dan dat de scope ervan duidelijk is (heb je een compleet beeld op basis waarvan de directie een beslissing kan nemen?), en dat er (achteraf) geen meningsverschillen kunnen ontstaan over de gebruikte terminologie.
Definities
Ik noemde ze al even, gangbaar is om bij informatiebeveiliging te spreken van:
- Vertrouwelijkheid: hoe zorg je dat uitsluitend geautoriseerden informatie kunnen bekijken?
- Integriteit: hoe zorg je dat uitsluitend door geautoriseerden informatie kunnen wijzigen en deze niet technisch corrupt raakt?
- Beschikbaarheid: persoonlijk splits ik deze bij voorkeur op in de volgende criteria:
- Bereikbaarheid: hoe snel moeten geautoriseerden informatie kunnen benaderen?
- Onmisbaarheid: hoe erg is het als geautoriseerden informatie nooit meer zullen kunnen benaderen?
Het is essentieel dat bovenstaande definties zijn vastgelegd voordat een risico-analyse wordt uitgevoerd. Bijvoorbeeld van het begrip "integriteit" kun je verschillende definities vinden: velen nemen daarin aspecten mee als "volledigheid", "tijdigheid" en "correctheid". Ik vind dat inhoudelijke zaken waar beveiligers zich niet mee bezig moeten houden (buiten het eigen werk natuurlijk). En beschikbaarheid wordt al snel vertaald in "uptime", "MTBF" en dergelijke. Let daarbij op of gepland onderhoud onder downtime wordt gerekend!
Voor- en nadelen van https: Tweakers
Ik heb het artikel en een flink aantal reacties onder [1] gelezen en heb mij verbaasd over het beperkte aantal voor- en tegenargumenten en het aantal ongefundeerde meningen.
Wat mij opvalt als ik inlog bij Tweakers.net is het volgende. Inloggen gebeurt inderdaad herkenbaar via https (secure.tweakers.net, dus geen onzichtbare https "post" onder water). Echter, daarna val je weer terug naar http, maar "blijf je ingelogd".
De server "weet" wie jij bent omdat jouw webbrowser, bij elke request, een authentication cookie meestuurt. In dat cookie zitten, onder meer, een "userid" (nummer, equivalent met jouw gebruikersnaam) en een equivalent voor jouw wachtwoord - dit om aan te tonen dat jij jij bent. Deze informatie wordt onversleuteld verzonden. Iemand met netwerktoegang kan eenvoudig jouw sessie "overnemen". Sterker, als je de browser sluit, word je niet uitgelogd; het cookie blijft, zo te zien, 24 uur geldig.
Ik heb in alle reacties onder het artikel gezocht naar "cook". In de 397 reacties van dit moment (19:10) zijn er slechts 3 personen die op onversleutelde cookies wijzen (wellicht zijn er een aantal "me too" reacties, die heb ik niet geteld). Alle drie die reacties hebben, op dit moment (19:10), een score van +1. Hoewel ik vermoed dat heel wat systeembeheerders Tweakers bezoeken, lijkt niemand van "firesheep" [2] te hebben gehoord, want dat wordt geheel niet genoemd.
[2]: https://en.wikipedia.org/wiki/Firesheep
Het belangrijkste aandachtspunt in de Tweakers discussie lijkt performance te zijn. Daarnaast noemen velen "privacy", maar slechts weinigen maken duidelijk waarom dat belangrijk zou kunnen zijn, en soms worden zij weggehoond.
Waarom wel/niet https?
Laat ik maar eens, tegendraads als ik soms ben, beginnen met een viertal nadelen te noemen (N1 t/m N4), en verderop 4 voordleen (V1 t/m V4). Er zijn meer voor- en nadelen te bedenken, maar die ik noem worden vaak niet goed als zodanig onderkend (en soms moet je ergens een punt achter weten te zetten ;)
Nadelen van https
N1) Complexiteit en veranderlijkheid
Het is ongelofelijk complexe materie. Er bestaat geen betrouwbare wereldwijde "CryptoCERT" organisatie die goede adviezen geeft hoe je de webserver(s), loadbalancers of SSL offloaders moet configureren. En feitelijk is zo'n organisatie broodnodig, want de "best practice" situatie kan per dag veranderen (denk maar aan lekken als Heartbleed).
Vele adviseurs roepen dat je iets niet moet doen omdat het niet veilig meer is. Zij komen echter lang niet altijd met volwaardige alternatieven, zoals NCSC [3] en zelf heb ik hier deze week ook enigszins aan meegedaan: [4]. Deze adviseurs kennen jouw configuratie niet, en kunnen de impact daarop bij eventuele wijzigingen niet overzien. Gegevens over clients die bepaalde configuraties niet (meer) ondersteunen zijn wel te vinden, maar hoe betrouwbaar zijn die?
[3]: https://www.security.nl/posting/40577/NCSC+waarschuwt+voor+RC4+encryptiealgoritme
[4]: https://www.security.nl/posting/406116/https+lekjes%3A+DigiD%2C+KPN%2C+ABP%2C+SNS%2C+Triodos%2C+ASN
Alternatieven voor zo'n CryptoCERT:
Persoonlijk heb ik een enorme waardering voor mensen als Ivan Ristic, die hun nek durven uit te steken door adviezen uit te brengen [5]. Maar ook Ivan Ristic is een mens: ook hij kan zich vergissen of iets over het hoofd zien.
[5]: http://blog.ivanristic.com/, https://community.qualys.com/blogs/authors/ivanr en https://www.ssllabs.com/
Op dit moment zie ik goede adviezen in https://wiki.mozilla.org/Security/Server_Side_TLS maar ik durf niet te voorspellen dat dit zo blijft.
De site BetterCrypto.org leek een fantastisch initatief, alleen blijft hun adviesdocument Applied Crypto Hardening [6] de "draft" status houden en is sinds 2014-07-11 niet meer bijgewerkt.
[6]: https://bettercrypto.org/static/applied-crypto-hardening.pdf
N2) Hoe ver ga je, welke features implementeer je?
Qua beveiliging voor jouw klanten kun je het beste de allermodernste ciphers en technieken ondersteunen (en alle legacy meuk uitzetten). Dat kan leiden tot de volgende problemen:
- Jouw hard en software moet dit wel ondersteunen. Zo niet: trek de buidel.
- Mogelijk kan een deel van jouw klanten jouw site niet meer benaderen (geheel niet of met foutmeldingen).
- Je moet de juiste specialisten in huis hebben om e.e.a. te kunnen testen en implementeren.
- Velen vergeten dat een "main site", content van allerlei andere sites laadt, zowel eigen sites of sites van derden met static content (zoals plaatjes, jquery) en advertenties: afhankelijk van keuzes die je maakt moeten ook zij aan bepaalde voorwaarden voldoen.
- Bij sites met zeer vertouwelijke informatie kan het zijn dat je, tussen jouw webserver (of ander feitelijke device dat versleutelt, reverse proxy zeg maar) en het internet een sniffer wilt zetten, bijv. om te kunnen detecteren dat die webserver (of reverse proxy) gecompromitteerd is geraakt. Dat kan door zo'n passief monitoring device te voorzien van de private key van de webserver. Maar dat heeft alleen zin als je geen forward secrecy ciphers ondersteunt! Doe je dat wel, dan is zo'n sniffer zinloos.
- Geadviseerde technieken als HSTS kunnen, soms onverwacht, tot complicaties leiden.
N3) Heb je de nodige specialisten in huis?
Grondige kennis van private keys, public keys en certificaten is essentieel. Zeer gewenst is kennis van de nieuwste technieken, zoals OCSP stapling, HSTS en FS (Forward Secrecy, ook aangeduid als PFS voor Perfect Forward Secrecy) en kreten als "mixed content".
Begin niet aan https als je niet bereid bent "bijblijvende" specialisten permanent of op tijdelijke basis in huis te halen. Een bekende beginnersfout bij https is het installeren van het server certificaat, maar daarbij vergeten intermediate certificaten te installeren (ik heb deze fout ook ooit gemaakt). Maar zoals duidelijk mag zijn uit de rest van dit verhaal, en discussies op bijv. de "cryptography" en "TLS" maillijsten [7], is dit geen sinecure.
[7]: http://www.metzdowd.com/pipermail/cryptography/ en http://www.ietf.org/mail-archive/web/tls/current/threads.html
N4) Zorg voor een incident response plan en een beschikbaar team
Dat zou voor elke webserver moeten gelden, maat met Heartbleed hebben we gezien hoe van de ene op de andere dag bekend wordt dat ongeautoriseerde aanvallers vanaf internet het werkgeheugen van webservers kunnen uitlezen, en daarmee griezelig vertrouwelijke informatie kunnen uitlezen [8].
[8]: http://un1c0rn.net/search?q=%22Authorization+basic%22
De afgelopen maanden hebben grote bedrijven als Google, HP en IBM ingezien hoe afhankelijk zij zijn geworden van open source software, zoals OpenSSL maar ook andere SSL "stacks". Er zijn verschillende initiatieven gestart waarbij de veiligheid van dat soort software zorgvuldig wordt onderzocht. Dat kan niet anders dan leiden tot een stroom patches. Bij elk van die patches is de wijze van bekendmaken weer heel lastig: aan wie vertel je welke details op voorhand? In de praktijk komt het erop neer dat je als een razende aan het werk moet zodra kritische beveiligingspatches worden gepubliceerd, met name als je een high-risk website runt.
Voordelen van https
V1) Server-authenticatie
Vaak vergeten: primair gaat het bij https om authenticatie van de server.
Als jij, als gebruiker, niet inlogt, en zelfs als de verbinding niet (of slecht) versleuteld is, en vervolgens informatie tot jou neemt, is het in bijna alle gevallen belangrijk dat je weet van wie die informatie afkomstig is. Hoe geloofwaardig is die informatie anders?
Helaas hebben we in Nederland geen .gov.nl systeem voor overheidswebsites. Hoe weet ik nu of bijv. een site als [9] een overheidswebsite is? Niet. Elke idioot kan een website beginnen met een naam waarin "overheid" voorkomt. Als ik deze site (die overigens zeer interessante informatie bevat voor beveiligers) via https probeer te benaderen, geeft mijn browser een foutmelding. Die gaat overigens zover dat, ik in Firefox, niet "door" kan klikken om toch toegang te krijgen.
[9] http://www.cip-overheid.nl/
Stel dat [9] wel een geldig certificaat zou hebben, dan zou het goed zijn als daaruit eenduidig zou kunnen worden opgemaakt dat het hierbij om een echte overheidswebsite gaat. Nu is [9] wellicht een slecht voorbeeld. Een ander dus, laten we het certificaat van [10] bekijken:
[10]: https://www.digid.nl
Leken kunnen zelden betrouwbaar vaststellen welke site names zij wel of niet kunnen vertrouwen. Daarvoor zijn zij te vaak afhankelijk van reclame op TV, familie/kennisen/vrienden ze erop wijzen. Of URL's die genoemd worden op andere sites die, om de een of andere reden, al wel worden vertrouwd.
Voorbeeld: [11]. Dit moet haast wel een betrouwbare site zijn, want (A) het is https, en (B) verschillende overheidssites verwijzen hiernaar als "tip" (waaronder de vernieuwde [12]). Echter, van wie is deze site [11]? Daarover kan ik niets terugvinden, noch in het certificaat, noch in informatie op de site zelf. Los van hoe goed de wachtwoorden zijn die deze site aanbeveelt: ik ga niets van wat zij adviseren daadwerkelijk gebruiken, en naast mij zou helemaal niemand dat moeten doen.
En waarom krijg ik op [12] eigenlijk geen slotje? (Mixed content - [13] geeft antwoord). En dit ([12]) is een site die ons binnenkort moet leren veiliger met internet om te gaan... Anderzijds geeft dit aan dat het kennelijk lastig is om https goed te doen.
[11]: https://www.wisseljewachtwoord.nl/
[12]: https://www.alertonline.nl/
[13]: https://www.whynopadlock.com/ (vul in: https://www.alertonline.nl/)
Nb. zonder dat slotje moet ik in Firefox en Internet Explorer zoeken naar hoe ik het certificaat kan bekijken. Dat is jammer, want het certificaat van [12] is beter dan van DigiD:
Hopelijk ten overvloede: https met authenticatie (certificaat) maar zonder (of met slechte) encryptie is nauwelijks zinvol, omdat een MitM aanvaller dan informatie kan wijzigen. En daarmee komen we op het volgende punt.
V2) Integriteit van geboden informatie
Als een aanvaller de DNS instellingen in mijn router gewijzigd heeft, of als ik van een publiek draadloos netwerk gebruik maak, hoe weet ik dan zeker dat als ik [9] bezoek, niets op die site door een aanvaller wordt geïnjecteerd? Idem als ik een executable download van sourceforge.net?
Antwoord: dat weet je niet. Soms zijn executables voorzien van een digitale handtekening (Authenticode of PGP). In een groter deel van de gevallen wordt een MD5 hash gepubliceerd - die jij via hetzelfde, onversleutelde kanaal, ophaalt - en die dus ook on-the-fly door een aanvaller kan worden gewijzigd. Praktijk is dat executables worden gedownload, gestart en waarschuwingen over ontbrekende handtekeningen worden genegeerd.
Maar ook tekstuele informatie kan je op een verkeerd been zetten. De website van uw autogarage zou een IBAN nummer kunnen tonen waar u de rekening naar toe moet overmaken; een MitM (Man-in-the-Middle) aanvaller zou dat on-the-fly kunnen wijzigen. Naast hele blokken tekst kunnen in webpagina's kunnen MitM aanvallers natuurlijk ook links in webpagina's wijzigen. Daarmee zijn zeer geraffineerde phishing- en andere frauduleuze aanvallen denkbaar.
Voorbeeld: u tikt asnbank.nl in de URL-balk van uw browser en herkent de site van de vorige keer. U klikt rechtsboven op "Inloggen". De MitM-aanvaller (waar u geen weet van heeft) stuurt u vervolgens een pagina die hij kan opmaken zoals hem belieft. Hij kan daar desgewenst in zetten: "t.g.v. een storing is deze site momenteel niet via https te bereiken".
Maar hij kan ook gokken dat het u niet opvalt dat het slotje ontbreekt; immers, u bent afgeleid doordat u op dat moment uw lange wachtwoord moet herinneren. Of de aanvaller stuurt u naar een site met slotje, echter met een naam die lijkt op asnbank.nl, of een naam waar die karakterreeks in voorkomt. Die aanvaller zit er heus niet mee dat niet iedereen hier intrapt, als u het maar doet...
Nb. om bovenstaande reden pleit ik ervoor, met name bij sites waar aanvallers financieel voordeel kunnen halen, dat de hele site, en met name de "landing page", https gebruikt. En dat dit middels HSTS en procedurele instructies (maak een snelkoppeling in uw webbrowser die begint met https://) wordt toegepast.
V3) Privacy van de bezoeker
Vooropgesteld: https biedt geen 100% privacy voor bezoekers. Iedereen die tussen webbrowser en webserver kan meekijken op de verbinding, ook als deze fatsoenlijk is versleuteld, ziet het zowel het IP-adres van de bezoeker als het IP-adres van de server. Moderne browsers sturen daarnaast de gewenste domainname mee (in het kader van SNI, Server Name Indication) en de server stuurt haar certificaat naar de browser, beide nog voordat de verbinding is versleuteld.
Maar ook daarna kan het mogelijk zijn om vast te stellen welke pagina's een lezer heeft bezocht. Als de aanvaller dezelfde pagina's opent en kijkt hoeveel bytes er verzonden zijn, kan hij aan de hand daarvan in veel gevallen vaststellen welke pagina's de bezoeker geopend heeft. En aan de hand van de tijd voordat nieuwe nieuwe informatie wordt uitgewisseld, gokken welk deel van de informatie door de bezoeker gelezen is.
Het nut van https ontstaat pas op het moment dat de gebruiker meer informatie naar de site stuurt dan slechts de URL's van gewenste pagina's. Ook als (wellicht juist indien) een gebruiker anoniem een bijdrage op security.nl of tweakers.net wil posten, al dan niet gebruik makend van een nickname, is het onwenselijk dat te achterhalen valt wie die anonieme gebruiker feitelijk is.
V4) Authenticatie van de bezoeker
Voor de eigenaar van een website is het meestal van belang dat zij weet wie de gebruiker is die bepaalde wijzigingen aanbrengt, om o.a. de volgende redenen:
1) Om gebruikers die "het niet snappen" van dienst te kunnen zijn door ze via een ander kanaal te kunnen benaderen;
2) Om gebruikers die zich misdragen te kunnen benaderen en/of sanctioneren;
3) Om te voorkomen dat gebruikers overstappen naar een concurrent vanwege de reden hieronder.
Voor de gebruiker is het belangrijk om zich betrouwbaar te authenticeren als zij informatie wijzigt op een website, niet zozeer voor zichzelf, maar om te voorkomen dat een derde zich als haar kan voordoen. We kennen allemaal de gevallen van bijv. gecompromitteerde twitteraccounts van bekende personen waarbij aanvallers zich voordoen als. En vanzelfsprekend is identity-theft exact waar aanvallers bij internetbankieren (o.a. phishing) op uit zijn.
Om initiële gebruikerauthenticatie betrouwbaar te laten plaatsvinden is het dus noodzakelijk dat de gebruiker zeker weet dat hij op de "juiste website zit" en dat eventuele MitM aanvallers die informatie niet kunnen afkijken. Ook indien niet het wachtwoord zelf wordt verzonden, maar een hash, is dit belangrijk (Google: pass-the-hash attacks).
Maar ook na het initiële inloggen is het noodzakelijk dat de server "weet" dat het nog steeds om dezelfde gebruiker gaat, ook indien de browser geheel nieuwe verbindingen opent (in de praktijk gebeurt dat ontzettend vaak). Meestal worden hiervoor session cookies gebruikt, en die zijn, voor een aanvaller, bijna net zoveel waard als een gebruikersnaam en wachtwoord. Dus ook die horen via een geauthenticeerde en versleutelde verbinding te worden verzonden. Tweakers lapt dit al jaren aan hun laars.
Conclusie
Een website overzetten van http naar https is een ingewikkeld vraagstuk. Hierboven ben ik slechts ingegaan op een beperkt aantal beveiligingsaspecten (vertrouwelijkheid van uitgewisselde informatie anders dan authenticatiegegevens heb ik niet eens benoemd). Er kan dus nog veel meer spelen!
Onderschat zo'n beslissing niet: haal de juiste kennis in huis en begin met een "PoC" (Proof of Concept) om een beeld te krijgen van de consequenties. Richt een een test- en acceptatieomgeving in - en zorg dat je, met name die laatste en de juiste mensen, te allen tijde tot je beschikking hebt.
Veel succes!
Hoewel de grootste onthullingen over de praktijken van geheime diensten al weer enige tijd achter ons liggen, is de discussie over authenticatie en versleuteling nog niet afgezwakt: integendeel, zo lijkt het.
Steeds meer websites die eerst uitsluitend via http te benaderen waren, overwegen om hun website ook (of zelfs uitsluitend) toegankelijk maken via https.
Dat die afweging lastig is blijkt bijvoorbeeld uit Tweakers.net, die vandaag aan hun lezers vraagt [1] wat zij daarvan vinden; daarover later meer.
[1]: http://tweakers.net/plan/790/dilemma-moet-tweakers-https-inzetten.html
In dit artikel noem ik een aantal concrete voor- en nadelen die een rol zouden moeten spelen bij de overweging om over te stappen op https. D.w.z. in elk geval die aspecten die tijdens een, m.i. noodzakelijke, risico-analyse aan de orde horen te komen. Ik hoop dat andere Security.nl lezers mij middels reacties -waar nodig- corrigeren, en vooral aanvullen zodat geïnteresseerden een goed beeld krijgen van aspecten waarmee zij rekening mee moeten houden.
Risico-analyse
Belangrijk is dat je, voordat je een "beveiligingsmaatregel" neemt, een risico-analyse uitvoert. Daarmee probeer je vast te stellen wat de organisatie er uiteindelijk mee "opschiet".
De reden dat ik "beveiligingsmaatregel" tussen dubbele aanhalingstekens schrijf, is dat je bij een risico-analyse verder kijkt dan naar de vertrouwelijkheid van gegevens: ook de beschikbaarheid (en integriteit) van informatie zijn van belang. Immers, als jouw website de helft van de tijd down is omdat er beveiligingsupdates moeten worden geïnstalleerd en/of de site veel gevoeliger voor DoS (Deinal of Service) attacks is geworden, is de site welliswaar veiliger, maar kunnen de maatregelen er ook toe leiden dat klanten weglopen.
Anderzijds, het feit dat Tweakers.net geen fatsoenlijke beveiliging biedt, resulteert erin dat ik persoonlijk daar al twee jaar niet meer heb ingelogd (tot vandaag, om te testen).
Ook "opschiet" schreef ik tussen dubbele aanhalingstekens: een risico-analyse uitgevoerd door beveiligers is vaak incompleet. Als er al concrete te nemen maatregelen uit volgen, is de kans groot dat de financiële consequenties daarvan nog nader moeten worden onderzocht. En dan bedoel ik niet alleen qua aanschaf van hard- en software, maar ook de menskracht die je initieel, maar ook daarna, nodig hebt om de nieuwe configuratie goed te kunnen blijven ondersteunen.
Als je een risico-analyse laat uitvoeren, zorg dan dat de scope ervan duidelijk is (heb je een compleet beeld op basis waarvan de directie een beslissing kan nemen?), en dat er (achteraf) geen meningsverschillen kunnen ontstaan over de gebruikte terminologie.
Definities
Ik noemde ze al even, gangbaar is om bij informatiebeveiliging te spreken van:
- Vertrouwelijkheid: hoe zorg je dat uitsluitend geautoriseerden informatie kunnen bekijken?
- Integriteit: hoe zorg je dat uitsluitend door geautoriseerden informatie kunnen wijzigen en deze niet technisch corrupt raakt?
- Beschikbaarheid: persoonlijk splits ik deze bij voorkeur op in de volgende criteria:
- Bereikbaarheid: hoe snel moeten geautoriseerden informatie kunnen benaderen?
- Onmisbaarheid: hoe erg is het als geautoriseerden informatie nooit meer zullen kunnen benaderen?
Het is essentieel dat bovenstaande definties zijn vastgelegd voordat een risico-analyse wordt uitgevoerd. Bijvoorbeeld van het begrip "integriteit" kun je verschillende definities vinden: velen nemen daarin aspecten mee als "volledigheid", "tijdigheid" en "correctheid". Ik vind dat inhoudelijke zaken waar beveiligers zich niet mee bezig moeten houden (buiten het eigen werk natuurlijk). En beschikbaarheid wordt al snel vertaald in "uptime", "MTBF" en dergelijke. Let daarbij op of gepland onderhoud onder downtime wordt gerekend!
Voor- en nadelen van https: Tweakers
Ik heb het artikel en een flink aantal reacties onder [1] gelezen en heb mij verbaasd over het beperkte aantal voor- en tegenargumenten en het aantal ongefundeerde meningen.
Wat mij opvalt als ik inlog bij Tweakers.net is het volgende. Inloggen gebeurt inderdaad herkenbaar via https (secure.tweakers.net, dus geen onzichtbare https "post" onder water). Echter, daarna val je weer terug naar http, maar "blijf je ingelogd".
De server "weet" wie jij bent omdat jouw webbrowser, bij elke request, een authentication cookie meestuurt. In dat cookie zitten, onder meer, een "userid" (nummer, equivalent met jouw gebruikersnaam) en een equivalent voor jouw wachtwoord - dit om aan te tonen dat jij jij bent. Deze informatie wordt onversleuteld verzonden. Iemand met netwerktoegang kan eenvoudig jouw sessie "overnemen". Sterker, als je de browser sluit, word je niet uitgelogd; het cookie blijft, zo te zien, 24 uur geldig.
Ik heb in alle reacties onder het artikel gezocht naar "cook". In de 397 reacties van dit moment (19:10) zijn er slechts 3 personen die op onversleutelde cookies wijzen (wellicht zijn er een aantal "me too" reacties, die heb ik niet geteld). Alle drie die reacties hebben, op dit moment (19:10), een score van +1. Hoewel ik vermoed dat heel wat systeembeheerders Tweakers bezoeken, lijkt niemand van "firesheep" [2] te hebben gehoord, want dat wordt geheel niet genoemd.
[2]: https://en.wikipedia.org/wiki/Firesheep
Het belangrijkste aandachtspunt in de Tweakers discussie lijkt performance te zijn. Daarnaast noemen velen "privacy", maar slechts weinigen maken duidelijk waarom dat belangrijk zou kunnen zijn, en soms worden zij weggehoond.
Waarom wel/niet https?
Laat ik maar eens, tegendraads als ik soms ben, beginnen met een viertal nadelen te noemen (N1 t/m N4), en verderop 4 voordleen (V1 t/m V4). Er zijn meer voor- en nadelen te bedenken, maar die ik noem worden vaak niet goed als zodanig onderkend (en soms moet je ergens een punt achter weten te zetten ;)
Nadelen van https
N1) Complexiteit en veranderlijkheid
Het is ongelofelijk complexe materie. Er bestaat geen betrouwbare wereldwijde "CryptoCERT" organisatie die goede adviezen geeft hoe je de webserver(s), loadbalancers of SSL offloaders moet configureren. En feitelijk is zo'n organisatie broodnodig, want de "best practice" situatie kan per dag veranderen (denk maar aan lekken als Heartbleed).
Vele adviseurs roepen dat je iets niet moet doen omdat het niet veilig meer is. Zij komen echter lang niet altijd met volwaardige alternatieven, zoals NCSC [3] en zelf heb ik hier deze week ook enigszins aan meegedaan: [4]. Deze adviseurs kennen jouw configuratie niet, en kunnen de impact daarop bij eventuele wijzigingen niet overzien. Gegevens over clients die bepaalde configuraties niet (meer) ondersteunen zijn wel te vinden, maar hoe betrouwbaar zijn die?
[3]: https://www.security.nl/posting/40577/NCSC+waarschuwt+voor+RC4+encryptiealgoritme
[4]: https://www.security.nl/posting/406116/https+lekjes%3A+DigiD%2C+KPN%2C+ABP%2C+SNS%2C+Triodos%2C+ASN
Alternatieven voor zo'n CryptoCERT:
Persoonlijk heb ik een enorme waardering voor mensen als Ivan Ristic, die hun nek durven uit te steken door adviezen uit te brengen [5]. Maar ook Ivan Ristic is een mens: ook hij kan zich vergissen of iets over het hoofd zien.
[5]: http://blog.ivanristic.com/, https://community.qualys.com/blogs/authors/ivanr en https://www.ssllabs.com/
Op dit moment zie ik goede adviezen in https://wiki.mozilla.org/Security/Server_Side_TLS maar ik durf niet te voorspellen dat dit zo blijft.
De site BetterCrypto.org leek een fantastisch initatief, alleen blijft hun adviesdocument Applied Crypto Hardening [6] de "draft" status houden en is sinds 2014-07-11 niet meer bijgewerkt.
[6]: https://bettercrypto.org/static/applied-crypto-hardening.pdf
N2) Hoe ver ga je, welke features implementeer je?
Qua beveiliging voor jouw klanten kun je het beste de allermodernste ciphers en technieken ondersteunen (en alle legacy meuk uitzetten). Dat kan leiden tot de volgende problemen:
- Jouw hard en software moet dit wel ondersteunen. Zo niet: trek de buidel.
- Mogelijk kan een deel van jouw klanten jouw site niet meer benaderen (geheel niet of met foutmeldingen).
- Je moet de juiste specialisten in huis hebben om e.e.a. te kunnen testen en implementeren.
- Velen vergeten dat een "main site", content van allerlei andere sites laadt, zowel eigen sites of sites van derden met static content (zoals plaatjes, jquery) en advertenties: afhankelijk van keuzes die je maakt moeten ook zij aan bepaalde voorwaarden voldoen.
- Bij sites met zeer vertouwelijke informatie kan het zijn dat je, tussen jouw webserver (of ander feitelijke device dat versleutelt, reverse proxy zeg maar) en het internet een sniffer wilt zetten, bijv. om te kunnen detecteren dat die webserver (of reverse proxy) gecompromitteerd is geraakt. Dat kan door zo'n passief monitoring device te voorzien van de private key van de webserver. Maar dat heeft alleen zin als je geen forward secrecy ciphers ondersteunt! Doe je dat wel, dan is zo'n sniffer zinloos.
- Geadviseerde technieken als HSTS kunnen, soms onverwacht, tot complicaties leiden.
N3) Heb je de nodige specialisten in huis?
Grondige kennis van private keys, public keys en certificaten is essentieel. Zeer gewenst is kennis van de nieuwste technieken, zoals OCSP stapling, HSTS en FS (Forward Secrecy, ook aangeduid als PFS voor Perfect Forward Secrecy) en kreten als "mixed content".
Begin niet aan https als je niet bereid bent "bijblijvende" specialisten permanent of op tijdelijke basis in huis te halen. Een bekende beginnersfout bij https is het installeren van het server certificaat, maar daarbij vergeten intermediate certificaten te installeren (ik heb deze fout ook ooit gemaakt). Maar zoals duidelijk mag zijn uit de rest van dit verhaal, en discussies op bijv. de "cryptography" en "TLS" maillijsten [7], is dit geen sinecure.
[7]: http://www.metzdowd.com/pipermail/cryptography/ en http://www.ietf.org/mail-archive/web/tls/current/threads.html
N4) Zorg voor een incident response plan en een beschikbaar team
Dat zou voor elke webserver moeten gelden, maat met Heartbleed hebben we gezien hoe van de ene op de andere dag bekend wordt dat ongeautoriseerde aanvallers vanaf internet het werkgeheugen van webservers kunnen uitlezen, en daarmee griezelig vertrouwelijke informatie kunnen uitlezen [8].
[8]: http://un1c0rn.net/search?q=%22Authorization+basic%22
De afgelopen maanden hebben grote bedrijven als Google, HP en IBM ingezien hoe afhankelijk zij zijn geworden van open source software, zoals OpenSSL maar ook andere SSL "stacks". Er zijn verschillende initiatieven gestart waarbij de veiligheid van dat soort software zorgvuldig wordt onderzocht. Dat kan niet anders dan leiden tot een stroom patches. Bij elk van die patches is de wijze van bekendmaken weer heel lastig: aan wie vertel je welke details op voorhand? In de praktijk komt het erop neer dat je als een razende aan het werk moet zodra kritische beveiligingspatches worden gepubliceerd, met name als je een high-risk website runt.
Voordelen van https
V1) Server-authenticatie
Vaak vergeten: primair gaat het bij https om authenticatie van de server.
Als jij, als gebruiker, niet inlogt, en zelfs als de verbinding niet (of slecht) versleuteld is, en vervolgens informatie tot jou neemt, is het in bijna alle gevallen belangrijk dat je weet van wie die informatie afkomstig is. Hoe geloofwaardig is die informatie anders?
Helaas hebben we in Nederland geen .gov.nl systeem voor overheidswebsites. Hoe weet ik nu of bijv. een site als [9] een overheidswebsite is? Niet. Elke idioot kan een website beginnen met een naam waarin "overheid" voorkomt. Als ik deze site (die overigens zeer interessante informatie bevat voor beveiligers) via https probeer te benaderen, geeft mijn browser een foutmelding. Die gaat overigens zover dat, ik in Firefox, niet "door" kan klikken om toch toegang te krijgen.
[9] http://www.cip-overheid.nl/
Stel dat [9] wel een geldig certificaat zou hebben, dan zou het goed zijn als daaruit eenduidig zou kunnen worden opgemaakt dat het hierbij om een echte overheidswebsite gaat. Nu is [9] wellicht een slecht voorbeeld. Een ander dus, laten we het certificaat van [10] bekijken:
CN = www.digid.nl
OU = DigiD
O = Logius
L = 's-Gravenhage
ST = Zuid-Holland
C = NL
Hoe moet een leek weten dat het hier wel degelijk om een overheidsorgainsatie gaat? WTF is Logius? Ik weet dat toevallig, maar weet u het ook? En, belangrijker, uitgevers van digitale certificaten?OU = DigiD
O = Logius
L = 's-Gravenhage
ST = Zuid-Holland
C = NL
[10]: https://www.digid.nl
Leken kunnen zelden betrouwbaar vaststellen welke site names zij wel of niet kunnen vertrouwen. Daarvoor zijn zij te vaak afhankelijk van reclame op TV, familie/kennisen/vrienden ze erop wijzen. Of URL's die genoemd worden op andere sites die, om de een of andere reden, al wel worden vertrouwd.
Voorbeeld: [11]. Dit moet haast wel een betrouwbare site zijn, want (A) het is https, en (B) verschillende overheidssites verwijzen hiernaar als "tip" (waaronder de vernieuwde [12]). Echter, van wie is deze site [11]? Daarover kan ik niets terugvinden, noch in het certificaat, noch in informatie op de site zelf. Los van hoe goed de wachtwoorden zijn die deze site aanbeveelt: ik ga niets van wat zij adviseren daadwerkelijk gebruiken, en naast mij zou helemaal niemand dat moeten doen.
En waarom krijg ik op [12] eigenlijk geen slotje? (Mixed content - [13] geeft antwoord). En dit ([12]) is een site die ons binnenkort moet leren veiliger met internet om te gaan... Anderzijds geeft dit aan dat het kennelijk lastig is om https goed te doen.
[11]: https://www.wisseljewachtwoord.nl/
[12]: https://www.alertonline.nl/
[13]: https://www.whynopadlock.com/ (vul in: https://www.alertonline.nl/)
Nb. zonder dat slotje moet ik in Firefox en Internet Explorer zoeken naar hoe ik het certificaat kan bekijken. Dat is jammer, want het certificaat van [12] is beter dan van DigiD:
CN = www.alertonline.nl
OU = Rijksoverheid
O = Dienst Publiek en Communicatie (DPC)
L = 's-Gravenhage
ST = Zuid-Holland
C = NL
OU = Rijksoverheid
O = Dienst Publiek en Communicatie (DPC)
L = 's-Gravenhage
ST = Zuid-Holland
C = NL
Hopelijk ten overvloede: https met authenticatie (certificaat) maar zonder (of met slechte) encryptie is nauwelijks zinvol, omdat een MitM aanvaller dan informatie kan wijzigen. En daarmee komen we op het volgende punt.
V2) Integriteit van geboden informatie
Als een aanvaller de DNS instellingen in mijn router gewijzigd heeft, of als ik van een publiek draadloos netwerk gebruik maak, hoe weet ik dan zeker dat als ik [9] bezoek, niets op die site door een aanvaller wordt geïnjecteerd? Idem als ik een executable download van sourceforge.net?
Antwoord: dat weet je niet. Soms zijn executables voorzien van een digitale handtekening (Authenticode of PGP). In een groter deel van de gevallen wordt een MD5 hash gepubliceerd - die jij via hetzelfde, onversleutelde kanaal, ophaalt - en die dus ook on-the-fly door een aanvaller kan worden gewijzigd. Praktijk is dat executables worden gedownload, gestart en waarschuwingen over ontbrekende handtekeningen worden genegeerd.
Maar ook tekstuele informatie kan je op een verkeerd been zetten. De website van uw autogarage zou een IBAN nummer kunnen tonen waar u de rekening naar toe moet overmaken; een MitM (Man-in-the-Middle) aanvaller zou dat on-the-fly kunnen wijzigen. Naast hele blokken tekst kunnen in webpagina's kunnen MitM aanvallers natuurlijk ook links in webpagina's wijzigen. Daarmee zijn zeer geraffineerde phishing- en andere frauduleuze aanvallen denkbaar.
Voorbeeld: u tikt asnbank.nl in de URL-balk van uw browser en herkent de site van de vorige keer. U klikt rechtsboven op "Inloggen". De MitM-aanvaller (waar u geen weet van heeft) stuurt u vervolgens een pagina die hij kan opmaken zoals hem belieft. Hij kan daar desgewenst in zetten: "t.g.v. een storing is deze site momenteel niet via https te bereiken".
Maar hij kan ook gokken dat het u niet opvalt dat het slotje ontbreekt; immers, u bent afgeleid doordat u op dat moment uw lange wachtwoord moet herinneren. Of de aanvaller stuurt u naar een site met slotje, echter met een naam die lijkt op asnbank.nl, of een naam waar die karakterreeks in voorkomt. Die aanvaller zit er heus niet mee dat niet iedereen hier intrapt, als u het maar doet...
Nb. om bovenstaande reden pleit ik ervoor, met name bij sites waar aanvallers financieel voordeel kunnen halen, dat de hele site, en met name de "landing page", https gebruikt. En dat dit middels HSTS en procedurele instructies (maak een snelkoppeling in uw webbrowser die begint met https://) wordt toegepast.
V3) Privacy van de bezoeker
Vooropgesteld: https biedt geen 100% privacy voor bezoekers. Iedereen die tussen webbrowser en webserver kan meekijken op de verbinding, ook als deze fatsoenlijk is versleuteld, ziet het zowel het IP-adres van de bezoeker als het IP-adres van de server. Moderne browsers sturen daarnaast de gewenste domainname mee (in het kader van SNI, Server Name Indication) en de server stuurt haar certificaat naar de browser, beide nog voordat de verbinding is versleuteld.
Maar ook daarna kan het mogelijk zijn om vast te stellen welke pagina's een lezer heeft bezocht. Als de aanvaller dezelfde pagina's opent en kijkt hoeveel bytes er verzonden zijn, kan hij aan de hand daarvan in veel gevallen vaststellen welke pagina's de bezoeker geopend heeft. En aan de hand van de tijd voordat nieuwe nieuwe informatie wordt uitgewisseld, gokken welk deel van de informatie door de bezoeker gelezen is.
Het nut van https ontstaat pas op het moment dat de gebruiker meer informatie naar de site stuurt dan slechts de URL's van gewenste pagina's. Ook als (wellicht juist indien) een gebruiker anoniem een bijdrage op security.nl of tweakers.net wil posten, al dan niet gebruik makend van een nickname, is het onwenselijk dat te achterhalen valt wie die anonieme gebruiker feitelijk is.
V4) Authenticatie van de bezoeker
Voor de eigenaar van een website is het meestal van belang dat zij weet wie de gebruiker is die bepaalde wijzigingen aanbrengt, om o.a. de volgende redenen:
1) Om gebruikers die "het niet snappen" van dienst te kunnen zijn door ze via een ander kanaal te kunnen benaderen;
2) Om gebruikers die zich misdragen te kunnen benaderen en/of sanctioneren;
3) Om te voorkomen dat gebruikers overstappen naar een concurrent vanwege de reden hieronder.
Voor de gebruiker is het belangrijk om zich betrouwbaar te authenticeren als zij informatie wijzigt op een website, niet zozeer voor zichzelf, maar om te voorkomen dat een derde zich als haar kan voordoen. We kennen allemaal de gevallen van bijv. gecompromitteerde twitteraccounts van bekende personen waarbij aanvallers zich voordoen als. En vanzelfsprekend is identity-theft exact waar aanvallers bij internetbankieren (o.a. phishing) op uit zijn.
Om initiële gebruikerauthenticatie betrouwbaar te laten plaatsvinden is het dus noodzakelijk dat de gebruiker zeker weet dat hij op de "juiste website zit" en dat eventuele MitM aanvallers die informatie niet kunnen afkijken. Ook indien niet het wachtwoord zelf wordt verzonden, maar een hash, is dit belangrijk (Google: pass-the-hash attacks).
Maar ook na het initiële inloggen is het noodzakelijk dat de server "weet" dat het nog steeds om dezelfde gebruiker gaat, ook indien de browser geheel nieuwe verbindingen opent (in de praktijk gebeurt dat ontzettend vaak). Meestal worden hiervoor session cookies gebruikt, en die zijn, voor een aanvaller, bijna net zoveel waard als een gebruikersnaam en wachtwoord. Dus ook die horen via een geauthenticeerde en versleutelde verbinding te worden verzonden. Tweakers lapt dit al jaren aan hun laars.
Conclusie
Een website overzetten van http naar https is een ingewikkeld vraagstuk. Hierboven ben ik slechts ingegaan op een beperkt aantal beveiligingsaspecten (vertrouwelijkheid van uitgewisselde informatie anders dan authenticatiegegevens heb ik niet eens benoemd). Er kan dus nog veel meer spelen!
Onderschat zo'n beslissing niet: haal de juiste kennis in huis en begin met een "PoC" (Proof of Concept) om een beeld te krijgen van de consequenties. Richt een een test- en acceptatieomgeving in - en zorg dat je, met name die laatste en de juiste mensen, te allen tijde tot je beschikking hebt.
Veel succes!
Reacties (21)
De enige reden waarom tweakers.net halfslachtig omgaat met https is dat zij kennelijk afhankelijk zijn van advertentie providers die weigeren https te ondersteunen voor hun content. Google en haar dochters, bijvoorbeeld, bieden dat wel aan. Tijd om die advertentieboeren dus onder druk te zetten. En tweakers zou dat soort partners niet moeten willen hebben, gezien de branche....
@Erik :
"Anderzijds, het feit dat Tweakers.net geen fatsoenlijke beveiliging biedt, resulteert erin dat ik persoonlijk daar al twee jaar niet meer heb ingelogd (tot vandaag, om te testen)."
Kan je ons dan eens laten weten welke risico's er naar voren kwamen bij het niet-encrypted gebruik van Tweakers.net aangezien je stelt dat je een risico analyse hebt gemaakt ? Mijn account daar hergebruik ik nergens anders. Voor de rest deel ik niets met de website wat gevoelig is. Jij wel ?
"Anderzijds, het feit dat Tweakers.net geen fatsoenlijke beveiliging biedt, resulteert erin dat ik persoonlijk daar al twee jaar niet meer heb ingelogd (tot vandaag, om te testen)."
Kan je ons dan eens laten weten welke risico's er naar voren kwamen bij het niet-encrypted gebruik van Tweakers.net aangezien je stelt dat je een risico analyse hebt gemaakt ? Mijn account daar hergebruik ik nergens anders. Voor de rest deel ik niets met de website wat gevoelig is. Jij wel ?
"En tweakers zou dat soort partners niet moeten willen hebben, gezien de branche...."
Hoezo, ben jij dan bereid om, in ruil voor het afschaffen van advertenties, geld te betalen voor Tweakers ? Of mogen ze geen geld verdienen aan de website (die ook aardig wat geld kost) ?
Hoezo, ben jij dan bereid om, in ruil voor het afschaffen van advertenties, geld te betalen voor Tweakers ? Of mogen ze geen geld verdienen aan de website (die ook aardig wat geld kost) ?
27-10-2014, 13:53 door
Erik van Straten
Door Anoniem: "En tweakers zou dat soort partners niet moeten willen hebben, gezien de branche...."
Hoezo, ben jij dan bereid om, in ruil voor het afschaffen van advertenties, geld te betalen voor Tweakers ? Of mogen ze geen geld verdienen aan de website (die ook aardig wat geld kost) ?
Ik heb geen bezwaar tegen reclame als websites, die mij die reclame laten bekijken, verantwoordelijkheid nemen voor de inhoud daarvan. In plaats van dat websites een veiliger advertentiemodel omarmen, laten ze bezoekers steeds vaker Russisch Roulette spelen.Hoezo, ben jij dan bereid om, in ruil voor het afschaffen van advertenties, geld te betalen voor Tweakers ? Of mogen ze geen geld verdienen aan de website (die ook aardig wat geld kost) ?
Op 2014-07-20 legde Joost Schellevis in een uitstekend artikel uit wat er mis is op de advertising markt, zie https://tweakers.net/reviews/3614/1/overal-een-kans-op-een-virus-hoe-banners-worden-misbruikt-inleiding.html en volgende pagina's.
Uit https://tweakers.net/reviews/3614/2/overal-een-kans-op-een-virus-hoe-banners-worden-misbruikt-advertentieruimte-inkopen.html:
Door Joost Schellevis, zondag 20 juli 2014 10:32: Daarnaast kunnen aanvallers net als legitieme bedrijven advertentieruimte inkopen. Dat is makkelijker dan ooit, nu steeds meer websites hun advertentieruimte verkopen via partnerbedrijven en geautomatiseerde beurzen. Daardoor weten ze vaak niet wie er op hun website adverteert. Steeds meer websites stappen over op die geautomatiseerde bannerverkoop; ook Tweakers houdt er momenteel een proef mee.
Die "proef" loopt kennnelijk al veel langer, uit https://gathering.tweakers.net/forum/list_message/40924774#40924774 (maar lees vooral verder, want hier blijft het niet bij):
Door "thanx", maandag 23 september 2013 08:32: hmmm
Vandaag start ik tweakers en krijg ik direct een waarschuwing van Trend Micro.
Kennelijk wordt er iets getriggerd wat TM niet leuk vindt :)
Gebeurde maar één keer, kan het (nog?) niet reproduceren....
betreft script van http://eu2.madsone.com/js/adrequest.js?_=1379917322238 (en de rest van de url is voor mij onleesbaar omdat dat in de TM client niet zichtbaar is)
Tot nu toe nog nooit last van gehad op tweakers.
Goh, wat een verrassing.Vandaag start ik tweakers en krijg ik direct een waarschuwing van Trend Micro.
Kennelijk wordt er iets getriggerd wat TM niet leuk vindt :)
Gebeurde maar één keer, kan het (nog?) niet reproduceren....
betreft script van http://eu2.madsone.com/js/adrequest.js?_=1379917322238 (en de rest van de url is voor mij onleesbaar omdat dat in de TM client niet zichtbaar is)
Tot nu toe nog nooit last van gehad op tweakers.
Door Anoniem: "En tweakers zou dat soort partners niet moeten willen hebben, gezien de branche...."
Hoezo, ben jij dan bereid om, in ruil voor het afschaffen van advertenties, geld te betalen voor Tweakers ? Of mogen ze geen geld verdienen aan de website (die ook aardig wat geld kost) ?
Hoezo, ben jij dan bereid om, in ruil voor het afschaffen van advertenties, geld te betalen voor Tweakers ? Of mogen ze geen geld verdienen aan de website (die ook aardig wat geld kost) ?
Nee: het concept van het aanbieden van http advertenties op een https website is verouderde achterhaalde techniek die je moet mijden. Als je ad-provider(s) dat niet wil(len), moet je geen zaken met ze willen doen. Als alle majors het kunnen moet tweakers het ook.
Het is storend en onnodig om daarbij te beginnen over inkomsten stromen. Dat is gewoon niet zo. Kies betrouwbare partners die weten wat ze doen en je hele site is https. ZOnder inkomsten verlies, eerder winst want je site loopt ook minder risico's.
27-10-2014, 15:20 door
Vandy
Wederom een zeer informatieve post, Erik, dank! En je hebt de voorpagina weer gehaald, zie ik.
Door Erik van Straten:
Die "proef" loopt kennnelijk al veel langer ... (maar lees vooral verder, want hier blijft het niet bij)
..
Die "proef" loopt kennnelijk al veel langer ... (maar lees vooral verder, want hier blijft het niet bij)
..
[+] Over die proef is hier ook al het nodige opgemerkt onder :
"Tweakers alles toelaten ?" en oa 2 longread reacties
https://www.security.nl/posting/398931#posting399600
https://www.security.nl/posting/398931#posting399073
[+] Is de Https wel/niet vraag zelf niet veel te eenzijdig ?
Want waar gaat het om?
Wel of geen https toestaan? Of mogelijk ook wel/niet extra code toestaan?
Allebei?
Ik denk eerlijk gezegd het laatste wanneer het om reclame gaat en het eerste wanneer het gaat om gebruikersfunctionaliteit als het inloggen / plaatsen van reacties en gegevens beheer.
Wat betreft de reclame en https.
Wel of niet je reclame input monitoren is minstens net zo belangrijk, of het nu over http of over https is, heb niet de indruk dat dat gebeurt.
En anders vrij selectief.
[+] Aannames * bij diverse constateringen :
Het is me opgevallen dat wanneer je op Tweakers (op hunnies verzoek) alles aan beschermende addons/extensies uitzet, er onregelmatig ineens geavanceerde HTML5Canvas tracking code actief is.
Onduidelijk was me steeds nog op welke pagina's dat gebeurde en wanneer precies.
12 )[/i] Onbekende Adder in het gras - Canvas fingerprinting op Tweakers ?!
(https://www.security.nl/posting/398931/Tweakers+alles+toelaten+%3F )Inmiddels is me met een zeer sterk vermoeden duidelijk dat die code (net altijd) actief is op het moment dat er een knalgele reclame-banner van Autotrack (ook persgroep) actief in beeld getoond wordt.
Het meerdere malen van samenvallen van feiten is op zich nog geen sluitend bewijs, ontzet Autotrack dan met een andere/betere analyse.
Ervan uitgaande dat Tweakers haar gebruikers zelf niet op deze slinkse wijze trackt (...) met gebruik van het geavanceerde HTML5Canvas tracking, wordt dan in ieder geval toch duidelijk dat zij haar reclames niet altijd monitort en controleert op extra actieve codes, of dit bewust toestaat.
Dat betekent niet alleen dat een aanbieder als Autotrack op dat banner moment reclame serveert maar ook nog eens actief met code de gebruikers trackt. (Dubbele winst.)
Als Autotrack extra code in haar reclame kan mee serveren kan elke andere malvertiser dat ook.
Tweakers heeft er na het experiment het volle vertrouwen in dat zij geen slachtoffer wordt van malvertising omdat haar tarieven aan de hoge kant zijn.
[+] Security argument(en) Tweakers
Eén belangrijk Security argument van Tweakers voor de 'succes'aanpak : Security by obscurity (?)
https://www.security.nl/posting/398931#posting399600[+] Vele 3rd party verbindingen, Https en http dus security en privacy risico's voor gebruikers
13) Buitenste-binnen Tweakers
https://www.security.nl/posting/398931#posting399073Tweakers maakt haar keuzes en gebruikers ook.
De ene gebruiker zet vol vertrouwen alles open voor reclame, tracking en het weggeven van haar configuratis/computerprofiel bij toegepaste HTML5Canvas tracking.
Een ander weer niet, met goed te verdedigen (security/privacy) recht. Het verdienmodel van de aanbieders gaat niet boven de security van de lezers, hoe hard de content aanbieder ook vindt van wel.
* Een aanname
(of een verkeerde conclusie?)
27-10-2014, 19:16 door
ej__
Je vergeet een belangrijk voordeel: google gaat sites met https voortrekken boven sites zonder http...
Waarom eindigt het artikel met "Een website overzetten van http naar https is een ingewikkeld vraagstuk" ?
Zo lastig is het toch niet?
Waar is de tijd gebleven dat gretige techneuten dit soort varkentjes wel eens even wasten en er nog voldoening uit haalden ook?
Zo lastig is het toch niet?
Waar is de tijd gebleven dat gretige techneuten dit soort varkentjes wel eens even wasten en er nog voldoening uit haalden ook?
Moet men voor deze vraag niet beginnen bij de essentie van het versleutelen. In het geval van tweakers ga je publiekelijk toegankelijke artikelen met ook nog eens doodnormaal karakter nu standaard versleuteld aanbieden. Wat is de meerwaarde hiervan? Als je niet wil dat iemand kan meekijken welke artikelen je leest kun je zelf kiezen voor https? Iets wat misschien pas wenselijk is bij het via een hotspot opzoeken van informatie op een medische website over een of andere lichamelijke aandoening.
Het probleem van alles versleutelen is dat het het internet er niet veiliger op zal maken. Inlichtingendiensten willen toch alles wel te weten komen en hebben niet te vergeten enorm veel resources. Als alle verkeer ineens versleuteld is zijn zij nog veel meer genoodzaakt bij zwakheden in verschillende soorten encryptie en inbraak in systemen. En verzwakte encryptie en systemen zijn dan tevens een prooi voor alles wat niet-overheid is. De optelsom is dus onveiliger.
Als we eerst eens zorgen dat portals waar echt persoonlijke informatie in omgaat (b.v. medische wereld / verzekeraars / uitzendbureaus / gemeenten / etc ) https gebruiken voor het aanmelden van gegevens dan zijn we al een behoorlijk eind op weg naar de gulden middenweg. Nu is het namelijk triest gesteld met de portals waar burgers allerlei formulieren moeten invullen. Helaas bemoeit de overheid zich hier weer niet genoeg mee. Het enige wat je nu kan doen is bij het College bescherming persoonsgegevens http://www.mijnprivacy.nl/signaal/Pages/Signaal_geven.aspx invullen en hopen dat er iets mee gebeurd.
En verder, het implementeren van DNSSEC en een einde maken aan het onversleuteld rondmailen van allerlei gevoelige documenten zijn denk ik belangrijkere doelen dan tweakers.net standaard over https.
Het probleem van alles versleutelen is dat het het internet er niet veiliger op zal maken. Inlichtingendiensten willen toch alles wel te weten komen en hebben niet te vergeten enorm veel resources. Als alle verkeer ineens versleuteld is zijn zij nog veel meer genoodzaakt bij zwakheden in verschillende soorten encryptie en inbraak in systemen. En verzwakte encryptie en systemen zijn dan tevens een prooi voor alles wat niet-overheid is. De optelsom is dus onveiliger.
Als we eerst eens zorgen dat portals waar echt persoonlijke informatie in omgaat (b.v. medische wereld / verzekeraars / uitzendbureaus / gemeenten / etc ) https gebruiken voor het aanmelden van gegevens dan zijn we al een behoorlijk eind op weg naar de gulden middenweg. Nu is het namelijk triest gesteld met de portals waar burgers allerlei formulieren moeten invullen. Helaas bemoeit de overheid zich hier weer niet genoeg mee. Het enige wat je nu kan doen is bij het College bescherming persoonsgegevens http://www.mijnprivacy.nl/signaal/Pages/Signaal_geven.aspx invullen en hopen dat er iets mee gebeurd.
En verder, het implementeren van DNSSEC en een einde maken aan het onversleuteld rondmailen van allerlei gevoelige documenten zijn denk ik belangrijkere doelen dan tweakers.net standaard over https.
Okee. Dus bij https geeft de server mij unieke informatie waaraan ik kan zien of ik wel echt met de bedoelde server ben verbonden (namelijk die certificaat-informatie). Dit noem je ook wel "authenticatie van de server."
(lijkt een beetje op "legitimeren" in het gewone dagelijkse leven, maar nu is meneer de agent (de "server") zo vriendelijk om zich aan jou te legitimeren... Best wel een goed idee eigenlijk?)
Misschien domme vraag, maar voor de zekerheid stel ik hem toch maar:
verstrekt een computer (cliënt) op eenzelfde soort manier ook unieke informatie aan de server. Dus zodat de server precies kan zien met welke computer hij heeft te maken? (nee, ik denk hier niet aan IP-adressen en/of cookies)
Of anders gezegd: bezit iedere computer (in de software???) ook een nogal uniek "certificaat" waarmee hij zich bij het gebruik van https iedere keer op dezelfde manier "legitimeert"?
(lijkt een beetje op "legitimeren" in het gewone dagelijkse leven, maar nu is meneer de agent (de "server") zo vriendelijk om zich aan jou te legitimeren... Best wel een goed idee eigenlijk?)
Misschien domme vraag, maar voor de zekerheid stel ik hem toch maar:
verstrekt een computer (cliënt) op eenzelfde soort manier ook unieke informatie aan de server. Dus zodat de server precies kan zien met welke computer hij heeft te maken? (nee, ik denk hier niet aan IP-adressen en/of cookies)
Of anders gezegd: bezit iedere computer (in de software???) ook een nogal uniek "certificaat" waarmee hij zich bij het gebruik van https iedere keer op dezelfde manier "legitimeert"?
28-10-2014, 13:09 door
Mapa
Door Anoniem:
Misschien domme vraag, maar voor de zekerheid stel ik hem toch maar:
verstrekt een computer (cliënt) op eenzelfde soort manier ook unieke informatie aan de server. Dus zodat de server precies kan zien met welke computer hij heeft te maken? (nee, ik denk hier niet aan IP-adressen en/of cookies)
Of anders gezegd: bezit iedere computer (in de software???) ook een nogal uniek "certificaat" waarmee hij zich bij het gebruik van https iedere keer op dezelfde manier "legitimeert"?
Het proces wat jij beschrijft bestaat wel (tweezijdige SSL), maar gebeurt met consent van de gebruiker, als deze een gekwalificeerd certificaat heeft dat zijn identiteit bewijst. De gemiddelde gebruiker heeft echter niet zo'n certificaat en dan wordt er (anders dan de door jou al geschetste ip adressen, cookies, browser fingerprinting) geen identificatie gedaan.Misschien domme vraag, maar voor de zekerheid stel ik hem toch maar:
verstrekt een computer (cliënt) op eenzelfde soort manier ook unieke informatie aan de server. Dus zodat de server precies kan zien met welke computer hij heeft te maken? (nee, ik denk hier niet aan IP-adressen en/of cookies)
Of anders gezegd: bezit iedere computer (in de software???) ook een nogal uniek "certificaat" waarmee hij zich bij het gebruik van https iedere keer op dezelfde manier "legitimeert"?
29-10-2014, 00:20 door
Erik van Straten
Ik wil op deze plaats mijn excuses aanbieden.
In een bijdrage die ik ca. 24 uur geleden hier heb gepost, verwees ik (als voorbeeld) naar een lid van Tweakers. Hoewel ik zijn naam niet noemde, vermeldde ik wel zijn nickname (en plaatste een verwijzing naar een plaatje van zijn kamer - dat hij zelf op Internet gezet had). En ik schreef dat ik zijn woonplaats, en vermoedelijk zijn adres, eenvoudig kon vinden. Op basis daarvan schetste ik een scenario hoe een kwaadwillende aanvaller van deze kennis, en het gebrek aan https bij Tweakers, misbruik zou kunnen maken van zijn "gezag" op de Tweakers website.
De redactie heeft mijn bijdrage -terecht- verwijderd. Ik zal voortaan proberen om mijn punt te maken zonder daar personen bij te betrekken die inhoudelijk niets met de zaak te maken hebben.
In een bijdrage die ik ca. 24 uur geleden hier heb gepost, verwees ik (als voorbeeld) naar een lid van Tweakers. Hoewel ik zijn naam niet noemde, vermeldde ik wel zijn nickname (en plaatste een verwijzing naar een plaatje van zijn kamer - dat hij zelf op Internet gezet had). En ik schreef dat ik zijn woonplaats, en vermoedelijk zijn adres, eenvoudig kon vinden. Op basis daarvan schetste ik een scenario hoe een kwaadwillende aanvaller van deze kennis, en het gebrek aan https bij Tweakers, misbruik zou kunnen maken van zijn "gezag" op de Tweakers website.
De redactie heeft mijn bijdrage -terecht- verwijderd. Ik zal voortaan proberen om mijn punt te maken zonder daar personen bij te betrekken die inhoudelijk niets met de zaak te maken hebben.
Door Anoniem: Waarom eindigt het artikel met "Een website overzetten van http naar https is een ingewikkeld vraagstuk" ?
Zo lastig is het toch niet?
Waar is de tijd gebleven dat gretige techneuten dit soort varkentjes wel eens even wasten en er nog voldoening uit haalden ook?
Zo lastig is het toch niet?
Waar is de tijd gebleven dat gretige techneuten dit soort varkentjes wel eens even wasten en er nog voldoening uit haalden ook?
Juist, ja. Er is nix moeilijks aan, qua techniek. Het moeilijke is afleren te luisteren naar marketing dumbo's die beweren dat zij anders geen ad-content kunnen leveren. De grachtengordel zit vol met dat soort onkunde en tweakers luistert er kennelijk naar... Technisch is het een eitje. Google ondersteunt je er zelfs bij en dan kan mijn oma het ook.
Door Anoniem:
Juist, ja. Er is nix moeilijks aan, qua techniek. Het moeilijke is afleren te luisteren naar marketing dumbo's die beweren dat zij anders geen ad-content kunnen leveren. De grachtengordel zit vol met dat soort onkunde en tweakers luistert er kennelijk naar... Technisch is het een eitje. Google ondersteunt je er zelfs bij en dan kan mijn oma het ook.
Door Anoniem: Waarom eindigt het artikel met "Een website overzetten van http naar https is een ingewikkeld vraagstuk" ?
Zo lastig is het toch niet?
Waar is de tijd gebleven dat gretige techneuten dit soort varkentjes wel eens even wasten en er nog voldoening uit haalden ook?
Zo lastig is het toch niet?
Waar is de tijd gebleven dat gretige techneuten dit soort varkentjes wel eens even wasten en er nog voldoening uit haalden ook?
Juist, ja. Er is nix moeilijks aan, qua techniek. Het moeilijke is afleren te luisteren naar marketing dumbo's die beweren dat zij anders geen ad-content kunnen leveren. De grachtengordel zit vol met dat soort onkunde en tweakers luistert er kennelijk naar... Technisch is het een eitje. Google ondersteunt je er zelfs bij en dan kan mijn oma het ook.
Het lichte vermoeden bestaat dat je dit artikel niet gelezen hebt.
"Tweakers schakelt automatische bannerverkoop in"
https://tweakers.net/plan/772/tweakers-schakelt-automatische-bannerverkoop-in.html?mode=nested&niv=-1&order=asc&page=1#reacties
Het is de moeite waard.
Zeker met de reacties erbij, een must voor de discussie, ga er maar goed voor zitten. Let extra op de reacties van de mee reagerende redacteuren en hoofdredacteur.
Op de tweede pagina 'precies' de argumenten behandeld die je hier aansnijdt
https://tweakers.net/plan/772/tweakers-schakelt-automatische-bannerverkoop-in.html?mode=nested&niv=-1&order=asc&page=2#reacties
Licht na het lezen van die tweede tweakers pagina jouw reactie nog eens toe.
Door Anoniem:
Misschien domme vraag, maar voor de zekerheid stel ik hem toch maar:
verstrekt een computer (cliënt) op eenzelfde soort manier ook unieke informatie aan de server. Dus zodat de server precies kan zien met welke computer hij heeft te maken? (nee, ik denk hier niet aan IP-adressen en/of cookies)
Of anders gezegd: bezit iedere computer (in de software???) ook een nogal uniek "certificaat" waarmee hij zich bij het gebruik van https iedere keer op dezelfde manier "legitimeert"?
Misschien domme vraag, maar voor de zekerheid stel ik hem toch maar:
verstrekt een computer (cliënt) op eenzelfde soort manier ook unieke informatie aan de server. Dus zodat de server precies kan zien met welke computer hij heeft te maken? (nee, ik denk hier niet aan IP-adressen en/of cookies)
Of anders gezegd: bezit iedere computer (in de software???) ook een nogal uniek "certificaat" waarmee hij zich bij het gebruik van https iedere keer op dezelfde manier "legitimeert"?
Er gebeurt ongeveer het volgende wanneer je browser een beveiligde verbinding (https) opzet:
1. Server and client komen een cipher-algoritme overeen die aan beide zijden wordt ondersteund
2. Server zendt zijn publieke sleutel en certificaat naar de client
3. Client kan certificaat verifiëren m.b.v. digitale handtekening van Certification Authority die certificaat heeft uitgebracht.
4. Client (browser) genereert een willekeurig getal ("master secret"), codeert dit met de publieke sleutel van de server,
en zendt het naar de server. (opmerking: alleen de server kan dit decoderen met behulp van de private sleutel)
5. Beide partijen leiden van het "master secret" de sleutel af die tijdens de sessie voor de rest van de communicatie
tussen betreffende client en server gebruikt zal worden.
Iemand die ergens de lijn zou aftappen, kan bij deze methode geen inhoudelijke informatie over de lijn zien gaan.
En een minstens zo belangrijk veiligheidsaspect bij dit onderwerp (en nog steeds niet iedereen lijkt dit te beseffen):
een aanvaller kan bij https niet meer zoals bij http gemakkelijk valse inhoud injecteren!
(denk hierbij niet alleen aan puur informatievervalsing, maar bijv. ook aan dingen als een link aanpassen door hem naar een site met malware door te laten verwijzen, e.d. zoals Erik van Straten in zijn uitgebreide betoog ook min of meer wel aangeeft) Dergelijke geintjes kun je vooral tegenkomen bij publieke WiFi-spots.
Het draait bij https dus niet alleen maar om het wel of niet vertrouwelijk zijn van informatie.
Want https helpt tegen méér dingen dan alleen maar informatie vertrouwelijk houden.
Dus zelfs wanneer de hele wereld alle informatie best weten mag, kan https nog steeds heel erg nuttig zijn!
Maar terugkomend op je vraag: hiermee is (hoop ik) nog wat verduidelijkt en bevestigd dat het zo is als "13:09 door IDtect" al min of meer zei: er kan (anders dan de door jou al geschetste ip adressen, cookies, browser fingerprinting) normaalgesproken geen identificatie worden gedaan.
Mvg, cluc-cluc.
27-10-2014, 13:14 door Anoniem: @Erik :
"Anderzijds, het feit dat Tweakers.net geen fatsoenlijke beveiliging biedt, resulteert erin dat ik persoonlijk daar al twee jaar niet meer heb ingelogd (tot vandaag, om te testen)."
Kan je ons dan eens laten weten welke risico's er naar voren kwamen bij het niet-encrypted gebruik van Tweakers.net aangezien je stelt dat je een risico analyse hebt gemaakt ?
Ik weet niet waar jij leest dat ik stel dat ik een risico-analyse van Tweakers.net heb gemaakt. Wat ik probeer duidelijk te maken, is dat je bij zo'n vraagstuk een risico-analyse hoort te (laten) maken, op maat gesneden op de organisatie en haar "klanten"."Anderzijds, het feit dat Tweakers.net geen fatsoenlijke beveiliging biedt, resulteert erin dat ik persoonlijk daar al twee jaar niet meer heb ingelogd (tot vandaag, om te testen)."
Kan je ons dan eens laten weten welke risico's er naar voren kwamen bij het niet-encrypted gebruik van Tweakers.net aangezien je stelt dat je een risico analyse hebt gemaakt ?
Het inleidende stuk op tweakers.net [1] (link bovenaan deze pagina) suggereert geenszins dat dit gebeurd is; de grootste zorg lijkt performance te zijn (ruim 4 jaar geleden liet Google al zien dat dit geen issue hoeft te zijn, zie https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html, en ondertussen draaien vele zeer grote sites op https).
Ik heb terloops wel op één risico gewezen, namelijk dat, als je ingelogd bent op tweakers.net, jouw authenticatie cookie onversleuteld wordt verzonden en daardoor gekaapt zou kunnen worden. Daar moet je je dan wel de vragen bij stellen: A) waarom zou een aanvaller dat willen en B) hoe lastig is het om zo'n aanval uit te voeren.
A) Een aanvaller kan verschillende motieven hebben, ik noem er een viertal (allemaal identiteitsdiefstal, 1+2 gericht tegen een specifieke Tweaker, bij de andere twee is "wie" nauwelijks van belang):
1) "Defacement": iemand die een hekel heeft aan een Tweaker, zou diens account kunnen kapen, en dan namens die persoon ruzie maken met andere Tweakers. Dat kan knap lastig uit te leggen zijn. Ik zie vaak genoeg hier op security.nl mensen klagen die voor schut worden gezet.
2) De aanvaller kan zodanige schofferende bijdragen namens een Tweaker plaatsen dat die Tweaker gebanned wordt. Lastig uit te leggen, zie het maar eens te bewijzen dat jij die bijdragen niet gepost hebt.
3) Misbruik maken van "gezag": stel je een Tweaker voor die er om bekend staat dat hij vaak links post naar handige tools, waar vervolgens weer anderen naar verwijzen. Of denk aan door een Tweaker gescheven reviews waarbij links naar firmware denkbaar zijn. Een aanvaller die dergelijke links wijzigt (of toevoegt) zodat malware wordt gedownload, kan die Tweaker in diskrediet brengen (en is zelf lastig te traceren).
4) Een Tweaker zou een mailtje kunnen ontvangen van een afperser:
Ik heb in meer dan 1000 van jouw oudere bijdragen links naar kinderporno opgenomen. Ik noem er enkele dit om te bewijzen: <1>, <2>, <3>. Als jij mij 1 Bitcoin betaalt vertel ik je welke andere bijdragen ik gewijzigd heb. Als je niet binnen 1 week betaalt doe ik aangifte bij de politie.
Waarschijnlijk zal de Tweaker meteen zijn wachtwoord wijzigen, maar dat lost het probleem natuurlijk niet op.En tenzij de Tweaker een slim tooltje bedenkt, kan hij blijven twijfelen of hij alle ongewenste links heeft kunnen verwijderen.
Een creatieve aanvaller kan vast wel meer narigheid bedenken.
Een account zegt iets over jou (en kennelijk snap je dat heel goed, want je post hier anoniem - iets dat niet kan op Tweakers.net). Het is moeilijk om je voor te stellen dat iemand misbruik van van jouw account zou willen maken, maar de praktijk is dat er mensen zijn die dit overkomt. Niet veel, maar je zult het maar zijn.
B) Hoe lastig is zo'n aanval? Ik vermoed dat er Tweakers te vinden zijn die hun IP-adres (evt. via DynDNS etc.) en merk+type modem hebben gepost, en dat remote toegang enabled is. Bij de loodgieter lekt de kraan, de kans dat je op zo'n modem kunt inbreken en de DNS instellingen wijzigen acht ik in een deel van de gevallen reëel.
Van veel Tweakers is het ook niet moeilijk om hun woonplaats en adres te achterhalen. Een aanvaller zou dan vlak bij het huis van zo'n Tweaker zijn WiFi kunnen proberen te hacken. Of de aanvaller wacht tot die (of een willekeurige) Tweaker via een public WiFi hotspot inlogt op de Tweakers site. Een willekeurig TU studentenhuis is ook een "mooi" target.
Afgelopen maandagavond werd in het 20:00 Journaal (http://nos.nl/uitzendingen/22359-nos-journaal-27-oktober-2014-2000u.html, op offset 19:25), nog gewaarschuwd voor open WiFi netwerken. Helaas was dat wel weer een enorm ingekort sensatieverhaal. Zomaar meekijken bij een Facebook login kan niet, want juist https beschermt je (en juist dat knippen ze eruit). Met MSIE wel onder voorwaarde dat je weet waar je op moet letten, maar met andere browsers is de kans op een geslaagde MitM aanval, door HSTS (http Strict-Transport-Security), nagenoeg nul.
27-10-2014, 23:19 door Anoniem: In het geval van tweakers ga je publiekelijk toegankelijke artikelen met ook nog eens doodnormaal karakter nu standaard versleuteld aanbieden. Wat is de meerwaarde hiervan?
Zie mijn reactie hierboven. Of lees artikelen te vinden via Google: firesheep site:security.nlHttp heeft z'n langste tijd gehad. Uit
https://www.ietf.org/proceedings/90/slides/slides-90-httpbis-0.pdf:
Door Adam Langley:
Plaintext is no longer reasonable.
We cannot build a sane Internet without end-to-end cryptography.
Laten we nou niet zeuren over een paar milliseconden (performanceverlies) en het Internet veiliger maken, maar dan wel meteen goed!Plaintext is no longer reasonable.
We cannot build a sane Internet without end-to-end cryptography.
@Anoniem 27-10-2014, 15:35: dank voor jouw post, ik zie dat de discussie over gevaarlijke reclamebanners op Tweakers al eerder is gevoerd. Ik heb me ook in die discussie laten meetrekken. Ervan uitgaande dat de advertisers die nog geen https ondersteunen, dat in de portemonnee zullen gaan voelen, komt dat vanzelf wel goed (https zal malvertising echter niet verhinderen).
Het volgend artikel vond ik eind van de middag toevallig: https://wingolog.org/archives/2014/10/17/ffs-ssl, grappig geschreven vind ik. Maar wel typisch waar een onervaren beheerder tegenaan loopt nadat diens baas zegt "doe de site ff via https".
Voor die site-eigenaren kost beveiligen geld, niks doen is veel goedkoper (er worden, bij geconstateerde misstanden, zelden boetes uitgedeeld). De praktijk is (helaas) dat alleen media-aandacht gevolgd door kamervragen in een deel van de gevallen iets uithaalt. Met mijn artikelen probeer ik vooral een stuk bewustzijn bij beheerders te kweken (zoveel mogelijk onderbouwd met argumenten en referenties). Want klussen, die "moeten van de baas", terwijl de uitvoerder niet snapt waarom, gaan zelden in 1x goed.
Kennelijk is men zich onvoldoende bewust van de risico's - getuige de vele vragen waarom https nodig is (c.q. meningen dat https onzin is en teveel performance kost), ook bij sites als Tweakers.net.
Aan iedereen die gereageerd heeft: dank voor jullie bijdragen!
27-10-2014, 22:58 door Anoniem: Waarom eindigt het artikel met "Een website overzetten van http naar https is een ingewikkeld vraagstuk" ?
Zo lastig is het toch niet?
Als dat klopt dan begrijp ik niet waarom sites als van DigiD, KPN ABP, SNS en ASN nog zodanig RC4 ondersteunen dat bijna elke verbinding daar gebruik van maakt. Zie ook https://www.security.nl/posting/406605/Overheid+gaat+burgers+via+veiliginternetten_nl+voorlichten.Zo lastig is het toch niet?
Het volgend artikel vond ik eind van de middag toevallig: https://wingolog.org/archives/2014/10/17/ffs-ssl, grappig geschreven vind ik. Maar wel typisch waar een onervaren beheerder tegenaan loopt nadat diens baas zegt "doe de site ff via https".
27-10-2014, 23:19 door Anoniem: Het probleem van alles versleutelen is dat het het internet er niet veiliger op zal maken. Inlichtingendiensten willen toch alles wel te weten komen en hebben niet te vergeten enorm veel resources. Als alle verkeer ineens versleuteld is zijn zij nog veel meer genoodzaakt bij zwakheden in verschillende soorten encryptie en inbraak in systemen. En verzwakte encryptie en systemen zijn dan tevens een prooi voor alles wat niet-overheid is. De optelsom is dus onveiliger.
Los van dat ik denk dat inlichtendiensten nog heel veel mogelijkheden hebben, bevestig je zelf dat de informatie op Tweakers openbaar is. Er is dus geen aanleiding voor inlichtendiensten om op verbindingen met die site in te breken. Het gaat mij trouwens vooral om het beperken van cybercrime.27-10-2014, 23:52 door Anoniem: Misschien domme vraag, maar voor de zekerheid stel ik hem toch maar:
verstrekt een computer (cliënt) op eenzelfde soort manier ook unieke informatie aan de server. Dus zodat de server precies kan zien met welke computer hij heeft te maken? (nee, ik denk hier niet aan IP-adressen en/of cookies)
Of anders gezegd: bezit iedere computer (in de software???) ook een nogal uniek "certificaat" waarmee hij zich bij het gebruik van https iedere keer op dezelfde manier "legitimeert"?
Nee, dat is geen domme vraag. Zoals cluc-cluc hierboven beschrijft wordt heel soms van een client certificaat gebruik gemaakt, als extra beveiliging (naast gebruikersnaam en wachtwoord). De eigenaar van de server is echter niet geïnteresseerd in jouw computer, maar juist in wie jij bent, de interaktieve gebruiker. Daarom moet je op veel sites een account maken om zinvolle functionaliteit te krijgen.verstrekt een computer (cliënt) op eenzelfde soort manier ook unieke informatie aan de server. Dus zodat de server precies kan zien met welke computer hij heeft te maken? (nee, ik denk hier niet aan IP-adressen en/of cookies)
Of anders gezegd: bezit iedere computer (in de software???) ook een nogal uniek "certificaat" waarmee hij zich bij het gebruik van https iedere keer op dezelfde manier "legitimeert"?
27-10-2014, 23:52 door Anoniem: Als we eerst eens zorgen dat portals waar echt persoonlijke informatie in omgaat (b.v. medische wereld / verzekeraars / uitzendbureaus / gemeenten / etc ) https gebruiken voor het aanmelden van gegevens dan zijn we al een behoorlijk eind op weg naar de gulden middenweg. Nu is het namelijk triest gesteld met de portals waar burgers allerlei formulieren moeten invullen. Helaas bemoeit de overheid zich hier weer niet genoeg mee. Het enige wat je nu kan doen is bij het College bescherming persoonsgegevens http://www.mijnprivacy.nl/signaal/Pages/Signaal_geven.aspx invullen en hopen dat er iets mee gebeurd.
Waarom is dat het enige dat je kunt doen? Gebruik de kennis die je hebt en meld misstanden bij de site-eigenaren en/of post ze op sites als security.nl.Voor die site-eigenaren kost beveiligen geld, niks doen is veel goedkoper (er worden, bij geconstateerde misstanden, zelden boetes uitgedeeld). De praktijk is (helaas) dat alleen media-aandacht gevolgd door kamervragen in een deel van de gevallen iets uithaalt. Met mijn artikelen probeer ik vooral een stuk bewustzijn bij beheerders te kweken (zoveel mogelijk onderbouwd met argumenten en referenties). Want klussen, die "moeten van de baas", terwijl de uitvoerder niet snapt waarom, gaan zelden in 1x goed.
Kennelijk is men zich onvoldoende bewust van de risico's - getuige de vele vragen waarom https nodig is (c.q. meningen dat https onzin is en teveel performance kost), ook bij sites als Tweakers.net.
Aan iedereen die gereageerd heeft: dank voor jullie bijdragen!
Zoals cluc-cluc hierboven beschrijft wordt heel soms van een client certificaat gebruik gemaakt, als extra beveiliging (naast gebruikersnaam en wachtwoord).
Kleine justificatie hier: ik ging in mijn bericht van 16:39 juist even in op een normale situatie van de doorsnee internetter,
waarbij alleen de website een certificaat levert, en de cliënt niet. ;-)
De informatie over de mogelijkheid van een cliënt-certificaat is van IDtect, 28-10-2014, 13:09.
Voor bepaalde doelen kan dit handig zijn. Het eerste waar ik aan denk is een eigen E-mail-certificaat. Eigenlijk net zoiets.
Bij gecertificeerde E-mail weet men zo goed als zeker wie de afzender van een bericht is.
Overigens niets aan te merken op dat bericht van IDtect. Maar vermoedde dat het verduidelijkend kon zijn om nog even kort te beschrijven hoe een https -verbinding (met alleen een servercertificaat en geen cliëntcertificaat) tot stand komt, en dat "legitimatie" van de client daarbij dus niet nodig is. Vandaar dat ik dit in mijn post van 16:39 nog even had gedaan.
Mvg, cluc-cluc.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
