In reactie op: Vandaag, 00:56 door Erik van Straten - Bijgewerkt: Vandaag, 00:58
Beste Erik, voor mij lijkt het alsof je soms wel eens dingen uit zijn context haalt, en ze vervolgens plaatst
in een hele andere context die niet van toepassing is. Dat is niet zo'n eerlijke methode.
Graag wil ik dat recht zetten.
Om te beginnen haal je het voorbeeld aan van "WEP", dat serieus is gekraakt. Maar wij hadden het over 3DES,
dat dus al tientallen jaren
juist niet echt serieus is gekraakt. Zoiets is druiven met appels vergelijken.
Juist deze lange periode wijst er op, dat 3DES kennelijk niet zo gemakkelijk echt serieus te kraken is.
Waar het mij om ging, is dat sommigen een 112 bits cipher maar "bitter weinig" vinden,
en dat men veiligheid alleen maar afmeet aan die sleutellengte.
Maar ik rekende jullie voor, dat in het ideale geval 112 bits niet per sé te weinig hoeft te zijn.
In ieder geval hoef je niet zo bang te zijn voor een snelle succesvolle "brute force attack".
Dat de zaken in werkelijkheid vaak niet 100% ideaal zijn (ook bij 3DES niet helemaal), moge duidelijk zijn.
Uit mijn tekst die daarna kwam over "cipherstrength" en "keylength" mocht dit ook wel blijken.
Wil je de veiligheid van ciphers goed beoordelen, dan zou het niet alleen over sleutellengte moeten gaan,
maar ook over de kwaliteit van het algoritme.
Zet je een cipher suite A met een sterk algoritme en een wat kortere sleutel eens af tegen een cipher suite B
met een zwak (kwetsbaar) algoritme maar met een langere sleutel, dan kún je beter af zijn met cipher suite A,
ook al heeft deze een kortere sleutel.
Probleem is alleen wel: hoe bepaal je nu de mate van kwetsbaarheid van een algoritme?
Want kwetsbaarheden tekenen zich meestal pas later af in de praktijk,
en/of pas als vele geleerden zich er jarenlang over hebben gebogen... Dat is dus het grootste probleem bij de beoordeling.
En daarom hebben we toch de neiging om maar naar de sleutellengte te kijken, want dat weten we tenminste zeker.
Maar eigenlijk kunnen we elkaar daar dus gemakkelijk mee voor de gek houden.
M.a.w.: een cipher met een 256 bits sleutel maar met een nogal beroerd (kwetsbaar) algoritme,
hoeft niet beslist beter te zijn dan een cipher met een 128 bits sleutel en een veel sterker algoritme.
Men moet zich dus niet teveel blind staren op de feitelijke lengte van de sleutel, want dit zegt lang niet alles.
Het is hooguit een indicatie, een indruk. Maar wel met de nodige "slagen om de arm".
Er bestaan ook goede algoritmen waarvan aan de oppervlakte liggende zwakheden al bekend zijn, en die worden soms meteen ingecalculeerd. Bij 3DES is dit het geval. Want 3DES is feitelijk 168 bits (3 x 56 bits), maar wordt meestal als 112 bits gepresenteerd. Het NCSC noemt dit met een mooi woord 112 bits "security-equivalent".
Natuurlijk is het prima dat jij, Erik, er nog eens op wees dat er meestal geen sprake van een ideale situatie is,
en dat ook via een andere weg dan "brute force" (bijv. door kwetsbaarheden/lekken van het algoritme uit te buiten)
op één of andere manier (iets van) de ciphertext (=je versleutelde data die over de lijn gaat) kan worden blootgelegd.
Maar je had het wat mij betreft wat beter (eerlijker) kunnen brengen.
Ten tweede reageer je op mijn "men zou niet zomaar de "cipher strength" moeten afmeten aan de hand van puur en alleen de key-length!" als volgt:
De volgorde in de webpagina is totaal irrelevant als de serverbeheerder geen voorkeurvolgorde heeft geconfigureerd. Het lijstje had net zo goed op alfabet gesorteerd kunnen zijn, of op geboorteddaum van de uitvinder van de cipher. Toevallig kiest SSLlabs ervoor om te sorteren op de geadverteerde sleutellengte.
Waar maak je dat uit op dan? Kijk nog eens heel goed wat SSLLABS boven zo'n cipherlijst zet.
Ik citeer: "
Cipher Suites (sorted by strength; the server has no preference).
Ik herhaal:
sorted by strength!.
Er staat niet "sorted by advertized keysize" of iets dergelijks.
Hadden ze dat maar gedaan, dan had jij mij hier niet over gehoord. Maar nu zaaien ze in zulke
"sorted by strength" -cipherlijsten dus de verwarring dat 3DES (112) sterker zou zijn dan AES (128).
Bekijk het nog maar eens heel nauwkeurig zou ik zeggen. Het is gewoon niet correct.
Ten derde waarschuwde ik voor een MitM attack in geval van ondersteuning van brakke ciphers.
Zelfs ook als de server zo is geconfigureerd, dat deze "geen voorkeur" voor een cipher heeft,
en zelfs ook als de server naast die brakke ciphers ook nog gewoon sterke ciphers ondersteunt.
En dan reageer jij hierop door er op zijsporen van alles omheen te vertellen over zaken die misschien op zichzelf genomen en onder bepaalde omstandigheden helemaal niet onwaar zijn, maar ze doen volgens mij niet zo ter zake.
Zo ontstaat er obfuscatie t.a.v. het punt waar het daar feitelijk om draaide, namelijk:
"denk nu alsjeblieft niet te snel dat je geen extra risico's loopt bij servers die "geen voorkeur"
voor een cipher hebben, en die naast sterke ciphers ook nog hele brakke ciphers ondersteunen."
(En dat servers om die reden liefst totaal geen brakke cipher suites zouden moeten ondersteunen)
Concreet moet je hierbij denken aan een zogenaamde "Cipher suite rollback".
Deze aanval richt zich op het limiteren van de verstrekte cipher-suite lijst tot uitsluitend zwakkere of NULL-ciphers.
Een Man-in-the-middle (MitM) aanvaller zou bijvoorbeeld de initiële ClientHello message kunnen wijzigen
en alle sterke cipher-suites van die ClientHello message afstrippen, zodat er alleen nog maar hele zwakke ciphers op de lijst staan. Desnoods probeert de aanvaller zelf zwakke ciphers toe te voegen.
Deze aldus gemanipuleerde ClientHello wordt vervolgens doorgestuurd naar zo'n server die "zonder voorkeur"
ondermeer die zwakkere cipher suites ondersteunt, et voilá...
Wie als leek dan nog een browser heeft die eveneens dit soort zwakke ciphers nog ondersteunt, krijgt er dan mee te maken dat de hele sessie dus over een zwak versleutelde (afluisterbare) verbinding wordt gecommuniceerd, met alle risico's van dien. Dus nogmaals: servers moeten daarom liefst helemaal geen brakke cipher suites ondersteunen,
want dit is niet altijd geheel zonder risico's. Oók niet als de server "geen voorkeur" voor een cipher heeft.
Voor wat het laatste onderwerp betreft: wat ik dus niet helemaal begreep was deze zinsnede:
de 40 bit ciphers komen vóór de 56 bit ciphers - wisseljebeheerder was een betere naam geweest
Waarom zeg je zo nadrukkelijk "de 40 bits ciphers komen vóór de 56 bit ciphers", en zeg je pas daarna:
"wisseljebeheerder was een betere naam geweest"???
Het is toch niet de schuld van de beheerder dat SSLLABS bij een server "ZONDER VOORKEUR"
een 40-bits cipher vóór een 56-bits cipher plaatst?
Wat mij betreft doet het hier weinig ter zake dat het 40-bits cipher vóór de 56 bits in de lijst staat.
Maar het feit dat deze twee brakke ciphers überhaupt in de lijst staan (ongeacht de volgorde),
ja, dat wekt inderdaad bij mij wel vragen op, ja, of die systeembeheerder daar wel op zijn plaats is.
En o ja (-; toegift ;-) je had het ook nog even over die richtlijnen van NCSC. Daarbij moest ik weer denken aan 3DES
dat ik een poosje geleden had betiteld met "veilig genoeg". Maar jij leek het daar toen niet mee eens te zijn.
Zojuist nog even in de onlangs uitgekomen "ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS)"
van het Nationaal Cyber Security Centrum gelezen wat het NCSC zegt over DES, 3DES en RC4:
1. DES en 3DESOp blz. 15 is na te lezen dat 3DES cipher suites in de categorie "voldoende" vallen.
De categorie "voldoende" is bedoeld om de nodige compatibliteit met oudere apparaten te behouden.
Een "voldoende" algoritme biedt minstens 112 bits "security-equivalent".
"Security-equivalent" is een term die NCSC gebruikt als indicatie voor de sterkte van een cipher.
Bijvoorbeeld: ECDSA met een sleutellengte van 256 bits en AES met een sleutellengte van 128 bits
hebben allebei een security-equivalent van 128 bits.
De 3DES ciphers voldoen aan de vereiste 112 bits, maar enkelvoudige of tweevoudige DES ciphers niet.
De zogenaamde "triple-DES" (3DES) cipher suites zijn dus "veilig genoeg" (=voldoende veilig) bevonden.
Maar enkelvoudige DES ciphers (56 bits) worden nergens meer aangeraden, en als "verouderd" beschouwd.
2. RC4Het NCSC schrijft op blz.5 onder "BEAST-aanvalstechniek" betreffend RC4 het volgende voor:
"
RC4 kent echter zijn eigen kwetsbaarheden en dient niet gekozen te worden."
Op blz.16 is de waardering voor het RC4-algoritme dan ook een "onvoldoende".
Elders wordt RC4 als "verouderd" beschouwd, samen met DES. (enkelvoudig, 56 bits).
(zie blz. 33 bij "Bulkversleuteling")
In de "ciphersuite richtlijnen" op blz.15 komen RC4 en (enkelvoudig, 56 bits) DES dan ook niet voor.
Kortom: De
richtlijn van het NCSC (Nationaal Cyber Security Centrum) is:
gebruik geen RC4 en geen (56 bits) DES!Maar
3DES (bijv. TLS_RSA_WITH_3DES_EDE_CBC_SHA)
mag (vooralsnog) als het nodig is nog even
blijven.
Lijkt me duidelijk, en "veilig genoeg" om een punt te zetten achter de discussie over DES, 3DES en RC4. :-))
(dat o.a. Triodos daar nog lering uit mag trekken) ;-)
Mvg, cluc-cluc