Google-onderzoekers vinden ernstig lek in oude ssl-versie - update

Onderzoekers van Google hebben een kwetsbaarheid in ssl 3.0 gevonden die een aanvaller die pakketten weet te onderscheppen onder meer cookies laat stelen. Hoewel ssl 3.0 al jarenlang verouderd is, wordt deze versie vaak nog ondersteund.

De Google-onderzoekers hebben de bug Poodle - Padding Oracle On Downgraded Legacy Encryption - genoemd. In tegenstelling tot de Heartbleed-bug in OpenSSL, waarbij aanvallers een deel van de inhoud van het interne geheugen van een server met OpenSSL konden uitlezen, is Poodle geen kwetsbaarheid in een specifieke ssl-implementatie, maar in het onderliggende protocol.

Een aanvaller moet iemands verkeer kunnen onderscheppen voor misbruik, bijvoorbeeld door een malafide netwerk op te zetten. Vervolgens kan javascript worden gebruikt om cookies te onderscheppen. Die methode is vergelijkbaar met de Beast-kwetsbaarheid in tls 1.0 die in 2011 aan het licht kwam.

Er is geen workaround beschikbaar, benadrukken de onderzoekers: ssl 3.0 moet compleet worden vermeden. Het probleem is dat veel browsers en servers nog steeds het achttien jaar oude ssl 3.0 ondersteunen. Een aanvaller kan de browser van een gebruiker er bovendien toe verleiden om over te stappen op ssl 3.0, door handshakes met nieuwere ssl/tls-versies te laten mislukken.

Google gaat zelf ssl 3.0-ondersteuning uit Google Chrome verwijderen. Ondanks dat ssl 3.0 volgens Mozilla nog steeds voor miljoenen transacties wordt gebruikt, wordt de ondersteuning in Firefox 34 ook uitgefaseerd. Als ook serversoftware ondersteuning voor ssl 3.0 uitfaseert, levert dat vooral problemen op voor gebruikers van oudere software, zoals gebruikers van Internet Explorer 6. Gebruikers kunnen testen of hun browser getroffen is via Poodletest.com.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (75)

Of voor de servermensen onder ons:
SSLProtocol all -SSLv2 -SSLv3

(En als je dan toch bezig bent, gooi er ook iets ij als:
SSLHonorCipherOrder On
SSLCompression Off

Apache 2.2:
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

Apache 2.4
#SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

En voor volledige configuraties, ook andere servers, zie https://wiki.mozilla.org/Security/Server_Side_TLS

Toch handig dat OpenSSL; alles (blijven) ondersteunen zodat je alles stuk voor stuk uit moet zetten

Overigens word het internet voor IE6 weer een heel groot stuk kleiner voor de mensen die er nog gebruik van moeten maken, dus eigenlijk zijn deze bugs niet eens zo slecht

[Reactie gewijzigd door Kees op 15 oktober 2014 09:02]

En doe een test op https://ssllabs.com/ssltest/analyze.html om te kijken of alles correct staat.

En/of gebruik https://ssl-tools.net/webservers/

Just noting, die eerste is heel erg goed en aan te raden.
(Net ff getest, lollig genoeg geeft ie geen waarschuwing als SSLv3 is ingeschakeld oO Kreeg alsnog een A+ rating haha! Maar dan kan je t iig wel in t rapport zien als je t als admin niet zeker weet. )

... Maar die tweede is soms echt gaar.
Lijkt bij bepaalde SNI hosts al redelijk over z'n nek te gaan en geeft bij de meest leip onbenullige randconfiguraties al aan dat er totaal geen werkelijke SSL verbinding mogelijk zou zijn terwijl SSL perfect functioneert; zelfs met een van de veiligste instellingen.

Voordat mensen zich zonder reden druk gaan maken als er een rood scherm verschijnt bij die 2e URL: lees dus eerst heel goed de exacte foutmelding alvorens je adrenaline niveau omhoog te pompen.

Ik had dat ook gezien, wilde ook een melding maken bij ssllabs om SSv3 te checken maar dat moet via forum registratie etc etc dus liet ik het maar even zo, er vanuit gaand dat ze deze laatste "best practice" ongetwijfeld hebben gelezen en ze hun test daarop aanpassen.

De ss-tools.net doet ook bij een aantal van mijn eigen sites niet helemaal correct weergeven wat klopt en wat niet.

Voor een snelle check kan je ook https://www.tinfoilsecurity.com/poodle gebruiken

Minder uitgebreid (en sneller), maar gebruik deze ook nog wel eens:
https://sslanalyzer.comodoca.com

En ja, ze zullen nog aangepast moeten worden. Ook deze geeft nog geen weak of andere waarschuwing op SSLv3.

En voor de Windows gebruikers, je kunt SSL 3.0 disablen door de volgende registry aanpassing te doen:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
"Enabled"=dword:00000000

Hierna ben ik in ieder geval volgens de poodletest not vulnerable.

Of je download IIS Crypto, drukt op de knop 'Best Practices', vinkt vervolgens SSL 3.0 uit, druk dan op 'Apply' en restart je server.

Goede tip, die kende ik nog niet. Morgen eens uitproberen op mijn csg servers.
Danke je wel.

Mja, ik verkies regedit en een microsoft kb‘tje voor de eerste server en een simpele .reg file of gpo voor de rest, boven een overkill .net programma met license agreement waarvan ik verder niks weet, die ik op elke server moet gaan klikken.

Juist, en er is een /server key op de zelde locatie!

Correct, voor meer info:
http://support.microsoft.com/kb/245030

Ennn voor nginx, puur om v3 te deactiveren:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;


... uiteraard daarna nginx herstarten.
Let wel dat t ook nog aan te raden valt speciek je ciphers ook beter in te stellen; maar hiermee is in ieder geval SSLv3 eruit gesloopt.

-edit-
Ok, toch maar een cipher configuratie voor nginx erbij:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK';


P.S.
Kees, die # in je Apache 2.4 config... You sure that should be in there?

[Reactie gewijzigd door WhatsappHack op 15 oktober 2014 08:23]

Voor mensen met Cpanel/WHM kun je -SSLv2:-SSLv3 aan je "SSL Cipher Suite" configuratie toevoegen bij Service Configuration/Apache Configuration om SSL v2 en SSL v3 uit te schakelen.

Toch een aanvulling hierop.
!!LET OP: DIT IS VOOR APACHE 2.4!!

Dit werkt niet lekker via WHM. Kijk maar in je httpd.conf, dat is niet de juiste manier om ermee om te gaan.
Hebben hier al een case over lopen bij cPanel.

Je kan voor nu het beste de volgende stappen volgen:
1.) Kopieer /var/cpanel/templates/apache2_4/main.default naar /var/cpanel/templates/apache2_4/main.local als je nog geen main.local hebt
2.) Wijzig de .local, zoek naar [% IF supported.mod_ssl -%]
Je ziet iets als dit staan:

[% IF supported.mod_ssl -%]
# SSLCipherSuite can be set in WHM under 'Apache Global Configuration'
[% IF main.sslciphersuite.item.sslciphersuite.length %]SSLCipherSuite [% main.sslciphersuite.item.sslciphersuite %][% END %]

Vervang dat voor:

[% IF supported.mod_ssl -%]
# SSLCipherSuite can be set in WHM under 'Apache Global Configuration'
[% IF main.sslciphersuite.item.sslciphersuite.length %]SSLCipherSuite [% main.sslciphersuite.item.sslciphersuite %][% END %]
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLPassPhraseDialog builtin
SSLCompression Off

3.) De ciphersuite zelf tik je vervolgens alsnog in WHM in...
Bijvoorbeeld:

ALL:EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

4.) En dan niet vergeten op REBUILD te klikken.
Ook als je je ciphers niet wijzigt, alsnog rebuilden om de nieuwe config die je in main.local hebt aangepast in te laden!

Voila, bekijk je httpd.conf nu nog eens.
Ziet er een stuk beter uit, werkt ook beter.

[Reactie gewijzigd door WhatsappHack op 16 oktober 2014 01:27]

3.) De ciphersuite zelf tik je vervolgens alsnog in WHM in...
Bijvoorbeeld:
ALL:EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

Waarom nog RC4 ondersteunen? Deze is realtime te kraken.
Heb je nog hele belangrijke XP/MSIE6 users? Anders moet ie weg zou ik zeggen.

Klopt, in principe is daarvoor TLS_FALLBACK_TCSV beter voor geschikt...
IE6 is sowieso al incompatible, in principe, met de gegeven ciphersuite; maar om niet alles te mollen... Tja, dat is een afweging die de sysadmin moet maken; maar je hebt gelijk.

Eerder zijn ook al de aangeraden instellingen van Mozzila gelinkt, die kan je eventueel ook gebruiken en slopen RC4 er wel uit:

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

[Reactie gewijzigd door WhatsappHack op 15 oktober 2014 21:30]

Gelukkig stond her bij ons al goed (nog maar net 3 weken, moet ik eerlijkheidshalve zeggen natuurlijk).

[Reactie gewijzigd door djwice op 15 oktober 2014 21:54]

Thanks voor de tip, hopelijk fixen ze dit snel aangezien hun standaard instellingen ook gebruik maken van -SSLv2 en dat soort dingen terwijl het mij inderdaad ook al beter leek om dit zoals aanbevolen met SSLProtocol etc. te regelen.

Gelukkig scoren we alsnog A-

Edit:

SSLSessionCacheTimeout 300
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin

Let er op dat dit er al in staat, niet dat je dit er dubbel in zet ... dat zorgde er bij mij schijnbaar voor dat OCSP stapling niet (meer) werkte.

Nu scoren we A én PCI compliance

[Reactie gewijzigd door Ventieldopje op 15 oktober 2014 20:50]

Ja klopt;
Als je echter die -SSLv3 toevoegt in de SSLCipherSuite directive via WHM, dan heb je als resultaat dat een groot scala aan browers, ook recente; eg Firefox, enorme problemen krijgen omdat ook TLS 1.0 en 1.1 eruit worden gesloopt.

Yep, niet vergeten om daarna op rebuild configuration klikken en nogmaals bevestigen in t overzicht scherm dat dan getoond wordt.
Vooral dat laatste vergeten veel mensen met cPanel servers nog al eens.

Trouwens, als je dan toch bezig bent daar kun je net zo goed meteen ff alle andere instellingen op PCI Compliant zetten.

[Reactie gewijzigd door WhatsappHack op 15 oktober 2014 15:59]

Als ik me niet vergis schakelt de PCI compliant instelling alleen SSLv2 uit en niet SSLv3. Beetje mee oppassen dus voordat je klakkeloos alles PCI compliant maakt op een productie server

Vandaar "alle andere instellingen", maar dat had ik misschien duidelijker moeten omschrijven inderdaad!

Die # is er zeker nodig, want ik draai nog apache 2.2 en dan gaat die 2.4 config wel werken, maar kun je ineens niet meer Internet Explorer gebruiken om deze site te bezoeken

Ah juist
Maar voor mensen die wel 2.4 draaien en dit als voorbeeld nemen lijkt t me niet zo handig om die er in te laten staan natuurlijk; misschien handig te vermelden voordat er een copy/paste koning mee aan de haal gaat. Al verdien je t dan eigenlijk gewoon...

Ik heb voor DirectAdmin beheerders hier neer gezet hoe het te patchen is:
http://forum.directadmin....50099&p=258183#post258183

Toch handig dat OpenSSL; alles (blijven) ondersteunen zodat je alles stuk voor stuk uit moet zetten

De FIPS module zet heel veel automatisch voor je uit. Dan wordt je Apache config heel eenvoudig.

SSLProtocol -all +TLSv1.2 +TLSv1.1 +TLSv1
SSLCipherSuite AES256:AES128:3DES:HIGH
SSLHonorCipherOrder On
SSLFIPS on

of

SSLProtocol -all +TLSv1.2 +TLSv1.1 +TLSv1
SSLCipherSuite HIGH:!3DES:!AES128
SSLHonorCipherOrder On
SSLFIPS on

Zie
Jan-E in 'nieuws: Google-onderzoekers vinden ernstig lek in oude ssl-versie - update'

[Reactie gewijzigd door Jan-E op 15 oktober 2014 13:09]

Let wel even op met fips... fips compliant betkent ook dat de nieuwste en sterkste cyphers niet beschikbaar zijn, simpelweg omdat die nog niet goedgekeurd zijn.
Om diezelfde reden, en omdat je het scala aan technologieen dusdanig beperkt dat nogal wat 3rd party spul kuren vertoont, heeft MS de aanbeveling om "use fips compliant algorithms..." aan te zetten in de security policy, verwijdert uit de security aanbevelingen.
http://blogs.technet.com/...ng-fips-mode-anymore.aspx

Gooi gelijk ook even de RC4 suite weg, deze blijf je ondersteunen en daarvan is al langer bekend dat deze kwetsbaar is. Tevens ondersteun je 3DES en die is kwetsbaar voor een meat in the middle aanval, en dus ook kwetsbaar.

Kleine correctie, 3DES is nog steeds volledig veilig. De 'meet in the middle' methode is namelijk geen kwetsbaarheid, maar een aanvalsmethode. En enkel een theoretische.

Immers 3DES is zoals de naam zegt 3 lagen DES. Samen is dat 168 bit brute force protectiebescherming. Absoluut onkraakbaar dus. Echter omdat het in feite 3 laten DES is is er een alternatieve aanvalsmethode naast brute force. Bji deze methode kun je vanaf één kant gaan rekenen, en dan vanaf de andere kant mete en lookup tabel aan de gang gaan. Vandaar 'meet in the middle'.

Doe je dat hoeft je "slechts" 112 bit brute force te berekenen indien je de beschikking hebt over eeb lookup table van de resterende 56 bits.

Echter:

1) 112 bits is nog steeds onkraakbaar. En zelfs voor de NSA Het is namelijk nog steeds heel ver in het astronomische.
2) Die lookup table is leuk, maar reken maar eens uit hoe groot die moet zijn voor 56 bits DES. Je hebt dan al een klein datacenter aan storage nodig. het is dus vooral een theoretisch gekkigheidje dan echte praktische methode.

Dus zelfs als supercomputers 112bits zouden kunnen kraken, moet je nog steeds een bizar grote opslag klaar hebben staan. En dan nog kan men slechts één sleutel tegelijk breken.

De verwachting is dat pas in 2030 er misschien super-computers zijn, die die 112bit kunnen proberen aan te pakken. Echter op dat moment is AES 128 ook al in zicht en hebben we grotere problemen.

De reden waarom 3DES uit de gratie is is omdat het op software erg zwaar is. Het algorithme was namelijk ontwikkeld in de tijd dat encryptie vooral in hardware gedaan wordt, en het algorithme leent zich slecht voor gewone AMD/Intel/ARM/etc CPU's.

3DES is echter bijvoorbeeld nu nog steeds wel erg populair in kleine microcontrollers. Denk o.a. aan je bankpas!

De verwachting is dat pas in 2030 er misschien super-computers zijn, die die 112bit kunnen proberen aan te pakken. Echter op dat moment is AES 128 ook al in zicht en hebben we grotere problemen.

Het is geen probleem om AES128 op https-servers ook uit te zetten. Je bent dan niet meer bereikbaar voor IE6 & IE8 op XP, Android 2.3 en alle Java-versies. Zie https://www.ssllabs.com/s...tml?d=sessiondatabase.net

Wanneer komt AES 256 in zicht van de supercomputers?

Edit Next version of SSL Labs:
https://dev.ssllabs.com/s...tml?d=sessiondatabase.net

Edit 2
Die server heb ik nu overgezet naar OpenSSL FIPS 1.0.1j. dev.ssllabs heeft door dat TLS_FALLBACK_SCSV onderstend wordt

[Reactie gewijzigd door Jan-E op 15 oktober 2014 22:52]

En XP was je toch al kwijt door 3DES te verwijderen. Maar ik mag hopen dat in 2030 niemand meer XP gebruikt

Maar er zijn nog geen schattingen voor wanneer AES 256bit kwetsbaar zal zijn. Wellicht wel nooit. Immers de benodigde berekeningen zijn bizar astronomisch, dus als AES ooit gebroken wordt is dat eerder door een nog niet ontdekte fundamentele kwetsbaarheid dan door brute force super computers.

Het probleem met de RC4 suite weggooien is dat je dan IE6-IE8 helemaal niet meer ondersteunt iirc. Ik moet eerst even kijken of dat wel een goed idee is..

Uit je eigen link https://wiki.mozilla.org/...r_Side_TLS#RC4_weaknesses

RC4 weggooien zou geen problemen mogen zijn aangezien Windows XP ook 3DES ondersteunt.

Het probleem is namelijk niet de browser, maar het OS. Bij Windows levert namelijk het OS de SSL-implementatie. Vista ondersteunt TLS 1.0 met AES encryptie en is dus ook met IE8 dus nog veilig. Op Windows XP is echter enkel SSL 3.0 met of RC4 or 3DES beschikbaar.

Wil je toch XP met IE6-8 ondersteunen kun je dus RC4 best uitzetten mits je 3DES aan laat staan.

Wil je dat liever niet, zorg dan dat 3DES in ieder geval hoger in de cypher volgorde staat. IE6-8 zal dan automatisch 3DES nemen.

EDIT: ik zie dat jullie huidige configuratie inmiddels al RC4 verwijdert heeft. Ofwel

[Reactie gewijzigd door Armin op 15 oktober 2014 17:48]

Het beste kun je OpenSSL in FIPS mode zetten. OpenSSL op CentOS en Redhat is standaard al gecompileerd met de FIPS module. Aanzetten van FIPS doe je dan als volgt:
https://access.redhat.com..._Processing_Standard.html

Als je Apache op een Windows 2008/2012 server draait moet je OpenSSL opnieuw compileren. Korte beschrijving: http://www.apachelounge.com/viewtopic.php?t=6197 (zie 2e reactie van mijn kant).

Apache config als jouw OpenSSL met FIPS is gebouwd:

SSLProtocol -all +TLSv1.2 +TLSv1.1 +TLSv1
SSLCipherSuite AES256:AES128:3DES:HIGH
SSLHonorCipherOrder On
SSLFIPS on

Deze config ondersteunt nog IE8 op XP. Zie
https://www.ssllabs.com/s...ie8xp.sessiondatabase.net

Als je IE8 op XP wilt laten vallen, kun je die 2e regel vervangen door
SSLCipherSuite HIGH:!3DES:!AES128
Dan krijg je zo iets als
https://www.ssllabs.com/s...tml?d=sessiondatabase.net

Edit: SSLLabs is bezig om een Poodle check aan de server tests toe te voegen:
https://twitter.com/ivanristic/status/522351216831893504

Edit 2: Try the next version of SSL Labs here: https://dev.ssllabs.com
POODLE warnings, FALLBACK SCSV detection, SSL3 client detection.

Edit 3: OpenSSL FIPS 1.0.1j for Apache 2.4.10 Win32 VC9:
https://phpdev.toolsforre...j-fips-2.4.10-x86-vc9.zip

Edit 4: dev.ssllabs.com correctly detects TLS_FALLBACK_SCSV
https://dev.ssllabs.com/s...tml?d=sessiondatabase.net

[Reactie gewijzigd door Jan-E op 15 oktober 2014 22:49]

Voor firefox heeft mozilla een extensie om SSL 3.0 uit te zetten

https://addons.mozilla.or...ddon/ssl-version-control/

Als ik de test uitvoer via Chrome Canary Version 40.0.2189.0 canary (64-bit) dan zegt ie dat ik nog steeds vulnerable ben.

Het mooie is dat in Internet Explorer 8 de test faalt (ik krijg geen enkel plaatje te zien). Er lijkt dus of iets fout te gaan met het laden van het plaatje, of de browser is non vulnerable maar ondersteunt de onerror niet.

Dit is overigens "de test"

<img style="margin-left: 50px;" src="https://sslv3.dshield.org/vulnpoodle.png" onerror="this.src='nonvuln.png'" width="height=400" id="image">

[edit]
@the_stickie
Inderdaad prima test, behalve dat ik het plaatje niet te zien krijg terwijl in mijn internet explorer settings wel staat "use SSL 3.0". Lijkt me meer een bug in IE, maar dat maakt de test wel minder effectief.

@Armin, dank voor de duidelijke toelichting! Het downgrade stuk heeft me waarschijnlijk 'gered' (heb overigens W7)

[Reactie gewijzigd door pietje63 op 15 oktober 2014 18:51]

Prima test als de server die het plaatje aanbiedt enkel ssl 3.0 onderteund

Je draait op XP of Vista?

Op XP heb je enkel de keuze om SSL 3.0 te gebruiken in combinatie met IE8 en ben je dus altijd kwetsbaar. Nu is XP gebruiken uberhaupt geen goed idee

Op Vista en hoger kun je SSL 3.0 uitzetten en ben je met IE8 dus niet kwetsbaar.

Echter, aangezien Internet Explorer niet kwetsbaar is voor het downgrade deel van de POODLE attack (anders dan Google Chrome) zou je zélfs al zet je SSL 3.0 niet uit, je nog steeds nauwelijks vatbaar zijn op Vista.

Deze test-site test namelijk enkel of je SSL 3.0 gebruikt en niet het downgrade deel van de aanval. Zonder die tweede component is deze aanval echter zo goed als onmogelijk want zal je browser nooit SSL 3.0 gebruiken.

Op Google Chrome kan een aanvaller namelijk de browser dwingen te downgraden naar SSL 3.0 ook al ondersteunen zowel client als server veiligere protocollen. Op Internet Explorer kan een aanvaller dat niet. Het is deze combo die het lek ernstig maakt.

Je browser ondersteund nog SSLv3, het zal starten met websites (twitter, google etc) en de browsers volgen later. Lees ook http://googleonlinesecuri...es-exploiting-ssl-30.html waarin ze aangeven het nog te testen en binnenkort in chrome SSLv3 uit te zetten.

In the coming months, we hope to remove support for SSL 3.0 completely from our client products.

[Reactie gewijzigd door randomnumber op 15 oktober 2014 08:21]

98% van de servers ondersteund nog ssl3 (okt 2014, van 200.000 sites)

https://www.trustworthyinternet.org/ssl-pulse/ (3de rij, 2de kolom)

Dat zal hopelijk snel minder worden.

[Reactie gewijzigd door apokalypse op 15 oktober 2014 08:24]

Voor bepaalde platformen en applicaties zal ssl 3.0 nu wel heel snel uitgefaseerd worden (denk aan de financiële wereld). Maar er zijn vast genoeg beheerders die het risico bij hun gebruikers willen leggen. Maw die ssl 3.0 enabled laten om geen gebruikers te verliezen. Dat hun cookies dan gepikt worden "is hun eigen schuld; ze hadden maar een recente of correcter geconfigureerde browser moeten gebruiken."

98% van de servers ondersteund nog ssl3 (okt 2014, van 200.000 sites)

https://www.trustworthyinternet.org/ssl-pulse/

Dat zal hopelijk snel minder worden.

Maakt niet veel uit zodra browsers standaard de ondersteuning voor SSL 3.0 uitschakelen. Uit her bericht:

Google heeft zelf alvast ssl 3.0-ondersteuning uit Google Chrome verwijderd. Ondanks dat ssl 3.0 volgens Mozilla nog steeds voor miljoenen transacties wordt gebruikt, wordt de ondersteuning in Firefox 34 ook uitgefaseerd.

Als de browser geen ondersteuning heeft voor SSL 3.0, dan kan een aanvaller ook geen downgrade attack gebruiken.

Voor eigen websites krijg ik een 'A+' in Qualys SSL Test, maar dat komt omdat ik het mij kan veroorloven om oudere browsers te negeren. Als jouw systeem niet up-to-date is, dan maak je maar geen verbinding met mijn server. Dat is natuurlijk geen oplossing voor webwinkels, banken en andere financiële instellingen, die vaak wel afhankelijk zijn van klanten met verouderde software.

Ik denk overigens dat de impact van deze kwetsbaarheid wel meevalt. Ja, je kan een rogue access point o.i.d. opzetten, maar hoe groot is dan de daadwerkelijke reikwijdte van aantal slachtoffers en succesvolle aanvallen? In de toekomst voorzie ik het nog wel dat steeds meer apparatuur (vooral van zakelijke gebruikers) altijd een actieve VPN verbinding krijgt naar huis om de kans op succesvolle aanvallen te verkleinen.

"Dat is natuurlijk geen oplossing voor webwinkels, banken en andere financiële instellingen, die vaak wel afhankelijk zijn van klanten met verouderde software."

Toch is dat de omgekeerde wereld.
Zeker bij banken; als veiligheid in t geding komt dan moeten "afhankelijke" partijen maar zorgen dat ze hun shit op orde krijgen.
Ook een doorn in t oog hoeveel bedrijven op achterlijk oude versies van IE zitten waardoor je soms door de meest belachelijke hoepeltjes moet springen om alles en iedereen maar blij te houden; soms denk ik dat het misschien eens een impuls zou geven om gewoon te zeggen "genoeg is genoeg, zoek t zelf maar uit."

Stle je voor dat bijv heartbleed niet te fixen zou zijn voor een bank omdat anders bij een grote afnemer de boel niet meer goed zou werken. Dat is gewoon gestoord.

Er zit een Security vs Usability aspect aan natuurlijk, maar het wordt vaak te gek voor woorden als je ziet wat een enorm verouderde troep er soms geactiveerd blijft door bedrijven, en soms klanten, met gestoord verouderde software die eisen dat t compatible blijft...

Fuck it, laat ze maar eens upgraden. Veiligheid wordt al te lang ondermijnd door dat soort onzin.
Ik ben me er terdege van bewust dat in sommige gevallen, vooral op interne netwerken die geschakeld zijn aan legacy meuk, dat soms makkelijker gezegd is dan gedaan... Maar waar trek je de lijn?

Het grootste argument is vaak "maar de kosten...", en denken dan niet aan "maar de kosten als t gekraakt wordt..."
Meh. /rant.

[Reactie gewijzigd door WhatsappHack op 15 oktober 2014 09:14]

Het grootste argument is vaak "maar de kosten...", en denken dan niet aan "maar de kosten als t gekraakt wordt..."

De afweging zekere kosten versus theoretische kosten is ook niet zo'n moeilijke. Dan neemt men het risico en noemt men dat "ondernemen".

Gelukkig ondersteunt nagenoeg alles ook al jarenlang TLS 1.0, dus kan je gerust SSL 3.0 uitschakelen in de settings van je browser of applicatie (bijv. Java settings panel). Kennelijk moet het eerst ernstig stuk gaan voordat een dergelijk oud protocol wordt uitgefaseerd.

Als ik het allemaal goed volg op Twitter (en ook hier in het artikel) is het vooral een probleem met oude IE gebruikers, blijkbaar zijn dat er nog zoveel dat het commercieel gezien pijn doet die af te sluiten.

is het vooral een probleem met oude IE gebruikers

plus browsers die kwetsbaar zijn voor een downgrade aanval. Dat is namelijk wat deze lek zo ernstig maakt. Google Chrome is kwetsbaar vandaar het Google bericht. Echter Internet Explorer (wanneer draaiend op Vista of hoger!) is bijvoorbeeld niet kwetsbaar, ook al zou je SSL 3.0 aan laten staan.

Een moderen browser zal immers ongeacht of het SSL 3.0 ondersteunt normaal een TLS 1.x variant gebruiken. Google heeft echter met de beste bedoelingen een downgrade mechanism ingevoerd als de connectie faalt. Dit was omdat vroege TLS 1.2 implementaties buggy waren. Gevolg is dat een MITM-aanvaller enkel de connectie van Google Chrome met een server hoeft te verstoren, en de browser probeert opnieuw met TLSA 1.1. De anvaller verstoort het opnieuw, etc en zo kun je een moderne Chrome dwingen op SSL 3.0 te gaan verbinden.

Internet Explorer is hiervoor niet kwetsbaar. Firefox geloof ik weer wel.

Het was al langer bekend dat Google hier een potentieel veiligheidslek had, maar tot nu toe was er geen bekende methode om dit te misbruiken.

Overigens is er dan nog geen panniek, want deze POODLE attack is eigenlijk enkel bruikbaar in combinatie met encrypted cookies. Een gewone connectie met je bank, zelfs over SSL 3.0, is in principe veilig. Dit omdat de aanval simplistisch gesteld als volgt gaat:

- aanvaller plaatst zich tussen jou en de server
- aanvaller verstoort indien nodig de TLS handshake en dwing een SSL 3.0 connectie af
- aanvaller hoopt dat er een CBC cypher gebruikt wordt en geen RC4. Anders faalt de aanval. (Maar RC4 is weer kwetsbaar voor een andere aanval.)
- aanvaller onderschept het cookie (wat hij niet kan lezen), en vervangt enkele bytes, en stuurt deze door naar de server
- aanvaller kijkt naar de het gedrag van de server en hoopt dat er een merbaar verschil is tussen een correct gedecodeerd cookie en corrupt cookie. Zo ja, heeft hij 1 byte kunnen decrypten.
- herhaal de vorige stap met een andere stukje vervangen data in het cookie tot je het hele cookie ontsleuteld hebt.

Het is een beetje een technisch verhaal, maar CBC cyphers gebruiken vaste blok-grootes. Als de data die je wilt encrypten kleiner is, vult hij het op met 'padding'. Omdat in SSL 3 er geen afspraken zijn over hoe dat moet, kan een ontvanger niet controleren of de padding correct is. De ontvanger kan enkel controleren of de decryptie lukt.

Een aanvaller kan met enige gericht gokken proberen het laatst blokje zo te vervangen dat de decodering lukt omdat het aantal padding bytes correct is. De aanvaller is er dan nog lang niet, maar er lekt zo wel informatie waarmee men misschien verder kan gaan. Echter 'misschien' kunnen decoderen is eng genoeg om geen risico te willen nemen.

Bij TLS 1.0 en hoger is de paddig beter definieerd en faalt deze aanval daarom.


Het advies SSL 3.0 uitzetten is overigens verder een goed advies. In draai zelf zo al ruim een jaar en heb nog maar 2 sites gevonden die SSL 3.0 nodig hadden. Bij IE kun je dan tijdens 'runtime' SSL 3 even aanzetten, die site bezoeken in een apart tabje, en dan weer uitzetten. Firefox (config optie) en Chrome (command line) is wat lastiger omdat het de browser restarten vereist, maar ook dat is waarschijnlijk niet zo vreselijk problematisch.

Als je https://www.modern.ie/en-us/ie6countdown moet geloven zou het voor de meeste (Westerse) landen niet uit mogen maken.

Ik meen me te herinneren dat IE6 wel TLS 1.0 ondersteunt, maar dat je het zelf aan moet zetten.

Edit: nu het eea wat duidelijker is, Windows XP ondersteunt dus alleen RC4 en 3DES voor SSL/TLS-verbindingen (en IE leunt op de 'secure channel' library van Windows) en die twee zijn ook al achterhaald.

[Reactie gewijzigd door Rafe op 15 oktober 2014 10:22]

Weet iemand toevallig of dit ook al bekend is bij Microsoft? Daarmee bedoel ik, hebben zij hier al een bericht / fix over gepubliceerd?

[Reactie gewijzigd door iFap op 15 oktober 2014 10:26]

Zie de KB om SSL 3.0 uit te schakelen
http://support.microsoft.com/kb/245030

Dit is van 2013...

[Reactie gewijzigd door iFap op 15 oktober 2014 10:58]

Zie het blokje "Applies to".
Het is dus wel degelijk nog relevant.

Dit is de goede:
https://technet.microsoft...ary/security/3009008.aspx

Bedankt. Echter geldt dit voor de clients alleen. Microsoft geeft hier namelijk aan dat je door middel van een GPO SSL v3.0 kunt uitschakelen. Ik wil eigenlijk weten hoe we dit server side kunnen oplossen. In het artikel wordt dit namelijk niet genoemd.

voor users om het uit te zetten in chrome: intellingen > proxy instellingen wijzigen > tab advanced > en vink uit.

voor firefox die het in versie 34 standaard uitzet( 25november ):
To modify:
(1) In a new tab, type or paste about:config in the address bar and press Enter. Click the button promising to be careful.

(2) In the Search box above the list, type or paste tls and pause while the list is filtered

(3) To disable SSL3 and requires TLS of one flavor or another, double-click security.tls.version.min and enter the desired value:

0 = SSL 3.0 okay
1 = at least TLS 1.0
2 = at least TLS 1.1 See WARNING below

(4) To disable TLS of one flavor or another, double-click security.tls.version.max and enter the desired value:

0 = up to SSL 3.0
1 = up to TLS 1.0
2 = up to TLS 1.1 See WARNING below

WARNING: According the following article, selecting TLS 1.1 may prevent connections to older servers from working: http://kb.mozillazine.org/Security.tls.version.

IE: stond die bij mij al uit. controleer of het vinkje SSL3.0 uitgevinkt staat bij instellingen > tab advanced


uiteindelijk test:
https://zmap.io/sslv3/schijnt niet goed te werken volgens Soldaatje
https://www.ssllabs.com/ssltest/viewMyClient.html

[Reactie gewijzigd door dezejongeman op 15 oktober 2014 10:17]

Die test zegt dat ik kwetsbaar ben, terwijl ik hem op 1 gezet heb.
security.tls.version.max lijkt me niet nodig om in te stellen, staat al op 3.
De test poodletest.com zegt dat ik niet kwetsbaar ben.
Deze test zegt dat ik nog steeds ssl3 heb: https://www.ssllabs.com/ssltest/viewMyClient.html, ok die test klopt niet.
Andere sites zeggen nu dat het wel uit staat.

[Reactie gewijzigd door Soldaatje op 15 oktober 2014 09:47]

Apart, als ik https://www.poodletest.com/ opvraag met Firefox 33.0 zegt hij dat ik niet kwetsbaar ben, terwijl ik niets heb aangepast aan m'n SSL settings, en ook die plugin niet heb geïnstalleerd. Goed nieuws natuurlijk, maar dat klopt toch niet?

Voor IE en Chrome geeft die site bij mij wel aan dat ze kwetsbaar zijn.

De test kijkt enkel of je SSL 3 aan heft staan, hetgeen een beetje een misleidende methode is om je kwetsbaarheid te testen.

Je bent namelijk kwetsbaar als
- of de client enkel SSL 3 ondersteunt
- of de server enkel SSL 3 ondersteunt
- of de client kwetsbaar is voor een downgrade aanval.

Internet Explorer op XP is dus kwetsbaar (enkel SSL 3), maar Internet Explorer op Vista en hoger in de praktijk niet (geen downgrade mogelijk), ook al geeft de website aan van wel.

Chrome is echter altijd kwetsbaar.

Firefox weet ik niet, maar wellicht staat SSL 3.0 toch stiekem uit? Zo niet, is er kans dat het en 'false negative' is en de connectie enkel faalde.

Ik neem aan dat een browser default de nieuwere protocollen gebruikt indien beschikbaar, ook al is SSL 3.0 ook nog bij client en server beschikbaar?

Ja, maar het is blijkbaar mogelijk een lagere versie te forceren als aanvaller.

Ja maar enkel op sommige browsers.