Onderzoekers vinden opnieuw problemen met ssl

Onderzoekers hebben beveiligingsproblemen gevonden in Diffie-Hellman, een protocol dat in ssl en tls wordt gebruikt om sleutels uit te wisselen. Daardoor kunnen kwaadwillenden een lagere graad van beveiliging afdwingen. Zowel websites als mailservers, ssh en vpn-verbindingen zijn getroffen.

De kwetsbaarheid is vergelijkbaar met de zogenoemde Freak-kwetsbaarheid, die eerder dit jaar aan het licht kwam. Daarbij konden aanvallers een lagere graad van beveiliging afdwingen, doordat veel webservers en browsers nog ondersteuning hebben voor verouderde encryptiestandaarden.

Normaliter gebruiken een client en een server het hoogste niveau van beveiliging dat door beide wordt ondersteund. In het geval van Freak en de nieuwe kwetsbaarheid kan een aanvaller echter een lagere, inmiddels achterhaalde graad van beveiliging forceren. Kwaadwillenden kunnen de communicatie daardoor eenvoudig ontsleutelen.

Het grote verschil met de Freak-kwetsbaarheid is dat die kwetsbaarheid in ssl-implementaties zat, waardoor slechts een deel van de gebruikers was getroffen. De nieuwe kwetsbaarheid, door onderzoekers Logjam gedoopt, bevindt zich echter in het veelgebruikte Diffie-Hellman-protocol, dat bij ssl en tls wordt gebruikt om encryptiesleutels uit te wisselen.

Daardoor zijn alle systemen die de verouderde encryptie ondersteunen, kwetsbaar. Daaronder is niet enkel 8,4 procent van de 1 miljoen grootste websites, stellen de onderzoekers, maar ook een groot aantal mailservers: de versleutelde versies van pop3, imap en smtp leunen op Diffie-Hellman. Ook vpn-servers en ssh-verbindingen lopen gevaar.

Systeembeheerders die zich na de Freak-aanval hebben gewapend door verouderde encryptiesuites uit te schakelen, zijn ook veilig voor de nieuwe aanval. De meeste browsers hebben echter nog ondersteuning voor de verouderde suites. Webbrowsers zijn momenteel bezig met het uitbrengen van patches voor het probleem; op dit moment is alleen Internet Explorer gepatcht. Gebruikers kunnen op de website van de onderzoekers testen of hun browser nog kwetsbaar is.

De ondersteuning voor verouderde encryptie is een erfenis uit het verleden: in de jaren negentig verbood de Amerikaanse overheid de export van lange encryptiesleutels. Gebruik van kortere encryptiesleutels maakte de berichten immers makkelijk te onderscheppen. Hoewel lange encryptiesleutels allang niet meer uit den boze zijn, is ondersteuning voor de korte, verouderde sleutels vanwege backwards-compatibility vaak nog steeds aanwezig.

Daarnaast hebben de onderzoekers een moeilijker te misbruiken, theoretischer probleem met Diffie-Hellman gevonden. Veel verbindingen die op Diffie-Hellman leunen zijn gebaseerd op dezelfde priemgetallen. De aanname is dat dat veilig genoeg is, maar de onderzoekers weerspreken dat. Een priemgetal van 768 bits kan volgens de onderzoekers door een onderzoeksteam worden gekraakt, en een priemgetal van 1024 bits door een overheid.

Is dat priemgetal gekraakt, dan kan het verkeer van 18 procent van de 1 miljoen grootste https-websites worden onderschept, evenals 26 procent van de ssh-servers en maar liefst 66 procent van de ipsec-vpn-servers. De onderzoekers raden sysadmins dan ook aan om unieke priemgetallen te gebruiken, met een lengte van 2048 bits.

Sinds april 2014 kwamen veel ernstige beveiligingsproblemen in ssl en ssl-implementaties aan het licht. Daaronder was HeartBleed, waarmee aanvallers het interne geheugen van een server met OpenSSL konden uitlezen. Ook vonden onderzoekers van Google een kwetsbaarheid in ssl 3.0, waardoor met javascript bijvoorbeeld cookies konden worden onderschept.

Reacties (77)

[Orthodroom]

Kan je ook ergens testen of je server kwetsbaar is?

[jorisros]

Op de gemelde site kan je hem ook testen
https://weakdh.org/sysadmin.html

[Verwijderd]

Na het maken van een nieuwe 2048-bit DH group kreeg ik bij deze test nogmaals het bericht dat ik een 1024-bit group gebruikte. Daarentegen pakte https://www.ssllabs.com/ssltest/ wel de changes op. Dus ik raad aan om ssllabs te gebruiken.

[azerty]

Het zou me niet verbazen moesten de getoonde resultaten (vooral gezien het feit dat ze zó snel op het scherm verschijnen) de status weergeven van toen ze het internet gescand hebben. Mijn resultaat (ook 1024 bit), is namelijk al zeker een maand (zo niet langer) al niet meer van toepassing, want ik heb die DH groep minimum een maand geleden al vervangen door een >= 2048 bit versie.

[Verwijderd]

De snelheid van de test verbaasde ik me ook al over. De aanname die je maakt lijkt mij de juiste. Voor actuele resultaten dus https://www.ssllabs.com/ssltest/ gebruiken.

[dolfje]

Of je kan het volgende gebruiken: http://security.uwsoftware.be/logjam.php
Iets minder data (hopelijk passen ze dat nog aan), maar de tool gebruikt geen cache (voor zover ik heb gemerkt)

[Tralapo]

Qualys SSl Labs geeft me een keurige A-score. De site van dolfje geeft vervolgens weer een foutmelding. Is die eerste al wel up-to-date voor dit probleem dan?

[jorisros]

Dat is gek, want ik maakte bij mij een nieuwe dh group aan en restartde nginx en het toen gaf die direct aan dat het inplaats van 1024 2048-bit geworden was. Het zag er niet naar uit dat het cached werd

[Armin]

Eens, doch waarom uberthaupt nog DHE gebruiken?

Apple ondersteund het geheel niet en Microsoft enkel met AES-GCM ciphers. Als je die laatste ondersteunt heeft je server software ook ECDHE, en wil je Apple gebruikers dus forward secrecy geven is DHE een no-go.

Dus waarom niet gewoon afscheid nemen van DHE in zijn algemeenheid? ECDHE heeft minder server load bij dezelfde security.

Om mijn eigen vraag te beantwoorden, er zijn twee antwoorden:
- Android 2.x compatibiliteit
- Oude Java 6 compatibiliteit

Doch als je daar je niet voor intereseerd kun je DHE helemaal uitzetten.

[MAX3400]

https://weakdh.org/sysadmin.html

En er staat ook al vermeld dat ze aanraden om je cipher veel langer te maken dan 512/768.

[Verwijderd]

Bij veel cloud en VPN diensten is men ook aan het overstappen naar chippers van 2048 bits.

[Verwijderd]

Zie mijn bericht van hieronder: Verwijderd in 'nieuws: Onderzoekers vinden opnieuw problemen met ssl'

[FREAKJAM]

Dat staat letterlijk in het artikel, kwestie van even lezen. Als je niet je browser bedoelt, kun je je server hier en hier testen.

Gebruikers kunnen op de website van de onderzoekers testen of hun browser nog kwetsbaar is.

[Reactie gewijzigd door FREAKJAM op 23 juli 2024 10:24]

[Crazy Harry]

Jouw username wordt wel heel toepasselijk met de naamgeving van die kwetsbaarheden

OT:
Ik snap echt niet dat men na de Freak-kwetsbaarheid niet is afgestapt van de backwards-compatibiliteit met oude protocollen. Mijn inziens is het dom dat men hiermee door is gegaan.
En natuurlijk dan zullen een hoop systemen incompatible worden op het moment dat je dwingt dat ze enkel met de modernste veiligheidsprotocollen compatible zijn, maar vroeg of laat komt die verplichte update toch. Je kan het direct doen, of je kan wachten tot er misbruik van gemaakt kan worden. In het eerste geval ben je op tijd, in het tweede geval ben je te laat.

Zo moeilijk is die redenatie toch niet dat men dat niet kan bedenken

[FREAKJAM]

Een kwetsbaarheid vergelijkbaar met de zogenoemde freak-kwetsbaarheid door onderzoekers logjam gedoopt. Je zou inderdaad haast denken dat ik er achter zit.

[Reactie gewijzigd door FREAKJAM op 23 juli 2024 10:24]

[Armin]

Ik snap echt niet dat men na de Freak-kwetsbaarheid niet is afgestapt van de backwards-compatibiliteit met oude protocollen

Er waren dan ook twee soorten 'men'

De eerste groep 'men' waren bedrijven als banken, Microsoft, Apple, etc die die zut al lang uit hadden staan. Waren toen niet kwetsbaar en zijn nu niet kwetsbaar.

De tweede groep 'men' waren websites die geen HTTPS serveren als primair doel. Denk aan kranten en andere HTTP-only sites Echter vaak heeft men een HTTPS voor intern management, blog user accounts, etc. En die waren kwetsbaar bij FREAK, en ook die zijn nu nog steeds kwetsbaar.

Dat is ook logisch, want als je export-ciphers aan hebt staan heb je uberhaupt niet geintereseerd in security, en ben je ook geen bedrijf dat onder verplichte audits staat (denk aan banken). En dus is het ook logisch dat het hele FREAK verhaal grootdeels aan hen voorbijgegaan is.

[Orthodroom]

Het staat er niet letterlijk, want er word juist specifiek de browser gemeld. informatie betreffende de server mist in mijn optiek.

[daan-ter-horst]

Heb net mijn browser geupdate (chrome 43.0.2357.65 m) maar deze is ook niet beveiligd tegen logjam. Welke browsers zijn hier al wel tegen beveiligd?

[Axewi]

Als je op dit moment veilig wil zijn kan je Firefox gebruiken en dan de oude encryptie uitschakelen.
1) installeer firefox.
2) typ in de adres balk: "about:config"
3) zoek naar ssl
4) zet "security.ssl3.dhe_rsa_aes_128_sha" op false
5) zet "security.ssl3.dhe_rsa_aes_256_sha" op false

en dan firefox opnieuw starten.
Testen kan je dan op de eerder genoemde site: https://weakdh.org/

[Crazy Harry]

Ik zie daar nog veel meer protocollen met lage lengtes staan, zijn die wel veilig dat jij weet?

[Axewi]

Zeker weten doe je het nooit, maar die andere zijn niet in het nieuws geweest. Je kan meer uitschakelen maar op en gegeven moment verlies je ook functionaliteit tot op het moment waar websites gedeeltelijk of helemaal niet meer werken .
Mijn advies is om de bovenstaande 2 te doen, en na een update te controleren.

Je zou voor de zekerheid kunnen controleren op andere vulnerabilities.
https://www.poodletest.com/ (poodle) nieuws: Google-onderzoekers vinden ernstig lek in oude ssl-versie - update

en een algemene check: https://www.howsmyssl.com/

[Crazy Harry]

Ah! Dat zijn mooie helpvolle links.
Zeker die laatste waarbij veel verschillende checks uitgevoerd worden, is erg handig.
Grappig dat ze bij een waardering van 'good' bij alles, een algemene waardering geven die geen 100% vertrouwen wekt; "Your SSL client is Probably Okay."

Komt overeen met jouw eerste 5 woorden

Goed dat ze dat doen, want anders krijg je een misplaatst gevoel van vertrouwen.

[hackerhater]

Thanks. Dat werkte prima

[thomas_n]

Met Iceweasel op Debian krijg ik op die testsite wel het bericht dat ik veilig zit. Ik weet niet of dat betekent dat Mozilla een patch voor Firefox heeft uitgebracht, of dat het Debian Security team het snel even tussendoor heeft gerepareerd.

[batjes]

Iceweasel lijkt veilig.
Maar...

"security.ssl3.dhe_rsa_aes_128_sha"
"security.ssl3.dhe_rsa_aes_256_sha"

Beide zijn wel actief in Iceweasel en dat zijn de 2 brakke SSLs die je zoals Axewi vermeld in Firefox zou moeten uitschakelen om veilig te zijn.

En in de recente changelogs van Iceweasel is er helemaal niets te vinden dat ze iets gedaan hebben aan deze exploit.

EDIT: Zojuist de bron geopent met Iceweasel en

Warning! Your web browser is vulnerable to Logjam and can be tricked into using weak encryption. You should update your browser.

[Reactie gewijzigd door batjes op 23 juli 2024 10:24]

[thomas_n]

Ik had eerder gekeken met de versie van Iceweasel uit het release-kanaal (backports) en daarmee kreeg ik het bericht dat het veilig was. Nu ik het probeer met de esr-versie (die standaard in stable zit) krijg ik inderdaad het "onveilig"-bericht.

Dat lijkt me betekenen dat er via het mozilla.debian.net kanaal vanochtend al een fix is gegeven, terwijl security.debian.net (waar de de security updates voor de esr-versie vandaan komt) het nog niet voor elkaar heeft.

[DataGhost]

Opera 12.16 (ja dat oude ding, die is nu bijna twee jaar oud) is ook veilig. Ik krijg namelijk een "low encryption level" dialoogje waar gevraagd wordt of ik wil approven of rejecten. Als ik reject zegt de site dat mijn browser veilig is, als ik approve krijg ik de melding dat 'ie onveilig is. Erg jammer dat dat in nieuwere versies niet meer het geval is en dat die gewoon vulnerable zijn.

[Jan-E]

Een beetje mosterd na de maaltijd: dit komt omdat Opera al in 2007 op de hoogte was van het probleem met zwakke DH-Keys. DH-Keys < 900 bits worden al 8 jaar door Opera als onveilig beschouwd:
http://www.ietf.org/mail-...tls/current/msg01647.html

Dat was al in de tijd van "Opera Mail/9.20 (Win32)", maar is bij het overschakelen op Webkit (>12) kennelijk weer verwijderd.

Edit: Als je doorleest in die thread, zie je dat Stephen Henson (core developer van OpenSSL) ook al op de hoogte was:
http://www.ietf.org/mail-...tls/current/msg01652.html

[Reactie gewijzigd door Jan-E op 23 juli 2024 10:24]

[MAX3400]

Staat duidelijk in het artikel?

Webbrowsers zijn momenteel bezig met het uitbrengen van patches voor het probleem; op dit moment is alleen Internet Explorer gepatcht.

[zjeeraar84]

Webbrowsers zijn momenteel bezig met het uitbrengen van patches voor het probleem; op dit moment is alleen Internet Explorer gepatcht.

[sun0000]

In het artikel staat:
If you use a browser…

Make sure you have the most recent version of your browser installed, and check for updates frequently. Google Chrome (including Android Browser), Mozilla Firefox, Microsoft Internet Explorer, and Apple Safari are all deploying fixes for the Logjam attack.

[Verwijderd]

Is dat priemgetal gekraakt, dan kan het verkeer van 18 procent van de 1 miljoen grootste https-websites worden onderschept, evenals 26 procent van de ssh-servers en maar liefst 66 procent van de ipsec-vpn-servers.

Volgens mij is IPsec sowieso al een VPN protocol dat als onveilig word gezien. En waarvan ook al langer wordt vermoed dat organisaties als de nsa er toegang tot toe hebben.

De 26% van de ssh verbindingen en 18% van de websites wel kwetsbaar is, is een veel groter probleem. Tijd voor die servers en sites om afscheid te nemen van het Diffie-Hellman-protocol.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 10:24]

[flabber]

[...]
Volgens mij is IPsec sowieso al een VPN protocol dat als onveilig word gezien. En waarvan ook al langer wordt vermoed dat organisaties als de nsa er toegang tot toe hebben.

Er zijn genoeg issues rondom IPsec, maar het Tweakers forumtopic waar je naar verwijst is een slechte bron om dit hard te maken. Dit topic handelt over slechts een beperkte set van VPN gebruik, namelijk het gebruik van VPN providers. Daarnaast bevat het in de inleiding al een aantal feitelijke fouten ten aanzien van verschillende protocollen.

Een betere bron zou Bruce Schneier zijn.
Een flink technisch stuk, maar met onderbouwing van elk argument tegen IPsec.
Maar daar is de conclusie dat ondanks meerdere issues, IPsec nog altijd te prefereren is boven een aantal andere protocollen.
Het is een oud artikel maar daar wordt al gesproken over de kwetsbaarheid voor downgrade attacks, wat dit nieuwe probleem in feite gewoon is.

[Dennis]

Diffie Hellman wordt meestal ook gebruikt in OpenVPN verbindingen. Ik denk dat er veel Tweakers zijn die dat gebruiken.

Verstandig is om dus 2048 of 4096-bit DH-parameters te gebruiken. Wil je een set van goede instructies hoe je je OpenVPN zo optimaal mogelijk kunt beveiligen, kijk dan op het blog van Gert van Dijk van FOX-IT. De DH-parameters staan hier ook tussen.

[gertvdijk]

Recente OpenVPN is niet zo kwetsbaar voor deze aanval in het algemeen, omdat het:

• geen hardcoded DH parameters in de software heeft (zoals Apache wel heeft bijvoorbeeld),
• De standaard instructies in de documentatie altijd vermelden om je eigen DH parameters te maken.

En thanks voor de link naar mijn blog. Er is best veel om rekening mee te houden, inderdaad.

[Armin]

De 26% van de ssh verbindingen en 18% van de websites wel kwetsbaar is, is een veel groter probleem. Tijd voor die servers en sites om afscheid te nemen van het Diffie-Hellman-protocol..

Dit!

Al zou ik zeggen dat die websites het probleem niet zijn. Dat zijn namelijk vrijwel nooit belangrijke websites zoals emailportals en banken, maar bijna altijd de blog-accounts van kranten en andere HTTP-only sites.

Maar veel erger zijn de SMTP servers. En met name het inter-server SMTP verkeer. Dus niet van jouw client naar een server, maar de grote mailservers onderling. Nu is SMTP met zijn optionele encryptie (KPN encrypt anno 2015 bijvoorbeeld nog steeds nooit enige bit bij inter-server verkeer) uberhaupt problematisch, maar het gebruik van zwakke DHE 'keys' blijft domweg smullen voor veiligheidsdiensten ...

Dus inderdaad, tijd om afscheid te nemen van DHE.

[cyberstalker]

Volgens mij is het probleem dat veel servers nog DH4 ondersteunen om zodoende ondersteuning voor oudere clients te houden (denk aan IE op XP). Als je DH4 uitzet werken deze niet meer voor jouw server. Helaas zijn er nog steeds bedrijven waarbij dit een issue is en die blijven eisen dat deze ondersteuning geleverd blijft worden.

Hiermee schiet je jezelf natuurlijk in de voet omdat je hiermee de beveiliging voor iedereen onderuit haalt.

[Crazy Harry]

Naar mijn mening is het dan ook slechte bedrijfsvoering wanneer je naar dergelijke klanten zou luisteren.
Wij hebben met een dergelijke situatie niet te maken dus het is een beetje makkelijk praat voor mij maar mij lijkt het handig als klanten gewoon gedwongen worden wanneer het om beveiliging gaat.
Een aankondiging dat je over x periode overgaat, en verouderde beveiliging uitfaseert. Vervolgens geef je (zelfs als het niet bij je kerntaken hoort) betaalde ondersteuning om te helpen bij de overgang.

Je klanten opvoeden ('educate your client'), is mijn inziens een grote deugd en gebeurd te weinig uit angst klanten te verliezen.

[Armin]

Volgens mij is het probleem dat veel servers nog DH4 ondersteunen om zodoende ondersteuning voor oudere clients te houden (denk aan IE op XP).

Meer ivm Android 2.x en Java 6 (= diverse bedrijfspakketten).

Windows XP ondersteunt geen DHE met RSA keys dus daar hoef je het niet voor te doen

[Faeron]

Mensen die de Hiawatha webserver gebruiken kunnen (wederom) lekker achterover hangen. Met de default instellingen is deze webserver niet kwetsbaar voor dit probleem.

[Tralapo]

Datzelfde geldt overigens voor gebruikers die hun site versterken met CloudFlare SSL. Die zijn ook niet kwetsbaar op dit moment.

Ik kende Hiawatha niet. Ziet er interessant uit, binnenkort eens mee prutsen.

[Armin]

Of IIS, Apache, NGix, etc.

Wil DHE_EXPORT aan staan moet je gewoon een behoorlijk oude configuratie hebben.

[Verwijderd]

1024 bits zijn al lang niet meer voldoende, en worden ook niet meer uitgegeven. Op dat punt is dit bericht "oud nieuws". Maar het is knap dat ze hebben aangetoond dat gebruik van een sleutel, waarvan we al weten dat die onveilig is, daadwerkelijk onveilig is.

[flabber]

1024 bits zijn al lang niet meer voldoende, en worden ook niet meer uitgegeven. Op dat punt is dit bericht "oud nieuws". Maar het is knap dat ze hebben aangetoond dat gebruik van een sleutel, waarvan we al weten dat die onveilig is, daadwerkelijk onveilig is.

Die 1024 bits die niet meer voldoende is gaat over (asymetricshe) RSA keys gebruikt voor certificaten. Dit staat geheel los van dit verhaal.
Praten over het aantal bits is zinloos als je het protocol er niet bij vermeldt.
Een symmetrische AES key van 256 bits wordt bijvoorbeeld nog algemeen beschouwd als veilig, waar een DES-key van 512 bits ongeveer gelijk staat aan het op slot zetten van je fiets met een tie-wrap.

[Verwijderd]

Ja en Nee. Ik was even op het verkeerde been gezet door Freak (dat op rsa gebaseerd is). Dus daarin heb je gelijk.

Aan de andere kant, voor DH en RSA bevat de sleutel een priemgetal, dus je mag aannemen dat in beide gevallen de veilige sleutellengte in enige zin wel op elkaar lijkt.

[Armin]

Klopt.

Het probleem zit herm er dan ook in dat veel servers bij gebruik van DHE-RSA key exchange een 1024 bit DH 'key' gebruiken ook al is de achterliggende RSA-key 2048bit. Dit omdat anders Java 6 over zijn nek gaat inclusief de talloze bedrijfspakketten die daarvan afhankelijk zijn.

En dus ga je nat want je RSA key is dan 2048 bit, maar de exchange slechtst beschermd met 1024 bit DH. Een aanvaller hoeft 'slechts' 1024 DH bit te kraken. DH en RSA zijn ruwweg even sterk dus gebruik je effectief maar een 1024 bit RSA key.

En erger nog, het blijkt dat veel servers (met name Linux gebaseerde systemen) geen volledig random DH 'keys' gebruiken. Dus het is niet enkel 1024 maar heeft ook nog eens 'voorkeuren'. Dat is ook al bekend en dus geen nieuws, maar dit onderzoek is wel het eerste dat al deze zaken koppelt in een soort end-to-end implementatie.

Een aanvaller zoals de AIVD kan dus deze 'voorkeur' keys gaan aanvallen (offline uitrekenen) via supercomputers, en daarna een significant deel van het verkeer uitlezen. Zou er geen voorkeur zijn, zou men slechts een miniem deel kunnen uitlezen en deze excercitie zinloos zijn.

[WhatsappHack]

Dit is toch helemaal geen fout in Diffie Hellman, of zie ik dat nou verkeerd?

Er staat zelfs in het artikel:

We have uncovered several weaknesses in how Diffie-Hellman key exchange has been deployed

Hoe het is *geimplementeerd*. Niet dat er daadwerkelijk een fout zou zitten in DH, maar gewoon de manier waarop het gebruikt wordt in TLS...
Derhalve lijkt "bevindt zich echter in het veelgebruikte Diffie-Hellman-protocol," me dan een foute conclusie. DH zelf is niet per definitie onveilig, de manier waarop het gebruikt wordt is wat het werkelijke probleem is. Daarom dat nieuwere versies en andere key configs het probleem gewoon oplossen...

[Armin]

Daarom dat nieuwere versies en andere key configs het probleem gewoon oplossen...

Nee, het probleem is dat DHE geen inherente bescherming tegen key downgrades heeft. Je hebt gelijk dat men nieuwere versies en betere key configs er in de praktik geen gevaar is, maar anders dan bij bijvoorbeeld FREAK het geen implementatiefout is, maar een eigenschap van het protocol.

Een 100% correcte DHE implementatie is dus theoretisch kwetsbaar in een MitM aanval tenzij de client nog wat additionele controles doet (= zwakke DHE keys weigeren), of de server bereid is bepaalde clients uit te sluiten (= zwakke DHE keys nooit genereren).

[WhatsappHack]

Hmmmm ja, ik snap je punt. Maar is dat nou een fout in DHE; of de gene die DHE wilt gebruiken?

Ik snap het probleem. Ik snap het "gebrek" van DHE. Maar dat is een gegeven van DHE.
Als je dat dan dus vooralsnog fout in gebruik neemt, is dat dan werkelijk een fout in DHE of van de gene die DHE zo heeft ingesteld?

Als jij een auto koopt waarvan men zegt "leg de reserve sleutel niet in de achterbak", en iemand legt het er toch in. Er wordt ingebroken, ze vinden de sleutel: starten en gassen maar, zonder probleem.
... Is dat dan een fout in de beveiliging van die auto, of van de gene die het verkeerd "implementeert" (eg: reservesleutel in de auto zelf stoppen, ipv op een veilige plek.)

Beetje rare vergelijking natuurlijk, maar je snapt denk ik wel wat ik bedoel?
Het blijft lastig. Het is en blijft een 'tekortkoming' van DHE uiteraard, en de kwetsbare suites zijn al behoorlijk oud (Srsly, TLS 1.0... Come on.); maar toch vind ik dat er op z'n minst een soort gedeelde schuld is.

[Armin]

Punt is echter is dat het ook met moderne TLS 1.2 ciphers kwetsbaar is. Dus een server met DHE en enkel moderne ciphers, maar eentje die wel wél een 1024 bit key toestaat, is kwetsbaar voor een downgrade ook al zouden client en server normaal gesproken een sterkere key kunnen/willen gebruiken. En dit dus ongeacht wat voor ciphers en TLS versie. En noch server en noch client merken dit. Dat is best heftig.

Dus als je als admin voor Java 6 clients 1024 bit DHE 'keys' wilt ondersteunen zullen alle andere moderne clients potentieel een ongemerkte downgrade kunnen ondergaan. Wil je dat niet is de enige opties als server-admin om of DHE geheel uit te zetten, of te accepteren dat Java 6 niet kan verbinden door de minimale bitsterkte op 2048 te zetten.

Als we het woord 'fout' wat sterk vinden is het op zijn minst een hiaat in het protocol.

Gelukkig zijn de omstandigheden om zo'n downgrade uit te voeren normaal gesproken erg moeilijk en is het gevaar dus klein indien je verder alles netjes op orde hebt. In die zin inderdaad gedeelde schuld ben ik met je eens.

[atlaste]

Vind het een beetje onduidelijk wat nu precies getroffen is. Kan het ook niet echt vinden in de artikelen.

Als ik het goed begrijp is het protocol vulnerable als je een oud priemgetal gebruikt. Dat lijkt vaak het geval te zijn. Dat lijkt me alleen een implementatiedetail; maw: sommige implementaties zijn getroffen en andere niet. De voorbeelden die genoemd worden van applicaties klinken allemaal als OpenSSL.

Kortom, dit kan dus betekenen dat alleen OpenSSL getroffen is en bijv. de Windows implementatie niet getroffen is... Kan iemand dit wel/niet confirmeren?

[R4gnax]

Als ik het goed begrijp is het protocol vulnerable als je een oud priemgetal gebruikt. Dat lijkt vaak het geval te zijn. Dat lijkt me alleen een implementatiedetail; maw: sommige implementaties zijn getroffen en andere niet. De voorbeelden die genoemd worden van applicaties klinken allemaal als OpenSSL.

Kortom, dit kan dus betekenen dat alleen OpenSSL getroffen is en bijv. de Windows implementatie niet getroffen is... Kan iemand dit wel/niet confirmeren?

Er zit een fundamentele fout in het protocol van de key-exchange tussen client en server. Dit is niet een implementatie-specifiek iets en alle implementaties die het protocol tot de letter implementeren zijn vatbaar hiervoor.

Er is een zeer kort moment tijdens de key-exchange waar een oude cipher op basis van een zwak 512-bits priemgetal niet te onderscheiden is van een cipher op basis van een sterk priemgetal.

Op voorwaarde dat je hardware ter beschikking hebt die snel genoeg is om real-time een juiste substituut 512-bits priem te genereren, kan een man-in-the-middle aanval de key-exchange overnemen en daarna de decryptie-sleutels van de sessie stelen.

Hiermee kunnen geen berichten aangepast worden, maar kunnen wel alle berichten gelezen worden.

[Reactie gewijzigd door R4gnax op 23 juli 2024 10:24]

[Armin]

Op voorwaarde dat je hardware ter beschikking hebt die snel genoeg is om real-time een juiste substituut 512-bits priem te genereren, kan een man-in-the-middle aanval de key-exchange overnemen en daarna de decryptie-sleutels van de sessie stelen.

Goede post!

Alleen en klein puntje op de i: dat 'snel genoeg' is momenteel nog steeds zo traag dat het meestal niet gaat werken. Immers we spreken nog steeds over doorgaans minuten.

Veel 'makkelijker' is als men TLS False Start optionele extentie gebruikt. In dat geval is er geen 'snel genoeg' restrictie, maar 'enkel' dat de server DHE_EXPORT onderstunt én men een MitM aanval kan opzetten.

IE en Chrome ondersteunen dit. Firefox inmiddels sinds kort (toevallig?) niet meer.

[Fermion]

Hoeveel meer problemen worden er nog gevonden en mijn vraag is nu, zijn deze prorblemen die de afgelopen jaren zijn gevonden met opzet ein gezet?

[Blokker_1999]

Neen, code word nog altijd geschreven door mensen en mensen maken fouten. Daarnaast is encryptie altijd maar tijdelijk veilig. Als computers krachtiger worden moet de encryptie volgen om brute force aanvallen voor te blijven. Als we dan oude protocollen blijven ondersteunen blijven we onszelf ook extra kwetsbaar maken.

Ik denk ook dat na de eerste grote kwetsbaarheid veel meer mensen zijn beginnen zoeken op kwestbaarheden binnen SS en er nu dus meer fouten gevonden worden, wat enkel maar positief is imho.

[flabber]

Het stuk

Het grote verschil met de Freak-kwetsbaarheid is dat die kwetsbaarheid in ssl-implementaties zat, waardoor slechts een deel van de gebruikers was getroffen. De nieuwe kwetsbaarheid, door onderzoekers Logjam gedoopt, bevindt zich echter in het veelgebruikte Diffie-Hellman-protocol, dat bij ssl en tls wordt gebruikt om encryptiesleutels uit te wisselen.

suggereert dat dit probleem veel meer in het protocol zelf zit, maar dat is niet het geval.
Noem het een implementatie fout of een configuratiefout, maar het DiffieHellman protocol is goed te gebruiken mits je de juiste parameters opgeeft.
En dat is eigenlijk hetzelfde als bij HeartBleed en vele andere vulnerabilities.

Verschillende zaken die in het onderzoeksrapport naar voren komen zijn eigenlijk altijd oorzaak van beveiligingsproblemen, ongacht het gebruikte protocol:

• het basis priemgetal om keys mee te berekenen wordt urenlang hergebruikt
• ondersteuning voor verouderde protocollen/CipherSuites is niet uitgeschakeld
• nieuwe 'gemaks-features' in clients/servers gaan buiten beveiligingsfeatures heen

Een heel mooie vind ik zelf de 'TLS warning alert' : blijkbaar kunnen browsers hiermee overtuigd worden om de time-out van een TLS handshake eventjes (of zelfs permanent bij Firefox!) op te schorten. Hiermee schept de attacker extra tijd om de gebruikte keys te achterhalen.

[Armin]

maar het DiffieHellman protocol is goed te gebruiken mits je de juiste parameters opgeeft.

In de praktijk waar, maar niet helemaal. het DHE protocol zélf is kwetsbaar in de zin dat het geen bescherming biedt tegen een verzwakking van de key. Een MitM aanvaller kan dus een 512/1024 key afdwingen ook al willen client en servere en sterke key.

Een client kan zich hier enkel tegen te beschermen door naast het DHE protocol bepaalde keys simpelweg te weigeren. In de praktijk echter kan men 1024 keys niet weigeren omdat teveel oude bedrijfspakketten daarvan afhankelijk zijn. Dus een aanvaller kan nog steeds een downgrade van 2048 bit DHE naar 1024 DHE afdwingen.

Verder overigens geheel eens met de kern van je boodschap: als client en vooral server DHE goed implementeren, ben je in de praktijk gewoon veilig.

En verder helemaal eens met je 'gemaks features' opmerking. HeartBleed, POODLE (via browser fallback) en ook de meest praktische aanvallen in deze aanval zijn allemaal gevolgen van extra's naast de kern-protocollen.