Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
SSLv3 "Poodle" lek voor leken
Hoe ga je, als gewone gebruiker, om met lekken die het nieuws halen maar waar nog geen druk-op-de-knop patch voor bestaat? Haal je je schouders op, of bezoek je sites als security.nl op zoek naar informatie? Om er vervolgens achter te komen dat allerlei nerds met onbegrijpelijke termen strooien, het niet eens zijn over de risico's die je loopt en uiteenlopende adviezen geven?
Uit https://www.security.nl/posting/405340/Ernstig+beveiligingslek+in+SSL+3_0+ontdekt#posting405403:
Wat is een protocol
Als je http://www.nu.nl/ in de URL balk van jouw webbrowser intikt en de Enter toets indrukt, gebeurt er vanalles. De meeste mensen zal het echter een biet zijn wat er precies gebeurt, zolang ze de verwachte nieuwssite maar voor hun neus krijgen. Het is een ander verhaal als je een foutmelding krijgt, maar meestal gaat het gewoon goed.
We vinden het ook heel normaal dat we hetzelfde nieuws te zien krijgen als we een andere webbrowser, een ander besturingssysteem of een smartphone i.p.v. een notebook gebruiken. En daarbij hebben we geen flauw idee welk besturingssysteem de server van www.nu.nl gebruikt en welke webserversoftware daarop draait.
Om dit mogelijk te maken heb je heel goede afspraken en spelregels nodig; ICT-ers gebruiken daar de term "protocol" voor. Uiteindelijk gaan er reeksen enen en nullen heen en weer tussen onze webbrowser en de gekozen webserver; we gebruiken protocollen om vast te leggen hoe die reeksen van enen en nullen moeten worden geïnterpreteerd.
Voorbeeld: de eerste acht nullen en enen aan HTML code (waarmee webpagina's zijn opgebouwd) die de webserver naar de webbrowser stuurt zijn 00111100. De webbrowser is zo geprogrammeerd dat die code vertaald wordt in het kleiner-dan teken, dus "<", en in het HTML protocol is verder vastgelegd wat de webbrowser moet doen met de informatie die daarop volgt. Als je wel eens broncode van een HTML pagina bekeken hebt, weet je dat deze meestal met < begint.
Meerdere lagen van protocollen
Als je een papieren brief in een brievenbus van PostNL gooit, interesseert het je niet hoe deze van A naar B gaat (bestelauto, trein, vrachtauto, vliegtuig, fiets), welke sorteercentra deze passeert, in welke postzak deze belandt en welk adres er op die postzak staat. Je wilt dat de brief onbeschadigd en op tijd wordt bezorgd. Je trekt als het ware een streep onder de "verbinding" tussen jezelf en de ontvanger; wat er onder die streep gebeurt interesseert je niet.
Vergelijkbaar, bij de uitwisseling van gegevens tussen server en browser worden meerdere protocollen gebruikt op verschillende "lagen" in de computers aan beide kanten. Het genoemde HTML protocol beschrijft hoe een webpagina eruit moet zien. Daaronder zit een http protocol, vergelijkbaar met een envelop waarbij HTML de brief is. Daaronder zit weer een netwerkprotocol (met opnieuw een soort envelop of, zo je wilt, postzak) dat er heel anders uitziet afhankelijk van of je WiFi naar je tablet, een netwerkkabel naar je PC of G3/G4 naar je mobiel gebruikt. Doordat die protocollen zo onafhankelijk mogelijk van elkaar zijn, maakt het type netwerkverbinding niet uit voor wat je van www.nu.nl te zien krijgt.
Direct nadat je http://www.nu.nl/ hebt ingetikt en Enter hebt gedrukt, maakt jouw PC gebruik van het DNS protocol om van de naam "www.nu.nl" het bijbehorende IP-adres op te zoeken. Net als postbodes niet weten waar Erik van Straten woont en minstens een postcode + huisnummer nodig hebben, gebruiken computers op internet unieke IP-adressen om met elkaar te communiceren. Waar de eerder genoemde protocollen voortdurend worden gebruikt, wordt DNS maar af en toe gebruikt; meestal onthoudt de webbrowser zo'n IP-adres een tijdje.
Wat is SSL
Ook SSL is een protocol. Het is uitgevonden toen mensen vertrouwelijke informatie tussen webbrowsers en servers wilden uitwisselen (men was er allang achter dat netwerkkabels kunnen worden afgetapt, waarmee derden de gegevens die worden uitgewisseld kunnen inzien en zelfs wijzigen).
Het SSL protocol verzorgt minimaal twee zaken:
1) Dat je als gebruiker behoorlijk zeker weet dat je verbinding hebt met de bedoelde server (dus
niet een server van een cybercrimineel);
2) Dat de verbinding zodanig goed is versleuteld dat iemand die een kabel aftapt, alleen maar onleesbare data ziet.
En dat natuurlijk onafhankelijk van besturingssysteem en/of webbrowser. Echter, besturingssystemen en browsers kunnen onderling flink verschillen, en veel fabrikanten hebben hun eigen idee over software die zo'n protocol verwerkt.
Bekende implementaties van software die het SSL protocol "verstaat" zijn OpenSSL (open source software), "Secure Channel" (ook bekend als SChannel) van Microsoft) en NSS (Network Security Services) zoals gebruikt door Firefox. Het "Heartbleed" lek eerder dit jaar ontstond door een implementatiefout (fout van de programmeur) in OpenSSL.
Wat is https
Hoewel het SSL protocol voor heel veel andere toepassingen wordt gebruikt, is https de meest bekende en vermoedelijk meest gebruikte toepassing. Feitelijk is SSL een laag die tussen het http protocol en het gebruikte netwerkprotocol wordt geschoven. SSL wordt actief direct nadat een IP-verbinding tussen jouw computer en de server is opgebouwd. Zodra de SSL verbinding tot stand is gekomen wordt er http verkeer uitgewisseld, wat weer een "drager" is voor HTML.
Wat gebeurt er bij het opzetten van een SSL verbinding
Aanvankelijk is er nog niets versleuteld. Immers, versleutelen heeft alleen zin als de ontvanger een sleutel heeft om uit te pakken wat de verzender heeft versleuteld en daarna heeft verstuurd. Beide partijen moeten dus een sleutel overeenkomen; dit is een van de zaken die gebeurt tijdens de SSL handshake (en dat is heel uitgekiend, want die sleutel kan natuurlijk niet onversleuteld worden uitgewisseld! Daar bestaan prima oplossingen voor, maar het voert te ver om dat hier nu uit te leggen).
Tijdens die handshake moet er meer worden overeengekomen. Zo zijn er, in de loop van de tijd, meerdere versies van het SSL protocol ontwikkeld. Daarbij zijn steeds verbeteringen doorgevoerd, zoals ondersteuning van nieuwere versleutelingsprotocollen (weer dat woord ;)
Wat is TLS
Lastig is dat een standaardisatiecommissie op een gegeven moment een nieuwe naam voor SSL heeft geïntroduceerd, namelijk TLS, en opnieuw bij versie 1.0 is begonnen. Op dit moment zijn de volgende versies van SSL en TLS in omloop:
SSL v2.0: Was al jaren kwetsbaar, niemand gebruikt dit.
SSL v3.0: Wordt nog steeds ondersteund door zeer veel servers, maar blijk "lek" te zijn.
TLS v1.0: Minimale verschillen met SSLv3. Voor zover nu bekend is TLS 1.0 niet lek.
TLS v1.1: Tussenversie.
TLS v1.2: Actuele versie, ondersteund door alle moderne webbrowsers, maar nog lang niet door alle servers.
Wat is het POODLE lek in SSLv3
Als je dat precies wilt weten kun je dit lezen: https://www.imperialviolet.org/2014/10/14/poodle.html. Los van de technische details: een aanvaller die kan "meekijken" op de verbinding (over hoe dat kan verderop meer) lijkt volkomen onleesbare versleutelde informatie te zien. Maar naar nu blijkt kan een aanvaller toch delen van de uitgewisselde informatie ontcijferen!
Iets dergelijks was allang bekend van SSL v2.0, en eerder waren er ook al lekken in SSLv3 die gerepareerd konden worden. Het huidige lek is zodanig dat repareren niet gaat, en bovendien had SSLv3 jaren geleden al buiten gebruik genomen moeten worden. Het gaat hierbij (in tegenstelling tot het eerder genoemde Heartbleed lek) om een denkfout in het protocol. Omdat alle programmeurs het protocol zo netjes mogelijk implementeren, zijn alle implementaties lek! De kwetsbaarheid in SSLv3 is dus onafhankelijk van besturingssystemen, webbrowsers en serversoftware.
Conclusie: we moeten voorkomen dat we vertrouwelijke gegevens uitwisselen via SSLv3.
Wat is het probleem, mijn browser gebruikt TLS v1.0 of TLS v1.2 naar alle https sites!
Klopt. Hoewel de meeste servers en browsers nog SSLv3 ondersteunen, zal tijdens de handshake voor het veiligste protocol worden gekozen dat beide kanten ondersteunen. Bij oudere servers is dat vaak TLS v1.0, bij moderne TLS v1.2.
En toch is er een probleem! Als een aanvaller zich in de verbinding tussen de webbrowser en de server weet te forceren, spreken we van een MitM aanval (Man-in-the-Middle). Die aanvaller kan gegevens ongewijzigd doorgeven, ze wijzigen of ze verwijderen. Daarmee kan hij de browser, tijdens de handshake, wijsmaken dat de server uitsluitend het SSLv3 protocol ondersteunt. Zo kan hij afdwingen dat er van SSLv3 gebruik gemaakt wordt, ook als beide partijen iets beters ondersteunen. Dit heet een "protocol downgrade attack".
Vervolgens laat hij de SSLv3 verbinding gewoon tot stand komen. Noch de client, noch de server heeft door dat er iets mis is, maar de aanvaller kan vervolgens proberen de uitgewisselde informatie te ontcijferen. De aanval zal vermoedelijk iets ingewikkelder zijn, voor zover ik het begrijp moet de aanvaller net doen alsof sommige gegevens corrupt raken waardoor server en/of client ze opnieuw zullen verzenden. Door beide partijen te dwingen bepaalde stukjes informatie herhaald uit te wisselen kan de aanvaller de versleutelde informatie stapje bij beetje ontcijferen. Theoretisch zouden clients en/of servers dit kunnen opmerken, maar in de praktijk wordt zoiets niet gelogd noch gemeld. Je hebt kans dat de verbinding wat trager lijkt dan normaal, maar dat kan ook door allerlei andere omstandigheden worden veroorzaakt ("hikken" zijn we ondertussen wel gewend, zeker op drukke WiFi netwerken).
Hoe komt die aanvaller op "mijn" netwerk?
Dit is, helaas, eenvoudiger dan veel mensen denken. In elk geval is het niet moelijk om een "rogue access point" (kwaadaardige WiFi hotspot) op te zetten. Stel een aanvaller weet dat jij vaak met de trein reist en dan van NS hotspots gebruik maakt. Dan kan hij, vanuit zijn auto voor jouw deur, een WiFi access point opzetten dat zich voordoet als een NS hotspot. Als hij daar een krachtige zender voor gebruikt is de kans groot dat als jij thuiskomt, jouw mobiele device (of de computer die je aanzet) met dat kwaadaardige hotspot verbindt in plaats van jouw eigen thuisnetwerk! En dat zonder dat je daar iets van merkt...
Tweede voorbeeld: als je via de webbrowser op jouw PC met een server op internet wilt communiceren, gaat dat natuurlijk via jouw modem/router en jouw ISP. Stel op jouw bedrade netwerk is ook een met malware besmette computer aangesloten. Dan is het in de praktijk zo dat de meeste netwerken niet kunnen voorkomen (en ook niet detecteren) dat die besmette computer zich "misdraagt" op dat netwerk. Die besmette computer kan zich bijvoorbeeld voordoen als jouw router/modem, en de kans is groot dat jouw PC daar in trapt. Het gevolg is dat de gegevens tussen jouw webbrowser en de server via die besmette computer lopen, waarmee een MitM aanval mogelijk is.
Derde voorbeeld: er zijn de laatste tijd erg veel lekken in modems/routers (ADSL-/kabel-) bij mensen thuis gevonden. In zo'n geval kunnen aanvallers bijvoorbeeld de in het modem ingestelde DNS server(s) te wijzigen. Als jij mijn.ing.nl als URL intikt, verloopt de DNS aanvraag voor het bijbehorende IP-adres dan niet meer via de vertrouwde DNS server van jouw ISP, maar gaat naar een DNS server in beheer van een cybercrimineel. En die kan jouw PC elk gewenst IP-adres teruggeven! Dat kan van een criminele server zijn die, als een doorgeefluik, op zijn beurt verbinding maakt met de echte mijn.ing.nl. Ook op die manier kan een MitM aanval worden uitgevoerd zonder dat je dit doorhebt. In zo'n geval klopt de URL (https://mijn.ing.nl/), er wordt een slotje getoond, de URL balk is groen etcetera. Alleen kijkt er wel stiekem iemand mee, dat wil zeggen, de aanvaller ziet nu het versleutelde verkeer voorbijkomen. Indien die aanvaller erin slaagt om (delen) van het met SSLv3 versleutelde verkeer te ontcijferen kan hij of zij wellicht jouw gebruikersnaam en wachtwoord achterhalen, en mogelijk gegevens (zoals door jou ingevulde rekeningnummers) wijzigen tijdens het verzenden van jouw webbrowser naar de webserver. Doordat Nederlandse banken allerlei aanvullende maatregelen gebruiken (tan codes, random readers en dergelijke) is het niet erg realistisch dat de aanvaller op deze manier geld naar een andere rekening kan sturen. Maar bijvoorbeeld in de VS, waar vaak uitsluitend met gebruikersnaam en wachtwoord gewerkt wordt, kan dat anders liggen.
Ten slotte: hoewel de kans klein is dat zo'n aanval dicht in de buurt van de server plaatsvindt, kun je dat niet uitsluiten. Voor een aanvaller is dat natuurlijk een stuk interessanter, hoe dichter bij de server van de bank, hoe meer potentiële slachtoffers. Denkbaar is dat cybercriminelen er grote bedragen voor over hebben om beheerders van ISP's qua netwerk "in de buurt van een bank" om te kopen.
Okay, wat kan ik doen?
Je kunt hopen dat alle servers gepatched worden; als servers geen SSLv3 meer ondersteunen kan deze (SSLv3) aanval niet meer worden uitgevoerd. Echter, vooral commerciële "bazen" bij bedrijven zijn bang dat klanten met oude browsers niet meer op hun servers terechtkunnen als oude protocollen worden uitgeschakeld. Daar komt bij dat systeembeheerders vaak overbelast zijn, en patches soms slecht of niet worden doorgevoerd. Grote banken hebben dit heus wel op orde, maar bijv. bij gemeenten en webwinkels zou het best nog wel even kunnen duren voordat SSLv3 is uitgeschakeld.
Je kunt dus het beste het heft in eigen hand nemen door zelf configuratiegegevens te wijzigen zodanig dat SSLv3 aan de "client zijde" (jouw PC/tablet etc. en/of browser) niet meer wordt ondersteund.
Testen van je webbrowser kan o.a. hier: https://www.poodletest.com/ (deze site is gebouwd door de goede en betrouwbare mensen van https://isc.sans.edu/).
Helaas kan er nog meer kwetsbaar zijn op jouw PC, maar welke software je gebruikt weet ik natuurlijk niet. Probeer na te gaan welke software netwerkverbindingen opzet (bijv. voor het automatisch ophalen van updates). Ook VPN software kan kwetsbaar zijn, vooral als de term "SSL" voorkomt in de naam. Hou heel goed producenten van software op jouw PC in de gaten, en installeer updates zodra deze beschikbaar zijn!
Internet Explorer
In de instellingen van Internet Explorer kun je ondersteuning voor SSLv3 eenvoudig uitzetten, zie bijvoorbeeld https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills-off-protocol/#internetexplorer (Engelstalige uitleg, je zult je fantasie moeten gebruiken voor de vertaling naar Nederlands).
Toch raad ik het af om het op die manier te doen, om de volgende redenen:
1) Rechtsonderaan die dialoogbox zitten knoppen "Restore advanced settings" en "Reset...". Ik weet uit eigen ervaring dat als iets niet werkt (bijv. een week later een slecht opgezette website, d.w.z. een probleem dat niets te maken heeft met SSLv3), je al snel geneigd bent op dat soort knoppen te drukken, om vervolgens te vergeten om de juiste instellingen weer terug te zetten.
2) Als er meerdere gebruikeraccounts zijn op de PC (kinderen bijvoorbeeld) moet je dit voor elk account herhalen en hopen dat ze eraf blijven.
3) Bovenstaande instellingen gelden mogelijk alleen voor Internet Explorer. Onderstaande wijziging geldt voor alle software die van Microsoft's SChannel software gebruik maakt voor SSL/TLS verbindingen (veel software doet dat, waaronder -voor zover ik weet- Windows Update/Microsoft update).
Beter (maar lastiger) is het wijzigen van het register:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
"Enabled"=dword:00000000
Kopieer bovenstaande tekst TUSSEN de strepen (dus exclusief die strepen!) naar het klembord. Start kladblok (notepad) en plak de tekst. Zorg dat er een lege regel is onder de regel die met "Enabled" begint.
BELANGRIJK #1: er zijn twee regels die beginnen en eindigen met een bakhaak, die mogen niet "omgeklapt" zijn! In elk van die regels hoort 1 spatie, namelijk tussen "SSL" en "3.0".
Sla op bijv. op je bureaublad als: DisableSSLv3.reg
BELANGRIJK #2: start nooit zomaar register informatie die je van internet gedownload hebt; controleer eerst of dit geldige informatie is. In dit geval kan dat in https://support.microsoft.com/kb/245030 (het is wel een beetje zoeken, maar ik vind dat ik moet waarschuwen - je moet niemand op internet zomaar vertrouwen).
Dubbel-klik op het opgeslagen bestand (waarvan je mogelijk de extensie ".reg" niet ziet).
Je krijgt een vraag of je het zeker weet: ja.
Je krijgt een bevestiging als het inlezen gelukt is.
BELANGRIJK #3: deze wijziging werkt pas nadat je alle vensters van Internet Explorer hebt gesloten! Doe dat dus eerst voordat je tests uitvoert.
Andere webbrowsers
Kijk eerst maar op https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills-off-protocol/. Update je browser zodra de eerstvolgende update beschikbaar is. Als er nog vragen zijn (hieronder) wil ik er wel verder op ingaan.
Succes!
Wijzigingen: gisteren heb ik, naast correctie van taalfouten, enkele kleine verduidelijkingen doorgevoerd en de kop van deze bijdrage uitgebreid (op verzoek van de redactie). Een grotere aanvulling heb ik gedaan (n.a.v. een reactie van cluc-cluc verderop) onder de paragraaf die begint met "Derde voorbeeld". Vandaag heb ik een spelfout en een slechte zinsconstructie gecorrigeerd.
Uit https://www.security.nl/posting/405340/Ernstig+beveiligingslek+in+SSL+3_0+ontdekt#posting405403:
Door Anoniem, 2014-10-15 15:29: En voor de leken....
Inhoeverre moeten mensen zich hier druk om maken?
Kan de bovenstaande reacties lezen, maar snappen??
Hoewel ik mijzelf tot de eerdergenoemde nerds reken, zal ik proberen om in begrijpelijke taal uit te leggen wat er aan de hand is, waar gewone eindgebruikers risico's lopen en wat ze daar tegen kunnen doen (ik schrijf dit niet voor beheerders, maar die mogen natuurlijk ook verder lezen en mij -waar nodig- corrigeren of aanvullen). Sla gerust secties over die je niet interesseren of die je niet begrijpt. Nb. ik gebruik de termen SSLv3 en SSL v3.0 door elkaar, ik bedoel er hetzelfde mee.Inhoeverre moeten mensen zich hier druk om maken?
Kan de bovenstaande reacties lezen, maar snappen??
Wat is een protocol
Als je http://www.nu.nl/ in de URL balk van jouw webbrowser intikt en de Enter toets indrukt, gebeurt er vanalles. De meeste mensen zal het echter een biet zijn wat er precies gebeurt, zolang ze de verwachte nieuwssite maar voor hun neus krijgen. Het is een ander verhaal als je een foutmelding krijgt, maar meestal gaat het gewoon goed.
We vinden het ook heel normaal dat we hetzelfde nieuws te zien krijgen als we een andere webbrowser, een ander besturingssysteem of een smartphone i.p.v. een notebook gebruiken. En daarbij hebben we geen flauw idee welk besturingssysteem de server van www.nu.nl gebruikt en welke webserversoftware daarop draait.
Om dit mogelijk te maken heb je heel goede afspraken en spelregels nodig; ICT-ers gebruiken daar de term "protocol" voor. Uiteindelijk gaan er reeksen enen en nullen heen en weer tussen onze webbrowser en de gekozen webserver; we gebruiken protocollen om vast te leggen hoe die reeksen van enen en nullen moeten worden geïnterpreteerd.
Voorbeeld: de eerste acht nullen en enen aan HTML code (waarmee webpagina's zijn opgebouwd) die de webserver naar de webbrowser stuurt zijn 00111100. De webbrowser is zo geprogrammeerd dat die code vertaald wordt in het kleiner-dan teken, dus "<", en in het HTML protocol is verder vastgelegd wat de webbrowser moet doen met de informatie die daarop volgt. Als je wel eens broncode van een HTML pagina bekeken hebt, weet je dat deze meestal met < begint.
Meerdere lagen van protocollen
Als je een papieren brief in een brievenbus van PostNL gooit, interesseert het je niet hoe deze van A naar B gaat (bestelauto, trein, vrachtauto, vliegtuig, fiets), welke sorteercentra deze passeert, in welke postzak deze belandt en welk adres er op die postzak staat. Je wilt dat de brief onbeschadigd en op tijd wordt bezorgd. Je trekt als het ware een streep onder de "verbinding" tussen jezelf en de ontvanger; wat er onder die streep gebeurt interesseert je niet.
Vergelijkbaar, bij de uitwisseling van gegevens tussen server en browser worden meerdere protocollen gebruikt op verschillende "lagen" in de computers aan beide kanten. Het genoemde HTML protocol beschrijft hoe een webpagina eruit moet zien. Daaronder zit een http protocol, vergelijkbaar met een envelop waarbij HTML de brief is. Daaronder zit weer een netwerkprotocol (met opnieuw een soort envelop of, zo je wilt, postzak) dat er heel anders uitziet afhankelijk van of je WiFi naar je tablet, een netwerkkabel naar je PC of G3/G4 naar je mobiel gebruikt. Doordat die protocollen zo onafhankelijk mogelijk van elkaar zijn, maakt het type netwerkverbinding niet uit voor wat je van www.nu.nl te zien krijgt.
Direct nadat je http://www.nu.nl/ hebt ingetikt en Enter hebt gedrukt, maakt jouw PC gebruik van het DNS protocol om van de naam "www.nu.nl" het bijbehorende IP-adres op te zoeken. Net als postbodes niet weten waar Erik van Straten woont en minstens een postcode + huisnummer nodig hebben, gebruiken computers op internet unieke IP-adressen om met elkaar te communiceren. Waar de eerder genoemde protocollen voortdurend worden gebruikt, wordt DNS maar af en toe gebruikt; meestal onthoudt de webbrowser zo'n IP-adres een tijdje.
Wat is SSL
Ook SSL is een protocol. Het is uitgevonden toen mensen vertrouwelijke informatie tussen webbrowsers en servers wilden uitwisselen (men was er allang achter dat netwerkkabels kunnen worden afgetapt, waarmee derden de gegevens die worden uitgewisseld kunnen inzien en zelfs wijzigen).
Het SSL protocol verzorgt minimaal twee zaken:
1) Dat je als gebruiker behoorlijk zeker weet dat je verbinding hebt met de bedoelde server (dus
niet een server van een cybercrimineel);
2) Dat de verbinding zodanig goed is versleuteld dat iemand die een kabel aftapt, alleen maar onleesbare data ziet.
En dat natuurlijk onafhankelijk van besturingssysteem en/of webbrowser. Echter, besturingssystemen en browsers kunnen onderling flink verschillen, en veel fabrikanten hebben hun eigen idee over software die zo'n protocol verwerkt.
Bekende implementaties van software die het SSL protocol "verstaat" zijn OpenSSL (open source software), "Secure Channel" (ook bekend als SChannel) van Microsoft) en NSS (Network Security Services) zoals gebruikt door Firefox. Het "Heartbleed" lek eerder dit jaar ontstond door een implementatiefout (fout van de programmeur) in OpenSSL.
Wat is https
Hoewel het SSL protocol voor heel veel andere toepassingen wordt gebruikt, is https de meest bekende en vermoedelijk meest gebruikte toepassing. Feitelijk is SSL een laag die tussen het http protocol en het gebruikte netwerkprotocol wordt geschoven. SSL wordt actief direct nadat een IP-verbinding tussen jouw computer en de server is opgebouwd. Zodra de SSL verbinding tot stand is gekomen wordt er http verkeer uitgewisseld, wat weer een "drager" is voor HTML.
Wat gebeurt er bij het opzetten van een SSL verbinding
Aanvankelijk is er nog niets versleuteld. Immers, versleutelen heeft alleen zin als de ontvanger een sleutel heeft om uit te pakken wat de verzender heeft versleuteld en daarna heeft verstuurd. Beide partijen moeten dus een sleutel overeenkomen; dit is een van de zaken die gebeurt tijdens de SSL handshake (en dat is heel uitgekiend, want die sleutel kan natuurlijk niet onversleuteld worden uitgewisseld! Daar bestaan prima oplossingen voor, maar het voert te ver om dat hier nu uit te leggen).
Tijdens die handshake moet er meer worden overeengekomen. Zo zijn er, in de loop van de tijd, meerdere versies van het SSL protocol ontwikkeld. Daarbij zijn steeds verbeteringen doorgevoerd, zoals ondersteuning van nieuwere versleutelingsprotocollen (weer dat woord ;)
Wat is TLS
Lastig is dat een standaardisatiecommissie op een gegeven moment een nieuwe naam voor SSL heeft geïntroduceerd, namelijk TLS, en opnieuw bij versie 1.0 is begonnen. Op dit moment zijn de volgende versies van SSL en TLS in omloop:
SSL v2.0: Was al jaren kwetsbaar, niemand gebruikt dit.
SSL v3.0: Wordt nog steeds ondersteund door zeer veel servers, maar blijk "lek" te zijn.
TLS v1.0: Minimale verschillen met SSLv3. Voor zover nu bekend is TLS 1.0 niet lek.
TLS v1.1: Tussenversie.
TLS v1.2: Actuele versie, ondersteund door alle moderne webbrowsers, maar nog lang niet door alle servers.
Wat is het POODLE lek in SSLv3
Als je dat precies wilt weten kun je dit lezen: https://www.imperialviolet.org/2014/10/14/poodle.html. Los van de technische details: een aanvaller die kan "meekijken" op de verbinding (over hoe dat kan verderop meer) lijkt volkomen onleesbare versleutelde informatie te zien. Maar naar nu blijkt kan een aanvaller toch delen van de uitgewisselde informatie ontcijferen!
Iets dergelijks was allang bekend van SSL v2.0, en eerder waren er ook al lekken in SSLv3 die gerepareerd konden worden. Het huidige lek is zodanig dat repareren niet gaat, en bovendien had SSLv3 jaren geleden al buiten gebruik genomen moeten worden. Het gaat hierbij (in tegenstelling tot het eerder genoemde Heartbleed lek) om een denkfout in het protocol. Omdat alle programmeurs het protocol zo netjes mogelijk implementeren, zijn alle implementaties lek! De kwetsbaarheid in SSLv3 is dus onafhankelijk van besturingssystemen, webbrowsers en serversoftware.
Conclusie: we moeten voorkomen dat we vertrouwelijke gegevens uitwisselen via SSLv3.
Wat is het probleem, mijn browser gebruikt TLS v1.0 of TLS v1.2 naar alle https sites!
Klopt. Hoewel de meeste servers en browsers nog SSLv3 ondersteunen, zal tijdens de handshake voor het veiligste protocol worden gekozen dat beide kanten ondersteunen. Bij oudere servers is dat vaak TLS v1.0, bij moderne TLS v1.2.
En toch is er een probleem! Als een aanvaller zich in de verbinding tussen de webbrowser en de server weet te forceren, spreken we van een MitM aanval (Man-in-the-Middle). Die aanvaller kan gegevens ongewijzigd doorgeven, ze wijzigen of ze verwijderen. Daarmee kan hij de browser, tijdens de handshake, wijsmaken dat de server uitsluitend het SSLv3 protocol ondersteunt. Zo kan hij afdwingen dat er van SSLv3 gebruik gemaakt wordt, ook als beide partijen iets beters ondersteunen. Dit heet een "protocol downgrade attack".
Vervolgens laat hij de SSLv3 verbinding gewoon tot stand komen. Noch de client, noch de server heeft door dat er iets mis is, maar de aanvaller kan vervolgens proberen de uitgewisselde informatie te ontcijferen. De aanval zal vermoedelijk iets ingewikkelder zijn, voor zover ik het begrijp moet de aanvaller net doen alsof sommige gegevens corrupt raken waardoor server en/of client ze opnieuw zullen verzenden. Door beide partijen te dwingen bepaalde stukjes informatie herhaald uit te wisselen kan de aanvaller de versleutelde informatie stapje bij beetje ontcijferen. Theoretisch zouden clients en/of servers dit kunnen opmerken, maar in de praktijk wordt zoiets niet gelogd noch gemeld. Je hebt kans dat de verbinding wat trager lijkt dan normaal, maar dat kan ook door allerlei andere omstandigheden worden veroorzaakt ("hikken" zijn we ondertussen wel gewend, zeker op drukke WiFi netwerken).
Hoe komt die aanvaller op "mijn" netwerk?
Dit is, helaas, eenvoudiger dan veel mensen denken. In elk geval is het niet moelijk om een "rogue access point" (kwaadaardige WiFi hotspot) op te zetten. Stel een aanvaller weet dat jij vaak met de trein reist en dan van NS hotspots gebruik maakt. Dan kan hij, vanuit zijn auto voor jouw deur, een WiFi access point opzetten dat zich voordoet als een NS hotspot. Als hij daar een krachtige zender voor gebruikt is de kans groot dat als jij thuiskomt, jouw mobiele device (of de computer die je aanzet) met dat kwaadaardige hotspot verbindt in plaats van jouw eigen thuisnetwerk! En dat zonder dat je daar iets van merkt...
Tweede voorbeeld: als je via de webbrowser op jouw PC met een server op internet wilt communiceren, gaat dat natuurlijk via jouw modem/router en jouw ISP. Stel op jouw bedrade netwerk is ook een met malware besmette computer aangesloten. Dan is het in de praktijk zo dat de meeste netwerken niet kunnen voorkomen (en ook niet detecteren) dat die besmette computer zich "misdraagt" op dat netwerk. Die besmette computer kan zich bijvoorbeeld voordoen als jouw router/modem, en de kans is groot dat jouw PC daar in trapt. Het gevolg is dat de gegevens tussen jouw webbrowser en de server via die besmette computer lopen, waarmee een MitM aanval mogelijk is.
Derde voorbeeld: er zijn de laatste tijd erg veel lekken in modems/routers (ADSL-/kabel-) bij mensen thuis gevonden. In zo'n geval kunnen aanvallers bijvoorbeeld de in het modem ingestelde DNS server(s) te wijzigen. Als jij mijn.ing.nl als URL intikt, verloopt de DNS aanvraag voor het bijbehorende IP-adres dan niet meer via de vertrouwde DNS server van jouw ISP, maar gaat naar een DNS server in beheer van een cybercrimineel. En die kan jouw PC elk gewenst IP-adres teruggeven! Dat kan van een criminele server zijn die, als een doorgeefluik, op zijn beurt verbinding maakt met de echte mijn.ing.nl. Ook op die manier kan een MitM aanval worden uitgevoerd zonder dat je dit doorhebt. In zo'n geval klopt de URL (https://mijn.ing.nl/), er wordt een slotje getoond, de URL balk is groen etcetera. Alleen kijkt er wel stiekem iemand mee, dat wil zeggen, de aanvaller ziet nu het versleutelde verkeer voorbijkomen. Indien die aanvaller erin slaagt om (delen) van het met SSLv3 versleutelde verkeer te ontcijferen kan hij of zij wellicht jouw gebruikersnaam en wachtwoord achterhalen, en mogelijk gegevens (zoals door jou ingevulde rekeningnummers) wijzigen tijdens het verzenden van jouw webbrowser naar de webserver. Doordat Nederlandse banken allerlei aanvullende maatregelen gebruiken (tan codes, random readers en dergelijke) is het niet erg realistisch dat de aanvaller op deze manier geld naar een andere rekening kan sturen. Maar bijvoorbeeld in de VS, waar vaak uitsluitend met gebruikersnaam en wachtwoord gewerkt wordt, kan dat anders liggen.
Ten slotte: hoewel de kans klein is dat zo'n aanval dicht in de buurt van de server plaatsvindt, kun je dat niet uitsluiten. Voor een aanvaller is dat natuurlijk een stuk interessanter, hoe dichter bij de server van de bank, hoe meer potentiële slachtoffers. Denkbaar is dat cybercriminelen er grote bedragen voor over hebben om beheerders van ISP's qua netwerk "in de buurt van een bank" om te kopen.
Okay, wat kan ik doen?
Je kunt hopen dat alle servers gepatched worden; als servers geen SSLv3 meer ondersteunen kan deze (SSLv3) aanval niet meer worden uitgevoerd. Echter, vooral commerciële "bazen" bij bedrijven zijn bang dat klanten met oude browsers niet meer op hun servers terechtkunnen als oude protocollen worden uitgeschakeld. Daar komt bij dat systeembeheerders vaak overbelast zijn, en patches soms slecht of niet worden doorgevoerd. Grote banken hebben dit heus wel op orde, maar bijv. bij gemeenten en webwinkels zou het best nog wel even kunnen duren voordat SSLv3 is uitgeschakeld.
Je kunt dus het beste het heft in eigen hand nemen door zelf configuratiegegevens te wijzigen zodanig dat SSLv3 aan de "client zijde" (jouw PC/tablet etc. en/of browser) niet meer wordt ondersteund.
Testen van je webbrowser kan o.a. hier: https://www.poodletest.com/ (deze site is gebouwd door de goede en betrouwbare mensen van https://isc.sans.edu/).
Helaas kan er nog meer kwetsbaar zijn op jouw PC, maar welke software je gebruikt weet ik natuurlijk niet. Probeer na te gaan welke software netwerkverbindingen opzet (bijv. voor het automatisch ophalen van updates). Ook VPN software kan kwetsbaar zijn, vooral als de term "SSL" voorkomt in de naam. Hou heel goed producenten van software op jouw PC in de gaten, en installeer updates zodra deze beschikbaar zijn!
Internet Explorer
In de instellingen van Internet Explorer kun je ondersteuning voor SSLv3 eenvoudig uitzetten, zie bijvoorbeeld https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills-off-protocol/#internetexplorer (Engelstalige uitleg, je zult je fantasie moeten gebruiken voor de vertaling naar Nederlands).
Toch raad ik het af om het op die manier te doen, om de volgende redenen:
1) Rechtsonderaan die dialoogbox zitten knoppen "Restore advanced settings" en "Reset...". Ik weet uit eigen ervaring dat als iets niet werkt (bijv. een week later een slecht opgezette website, d.w.z. een probleem dat niets te maken heeft met SSLv3), je al snel geneigd bent op dat soort knoppen te drukken, om vervolgens te vergeten om de juiste instellingen weer terug te zetten.
2) Als er meerdere gebruikeraccounts zijn op de PC (kinderen bijvoorbeeld) moet je dit voor elk account herhalen en hopen dat ze eraf blijven.
3) Bovenstaande instellingen gelden mogelijk alleen voor Internet Explorer. Onderstaande wijziging geldt voor alle software die van Microsoft's SChannel software gebruik maakt voor SSL/TLS verbindingen (veel software doet dat, waaronder -voor zover ik weet- Windows Update/Microsoft update).
Beter (maar lastiger) is het wijzigen van het register:
----------------------------------------------------------------------
Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
"Enabled"=dword:00000000
----------------------------------------------------------------------
Zorg dat je ingelogd bent met een beheeraccount.Kopieer bovenstaande tekst TUSSEN de strepen (dus exclusief die strepen!) naar het klembord. Start kladblok (notepad) en plak de tekst. Zorg dat er een lege regel is onder de regel die met "Enabled" begint.
BELANGRIJK #1: er zijn twee regels die beginnen en eindigen met een bakhaak, die mogen niet "omgeklapt" zijn! In elk van die regels hoort 1 spatie, namelijk tussen "SSL" en "3.0".
Sla op bijv. op je bureaublad als: DisableSSLv3.reg
BELANGRIJK #2: start nooit zomaar register informatie die je van internet gedownload hebt; controleer eerst of dit geldige informatie is. In dit geval kan dat in https://support.microsoft.com/kb/245030 (het is wel een beetje zoeken, maar ik vind dat ik moet waarschuwen - je moet niemand op internet zomaar vertrouwen).
Dubbel-klik op het opgeslagen bestand (waarvan je mogelijk de extensie ".reg" niet ziet).
Je krijgt een vraag of je het zeker weet: ja.
Je krijgt een bevestiging als het inlezen gelukt is.
BELANGRIJK #3: deze wijziging werkt pas nadat je alle vensters van Internet Explorer hebt gesloten! Doe dat dus eerst voordat je tests uitvoert.
Andere webbrowsers
Kijk eerst maar op https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills-off-protocol/. Update je browser zodra de eerstvolgende update beschikbaar is. Als er nog vragen zijn (hieronder) wil ik er wel verder op ingaan.
Succes!
Wijzigingen: gisteren heb ik, naast correctie van taalfouten, enkele kleine verduidelijkingen doorgevoerd en de kop van deze bijdrage uitgebreid (op verzoek van de redactie). Een grotere aanvulling heb ik gedaan (n.a.v. een reactie van cluc-cluc verderop) onder de paragraaf die begint met "Derde voorbeeld". Vandaag heb ik een spelfout en een slechte zinsconstructie gecorrigeerd.
Reacties (39)
Ik ben geen digibeet, ook al voel ik me wel vaak zo als ik de comments op deze site lees.
Stukken als deze maken het iets veiliger in de boze wereld.
Bedankt !
Stukken als deze maken het iets veiliger in de boze wereld.
Bedankt !
Inderdaad ontzettend goed stuk en erg verhelderend!
De link naar:
https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills-off-protocol/
levert een voortreffelijk uitvoerbare korte termijn oplossing op.
Erg veel dank Harry
De link naar:
https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills-off-protocol/
levert een voortreffelijk uitvoerbare korte termijn oplossing op.
Erg veel dank Harry
... duit ... zakje ...
Bedankt, zeer duidelijk, ook voor managers .... ;)
Bedankt, zeer duidelijk, ook voor managers .... ;)
Erik, in de eerste plaats weer mijn respect voor dit college voor de "digibeet", en de moeite die je er in heb gestoken. :-)
Eén opmerking:
Je wekt de indruk dat deze indringer dan in principe zondermeer alle communicatie zou kunnen meelezen.
Maar is het wel zo dat je hier als gebruiker dan helemaal niets van merkt?
Ik waag het te betwijfelen of het wel helemaal klopt wat je hier zegt.
Een (deels) groene balk betekent namelijk dat je te maken hebt met een geldig EV-certificaat.
Dit zou vrijwel niet na te maken zijn. Dus dat certificaat moet wel van de echte ing komen.
(men zou dat nog even achter het slotje kunnen controleren, vingerafdruk en zo)
Een groene balk duidt dus op een versleutelde verbinding tussen jouw computer en de echte ing.nl website.
En een versleutelde verbinding is niet af te luisteren.
(nou ja, het is wel af te luisteren, maar je wordt er geen wijs uit, want het is gecodeerd)
Nu is het "geheim" van client en bankserver die het mogelijk maakt om de communicatie weer te decoderen, niet te verkrijgen door alleen even de lijn om te leiden en af te tappen, omdat dit geheim zich deels in de client en deels in de server zelf bevindt en niet open en bloot over de lijn is gegaan.
Dus ook al heeft de MitM de verbinding gekaapt, dan kan hij er nog niets mee. Want hij kan het niet decoderen.
IMHO is het dus wel degelijk detecteerbaar wanneer er een actief opererende MitM aanwezig is die echt meeluistert.
Hetzij doordat het beveiligingscertificaat niet klopt (geen groene balk en/of verkeerde fingerprint etc.),
hetzij doordat de MitM kans heeft gezien om de beveiligingslaag (SSL) eraf te strippen.
Maar terugval van https naar http gaat bij een fatsoenlijke browser gepaard met een waarschuwing,
of anders staat er opeens http in je scherm in plaats van https.
En dat is bij gebruik van een fatsoenlijke browser detecteerbaar.
Nu echter SSLv3 via de ontdekte kwetsbaarheid gecompromitteerd kan worden, wordt het een ander verhaal,
en zijn er andere wegen geopend om de communicatie tussen client en bankserver te ontrafelen.
Je loopt nu inderdaad zo'n stilsluipend gevaar als jij beschrijft, maar alleen als je sslv3 zou gebruiken.
Maar je wekte door je formulering/context bij mij (net als in het OpenDNS topic) nogal de indruk dat je puur en alleen door DNS-vervalsing en de daarmee gepaarde omleiding en/of manipulatie van het netwerkverkeer tussen client en bankserver onopgemerkt kan inbreken op de verbinding, en onvoorwaardelijk alle communicatie ongecodeerd kunt afluisteren.
En dat lijkt mij van niet. (tenminste als je direct vanaf het begin de verbinding hebt opgezet in https, en niet in http)
Of heb ik ergens iets gemist?
Mvg, cluc-cluc.
Eén opmerking:
Derde voorbeeld: er zijn de laatste tijd erg veel lekken in modems/routers (ADSL-/kabel-) bij mensen thuis gevonden. In zo'n geval kunnen aanvallers bijvoorbeeld de in het modem ingestelde DNS server(s) te wijzigen. Als jij mijn.ing.nl als URL intikt, verloopt de DNS aanvraag voor het bijbehorende IP-adres dan niet meer via de vertrouwde DNS server van jouw ISP, maar gaat naar een DNS server in beheer van een cybercrimineel. En die kan jouw PC elk gewenst IP-adres teruggeven! Dat kan van een criminele server zijn die, als een doorgeefluik, op zijn beurt verbinding maakt met de echte mijn.ing.nl. Ook op die manier kan een MitM aanval worden uitgevoerd zonder dat je dit doorhebt. In zo'n geval klopt de URL (https://mijn.ing.nl/), er wordt een slotje getoond, de URL balk is groen etcetera. Alleen kijkt er wel stiekem iemand mee!
De laatste regels wekken de indruk dat je nergens aan kunt zien dat er een MitM ("Man-in the-midle") aanval heeft plaatsgevonden. In de verbinding met ing.nl heeft zich dan iemand binnengedrongen die zich tussen jouw computer en de server van de bank bevindt, zodat alle communicatie via die indringer verloopt. Je wekt de indruk dat deze indringer dan in principe zondermeer alle communicatie zou kunnen meelezen.
Maar is het wel zo dat je hier als gebruiker dan helemaal niets van merkt?
Ik waag het te betwijfelen of het wel helemaal klopt wat je hier zegt.
Een (deels) groene balk betekent namelijk dat je te maken hebt met een geldig EV-certificaat.
Dit zou vrijwel niet na te maken zijn. Dus dat certificaat moet wel van de echte ing komen.
(men zou dat nog even achter het slotje kunnen controleren, vingerafdruk en zo)
Een groene balk duidt dus op een versleutelde verbinding tussen jouw computer en de echte ing.nl website.
En een versleutelde verbinding is niet af te luisteren.
(nou ja, het is wel af te luisteren, maar je wordt er geen wijs uit, want het is gecodeerd)
Nu is het "geheim" van client en bankserver die het mogelijk maakt om de communicatie weer te decoderen, niet te verkrijgen door alleen even de lijn om te leiden en af te tappen, omdat dit geheim zich deels in de client en deels in de server zelf bevindt en niet open en bloot over de lijn is gegaan.
Dus ook al heeft de MitM de verbinding gekaapt, dan kan hij er nog niets mee. Want hij kan het niet decoderen.
IMHO is het dus wel degelijk detecteerbaar wanneer er een actief opererende MitM aanwezig is die echt meeluistert.
Hetzij doordat het beveiligingscertificaat niet klopt (geen groene balk en/of verkeerde fingerprint etc.),
hetzij doordat de MitM kans heeft gezien om de beveiligingslaag (SSL) eraf te strippen.
Maar terugval van https naar http gaat bij een fatsoenlijke browser gepaard met een waarschuwing,
of anders staat er opeens http in je scherm in plaats van https.
En dat is bij gebruik van een fatsoenlijke browser detecteerbaar.
Nu echter SSLv3 via de ontdekte kwetsbaarheid gecompromitteerd kan worden, wordt het een ander verhaal,
en zijn er andere wegen geopend om de communicatie tussen client en bankserver te ontrafelen.
Je loopt nu inderdaad zo'n stilsluipend gevaar als jij beschrijft, maar alleen als je sslv3 zou gebruiken.
Maar je wekte door je formulering/context bij mij (net als in het OpenDNS topic) nogal de indruk dat je puur en alleen door DNS-vervalsing en de daarmee gepaarde omleiding en/of manipulatie van het netwerkverkeer tussen client en bankserver onopgemerkt kan inbreken op de verbinding, en onvoorwaardelijk alle communicatie ongecodeerd kunt afluisteren.
En dat lijkt mij van niet. (tenminste als je direct vanaf het begin de verbinding hebt opgezet in https, en niet in http)
Of heb ik ergens iets gemist?
Mvg, cluc-cluc.
Ha cluc-cluc, ik heb het "derde voorbeeld" dat jij aanhaalt (hopelijk) wat verduidelijkt.
Met betrekking tot mijn "Derde voorbeeld" schreef je:
Maar als er een MitM tussen zit, die zich richting de webserver voordoet als webbrowser, en richting de webbrowser als webserver, kan hij tegen beide partijen liegen dat de andere kant uitsluitend SSLv3 ondersteunt!
Nb. specialisten zijn het er niet over eens of alle webbrowsers zich dan even makkelijk om de tuin kunnen laten leiden, maar aangezien dit nogal "onontgonnen" (niet veel onderzocht) gebied lijkt, neem ik het zekere voor het onzekere en raad ik iedereen aan om ondersteuning voor SSLv3 in alle webbrowsers uit te zetten. Dat is niet moeilijk en je bent niet kwetsbaar meer!
V.w.b. de OpenDNS discussie, dat ligt deels anders. In eerste instantie heb ik dat hier beantwoord, maar bij nader inzien heb ik mijn antwoord verplaatst naar https://www.security.nl/posting/404547/OpenDNS+geeft+certificaatfout+op+Internet_.
Door cluc-cluc: Erik, in de eerste plaats weer mijn respect voor dit college voor de "digibeet", en de moeite die je er in heb gestoken. :-)
Dank aan allen voor de positieve reacties!Met betrekking tot mijn "Derde voorbeeld" schreef je:
Door cluc-cluc: Ik waag het te betwijfelen of het wel helemaal klopt wat je hier zegt.
Een (deels) groene balk betekent namelijk dat je te maken hebt met een geldig EV-certificaat.
Dit zou vrijwel niet na te maken zijn. Dus dat certificaat moet wel van de echte ing komen.
(men zou dat nog even achter het slotje kunnen controleren, vingerafdruk en zo)
Een groene balk duidt dus op een versleutelde verbinding tussen jouw computer en de echte ing.nl website.
Exact.Een (deels) groene balk betekent namelijk dat je te maken hebt met een geldig EV-certificaat.
Dit zou vrijwel niet na te maken zijn. Dus dat certificaat moet wel van de echte ing komen.
(men zou dat nog even achter het slotje kunnen controleren, vingerafdruk en zo)
Een groene balk duidt dus op een versleutelde verbinding tussen jouw computer en de echte ing.nl website.
Door cluc-cluc: En een versleutelde verbinding is niet af te luisteren.
(nou ja, het is wel af te luisteren, maar je wordt er geen wijs uit, want het is gecodeerd)
Nu is het "geheim" van client en bankserver die het mogelijk maakt om de communicatie weer te decoderen, niet te verkrijgen door alleen even de lijn om te leiden en af te tappen, omdat dit geheim zich deels in de client en deels in de server zelf bevindt en niet open en bloot over de lijn is gegaan.
Dus ook al heeft de MitM de verbinding gekaapt, dan kan hij er nog niets mee. Want hij kan het niet decoderen.
En dat is nu precies waarom dit Poodle lek gevaarlijk is: een aanvaller kan, zonder sleutel, toch versleutelde gegevens ontcijferen (d.w.z. "ontsleutelen", maar dat is geloof ik geen Nederlands woord). Misschien kan hij niet alle informatie ontcijferen, maar soms is dat niet nodig om bijvoorbeeld een wachtwoord in handen te krijgen.(nou ja, het is wel af te luisteren, maar je wordt er geen wijs uit, want het is gecodeerd)
Nu is het "geheim" van client en bankserver die het mogelijk maakt om de communicatie weer te decoderen, niet te verkrijgen door alleen even de lijn om te leiden en af te tappen, omdat dit geheim zich deels in de client en deels in de server zelf bevindt en niet open en bloot over de lijn is gegaan.
Dus ook al heeft de MitM de verbinding gekaapt, dan kan hij er nog niets mee. Want hij kan het niet decoderen.
Door cluc-cluc: IMHO is het dus wel degelijk detecteerbaar wanneer er een actief opererende MitM aanwezig is die echt meeluistert.
Hetzij doordat het beveiligingscertificaat niet klopt (geen groene balk en/of verkeerde fingerprint etc.),
hetzij doordat de MitM kans heeft gezien om de beveiligingslaag (SSL) eraf te strippen.
Maar terugval van https naar http gaat bij een fatsoenlijke browser gepaard met een waarschuwing,
of anders staat er opeens http in je scherm in plaats van https.
En dat is bij gebruik van een fatsoenlijke browser detecteerbaar.
Helaas, het griezelige van deze aanval is dat een aanvaller in de achtergrond versleutelde gegevens kan ontcijferen terwijl alles klopt in jouw webbrowser en zonder dat jij dit kunt detecteren. Denkbaar is dat de bank het wel kan detecteren, namelijk als sprake is van DNS manipulatie en de computer van de aanvaller een Russisch IP-adres heeft. Maar de aanvaller kan daar net zo goed een gehackte computer ergens in Nederland voor inzetten.Hetzij doordat het beveiligingscertificaat niet klopt (geen groene balk en/of verkeerde fingerprint etc.),
hetzij doordat de MitM kans heeft gezien om de beveiligingslaag (SSL) eraf te strippen.
Maar terugval van https naar http gaat bij een fatsoenlijke browser gepaard met een waarschuwing,
of anders staat er opeens http in je scherm in plaats van https.
En dat is bij gebruik van een fatsoenlijke browser detecteerbaar.
Door cluc-cluc: Je loopt nu inderdaad zo'n stilsluipend gevaar als jij beschrijft, maar alleen als je sslv3 zou gebruiken.
Het is niet zo dat "je" SSLv3 gebruikt. Jouw webbrowser en webserver onderhandelen over het protocol dat ze gaan gebruiken (SSLv3, TLSv1, TLSv1.1 of TLSv1.2). Als zij niet worden gestoord kiezen ze het veiligste protocol dat beiden ondersteunen.Maar als er een MitM tussen zit, die zich richting de webserver voordoet als webbrowser, en richting de webbrowser als webserver, kan hij tegen beide partijen liegen dat de andere kant uitsluitend SSLv3 ondersteunt!
Nb. specialisten zijn het er niet over eens of alle webbrowsers zich dan even makkelijk om de tuin kunnen laten leiden, maar aangezien dit nogal "onontgonnen" (niet veel onderzocht) gebied lijkt, neem ik het zekere voor het onzekere en raad ik iedereen aan om ondersteuning voor SSLv3 in alle webbrowsers uit te zetten. Dat is niet moeilijk en je bent niet kwetsbaar meer!
Door cluc-cluc: Maar je wekte door je formulering/context bij mij (net als in het OpenDNS topic) nogal de indruk dat je puur en alleen door DNS-vervalsing en de daarmee gepaarde omleiding en/of manipulatie van het netwerkverkeer tussen client en bankserver onopgemerkt kan inbreken op de verbinding, en onvoorwaardelijk alle communicatie ongecodeerd kunt afluisteren.
Met de Poodle aanval sluit ik niet uit dat een aanvaller inderdaad een heel eind komt. Onvoorwaardelijk is het niet: hij moet een MitM aanval kunnen uitvoeren (bijv. door DNS manipulatie) en zowel client als server moeten SSLv3 ondersteunen. Waarschijnlijk kan hij vervolgens niet alle informatie ontcijferen, maar wellicht wel jouw wachtwoord afkijken.V.w.b. de OpenDNS discussie, dat ligt deels anders. In eerste instantie heb ik dat hier beantwoord, maar bij nader inzien heb ik mijn antwoord verplaatst naar https://www.security.nl/posting/404547/OpenDNS+geeft+certificaatfout+op+Internet_.
@Erik van Straten,
Dank voor al je moeite, een verademing om te lezen!
Dank voor al je moeite, een verademing om te lezen!
17-10-2014, 09:33 door
FSF-Moses
Netjes, overzichtelijk en vooral duidelijk en zeker niet alleen voor leken.
Klasse!
Klasse!
17-10-2014, 09:53 door
B3am
Duidelijk verhaal! Bedankt Erik van Straten.
Erik, bedankt voor de uitleg. Ik zit ook in de IT en probeer steeds duidelijk te zijn richting de gebruikers, maar dat is toch steeds weer heel lastig. En in periodes van "paniek" is er vaak niet eens tijd om er eens goed voor te gaan zitten. Vandaar dat ik ook regelmatig rapporten schrijf, waarbij ik wat meer tijd heb of neem om zaken duidelijk te verwoorden.
Peter
Peter
Mij zijn u weer zeer van de dankerige voor uw reacties, beste Erik, zowel voor het poodle-topic als het opendns-topic. ;-)
Ik hoorde wel een paar kleine "interferenties" alsof je de bedoeling van mijn laatste bericht niet helemaal begreep,
maar dat zal liggen aan een soort van "TLSv2.0" waar mijn communicatie soms mee begint. Moek us mee ophoue. ;-))
Onze eindconlusies zitten (hoe kan het ook anders) op dezelfde golflengte, en dat is het belangrijkste.
Dit:
Mensen mogen weten dat ze bij gebruik van TLS niet hoeven te vrezen voor dit specifiek door jou geschetste scenario.
In tegenstelling tot een SSLv3-verbinding kan een TLS-verbinding die niet meer vatbaar is voor een terugval naar het SSLv3-protocol (dankzij uitschakelen van SSLv3 zoals Erik in het topic had aangegeven) niet zo gemakkelijk stilletjes en geheel zonder dat je iets merkt worden uitgelezen in geval er sprake is van een DNS-manipulatie zoals geschetst in Erik's voorbeeld 3.
Nu is er voor de indringer nog wel een andere mogelijkheid om in zo'n situatie de communicatie over een TLS-verbinding mee te lezen, maar zolang TLS (nog?) niet is te kraken, zal de client daarvoor een certificaat van de indringer moeten accepteren, of http moeten gebruiken.
En als je goed oplet dan merk je zoiets natuurlijk meteen. (onjuist certificaat / URL-balk is niet groen bij EV-certificaten).
Ook als het de indringer mocht lukken om de encryptie uit te schakelen aan de client-zijde, dan merk je dit in je browser. (je ziet dan "http" in plaats van "https", en de browser geeft mogelijk een waarschuwing als er zoiets gebeurt)
Trouwens wanneer HSTS in je browser is geactiveerd voor de bezochte website (dit gebeurt als je browser en de bezochte server allebei HSTS ondersteunen, en je dezelfde website niet al te lang geleden ook al eens hebt bezocht) dan zal zoiets de indringer zeker niet lukken. HSTS forceert namelijk dat je browser een beveiligde verbinding opzet met de betreffende website. En als bovendien aan de serverkant de webserver altijd https forceert, dan kan een MitM ook aan de serverkant de encryptie niet uitschakelen. Het is dan zo goed als zeker dat de verbinding nergens op de lijn kan worden afgeluisterd.
Toch, zo realiseerde ik mij, wil dit helaas niet zeggen dat ons in zo'n scenario niets meer kan gebeuren met TLS.
Om het verhaal compleet te maken: zo'n indringer kan je computer ook nog bestoken met exploits en drive-by-downloads.
Want na een uitgaande verbinding naar het valse IP-adres dat door de valse DNS-server aan je computer werd verstrekt (ten gevolge van gemanipuleerde DNS-instellingen in je router) staat je router open voor inkomend verkeer vanaf ditzelfde valse IP-adres... En als je computer kwetsbaar is (meestal door verzuim van het installeren van security updates, of wegens het gebruik van verouderde software die niet meer wordt ondersteund) ben je dan toch nog de klos...
Ook via deze weg kan de MitM/indringer dus proberen om uiteindelijk communicatie mee te lezen/manipuleren, en zelfs nog meer. En ook in dit geval hoef je zoiets niet onmiddellijk te merken.
Best wel belangrijk dus, die DNS!
Een bedrijf als bijvoorbeeld OpenDNS speelt daar op in, door bij de DNS-aanvragen die jouw computer doet aan de OpenDNS-servers, voortdurend actief in de gaten te houden dat je niet wordt doorgestuurd naar websites die bekend staan als exploiters/malwareverspreiders.
Ook bieden ze een optie waarmee alle DNS-communicatie versleuteld wordt verzonden tussen client en DNS-server.
(standaard gebeurt dit namelijk onversleuteld, waardoor het in principe onderweg tamelijk eenvoudig is te manipuleren)
En desgewenst filtert OpenDNS op deze wijze bijvoorbeeld ook adware, porno en "big data" verzamelaars uit.
(echter als de DNS-instellingen van je internetrouter op één of andere manier toch zijn vervalst, en niet meer naar de OpenDNS-servers verwijzen, dan kan OpenDNS er verder ook niets meer aan doen...)
Kortom: wat algemene internetveiligheid betreft, is het ook zeer zeker de moeite waard om de nodige aandacht te schenken aan de keuze van je router, routerinstellingen, firmwareupdates, plus een sterk admin-wachtwoord op je router.
En zodoende zoveel mogelijk te voorkomen dat het scenario van Erik's derde voorbeeld überhaupt zou kunnen optreden.
Tot slot wil ik voor de volledigheid nog even noemen dat een "Man-in-the-Middle" uiteraard onopgemerkt en gemakkelijk
alle onversleutelde http-communicatie kan meelezen in geval je http zou gebruiken. Iets om rekening mee te houden.
Maar gelukkig verloopt alle communicatie met banken over https. Het mag nooit http worden gedurende je banksessie,
en het is aan te bevelen om altijd te beginnen met https in je browser. Zelfs ook als de webserver jouw http toch wel even automatisch omzet naar https. Want als je met http begint, is het niet uitgesloten dat zo'n MitM-aanvaller het allereerste stukje communicatie zou kunnen meelezen/manipuleren. En zelfs dat is alweer een risico...
Nu hoeft men niet meteen vreselijk van slag te raken van elk mogelijk risico, want het hele leven is een risico.
Maar als het volstrekt onnodig en zo eenvoudig te vermijden is, dan zou het wel zonde zijn als men het niet doet... ;-)
Mvg en nano-nano, cluc-cluc
Ik hoorde wel een paar kleine "interferenties" alsof je de bedoeling van mijn laatste bericht niet helemaal begreep,
maar dat zal liggen aan een soort van "TLSv2.0" waar mijn communicatie soms mee begint. Moek us mee ophoue. ;-))
Onze eindconlusies zitten (hoe kan het ook anders) op dezelfde golflengte, en dat is het belangrijkste.
Dit:
Onvoorwaardelijk is het niet: hij moet een MitM aanval kunnen uitvoeren (bijv. door DNS manipulatie)
en zowel client als server moeten SSLv3 ondersteunen.
is namelijk wat ik aan het licht wilde brengen met mijn bericht. En stemt overeen met: en zowel client als server moeten SSLv3 ondersteunen.
Je loopt nu inderdaad zo'n stilsluipend gevaar als jij beschrijft, maar alleen als je sslv3 zou gebruiken.
(met "gebruiken" bedoelde ik dat er daadwerkelijk sslv3 over de lijn gaat, ongeacht hoe dit tot stand is gebracht)Mensen mogen weten dat ze bij gebruik van TLS niet hoeven te vrezen voor dit specifiek door jou geschetste scenario.
In tegenstelling tot een SSLv3-verbinding kan een TLS-verbinding die niet meer vatbaar is voor een terugval naar het SSLv3-protocol (dankzij uitschakelen van SSLv3 zoals Erik in het topic had aangegeven) niet zo gemakkelijk stilletjes en geheel zonder dat je iets merkt worden uitgelezen in geval er sprake is van een DNS-manipulatie zoals geschetst in Erik's voorbeeld 3.
Nu is er voor de indringer nog wel een andere mogelijkheid om in zo'n situatie de communicatie over een TLS-verbinding mee te lezen, maar zolang TLS (nog?) niet is te kraken, zal de client daarvoor een certificaat van de indringer moeten accepteren, of http moeten gebruiken.
En als je goed oplet dan merk je zoiets natuurlijk meteen. (onjuist certificaat / URL-balk is niet groen bij EV-certificaten).
Ook als het de indringer mocht lukken om de encryptie uit te schakelen aan de client-zijde, dan merk je dit in je browser. (je ziet dan "http" in plaats van "https", en de browser geeft mogelijk een waarschuwing als er zoiets gebeurt)
Trouwens wanneer HSTS in je browser is geactiveerd voor de bezochte website (dit gebeurt als je browser en de bezochte server allebei HSTS ondersteunen, en je dezelfde website niet al te lang geleden ook al eens hebt bezocht) dan zal zoiets de indringer zeker niet lukken. HSTS forceert namelijk dat je browser een beveiligde verbinding opzet met de betreffende website. En als bovendien aan de serverkant de webserver altijd https forceert, dan kan een MitM ook aan de serverkant de encryptie niet uitschakelen. Het is dan zo goed als zeker dat de verbinding nergens op de lijn kan worden afgeluisterd.
Toch, zo realiseerde ik mij, wil dit helaas niet zeggen dat ons in zo'n scenario niets meer kan gebeuren met TLS.
Om het verhaal compleet te maken: zo'n indringer kan je computer ook nog bestoken met exploits en drive-by-downloads.
Want na een uitgaande verbinding naar het valse IP-adres dat door de valse DNS-server aan je computer werd verstrekt (ten gevolge van gemanipuleerde DNS-instellingen in je router) staat je router open voor inkomend verkeer vanaf ditzelfde valse IP-adres... En als je computer kwetsbaar is (meestal door verzuim van het installeren van security updates, of wegens het gebruik van verouderde software die niet meer wordt ondersteund) ben je dan toch nog de klos...
Ook via deze weg kan de MitM/indringer dus proberen om uiteindelijk communicatie mee te lezen/manipuleren, en zelfs nog meer. En ook in dit geval hoef je zoiets niet onmiddellijk te merken.
Best wel belangrijk dus, die DNS!
Een bedrijf als bijvoorbeeld OpenDNS speelt daar op in, door bij de DNS-aanvragen die jouw computer doet aan de OpenDNS-servers, voortdurend actief in de gaten te houden dat je niet wordt doorgestuurd naar websites die bekend staan als exploiters/malwareverspreiders.
Ook bieden ze een optie waarmee alle DNS-communicatie versleuteld wordt verzonden tussen client en DNS-server.
(standaard gebeurt dit namelijk onversleuteld, waardoor het in principe onderweg tamelijk eenvoudig is te manipuleren)
En desgewenst filtert OpenDNS op deze wijze bijvoorbeeld ook adware, porno en "big data" verzamelaars uit.
(echter als de DNS-instellingen van je internetrouter op één of andere manier toch zijn vervalst, en niet meer naar de OpenDNS-servers verwijzen, dan kan OpenDNS er verder ook niets meer aan doen...)
Kortom: wat algemene internetveiligheid betreft, is het ook zeer zeker de moeite waard om de nodige aandacht te schenken aan de keuze van je router, routerinstellingen, firmwareupdates, plus een sterk admin-wachtwoord op je router.
En zodoende zoveel mogelijk te voorkomen dat het scenario van Erik's derde voorbeeld überhaupt zou kunnen optreden.
Tot slot wil ik voor de volledigheid nog even noemen dat een "Man-in-the-Middle" uiteraard onopgemerkt en gemakkelijk
alle onversleutelde http-communicatie kan meelezen in geval je http zou gebruiken. Iets om rekening mee te houden.
Maar gelukkig verloopt alle communicatie met banken over https. Het mag nooit http worden gedurende je banksessie,
en het is aan te bevelen om altijd te beginnen met https in je browser. Zelfs ook als de webserver jouw http toch wel even automatisch omzet naar https. Want als je met http begint, is het niet uitgesloten dat zo'n MitM-aanvaller het allereerste stukje communicatie zou kunnen meelezen/manipuleren. En zelfs dat is alweer een risico...
Nu hoeft men niet meteen vreselijk van slag te raken van elk mogelijk risico, want het hele leven is een risico.
Maar als het volstrekt onnodig en zo eenvoudig te vermijden is, dan zou het wel zonde zijn als men het niet doet... ;-)
Mvg en nano-nano, cluc-cluc
Het huidige lek is zodanig dat repareren niet gaat,
Hoe rijm ik deze opmerking met het feit dat OpenSSL aangeeft hun implementatie wel van een patch te hebben voorzien?
Voor zover ik hem snap is dat niet veel meer dan een applicatie, die dus tegen de nieuwe versie gecompileerd moet zijn, de mogelijkheid geven om de fallback naar SSLv3 uit te laten schakelen en geen generieke fix.
[
En dat lijkt mij van niet. (tenminste als je direct vanaf het begin de verbinding hebt opgezet in https, en niet in http)
Of heb ik ergens iets gemist?
Mvg, cluc-cluc.
En dat lijkt mij van niet. (tenminste als je direct vanaf het begin de verbinding hebt opgezet in https, en niet in http)
Of heb ik ergens iets gemist?
Mvg, cluc-cluc.
Je hebt inderdaad iets gemist.
Als je een https sessie opzet zal het Poodle lek ervoor zorgen dat, binnen de SSL/TLS specificaties, een verbinding wordt opgezet met SSL v3.0. Deze browser acteert gewoon volgens specs en zal dus een groene balk laten zien. De versleutelde verbinding wordt echter niet met TLS opgezet maar met SSL v3.0. En die was kraakbaar.
Kortom: De aanval is best lastig want je moet er "tussen" zitten. Maar als het dan optreedt is de hele "downgrade" naar SSL v3.0 volgens de specs van SSL/TLS. Dus de browser heeft geen reden om een foutmelding oid te geven. Dus als je klikt op het slotje zie je ook gewoon het certificaat van de bank. De sessie is immers met dat certificaat opgezet. Alleen de encrypte pijp is opgezet met SSLv3.0 en omdat SSL v3.0 al eerder gekraakt is kunnen anderen meekijken.
Als je een https sessie opzet zal het Poodle lek ervoor zorgen dat, binnen de SSL/TLS specificaties, een verbinding wordt opgezet met SSL v3.0. Deze browser acteert gewoon volgens specs en zal dus een groene balk laten zien. De versleutelde verbinding wordt echter niet met TLS opgezet maar met SSL v3.0. En die was kraakbaar.
Kortom: De aanval is best lastig want je moet er "tussen" zitten. Maar als het dan optreedt is de hele "downgrade" naar SSL v3.0 volgens de specs van SSL/TLS. Dus de browser heeft geen reden om een foutmelding oid te geven. Dus als je klikt op het slotje zie je ook gewoon het certificaat van de bank. De sessie is immers met dat certificaat opgezet. Alleen de encrypte pijp is opgezet met SSLv3.0 en omdat SSL v3.0 al eerder gekraakt is kunnen anderen meekijken.
Je uitleg klopt wel, maar is beperkt. Dat ik het met dit beperkte gedeelte eens ben, mag blijken uit de eerste tien regels van bericht "14:57 door Anoniem".Kortom: De aanval is best lastig want je moet er "tussen" zitten. Maar als het dan optreedt is de hele "downgrade" naar SSL v3.0 volgens de specs van SSL/TLS. Dus de browser heeft geen reden om een foutmelding oid te geven. Dus als je klikt op het slotje zie je ook gewoon het certificaat van de bank. De sessie is immers met dat certificaat opgezet. Alleen de encrypte pijp is opgezet met SSLv3.0 en omdat SSL v3.0 al eerder gekraakt is kunnen anderen meekijken.
Sorry dat het in eerste instantie niet zo helder was wat ik bedoelde. Maar het is allemaal ook wat complex.
Mijn opmerking van 17:51 ging over het volgende statement van Erik in het derde voorbeeld van "Hoe komt die aanvaller op "mijn" netwerk":
Ook op die manier kan een MitM aanval worden uitgevoerd zonder dat je dit doorhebt. In zo'n geval klopt de URL (https://mijn.ing.nl/), er wordt een slotje getoond, de URL balk is groen etcetera. Alleen kijkt er wel stiekem iemand mee, dat wil zeggen, de aanvaller ziet nu het versleutelde verkeer voorbijkomen.
Dit statement kwam nogal onvoorwaardelijk over. Anders gezegd: het wekte de indruk dat zo'n soort aanval altijd zou slagen, zonder dat de gebruiker hier iets van zou kunnen merken. En daar zette ik vraagtekens bij.
Jouw reactie bevestigt misschien dat die vraagtekens niet geheel onterecht waren. Wat we gemakkelijk vergeten is dit:
TLS kan niet altijd worden gedegradeerd tot SSLv3. En alleen bij SSLv3 gaat op wat Erik heeft beweerd.
In geval je TLS-verbinding niet wil degraderen (bijvoorbeeld omdat de ondersteuning van SSLv3 op server en/of client zijn disabled), dan bestaan er weliswaar andere MitM-methoden om mee te kunnen luisteren op TLS (zonder het protocol te kraken, want dat lukt voor zover bekend met TLS (nog) niet), maar zulke alternatieve methoden zijn dus wél merkbaar.
Tenzij misschien de aanvaller nog sluwere methoden zou gebruiken, zoals malware injectie op een kwetsbare computer.
(voor meer details lees bericht van 14:57)
Mvg, cluc-cluc
Mijn complimenten voor deze duidelijke bijdragen Erik van Straten.
Een vraag/ opmerking.
Wanneer het register wordt gewijzigd is het misschien handig eerst een herstelpunt aan te maken? Mocht er onverhoopt iets fout gaan, dit misschien nog kan worden herstelt met het gemaakte herstelpunt.
Windows Verkenner/ Computer rechtermuisknop eigenschappen/ Geavanceerde systeeminstellingen/ Systeembeveiliging/
en dan de onder optie 'Nu een herstelpunt maken voor de stations waarvoor systeembeveiliging is ingeschakeld'. (maken).
Een vraag/ opmerking.
Wanneer het register wordt gewijzigd is het misschien handig eerst een herstelpunt aan te maken? Mocht er onverhoopt iets fout gaan, dit misschien nog kan worden herstelt met het gemaakte herstelpunt.
Windows Verkenner/ Computer rechtermuisknop eigenschappen/ Geavanceerde systeeminstellingen/ Systeembeveiliging/
en dan de onder optie 'Nu een herstelpunt maken voor de stations waarvoor systeembeveiliging is ingeschakeld'. (maken).
18-10-2014, 19:08 door
Erik van Straten
Door Bati:
Hoe rijm ik deze opmerking met het feit dat OpenSSL aangeeft hun implementatie wel van een patch te hebben voorzien?
Voor zover ik hem snap is dat niet veel meer dan een applicatie, die dus tegen de nieuwe versie gecompileerd moet zijn, de mogelijkheid geven om de fallback naar SSLv3 uit te laten schakelen en geen generieke fix.
Goede vraag! En dit zou best bij meer beheerders tot misverstanden kunnen leiden...Het huidige lek is zodanig dat repareren niet gaat,
Hoe rijm ik deze opmerking met het feit dat OpenSSL aangeeft hun implementatie wel van een patch te hebben voorzien?
Voor zover ik hem snap is dat niet veel meer dan een applicatie, die dus tegen de nieuwe versie gecompileerd moet zijn, de mogelijkheid geven om de fallback naar SSLv3 uit te laten schakelen en geen generieke fix.
In https://www.openssl.org/news/secadv_20141015.txt zie ik 4 patches:
- de eerste twee hebben niets met SSLv3 te maken;
- de vierde is een patch voor de build-option "no-ssl3", die in de vorige versie(s) van OpenSSL, indien gebruikt, een binary opleverde waarin SSLv3 kennelijk onvolledig was uitgeschakeld. De praktijk is echter dat bijv. Linux distributies met binaries worden uitgeleverd die deze optie niet gebruiken; de praktijk is dat je in configuratiefiles aangeeft of je SSLv3 wilt ondersteunen of juist niet.
De derde patch heet "SSL 3.0 Fallback protection". Dit moet helpen verhinderen dat een MitM (Man-in-the-Middel) aanvaller protocol downgrade attacks kan uitvoeren. Niet alleen van TLS v1.x naar SSLv3, maar ook bijv. van TLS v1.2 naar TLS v1.1. Prima! Anyway, ook dit is geen patch voor Poodle!
Nb. meer info over "SSL 3.0 Fallback protection", ook bekend als TLS_FALLBACK_SCSV, vind je in https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv (het is nog slechts een proposal, geen standaard dus, sinds 2013-09-25 zijn er 2 updates geweest van deze draft).
Er is en er komt GEEN patch voor Poodle!
Om te verduidelijken dat er geen patch voor Poodle kan en gaat komen, uit https://www.imperialviolet.org/2014/10/14/poodle.html:
Door Adam Langley, security engineer bij Google, 2014-10-14, over "POODLE attacks on SSLv3": Fundamentally, the design flaw in SSL/TLS that allows this is the same as with Lucky13 and Vaudenay's two attacks: SSL got encryption and authentication the wrong way around – it authenticates before encrypting.
Kan SSLv3 toch veilig worden gebruikt?
In https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack kun je lezen dat het wel degelijk mogelijk is om SSLv3 te gebruiken zonder kwetsbaar te zijn voor de Poodle attack. Dat komt omdat Poodle een aanval is op Chained Block Ciphers (CBC). Indien er een stream cipher gebruikt wordt bij SSLv3, ben je niet kwetsbaar voor de Poodle attack.
In https://www.openssl.org/docs/apps/ciphers.html#SSL_v3_0_cipher_suites_ kunnen we zien welke cipher suites OpenSSL ondersteunt bij gebruik van SSLv3 (aan de linkerkant staan de officiële benamingen, rechts de karakterreeksen die OpenSSL als parameter accepteert). Als we uit die lijst de volgende weglaten: alle anonymous connecties, alle CBC ciphers en alle ciphers met te korte sleutels (40 en 56 bits), houden we er 2 over:
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
En ook die moet je niet gebruiken, want RC4 is ook lek; zie mijn comment onder https://isc.sans.edu/forums/diary/Apple+Updates+not+just+Yosemite/18851.
Misschien schrijf ik hier binnenkort ook een NL artikel over.
19-10-2014, 14:43 door
Bati
Goede vraag! En dit zou best bij meer beheerders tot misverstanden kunnen leiden...
Thanks, ik ben expert in het stellen van goede vragen :-).
De conclusie dat er geen SSLv3 fix komt had ik gelukkig ook al getrokken, Bedankt voor de uitgebreide uitleg en het nemen van de tijd daarvoor! Wat mij betreft een voorbeeld van hoe een forum gebrukt zou moeten worden.
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
En ook die moet je niet gebruiken, want RC4 is ook lek
Nou... lek... Haast iedere cipher is dan op een bepaalde manier misschien wel in meer of mindere mate "lek". ;-)SSL_RSA_WITH_RC4_128_SHA
En ook die moet je niet gebruiken, want RC4 is ook lek
Maar RC4 is duidelijk zwakker dan men oorspronkelijk dacht. Hoewel nog niet meteen reden tot grote paniek.
Men dient er echter rekening mee te houden dat iemand die de lijn aftapt je internetcommunicatie kan opslaan,
en dat de techniek om RC4 te kraken steeds verder vordert. Zo kan na verloop van tijd informatie alsnog worden ontcijferd. Maar het is niet zo dat bijvoorbeeld www.SSLLABS.com je al een dikke onvoldoende geeft als je nog RC4-ciphers ondersteunt. Wel een advies om de ondersteuning van RC4 te stoppen, i.v.m. toenemende risico's.
En waarom zou je dit niet (nu we toch bezig zijn) meteen maar even in orde maken, voordat het beslist te laat is?
Je kunt zelfs niet helemaal uitsluiten dat professionals inmiddels RC4 misschien al zo goed als gekraakt hébben.
Maar dat weten we niet goed.
Wat is het geval?
Een goede "encryptie cipher" behoort zoveel mogelijk "random" (d.w.z.: willekeurig) te zijn. Maar door een voorkeur voor bepaalde waarden en patronen bij RC4-encryptie (vooral aan het begin van de communicatie) heeft men in ieder geval ontdekt dat men (fragmenten van) data kan blootleggen wanneer er vele malen dezelfde data wordt verstuurd.
Bijvoorbeeld een belangrijke cookie (met wachtwoord), die altijd als eerste wordt meegestuurd bij het inloggen.
Soms injecteert een aanvaller javascript om te forceren dat je browser de communicatie veelvuldig herhaalt.
Zo'n aanval kun je bemoeilijken door javascript in je browser uit te zetten.
Maar dit kan teveel ten koste gaan van de functionaliteit van de bezochte website. En het garandeert niet echt alles.
Het zekere voor het onzekere nemend, wordt daarom aangeraden om alle ciphers waar RC4 in voorkomt, uit te schakelen.
Hoe controleer ik of mijn browser nog RC4- Cipher Suites accepteert?
Via de volgende link kun je ondermeer zien of je browser kwetsbaar is voor POODLE, en tegelijk kun je daar ook zien welke Cipher Suites je browser momenteel allemaal ondersteunt: https://www.ssllabs.com/ssltest/viewMyClient.html
(POODLE -test werkt alleen bij javascript aan)
Als je niet vatbaar bent voor de "poodle"-aanval, dan verschijnt er: "Your user agent is not vulnerable" in het eerste vak
met als titel "SSL v3 POODLE Vulnerability".
Ben je er wel vatbaar voor, dan verschijnt daar in rode letters: "Your user agent is vulnerable. You should disable SSL 3."
Erik van Straten heeft al keurig uitgelegd hoe je SSL 3 uit moet zetten.
Vervolgens bekijk je in het direct daarop volgende vak met de titel "Protocol Features" de lijst "Cipher Suites". (na "Protocols"). Mocht er in de lijst met Cipher Suites iets met "RC4" voorkomen, dan is het aan te bevelen om de betreffende Cipher Suite uit te schakelen. De "find in page" -zoekfunctie van je browser kan overigens behulpzaam zijn om geen enkele RC4-Cipher Suite over het hoofd te zien.
Hoe je die RC4- Cipher Suites kunt uitschakelen, vertel ik zo dadelijk voor Firefox, Internet Explorer en Chrome.
Na uitschakeling van alle RC4-Cipher Suites zal je browser nooit meer een RC4-cipher accepteren,
en ben je voor aanvallen op RC4 dus niet meer kwetsbaar.
Dit houdt wel in, dat je dan ook niet meer over https kunt communiceren met websites die alleen maar RC4-ciphers ondersteunen. Maar dit zal naar verwachting niet vaak gebeuren bij het bezoeken van professionele websites.
Vooral als je een moderne browser gebruikt, die vele alternatieve en goede Cipher Suites ondersteunt.
[en voor hele oude browsers kan een 168-bits 3DES Cipher Suite (vaak met 112-bits aangeduid, omdat het effectief
maar 112 bits zijn) meestal nog een redelijk alternatief zijn. Deze is echter wel ca. 30x trager dan RC4]
RC4-ciphers uitschakelen in Firefox:
1. type in URL-balk: about:config, en klik bij waarschuwing op de knop dat je begrijpt dat je voorzichtig moet zijn.
2. Filter op: RC4
Je ziet nu de ciphers waar RC4 in voorkomt. Ze beginnen allemaal met security.ssl etc.
3. Zet al deze ciphers waar RC4 in voorkomt op "false". (bijv. door een dubbelklik op alle RC4-items die op "true" staan)
4. restart je browser.
5. controleer op https://www.ssllabs.com/ssltest/viewMyClient.html in de lijst met Cipher Suites dat er geen ciphers met RC4 meer in voorkomen.
RC4-ciphers uitschakelen in Microsoft Internet Explorer:
Je kunt de RC4-Ciphers uitzetten door het register te wijzigen:
----------------------------------------------------------------------------------------------------------------
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
"Enabled"=dword:00000000
-----------------------------------------------------------------------------------------------------------------
Zorg dat je ingelogd bent met een beheeraccount.
Je kunt voor alle zekerheid eerst nog even een herstelpunt of een kopie van je register maken.
Kopieer bovenstaande tekst TUSSEN de strepen (dus exclusief die strepen!) naar het klembord.
Start kladblok (notepad) en plak de tekst. Zorg dat er een lege regel is onder de regel die met "Enabled" begint.
Let ook weer op de drie "Belangrijk"-punten die Erik eerder heeft genoemd bij de registerwijzigingen voor SSL 3. (zie topic)
Sla dit bestand bijvoorbeeld op met de naam "DisableRC4.reg" (dus niet als een normale *.txt tekstfile) naar je bureaublad, en voeg deze samen met het register. (dubbelklik, of via rechtermuisknop)
Controleer na deze actie op https://www.ssllabs.com/ssltest/viewMyClient.html dat er geen ciphers met RC4 meer
voorkomen in de Cipher Suites lijst. Voor nadere informatie van Microsoft met betrekking tot RC4, zie:
http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx
RC4-ciphers uitschakelen in Chrome:
Chrome beheert een blacklist voor ongewenste Cipher Suites.
Voor het uitschakelen van RC4-ciphersuites dien je Chrome op te starten met de volgende commandline optie:
--cipher-suite-blacklist=0xc007,0xc011,0xc00c,0xc002,0x0005,0x0004
Controleer met https://www.ssllabs.com/ssltest/viewMyClient.html of nu alle RC4-ciphers inderdaad verdwenen zijn.
Mocht je eens goede redenen hebben om in Chrome ook nog andere Cipher Suites uit te schakelen, let dan in die lijst op het getal tussen haakjes dat met 0x begint, vlak achter de Cipher Suite die je wilt deactiveren.
Dit is een zogenaamd hexadecimaal getal, en een standaard code waarmee de betreffende Cipher Suite wordt aangeduid.
Door dit hexadecimale getal (gescheiden door een komma) in de commandline achter --cipher-suite-blacklist= toe te voegen, kun je in principe ook nog andere ongewenste Cipher Suites uitschakelen als dit ooit eens nodig mocht zijn.
Succes, en "happy safe surfing"! ;-)
Mvg, cluc-cluc
25-10-2014, 20:03 door
alexander038
Hallo Erik van Straten en cluc-cluc ik wou jullie nog even bedanken voor de topics en reacties over Poodle attacks, RC4, etc.
groeten, alex
groeten, alex
Hoe controleer ik of mijn browser nog RC4- Cipher Suites accepteert?
Via de volgende link kun je ondermeer zien of je browser kwetsbaar is voor POODLE, en tegelijk kun je daar ook zien welke Cipher Suites je browser momenteel allemaal ondersteunt: https://www.ssllabs.com/ssltest/viewMyClient.html
(POODLE -test werkt alleen bij javascript aan)
Als ik javascript aan zet is de verbinding onveilig en als ik hem uit zet is de verbinding 100% beveiligd, maar ssl.v3 wordt herkent! Terwijl met javascript ssl.v3 niet wordt ondersteund!
Er zit in javasscript een soort van maleware waardoor de verbinding niet meer veilig is volgens addon calomel! Dus ik vertrouw die site niet!
Via de volgende link kun je ondermeer zien of je browser kwetsbaar is voor POODLE, en tegelijk kun je daar ook zien welke Cipher Suites je browser momenteel allemaal ondersteunt: https://www.ssllabs.com/ssltest/viewMyClient.html
(POODLE -test werkt alleen bij javascript aan)
Als ik javascript aan zet is de verbinding onveilig en als ik hem uit zet is de verbinding 100% beveiligd, maar ssl.v3 wordt herkent! Terwijl met javascript ssl.v3 niet wordt ondersteund!
Er zit in javasscript een soort van maleware waardoor de verbinding niet meer veilig is volgens addon calomel! Dus ik vertrouw die site niet!
Door Anoniem: Hoe controleer ik of mijn browser nog RC4- Cipher Suites accepteert?
Via de volgende link kun je ondermeer zien of je browser kwetsbaar is voor POODLE, en tegelijk kun je daar ook zien welke Cipher Suites je browser momenteel allemaal ondersteunt: https://www.ssllabs.com/ssltest/viewMyClient.html
(POODLE -test werkt alleen bij javascript aan)
Als ik javascript aan zet is de verbinding onveilig en als ik hem uit zet is de verbinding 100% beveiligd, maar ssl.v3 wordt herkent! Terwijl met javascript ssl.v3 niet wordt ondersteund!
Er zit in javasscript een soort van maleware waardoor de verbinding niet meer veilig is volgens addon calomel! Dus ik vertrouw die site niet!
De verschillen met TLS/SSL versie wordt al gemeld, JavaScript is nodig om dit goed te kunnen detecteren.Via de volgende link kun je ondermeer zien of je browser kwetsbaar is voor POODLE, en tegelijk kun je daar ook zien welke Cipher Suites je browser momenteel allemaal ondersteunt: https://www.ssllabs.com/ssltest/viewMyClient.html
(POODLE -test werkt alleen bij javascript aan)
Als ik javascript aan zet is de verbinding onveilig en als ik hem uit zet is de verbinding 100% beveiligd, maar ssl.v3 wordt herkent! Terwijl met javascript ssl.v3 niet wordt ondersteund!
Er zit in javasscript een soort van maleware waardoor de verbinding niet meer veilig is volgens addon calomel! Dus ik vertrouw die site niet!
Als je JavaScript aan hebt staan, test de site ook op mixed content, dus wat niet beveiligd is met SSL/TLS. Je browser ziet dus niet niet alle content beveiligd is en geeft geen standaard slotje weer.
Door Anoniem: Hoe controleer ik of mijn browser nog RC4- Cipher Suites accepteert?
Via de volgende link kun je ondermeer zien of je browser kwetsbaar is voor POODLE, en tegelijk kun je daar ook zien welke Cipher Suites je browser momenteel allemaal ondersteunt: https://www.ssllabs.com/ssltest/viewMyClient.html
(POODLE -test werkt alleen bij javascript aan)
Als ik javascript aan zet is de verbinding onveilig en als ik hem uit zet is de verbinding 100% beveiligd, maar ssl.v3 wordt herkent! Terwijl met javascript ssl.v3 niet wordt ondersteund!
Er zit in javasscript een soort van maleware waardoor de verbinding niet meer veilig is volgens addon calomel! Dus ik vertrouw die site niet!
Via de volgende link kun je ondermeer zien of je browser kwetsbaar is voor POODLE, en tegelijk kun je daar ook zien welke Cipher Suites je browser momenteel allemaal ondersteunt: https://www.ssllabs.com/ssltest/viewMyClient.html
(POODLE -test werkt alleen bij javascript aan)
Als ik javascript aan zet is de verbinding onveilig en als ik hem uit zet is de verbinding 100% beveiligd, maar ssl.v3 wordt herkent! Terwijl met javascript ssl.v3 niet wordt ondersteund!
Er zit in javasscript een soort van maleware waardoor de verbinding niet meer veilig is volgens addon calomel! Dus ik vertrouw die site niet!
Als je alleen maar wilt zien welke cipher suites je browser ondersteunt, dan hoeft javascript niet aan.
Maar negeer dan de sslv3 waarschuwing, want zonder javascript zal de sslv3-status niet betrouwbaar worden getest.
Als je ook wilt zien of je kwetsbaar bent voor de POODLE-attack, dan moet javascript wel aan staan.
Het testen of bij jou SSLv3 aan of uit staat maakt onderdeel uit van deze test.
Staat sslv3 uit, dan ben je sowieso niet kwetsbaar voor POODLE.
Mij is tot op heden niet opgevallen dat er iets niet in de haak zou zijn met de aangegeven website.
Houd er ook wat rekening mee dat men tijdens de test de POODLE aanval zou kunnen simuleren (zonder verder schadelijk te zijn) want hoe wil je het anders testen?... Mogelijk dat sommige protectie-software hierop aanslaat?
Mvg, cluc-cluc.
30-10-2014, 01:36 door
Erik van Straten
@Anomiem (2014-10-29 17:08): die Calomel plugin (https://calomel.org/firefox_ssl_validation.html) kende ik nog niet, dank voor de tip!
Wat Anoniem van 2014-10-29 21:45 schrijft klopt helemaal, met https://www.ssllabs.com/ssltest/viewMyClient.html is (zo goed als zeker) niks mis.
Als je in Firefox geen mixed-content waarschuwingen wilt, kun je in about:config de waarde "security.mixed_content.block_display_content" op "true" zetten. Als je, voordat je dat doet en daarna, naar https://tweakers.net/ gaat, zie je het verschil meteen (de meeste plaatjes verschijnen niet meer met de waarde true).
Wat Anoniem van 2014-10-29 21:45 schrijft klopt helemaal, met https://www.ssllabs.com/ssltest/viewMyClient.html is (zo goed als zeker) niks mis.
Als je in Firefox geen mixed-content waarschuwingen wilt, kun je in about:config de waarde "security.mixed_content.block_display_content" op "true" zetten. Als je, voordat je dat doet en daarna, naar https://tweakers.net/ gaat, zie je het verschil meteen (de meeste plaatjes verschijnen niet meer met de waarde true).
Door Erik van Straten:
Als je in Firefox geen mixed-content waarschuwingen wilt, kun je in about:config de waarde "security.mixed_content.block_display_content" op "true" zetten. Als je, voordat je dat doet en daarna, naar https://tweakers.net/ gaat, zie je het verschil meteen (de meeste plaatjes verschijnen niet meer met de waarde true).
Als je in Firefox geen mixed-content waarschuwingen wilt, kun je in about:config de waarde "security.mixed_content.block_display_content" op "true" zetten. Als je, voordat je dat doet en daarna, naar https://tweakers.net/ gaat, zie je het verschil meteen (de meeste plaatjes verschijnen niet meer met de waarde true).
Dit lijkt mij niet zo'n zinvolle tip / niet zo'n verstandig advies.
Die waarschuwing is er niet voor niets ingebouwd en geeft juist (heel zinvol) aan dat de site niet helemaal over https communiceert.
Met het uitzetten van een waarschuwing waar je nou niet bepaald visueel last van hebt, ontneem je jezelf een belangrijke security waarschuwing.
Een gewaarschuwd mens telt voor twee, dat lukt alleen als je je ogen niet sluit voor waarschuwingen.
||-) =>> :-)
Door Anoniem:
Dit lijkt mij niet zo'n zinvolle tip / niet zo'n verstandig advies.
Die waarschuwing is er niet voor niets ingebouwd en geeft juist (heel zinvol) aan dat de site niet helemaal over https communiceert.
Met het uitzetten van een waarschuwing waar je nou niet bepaald visueel last van hebt, ontneem je jezelf een belangrijke security waarschuwing.
Een gewaarschuwd mens telt voor twee, dat lukt alleen als je je ogen niet sluit voor waarschuwingen.
||-) =>> :-)
Dit is niet alleen de waarschuwing uitzetten, maar alle content die niet over https verloopt blokkeren, met als bij-effect dat je geen waarschuwing meer krijgt.Door Erik van Straten:
Als je in Firefox geen mixed-content waarschuwingen wilt, kun je in about:config de waarde "security.mixed_content.block_display_content" op "true" zetten. Als je, voordat je dat doet en daarna, naar https://tweakers.net/ gaat, zie je het verschil meteen (de meeste plaatjes verschijnen niet meer met de waarde true).
Als je in Firefox geen mixed-content waarschuwingen wilt, kun je in about:config de waarde "security.mixed_content.block_display_content" op "true" zetten. Als je, voordat je dat doet en daarna, naar https://tweakers.net/ gaat, zie je het verschil meteen (de meeste plaatjes verschijnen niet meer met de waarde true).
Dit lijkt mij niet zo'n zinvolle tip / niet zo'n verstandig advies.
Die waarschuwing is er niet voor niets ingebouwd en geeft juist (heel zinvol) aan dat de site niet helemaal over https communiceert.
Met het uitzetten van een waarschuwing waar je nou niet bepaald visueel last van hebt, ontneem je jezelf een belangrijke security waarschuwing.
Een gewaarschuwd mens telt voor twee, dat lukt alleen als je je ogen niet sluit voor waarschuwingen.
||-) =>> :-)
30-10-2014, 11:16 door
Erik van Straten
2014-10-30 08:35, door Anoniem:
Exact, maar Anoniem@02:00 heeft wel een punt: volg niet zomaar adviezen op om instellingen te wijzigen als je niet weet wat de impact daarvan is. In dit geval ging het om iemand die, door de Calomel plugin te gebruiken, vermoedelijk weet wat zij of hij doet. En mijn bijdragen zijn altijd al zo lang... :)2014-10-30 02:00, door Anoniem:
Dit is niet alleen de waarschuwing uitzetten, maar alle content die niet over https verloopt blokkeren, met als bij-effect dat je geen waarschuwing meer krijgt.Door Erik van Straten: Als je in Firefox geen mixed-content waarschuwingen wilt [...] "security.mixed_content.block_display_content" op "true" zetten [...]
Dit lijkt mij niet zo'n zinvolle tip / niet zo'n verstandig advies. [...]Om misverstanden verder te voorkomen: "security.mixed_content.block_display_content = true" betekent niet dat het tonen van de waarschuwing geblokkeerd wordt, maar doet exact wat Anoniem@08:35 beschrijft.
Of je het verstandig is om mijn advies op te volgen, hangt er vanaf wat je wilt:
==> Als je gewaarschuwd wilt worden dat een specifieke website het niet zo nauw neemt met de beveiliging, of als je tijdens het willekeurige surfen (op zoek naar wat anders) wilt vaststellen welke websites het niet zo nauw nemen met beveiliging, heb je goede argumenten om mijn advies niet op te volgen. Plaatjes "via http" (waaronder "web bugs", meestal 1x1 pixel) zullen dan worden opgehaald, en de betreffende "meekijkende" site weet dat jij een bepaalde site + pagina bekeken hebt.
Hoewel er enige risico's kleven aan het verwerken van plaatjes (zie bijv. https://technet.microsoft.com/en-us/library/security/ms10-043.aspx), zijn die over het algemeen beperkt. Anderzijds, als je echt alles wilt weten, kun je "security.mixed_content.block_active_content" (default true) op false zetten (tip: kies mixed als filter in about:config om deze instellingen snel te vinden). Dan zie je nog beter dat websites onveilig zijn, maar tegelijkertijd loop je aanvullende risico's (waarvan andere webbrowsers vaak vinden dat die, by default, acceptabel zijn). Zie http://blog.ivanristic.com/2014/03/https-mixed-content-still-the-easiest-way-to-break-ssl.html voor een toelichting.
==> Als je "op safe wilt gaan", en geen zin hebt om de wereld te verbeteren, kun je mijn advies wel opvolgen. Je loopt er wat minder risico door.
Zelf heb ik geruime tijd met "security.mixed_content.block_display_content = true" gesurft. Ca. 2 weken geleden heb ik het uitgezet vanwege de artikelen die ik op security.nl heb geschreven. Binnenkort ga ik het, verwacht ik, weer aanzetten.
@ 08:35
Ja, helder, maar dat stond niet zo expliciet vermeld (test overgeslagen vanwege naamgeving rule, die leek duidelijk, niet dus).
@ 11:16
Niet zomaar adviezen opvolgen was op zich niet mijn punt hier (al ben ik het er mee eens en doe ik deze waarschuwing er altijd uit bij Terminal-gebruik tips).
De tip zoals gegeven onder 01:36 leek slechts een visuele oplossing.
Maar zoals wel vaker dekt de omschrijving van een rule in de about:config niet exact de lading (aan de tipgever dan de edele taak dat erbij te vermelden, maar wie is er perfect? Ik niet ;-)
Op de indruk dat het 'slechts' een visuele oplossing was, daar sloeg de opmerking dus op.
De opmerking wel/niet verstandig verder breder trekken is daarmee ten opzichte van mijn opmerking niet van toepassing maar verder wel in bredere zin informatief en inzichtelijk.
Extra tip-duiten in het zakje
• Kijken naar de mixed content : Adblock Plus en Element Hiding Helper for Adblock Plus
De element hiding optie geeft op een site met de optie 'Open blockable items' simpel en perfect weer wat er aan content geladen wordt, welke scripts en of het over http of https gebeurt.
Simpel ook per kolom te sorteren.
(Direct gebruik maken van een / de ingebouwde uitgebreide browser webdeveloper / console functie kan ook.
Kan zijn dat je die in sommige gevallen apart in je voorkeuren moet activeren, geloof ik.)
• Images blokkeren / 'laadbeheren' : Request Policy
(die van 1x1 pixel èn 1x2, 1x3, .. ;-)
Mijns inziens één van de meest ondergewaardeerde addons, is echt ook de enige in haar soort geloof ik.
Buitengewoon effectief tegen 3rd party tracking via images!
N.b. focust op domein (first & third party) en niet op verbindingssoort.
Zij maakt dus niet specifiek onderscheid tussen images via http en https.
Dat dan weer niet.
Ja, helder, maar dat stond niet zo expliciet vermeld (test overgeslagen vanwege naamgeving rule, die leek duidelijk, niet dus).
@ 11:16
Niet zomaar adviezen opvolgen was op zich niet mijn punt hier (al ben ik het er mee eens en doe ik deze waarschuwing er altijd uit bij Terminal-gebruik tips).
De tip zoals gegeven onder 01:36 leek slechts een visuele oplossing.
Maar zoals wel vaker dekt de omschrijving van een rule in de about:config niet exact de lading (aan de tipgever dan de edele taak dat erbij te vermelden, maar wie is er perfect? Ik niet ;-)
Op de indruk dat het 'slechts' een visuele oplossing was, daar sloeg de opmerking dus op.
De opmerking wel/niet verstandig verder breder trekken is daarmee ten opzichte van mijn opmerking niet van toepassing maar verder wel in bredere zin informatief en inzichtelijk.
Extra tip-duiten in het zakje
• Kijken naar de mixed content : Adblock Plus en Element Hiding Helper for Adblock Plus
De element hiding optie geeft op een site met de optie 'Open blockable items' simpel en perfect weer wat er aan content geladen wordt, welke scripts en of het over http of https gebeurt.
Simpel ook per kolom te sorteren.
(Direct gebruik maken van een / de ingebouwde uitgebreide browser webdeveloper / console functie kan ook.
Kan zijn dat je die in sommige gevallen apart in je voorkeuren moet activeren, geloof ik.)
• Images blokkeren / 'laadbeheren' : Request Policy
(die van 1x1 pixel èn 1x2, 1x3, .. ;-)
Mijns inziens één van de meest ondergewaardeerde addons, is echt ook de enige in haar soort geloof ik.
Buitengewoon effectief tegen 3rd party tracking via images!
N.b. focust op domein (first & third party) en niet op verbindingssoort.
Zij maakt dus niet specifiek onderscheid tussen images via http en https.
Dat dan weer niet.
We vinden het ook heel normaal dat we hetzelfde nieuws te zien krijgen als we een andere webbrowser, een ander besturingssysteem of een smartphone i.p.v. een notebook gebruiken. En daarbij hebben we geen flauw idee welk besturingssysteem de server van www.nu.nl gebruikt en welke webserversoftware daarop draait.
Na NetCraft er even te laten achter zoeken wast de laatst 'bekende' server (21 Oktober 2014) Apache voor de netsite http://www.nu.nl onder het OS Citrix Netscaler.
23/25/27/29 oktober 2014 server 'unknown' .
Door Anoniem: Hoe controleer ik of mijn browser nog RC4- Cipher Suites accepteert?
Via de volgende link kun je ondermeer zien of je browser kwetsbaar is voor POODLE, en tegelijk kun je daar ook zien welke Cipher Suites je browser momenteel allemaal ondersteunt: https://www.ssllabs.com/ssltest/viewMyClient.html
(POODLE -test werkt alleen bij javascript aan)
Als ik javascript aan zet is de verbinding onveilig en als ik hem uit zet is de verbinding 100% beveiligd, maar ssl.v3 wordt herkent! Terwijl met javascript ssl.v3 niet wordt ondersteund!
Er zit in javasscript een soort van maleware waardoor de verbinding niet meer veilig is volgens addon calomel! Dus ik vertrouw die site niet!
Via de volgende link kun je ondermeer zien of je browser kwetsbaar is voor POODLE, en tegelijk kun je daar ook zien welke Cipher Suites je browser momenteel allemaal ondersteunt: https://www.ssllabs.com/ssltest/viewMyClient.html
(POODLE -test werkt alleen bij javascript aan)
Als ik javascript aan zet is de verbinding onveilig en als ik hem uit zet is de verbinding 100% beveiligd, maar ssl.v3 wordt herkent! Terwijl met javascript ssl.v3 niet wordt ondersteund!
Er zit in javasscript een soort van maleware waardoor de verbinding niet meer veilig is volgens addon calomel! Dus ik vertrouw die site niet!
De https://calomel.org/ssl_certs.html website zegt zelf:
"We highly suggest using Qualys SSL Labs to test your site."
Dus om bij diezelfde WWW.SSLLABS.COM je browser te testen zal dan ook wel goed zitten?!
04-11-2014, 23:22 door
Erik van Straten
2014-11-04 18:39, door Anoniem: De https://calomel.org/ssl_certs.html website zegt zelf:
"We highly suggest using Qualys SSL Labs to test your site."
Dus om bij diezelfde WWW.SSLLABS.COM je browser te testen zal dan ook wel goed zitten?!
Ik vermoed dat het, statistisch gezien, een groter risico is om http://www.nu.nl/ te bezoeken dan https://www.ssllabs.com/ssltest/viewMyClient.html."We highly suggest using Qualys SSL Labs to test your site."
Dus om bij diezelfde WWW.SSLLABS.COM je browser te testen zal dan ook wel goed zitten?!
Je bent er nooit 100% zeker van dat een site niet gehacked is en dat alle beheerders voor 100% te vertrouwen zijn. Maar de eerstvolgende keer dat je de straat op gaat, kun je ook bij een verkeersongeluk betrokken raken. Patch je PC, draai een virusscanner en draag een veiligheidsriem in de auto en kijk goed uit voor je oversteekt: daarmee verlaag je de risico's.
Ervan uitgaande dat www.ssllabs.com niet gehacked is, en de beheerders wel te vertrouwen zijn: deze site stuurt combinaties van https en http verkeer naar jouw webbrowser die de Calomel plugin, onterecht, als kwaadaardig zou kunnen aanmerken. Ze zijn echter niet kwaadaardig; dit is de enige manier om jouw webbrowser zodanig aan de tand te voelen dat deze prijsgeeft welke beschermingsmaatregelen zijn ingebouwd of middels configuratie zijn aangezet.
Voor wat het waard is, ik bezoek die site in het volste vertrouwen dat Qualys.com geen kwaad in de zin heeft, anders dan dat zij statistieken verzamelen en publiceren en daarom deze dienst gratis beschikbaar stelt.
Voor wat betreft de betrouwbaarheid van www.ssllabs.com sluit ik mij aan bij de post
van Erik van Straten, 04-11-2014, 23:22.
Het enige waar wij als NL-inwoners misschien nog wel even op moeten letten,
is dat wij niet per ongeluk "www.ssllabs.NL" intypen.
(www.ssllabs.NL heeft volgens mij ook niets met wwww.ssllabs.COM te maken)
Www.ssllabs.NL gebruikt bovendien een niet-vertrouwd certificaat,
en geeft zonder voorkeur een mogelijkheid tot het gebruiken van zwakke 56 bit ciphers:
TLS_RSA_WITH_DES_CBC_SHA (0x9) en TLS_DHE_RSA_WITH_DES_CBC_SHA (0x15).
(en ook de RC4 ciphers TLS_RSA_WITH_RC4_128_MD5 (0x4) en TLS_RSA_WITH_RC4_128_SHA (0x5))
Risicotechnisch is dit onwenselijk, en niet conform de huidige richtlijnen van het NCSC.
Overigens wel grappig om te zien is dat de echte www.ssllabs.COM zichzelf een "A+" status geeft,
maar dat het "SSL3"-protocol nog altijd "aan" staat. (hoewel ze zelf aanraden om SSL3 "uit" te zetten,
zelfs ook als er mitigation maatregelen tegen POODLE zijn genomen. Zie:
https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack)
Verder ondersteunt de echte www.ssllabs.COM nog RC4 ciphers, maar gelukkig niet met een hoge voorkeur.
Vermoedelijk is de reden dat men om servers en clients goed te kunnen testen
het nodig blijft dat hun eigen server ook nog steeds SSL3 en RC4 aan moet kunnen.
van Erik van Straten, 04-11-2014, 23:22.
Het enige waar wij als NL-inwoners misschien nog wel even op moeten letten,
is dat wij niet per ongeluk "www.ssllabs.NL" intypen.
(www.ssllabs.NL heeft volgens mij ook niets met wwww.ssllabs.COM te maken)
Www.ssllabs.NL gebruikt bovendien een niet-vertrouwd certificaat,
en geeft zonder voorkeur een mogelijkheid tot het gebruiken van zwakke 56 bit ciphers:
TLS_RSA_WITH_DES_CBC_SHA (0x9) en TLS_DHE_RSA_WITH_DES_CBC_SHA (0x15).
(en ook de RC4 ciphers TLS_RSA_WITH_RC4_128_MD5 (0x4) en TLS_RSA_WITH_RC4_128_SHA (0x5))
Risicotechnisch is dit onwenselijk, en niet conform de huidige richtlijnen van het NCSC.
Overigens wel grappig om te zien is dat de echte www.ssllabs.COM zichzelf een "A+" status geeft,
maar dat het "SSL3"-protocol nog altijd "aan" staat. (hoewel ze zelf aanraden om SSL3 "uit" te zetten,
zelfs ook als er mitigation maatregelen tegen POODLE zijn genomen. Zie:
https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack)
Verder ondersteunt de echte www.ssllabs.COM nog RC4 ciphers, maar gelukkig niet met een hoge voorkeur.
Vermoedelijk is de reden dat men om servers en clients goed te kunnen testen
het nodig blijft dat hun eigen server ook nog steeds SSL3 en RC4 aan moet kunnen.
Top uitleg. Heel erg bedankt.
Via een mailing van Telfort werd ik er op geattendeerd dat mijn home server dit probleem zou hebben en kwam ik via de meegestuurde link op deze site.
Florisz
Via een mailing van Telfort werd ik er op geattendeerd dat mijn home server dit probleem zou hebben en kwam ik via de meegestuurde link op deze site.
Florisz
"Er kan geen beveiligde verbinding tot stand worden gebracht, omdat deze site een niet-ondersteund protocol gebruikt."
Dat staat bij een bepaalde site bij mij altijd tegenwoordig, terwijl ik er vroeger gewoon op kon.
Zou dit kunnen komen omdat ik een nieuwe modem heb? En hoe kan ik dit oplossen?
Dat staat bij een bepaalde site bij mij altijd tegenwoordig, terwijl ik er vroeger gewoon op kon.
Zou dit kunnen komen omdat ik een nieuwe modem heb? En hoe kan ik dit oplossen?
Door Anoniem: "Er kan geen beveiligde verbinding tot stand worden gebracht, omdat deze site een niet-ondersteund protocol gebruikt."
Dat staat bij een bepaalde site bij mij altijd tegenwoordig, terwijl ik er vroeger gewoon op kon.
Zou dit kunnen komen omdat ik een nieuwe modem heb? En hoe kan ik dit oplossen?
Dat staat bij een bepaalde site bij mij altijd tegenwoordig, terwijl ik er vroeger gewoon op kon.
Zou dit kunnen komen omdat ik een nieuwe modem heb? En hoe kan ik dit oplossen?
Ik heb met een bepaalde site, en een bepaalde browser op een bepaald tijdstip bepaalde problemen.
Zou mijn man daar de oorzaak van kunnen zijn? ;)
Geef eens wat meer informatie.
Door Anoniem 17-06-2015 18:28 uur: "Er kan geen beveiligde verbinding tot stand worden gebracht, omdat deze site een niet-ondersteund protocol gebruikt."
Dat staat bij een bepaalde site bij mij altijd tegenwoordig, terwijl ik er vroeger gewoon op kon.
Zou dit kunnen komen omdat ik een nieuwe modem heb? En hoe kan ik dit oplossen?
Dat staat bij een bepaalde site bij mij altijd tegenwoordig, terwijl ik er vroeger gewoon op kon.
Zou dit kunnen komen omdat ik een nieuwe modem heb? En hoe kan ik dit oplossen?
Hallo Anoniem 17-06-2015 18:28 uur.
Ik zou ten eerste willen adviseren om gewoon een nieuw topic te starten. Mogelijk krijg je dan meer reacties dan wanneer je een oud topic omhoog werkt. Dit topic is van oktober 2014
Maar goed wat betreft je probleem vallen mij de volgende twee mogelijkheden als eerst binnen die de oorzaak van het probleem eventueel zouden kunnen zijn. (vanwege de beperkte hoeveelheid informatie die je geeft is het onderstaande maar giswerk).
1) De brouwer die jij gebruikt ondersteund een protocol niet (meer) welke door de desbetreffende site wordt gebruikt die je niet meer kan bereiken, en er is geen ander protocol beschikbaar welke door zowel de website als jouw browser wordt ondersteund.
2) De desbetreffende site die je niet meer kan bereiken ondersteund een protocol niet (meer), welke nog wel door jouw browser ondersteund wordt, en er is geen ander protocol beschikbaar welke door zowel de website als jouw browser wordt ondersteund.
Maar zoals Anoniem ook aangeeft, wat meer info zou helpen, zoals weke website je niet kunt berijken, en weklkje browser je gebruikt aangezien het nu giswerk is en de bovenstaande 2 mogelijkheden dus nu ook alleen maar giswerk zijn.
18-06-2015, 00:36 door
Erik van Straten
17-06-2015, 18:28 door Anoniem: "Er kan geen beveiligde verbinding tot stand worden gebracht, omdat deze site een niet-ondersteund protocol gebruikt."
Dat staat bij een bepaalde site bij mij altijd tegenwoordig, terwijl ik er vroeger gewoon op kon.
Zou dit kunnen komen omdat ik een nieuwe modem heb? En hoe kan ik dit oplossen?
Een gewoon huis-tuin-en-keuken modem mag hier geen enkele invloed op hebben.Dat staat bij een bepaalde site bij mij altijd tegenwoordig, terwijl ik er vroeger gewoon op kon.
Zou dit kunnen komen omdat ik een nieuwe modem heb? En hoe kan ik dit oplossen?
Ik vermoed dat de betreffende website uitsluitend verouderde SSL protocollen en/of "cipher suites" ondersteunt, en dat jouw browser (of de door die browser gebruikte Windows bibliotheken voor https) recentelijk zodanig is bijgewerkt dat deze geen enkele "https verbindingsmethode" meer ondersteunt die ook de server ondersteunt.
Dit kun je vaststellen als volgt: ga met je webbrowser naar https://www.ssllabs.com/ssltest/viewMyClient.html. Met de browser die ik nu gebruik, zie ik:
Protocols
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3 No
SSL 2 No
Cipher Suites (in order of preference)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Forward Secrecy 128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Forward Secrecy 128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Forward Secrecy 256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Forward Secrecy 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Forward Secrecy 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3 No
SSL 2 No
Cipher Suites (in order of preference)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Forward Secrecy 128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Forward Secrecy 128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Forward Secrecy 256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Forward Secrecy 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Forward Secrecy 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
Vervolgens kun je de server testen op https://www.ssllabs.com/ssltest/. Als er geen gemeenschappelijke "Protocols" en "Cipher Suites" zijn, zal jouw browser geen versleutelde https verbinding met de server kunnen krijgen. Je kunt dit enigszins ermee vergelijken dat jouw browser een stel talen spreekt, en de server ook, maar dat er geen gemeenschappelijk taal bestaat die door beiden wordt gesproken en begrepen.
We horen graag nog even van je wat er aan de hand was, als je deze tests hebt uitgevoerd! Dan kunnen we misschien ook adviseren wat je eraan kunt doen, en of dat verstandig is of niet. We zijn er natuurlijk ook in geïnteresseerd om welke server het gaat, maar als je dat liever niet kwijt wilt begrijp ik dat.
Als je als relatieve leek inzicht wilt krijgen in dit soort basisprincipes (SSL, protocollen) dan kan ik de cursus "Internet History, Technology, and Security" op Coursera aanbevelen. Vanuit de historie en de problemen die daar ontstonden wordt de huidige inrichting van internet uitgelegd. Kost wat tijd, maar dan heb je ook wat.
https://www.coursera.org/learn/internet-history/home/info
https://www.coursera.org/learn/internet-history/home/info
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.
