Android- en Apple-gebruikers kwetsbaar door oude backdoor in ssl

Gebruikers van Android, iOS en Safari op OS X zijn kwetsbaar voor een nieuw gevonden bug in ssl-implementaties. Het gaat om een backdoor die door de Amerikaanse overheid is ingebouwd en kan worden misbruikt. Een aanvaller kan een lager niveau van encryptie afdwingen.

In de jaren negentig verbood de Amerikaanse regering bedrijven nog om buiten de Verenigde Staten sterke encryptie aan te bieden. Daardoor mochten rsa-encryptiesleutels in het buitenland bijvoorbeeld niet meer dan 512bit zijn, zodat de Amerikaanse geheime diensten de communicatie relatief eenvoudig konden kraken. Inmiddels is dat al jaren niet meer zo, maar de backdoor blijkt nog steeds te misbruiken, ontdekten onderzoekers van het Franse onderzoeksinstituut Inria en Microsoft Research.

Ondersteuning voor het lagere niveau van beveiliging blijkt nog steeds aanwezig te zijn in de ssl-stack van Chrome op Android. Ook iOS-telefoons zijn kwetsbaar, evenals Safari op OS X. Ook BlackBerry 10 zou kwetsbaar zijn, evenals sommige versies van Internet Explorer op Windows Phone. De desktopversie van Chrome is niet kwetsbaar, evenals Firefox en Internet Explorer.

De kwetsbaarheid blijkt al jaren aanwezig te zijn, maar bleef jaren onderbelicht. Bij het maken van een ssl-verbinding wordt vanuit de kwetsbare browsers niet actief om dit lagere niveau van beveiliging gevraagd, maar een server kan er wel om vragen. Een aanvaller zou zich daarbij voor kunnen doen als een server en de lagere graad van beveiliging forceren. In dat geval wordt de sleutel van slechts 512bit zonder waarschuwing geaccepteerd.

Rsa-sleutels van 512bit zijn relatief eenvoudig te kraken: volgens cryptograaf Matthew Green van de Johns Hopkins University kan een aanvaller daarvoor bijvoorbeeld de EC2-dienst van Amazon gebruiken. Om één certificaat te kraken is circa honderd dollar en 7,5 uur aan tijd nodig. Hoewel dan pas één certificaat is gekraakt, wordt hetzelfde certificaat door een website in de praktijk vaak aan meerdere bezoekers geserveerd. Standaard maakt Apache bijvoorbeeld een nieuw certificaat aan bij het opstarten van de server, dat aan alle bezoekers wordt geserveerd.

Een aanvaller zou dan wel nog een man in the middle-aanval moeten kunnen uitvoeren voordat hij het beveiligingsprobleem kan misbruiken. Daarvoor moet hij controle over de verbinding van een slachtoffer hebben, bijvoorbeeld door een vervalste wifi-hotspot op te zetten. Ook moeten websites ondersteuning hebben voor de 512bit-rsa-sleutels; uit een scan van de Universiteit van Michigan blijkt dat meer dan een derde van de websites dat heeft. Daaronder waren onder meer de websites van de FBI en het Witte Huis, die inmiddels zijn gepatcht. De website van de NSA is nog steeds vatbaar voor de aanval.

Gebruikers kunnen op de website FreakAttack.com zien of hun apparaat vatbaar is voor de aanval. De bug is aanwezig in SecureTransport van Apple en OpenSSL, dat in Android wordt gebruikt. Apple heeft al aangegeven volgende week een update te willen uitrollen. OpenSSL is al gepatcht. De bèta van Chrome voor Android heeft al een patch aan boord.

Privacy-activisten stellen dat de bug een voorbeeld is van hoe een overheidsbackdoor gebruikers onveiliger kan maken. Ze pleiten al langer tegen dergelijke backdoors. "We zien dat dit soort problemen uiteindelijk alle gebruikers treffen", zegt privacy-activist Cristopher Soghoian van de American Civil Liberties Union tegenover The Washington Post.

Vorig jaar 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.

Door Joost Schellevis

Redacteur

04-03-2015 • 08:07

122 Linkedin

Submitter: CabezaDelZorro

Lees meer

Reacties (122)

122
119
98
2
0
4
Wijzig sortering
Anoniem: 616000
4 maart 2015 08:12
Die SSL-backdoor lijkt een beetje op die malware van Lenovo, ook daar werd het mogelijk gemaakt om de SSL verbinding uiteindelijk te spoofen. Vooral dat dit BEWUST lijkt te zijn ingebouwd is zeer kwalijk.
Vooral dat dit BEWUST lijkt te zijn ingebouwd is zeer kwalijk.
Er was een tijd in de geschiedenis dat de VS vond dat al te geavanceerde crypto algoritmes het land niet mochten verlaten, om er voor te zorgen dat vijanden van het Westen (we praten hier over het Soviet tijdperk, zeg maar) op een vrij eenvoudige, legale manier aan deze algoritmes kon komen wat problematisch was voor de nationale veiligheid (De NSA was in die tijd namelijk ook al actief, alleen waren de rekencentra wat minder krachtig, zeg maar ;) ). Hierdoor was echter wel de crypto van elk land buiten de Verenigde Staten (ook die van "vrienden" en "bondgenoten") kwetsbaarder dan die van de Verenigde Staten zelf.

Dat we nu hier legaal gebruik mogen maken van PGP met sterke sleutels en SSL certificaten met een sleutel > 1024 bits is dus vooral te danken dat de Verenigde Staten medio jaren 90 geen grote bedreiging meer zag door de val van het communisme, en zich op het wereldtoneel neer kon zetten als absolute supermacht. Hierdoor hebben ze de krachtigere encryptie destijds vrijgegeven.

Als dit niet was gebeurt hadden we hier nog steeds encryptie gehad met zwakkere sleutels zoals de genoemde van 512 bits. Deze "bug" is dus feitelijk een overblijfsel van die zwakkere crypto, iets wat vanwege legacy redenen in vrijwel elk crypto subsysteem in elk besturingsysteem is achtergebleven (Net zoals de standaard -zwakkere- suite aan cipher algoritmes, overigens -- mocht je een met SSL beveiligde webserver onder beheer hebben dan is het vrij slim om daar ook even kritisch naar te kijken).

[Reactie gewijzigd door mindcrash op 4 maart 2015 09:26]

Nou, wat er op een gegeven moment gebeurde is dat er boeken geprint werden met broncode. Zo is de sterke versie van PGP de VS uit gekomen. Het exporteren van een dergelijk boek was namelijk wel toegestaan. Aan de andere kant van de plas werd dat boek dan weer gescanned en met behulp van OCR omgezet in code. Omslachtig, maar het werkte wel.
Nou, wat er op een gegeven moment gebeurde is dat er boeken geprint werden met broncode.
Ik heb in '99 amerikanen gesproken met sourcecode van het blowfish algoritme op hun t-shirt geprint. :)
Wat ik me dan afvraag: is er in Europa dan geen alternatieve versleuteling die daar niet aan gebonden is ontwikkeld? Ik neem aan dat er hier ook knappe koppen zitten.
AES. Ook wel bekend onder de naam Rijndael en van oorsprong Europees.
Anoniem: 442208
@alt-924 maart 2015 11:03
Maar AES is net als alle encryptie voorgangers beperkt tot iets wat binnen afzienbare tijd door de supercomputers te kraken viel, en dus ook hier heeft de "US", in dit geval het instituut NIST bepaalt hoe sterk het algortime is. AES-512 was daarom vroeger (misschien nog steeds wel) ook verboden, en verder heeft de NIST bepaalt hoe vaak er gelooped moet worden. Daarnaast is het voor bedrijven niet interessant om een encryptie te gebruiken die in de US verboden is want dan kun je het product daar niet produceren en niet verkopen. Ja, AES komt uit de EU, maar de US heeft het tot standaard gemaakt.

Zie ook hoe AES tot stand is gekomen:

http://en.wikipedia.org/w...cryption_Standard_process
Maar AES is net als alle encryptie voorgangers beperkt tot iets wat binnen afzienbare tijd door de supercomputers te kraken viel, en dus ook hier heeft de "US", in dit geval het instituut NIST bepaalt hoe sterk het algortime is. AES-512 was daarom vroeger (misschien nog steeds wel) ook verboden, en verder heeft de NIST bepaalt hoe vaak er gelooped moet worden. Daarnaast is het voor bedrijven niet interessant om een encryptie te gebruiken die in de US verboden is want dan kun je het product daar niet produceren en niet verkopen. Ja, AES komt uit de EU, maar de US heeft het tot standaard gemaakt.

Zie ook hoe AES tot stand is gekomen:

http://en.wikipedia.org/w...cryption_Standard_process
Hoe kom je er nou weer bij dat "aar AES is net als alle encryptie voorgangers beperkt tot iets wat binnen afzienbare tijd door de supercomputers te kraken viel"? Heb je daar een bron voor?

Volgens de wikipedia pagina die jij zelf aanhaalt:
NIST won praises from the cryptographic community for the openness and care with which they ran the standards process. Bruce Schneier, one of the authors of the losing Twofish algorithm, wrote after the competition was over that "I have nothing but good things to say about NIST and the AES process".
In tegenstelling tot de standaardisatie van SHA-3 heeft de NIST niets gedaan wat op weerstand vanuit de cryptografie community heeft geleid. Dat tesamen met het feit dat er geen aanvallen bekend zijn op de voleldige versie van AES maakt het nog steeds een zeer goede keuze.
Heb je misschien een bron voor het kunnen kraken van AES binnen afzienbare tijd door supercomputers?

Bij correct gebruik van AES heb je een key welke 2^256 mogelijkheden heeft. Gemiddeld genomen heb je de sleutel gevonden bij de helft van die mogelijkheden, dus 2^255 pogingen.

De snelste supercomputer op dit moment is de Tianhe-2 supercomputer met 33.86 petaflops. Deze machine zal voor het uitproberen van 2^255 mogelijkheden langer dan 5.4183479e52 jaar doen.

Ik vraag me door deze berekening dus ook af of jou claim wel klopt en daarom zou ik daar graag een bron van willen zien.
wat is afzienbare tijd... alles is relatief..
als de quantum computer eenmaal een feit is, dan lach je hierom.. kwestie van seconden...
Ik denk dat je in de war bent met een asymmetrische encryptie als RSA waar quantum computers theoretisch snel de encryptie kunnen kraken.

Bij een symmetrich algoritme als AES heb je echter niet dezelfde zwakte als bij RSA en kan je door middel van Grover's algoritme een quantum conputer gebruiken om een cypher block via brute-force op te lossen in 2n/2 stappen.

Dat betekend dat bij gebruik van AES-256 er 2^128 mogelijkheden overblijven.

In dat geval zal de quantum computer (er van uitgaande dat deze even snel gemaakt kan worden als de Tianhe-2 supercomputer) er gemiddeld 159.230.934.591.738 jaar over doen om een AES-256 sleutel te vinden.

Een flink stuk minder maar nog steeds verre van een 'kwestie van seconden'.
Wat ik me dan afvraag: is er in Europa dan geen alternatieve versleuteling die daar niet aan gebonden is ontwikkeld? Ik neem aan dat er hier ook knappe koppen zitten.

Goede vraag. japan, de Sovjets en Zuid-Korea hebben alle 3 hun eigen encryptie ontwikkeld voor HTTPS. Europa gek genoeg niet. (Voor militaire toepassingen wel uiteraard.)

Wél is het zo dat voor Amerikaanse multinationals deze wetten zo remmend werkten dat het soms makkelijker was om een stuk software in Europa te ontwikkelen dan in de USA en dan te exporteren. Dat is ook waarom deze wet afgeschaft is. Amerikaanse multinationals hebben gelobbied. Onder die 'lieve' Clinton kreeg men geen gehoor, en die 'verschrikkelijke' :+ Bush wel.
Er was een tijd in de geschiedenis dat de VS vond dat al te geavanceerde crypto algoritmes het land niet mochten verlaten, om er voor te zorgen dat vijanden van het Westen (we praten hier over het Soviet tijdperk, zeg maar) op een vrij eenvoudige, legale manier aan deze algoritmes kon komen wat problematisch was voor de nationale veiligheid (De NSA was in die tijd namelijk ook al actief, alleen waren de rekencentra wat minder krachtig, zeg maar ;) ). Hierdoor was echter wel de crypto van elk land buiten de Verenigde Staten (ook die van "vrienden" en "bondgenoten") kwetsbaarder dan die van de Verenigde Staten zelf.
Dat speelde ook bij Motorola en daarvan hadden de voor export bestemde toestellen per serie allemaal dezelfde sleutel waarmee het gsm-signaal werd opgebouwd terwijl andere merken zoals de Europese (Nokia, Siemens, ...) eigen sleutels hadden.
Dat betekende ook dat als je toestel gestolen was, je een Motorola niet kon laten blokkeren (je maakt dan immers de gehele serie van 100.000 of meer exemplaren onbruikbaar) terwijl dat met een ander merk theoretisch wel kon.

Prepaid bestond toen nog niet en de kosten van misbruik van een gestolen gsm konden makkelijk duizenden guldens bedragen. Darom raadde ik destijds iedereen af om Motorola of andere toestellen van USA-makelij te kopen.
Interessant om op te merken is inderdaad bijvoorbeeld dat OpenBSD vanaf 2000 al cryptografie vanuit Canada exporteert, omdat het vanuit daar wel mag.

Zie http://en.wikipedia.org/wiki/OpenBSD_Cryptographic_Framework
Het is onzin dat we de "sterke" encryptie van nu te danken hebben aan de NSA.

De NSA wordt nu - begrijpelijk - als 'vrijand' gezien, maar het is toch handig iets verder terug te kijken dan enkel 2013. De NSA heeft verschillende functies en veel ervaren cryptograven in dienst. Nog steeds wordt door vriend en vijand erkent, dat men daar kennis heeft die daarbuiten soms gewoon geheel niet bestaat.

Dat verschil begint wel minder te worden, maar ten tijde van het bedenken van bijvoorbeeld standaarden als AES en ECDHE was het heel gebruikelijk de NSA erbij te betrekken simpweg omdat er geen enkele andere organisatie op aarde is die zoveel kennis had. Plus dat men ook bij de NSA belang heeft bij het hebben van sterke algorithmens omdat immers de Amerikaanse overheid die zélf ook gebruikt.

Standaarden als AES en ECDHE hebben we dus wel degelijk mede te danken aan de NSA.
Dit lijkt er in geen geval op. Het is in tegenstelling tot wat er beweert wordt ook niet een 'echte' backdoor. Een backdoor wordt stiekem ingebouwd waardoor specifieke personen toegang krijgen tot een systeem. In dit geval was er een bekend export verbod op sterke encryptie en zoals het artikel ook gewoon schrijft was het bekend dat de RSA-key maar 5121 bytes groot mocht zijn. Ik vind het dan ook een beetje een suggestieve titel omdat backdoor een nogal beladen term is.

Er is nu ontdekt dat om wat voor reden dan ook bij een aantal systemen deze beperking nog oproepbaar te zijn onder bepaalde omstandigheden. Dát zou op aanvraag van de NSA kunnen zijn gebeurd maar gezien de vele mogelijkheden die ze al hadden om ssl te kraken, die ook nog eens makkelijker waren, lijkt dit eerder iets wat men in de software industrie ook wel een bug noemt. Na het toestaan van de betere keys zou deze code gewoon verwijderd moeten zijn, dat is deels gebeurt maar duidelijk niet grondig genoeg.
Anoniem: 616000
4 maart 2015 08:11
Ik snap niet dat mensen en bedrijven nog massaal voor amerikaanse software kiezen met bewust backdoors erin gebouwd.
En wat is het alternatief? Alles van Microsoft, Google en Apple vallen af.

Er gaan ongetwijfeld wat fanboys over vallen, maar Linux en een open source office pakket is voor de grote massa in het gunstigste geval een enorme stap terug in gebruiksgemak en productiviteit en hoogst waarschijnlijk gewoon een brug te ver.
In dit geval blijkt Microsoft spul dus wel veilig :+
Mijn Windows Phone 8.1 is niet vulnerable, net zoals waarschijnlijk alle Windows Phone 8 versies.

Windows 10 is een developer preview wat een pre-bèta versie is, is niet publiekelijk/ algemeen beschikbaar.
Anoniem: 118226
@Devian4 maart 2015 09:17
Geen idee. Ik heb windows spul. Maar is ook totaal niet relevant voor dit gedeelte van de discussie. De stelling van doorlopert is dat mensen eens moeten ophouden met kopen van amerikaanse software want daar zitten bewust backdoors ingebouwd. En dan komen een stelletje fanboys langs om hun geliefde OS te verdedigen. Aardig, maar niet relevant.
Mijn Lumia 520 met WP 8.1 wil de site niet laden. Is dit een goed teken? :X
Dat is een alpha versie, en zegt dus maar heel weinig over "Microsoft spul"
Helaas, Windows 10 is nog niet uit en telt niet mee. De huidige releases van Windows Phone 8.1 zijn niet kwetsbaar.
"Er gaan ongetwijfeld wat fanboys over vallen, maar Linux en een open source office pakket is voor de grote massa in het gunstigste geval een enorme stap terug in gebruiksgemak en productiviteit en hoogst waarschijnlijk gewoon een brug te ver."

Ik val er niet perse over hoor, maar waarom is het een stap terug in gebruiksgemak en productiviteit...? Is gewoon een kwestie van wennen.
Windows wordt mensen met de paplepel vanaf de basisschool ingegoten, dan is t logisch dat t ff slikken is als je opeens een compleet ander besturingsysteem installeert.

Maar een distro speciaal en vrijwel exclusief voor totale noobs, zoals Ubuntu, vangt dat best redelijk op. :) Daar is men zo aan gewend. Alsof je van iOS naar Android overstapt of vice versa: tis ff wennen, maar het vermindert in geen enkele mate je productiviteit.

Daarnaast draait Microsoft Office gewoon op Linux, maar dat terzijde :P
Linux is allang niet meer dat OS waar je perse de terminal nodig hebt om zaken te regelen. ;) (Al is de terminal wel verdomd handig en snel... ;))
Ik gebruik op mijn werk linux als ontwikkelplatform. Overstappen van Windows/OSX is gedeeltelijk wennen, maar Windows/OSX ligt echt nog mijlen ver voor op gebruiksgemak. Dat is nou eenmaal zo. Linux is prima, maar je hebt meer kennis nodig en een hoop dingen werken gewoon niet zo makkelijk. (al ben ik zelf ook nogal van de terminal. Vandaar dat ik thuis OSX heb. Uiterlijk en gemak van een gelikte GUI, en onderwater de kracht en een unix variant).

Office is in deze discussie uitgesloten, want gemaakt door een amerikaanse producent, en de stelling was om software van amerikaanse producenten links te laten liggen.
"Ik gebruik op mijn werk linux als ontwikkelplatform. Overstappen van Windows/OSX is gedeeltelijk wennen, maar Windows/OSX ligt echt nog mijlen ver voor op gebruiksgemak. Dat is nou eenmaal zo. Linux is prima, maar je hebt meer kennis nodig en een hoop dingen werken gewoon niet zo makkelijk."

Oneens. Dat is puur persoonlijke ervaring, niet of het ook daadwerkelijk zo is. Het is echt enkel wat je gewend bent en wat je als kind geleerd hebt waardoor t makkelijk lijkt.

Ik heb nu jaren nauwelijks Windows gebruikt, elke keer als ik met Windows 8 moet werken heb ik werkelijk geen flauw idee hoe die GUI werkt. Ik word er knettergek van, kan de helft niet vinden, hoe het in elkaar zit irriteert me enorm, etc...
Waarom? Ik ben het totaal nog niet gewend.
Met Windows 7 kan ik prima overweg en ik kan alles vinden tot op diep niveau in 't OS, maar bij Windows 8 moet ik t hebben van CMD... Anders kom ik er niet uit. ;)

Voor mij is Linux dus vele malen gebruiksvriendelijker dan Windows.
Ik denk dat er bijna geen verschil zit in de overstap maken tussen Windows 7 en Windows 8, of Windows 7 en een Linux distro... Bij beiden moet je er eerst helemaal aan wennen, en dan is nog maar de vraag welke t makkelijkst werkt. ;)

"Dat is nu eenmaal zo" is dus niet waar.
Dat ligt puur aan je persoonlijke ervaring. OSX vind ik trwns ook helemaal niet zo handig, maar ook dat is een kwestie van smaak en gewenning... :) Snapje?

Helemaal geen Amerikaanse software gebruiken is vrijwel onmogelijk, trouwens. De NSA is ook een grote contributor aan open-source, hehe.

[Reactie gewijzigd door WhatsappHack op 4 maart 2015 10:58]

Ik denk dat het voor de meeste Windows 7 gebruikers heel makkelijk is om over te stappen naar Windows 8. De meeste mensen gebruiken Windows voor:
- office
- internet
- foto's kijken
- soms gamen.

Daarnaast vind ik(dit is dus persoonlijk) dat de verschillen tussen Windows 7 en 8 klein zijn. Afgezien van het startscherm staat veel nog op de zelfde plek.
Personlijk vind ik 8 ook fijner dan 7.

Maar ik zelf gebruik thuis Centos 7 zeker net zo fijn. Alleen ik moet er aan denken dat sommige applicaties niet werken op linux. Zoals office daar gebruik ik LibreOffice voor en dat vind ik toch een grote achteruit gang t.o.v. Microsoft Office.

Maar een OS keuze is heel persoonlijk en de massa blijft toch bij Windows aangezien daar hun applicaties op werken.
Ik gebruik zelf ook CentOS. Office draait er prima op :)
Je moet alleen zorgen dat de wine bottle 32bit draait in plaats van 64, en eenmalig een environment export doen. Zodra je dat gedaan hebt werkt alles, alleen moet je voor powerpoint nog even een DLL naar native zetten.

5 minuutjes werk, en het draait als een tierelier.
Mind you, ik gebruik wel 2010. 2013 vind ik barslecht.
Het grootste probleem van Linux (voor digibeten) is het gebrek aan homogeniteit. Installaties verschillen teveel van elkaar qua front end, je moet niet-technische mensen vooral niet té veel keuze geven. Het grootste gedeelte van de mensen kan daar niet mee omgaan, verschillende Linux distributies kunnen dan net zo verschillend overkomen als het verschil tussen Windows en een Linux smaak.

Dat onderliggend dezelfde kernel aanwezig is zegt de meerderheid helemaal niks, die weet namelijk alleen dat ze ergens in een hoek moeten beginnen met klikken en dat moet niet bij de buurman anders gaan.

[Reactie gewijzigd door Sfynx op 4 maart 2015 22:05]

eComStation? Kun je in ieder geval native je DOS applicaties draaien.
De dat is toch gewoon de nieuwe naam van de oude Microsoft en IBM meuk OS/2? Net zo Amerikaans dus. Linux is echt de enige serieuze optie.
Yup, was ook geen serieuze suggestie, daarom de opmerking om DOS applicaties te draaien. Verder grotendeels ontwikkeld door Mensys, uit Nederland.

En alsof Amerikaanse bedrijven geen vinger in de pap hebben bij Linux. De grootste betrokken partijen in Linux zijn net zo Amerikaans, Red Hat, Novell, Intel, IBM, MS, Ti, etc.
Red Flag Linux? :+

Vanuit Europa zou er een os op basis van Minix gemaakt kunnen worden, gemaakt op Nederlandse bodem. Maar er zal enorm veel in geinvesteerd moeten worden qua geld en mankracht om dat op het niveau van de andere OSen te krijgen.

Misschien is een mobiel OS op basis van Opera ook mogelijk (uit Noorwegen), zoals Firefox Mobile en Chrome OS. Waarschijnlijk gebruikt die ook voornamelijk Amerikaanse technologie (zoals de rendering engine, beveiliging etc), dus ook dat zal eerst weer vervangen moeten worden.
Zover ik heb begrepen zijn oudere OpenSSL libraries voor Linux ook kwetsbaar. Feitelijk is er dus geen alternatief, en moet je als eindgebruiker maar hopen dat de ontwikkelaar van je platform vlot met een patch komt.

Overigens heb ik inmiddels trouwens wel gehoord dat aan de client kant Firefox niet vatbaar is voor FREAK. Heb je dus een oudere Android telefoon dan zou ik onmiddelijk overschakelen naar Firefox. Gebruik je Windows, Linux of OS X en ben je nog aan het wachten op een patch voor IE, Chrome of Safari dan zou je in de tussentijd ook kunnen overschakelen naar Firefox. Alleen iOS gebruikers zijn om bekende redenen nogal fucked, hoog tijd dat Tim de deur van dat platform wat betreft web browsers op een iets grotere kier zet, omdat je daarbij momenteel volledig bent overgeleverd aan de grillen van Apple enerzijds, en blackhats anderzijds.)
Anoniem: 118226
@mindcrash5 maart 2015 07:11
IOS gebruikers kunnen nog Chrome of Opera gebruiken. (maar die heb ik niet op de kwetsbaarheid getest)
Ik vermoed dat dit komt door het gebrek aan alternatieven en de veel gehoorde reactie 'ik doe niets stouts dus ik heb niets te verbergen'.

Zorgwekkend is het wel want als de overheid een backdoor kan gebruiken dan kunnen andere criminelen dat ook.
Mensen zoals de Britse premier David Cameron willen encryptie helemaal verbieden :

http://www.theguardian.co...-banking-messaging-terror

Dat idee slaat nergens op, dan kun je wel stoppen met Internet in Groot-Britannië. Bankieren, online shoppen enz wordt onmogelijk.

Daarnaast is het inbouwen van backdoors natuurlijk vragen om problemen, zoals dit artikel noemt. Je laat toch ook geen schip te water met alvast een gat in de romp?
Dat idee slaat nergens op, dan kun je wel stoppen met Internet in Groot-Britannië. Bankieren, online shoppen enz wordt onmogelijk.
Je denkt toch niet dat cameron van plan is dat te verbieden voor machtige bedrijven en instanties. Dit is bedoeld voor het gepeupel.
Ik vermoed dat dit komt door het gebrek aan alternatieven en de veel gehoorde reactie 'ik doe niets stouts dus ik heb niets te verbergen'.
Maar ze zeggen wel "ik vindt het fijn dat mijn persoonlijke gegevens beveiligd verstuurd worden" - in dit geval was niemand zich bewust dat al deze browsers nog vatbaar waren voor dit probleem. Zelfde verhaal met dat Lenovo gebeuren een paar weken geleden. En 99% van de mensen zal ook hier helemaal niks van vinden of zelfs niet van horen, want het is 'harde' techniek.
Het is onbegrijpelijk dat mensen met geheimen nog steeds gebruik maken van het internet dat inherent onveilig is.

Het is ook onbegrijpelijk dat mensen zodanig naief zijn dat ze denken dat alleen Amerikaanse software hier last van heeft.
Je moet ervanuit gaan dat alle software en alle hardware backdoors heeft waardoor kwaad willenden jouw geheime informatie aan je kunnen ontfutselen.
Geheime informatie hoort niet op apparatuur thuis die is verbonden met een oncontroleerbaar medium.

Het is ook verwerpelijk dat men dit een bug noemt, terwijl het opzettelijk, by design, zo is gebouwd.
Anoniem: 616000
@Alfa19704 maart 2015 08:23
Zolang men dankzij deze functie zéér kwetsbaar is voor een MITM attack, is het framen van deze functie als 'future' in plaats van als gevaarlijke bug zeer verwerpelijk.

[Reactie gewijzigd door Anoniem: 616000 op 4 maart 2015 08:25]

Het is een bug omdat het al lang verwijderd had moeten zijn (en is, in de meeste browsers).
Welke keuze heb je dan nog, buiten Android, IOS, Windows, BlackBerry??
Anoniem: 604167
@wjn4 maart 2015 13:59
Firefox OS, Ubuntu Touch, Sailfish OS
Klopt, je hebt keuze uit één (1) Jolla GSM, waarop je dan Android apps moet draaien. Firefox Marketplace heeft nog steeds Beta status. Ubuntu is er ook nog steeds niet, wordt wel mooi, maar is er nog niet.
Anoniem: 604167
@wjn4 maart 2015 14:28
Op Sailfish OS hoef je helemaal niet perse Android apps te draaien. Er bestaan namelijk ook native QT apps. Het zijn er niet Super veel, maar ze bestaan.
Omdat de rest van de wereld niet in staat blijkt te zijn om fatsoenlijke software te maken. We klagen altijd wel over die Amerikaanse bedrijven, maar we doen er zelf niets aan. Het is niet de schuld van Apple/Microsoft/Facebook/Google/etc dat er geen Europese (of Afrikaanse/Aziatische/...) varianten zijn die net zo succesvol zijn.

Het staat iedereen vrij om vergelijkbare dingen te maken maar dan beter. En als het beter is dan kan je net zo succesvol zijn. Dat is het mooie van deze branche.
amerikaanse software kiezen met bewust backdoors erin gebouwd.

Anders dan Tweakers meld is het dan ook geen backdoor, en is die ook niet ingebouwd door de Amerikaanse overheid. Ik denk overigens dat de artikelschrijver de bug niet geheel goed begrijpt, en het dus geen sensatiezucht is van Tweakers, maar het is goed te beseffen wat hier aan de hand is. Het is namelijk een bug en geen backdoor. Een backdoor suggeerd dat er iets geheims ingebouwd was en dat is niet het geval

Om te begripen wat hier aan de hand is moet je namelijk terug naar de jaren 70 en 80 van de koude oorlog. Encryptie was eigenlijjk synoniem aan hardware systemen en het primaire gebruik was militair. En dus zat er een export-restrictie op. Dat is niets bijzonders en ik allerlei landen zo. Ook anno 2015 als je als Nederlands bedrijf iets militairs wilt exporteren, moet je een vergunning aanvragen bij de Nederlandse overheid.

Echter in de jaren 90 met de opkomst van commerciele software veranderde de aard van encryptie en vooral ook toepassing. De oude export wetten waren echter wel van toepassing. Dat is pas onder president Bush afgeschaft. Die oude export wetten verboden simpelweg de export van zware encryptie. Bij het SSL protocol hield dat simpelweg in dat de maximale encryptie sterkte beperkt was, en ook de sterke van het protocol om de encryptiesleutel uit te wisselen beperkt was. Niks backdoor, gewoon een limiet op de sterkte van encryptie. Er was ook zeer nauwkeurig beschreven hoe en waar die beperkingen opzaten.

Onder druk van de Amerikaanse multinationals is deze wet afgeschaft, waarna die restrcities verdwenen. Moderne software maakt dan ook geen gebruik van deze zwake encryptie of uitwisseling van sleutels ... dacht men.

Nu blijkt echter één aspect van deze oude wetten (het uitwisselen van de sleutel) nog steeds actief in bepaalde software. Zoals het nu lijkt eigenlijk vooral OpenSSL. Het was al langer bekend - sinds HeartBleed - dat OpenSSL heel veel legacy code bevat. Dat was ook een van de kritieken op dat pakket, maar dat zou in principe niet uit mogen maken, want die oude code is vooral dode code. Moderne clients gebruiken de oude encryptie technieken niet meer en ook gebruiken ze geen zwakke sleuteluitwisseling.

Echter het blijkt nu dat als je een client gebruikt die dat wel doet, veel servers het nog steeds ondersteunen. Dat is vreemd maar op zich niet gevaarlijk. Wel gevaarlijk blijkt dat als je zo'n zwakke sleutel naar een moderne client terugstuurt, deze die accepteerd ondanks dat die om een sterke sleutel vroeg. En dat is de bug. Ofwel een moderne client vraagt om een sterke sleutel, maar krijgt een zwakke en geeft géén foutmelding.

Het is echter evident een bug want OpenSSL is open source, en is precies na te gaan wanneer welke code door wie gemaakt is. Het is een gevolg van drie zaken: 1) de totale onleesbaarheid van OpenSSL zodat zelfs encryptie experts moeite hebben de code te onderhouden 2) de complexiteit van de uitwisslingsprotocollen. Meeste stacks moeten er 4 ondersteunen die elk nét iets anders zijn. Ik om daar zo op terug. 3) En de wens om zoveel mogelijk code te hergebruiken. Dus liefst 1 functie die alle 4 de protocollen aan kan etc.

En dat geeft deze bug. Wat nu gebeurd is dat de server een zwakkere key terugstuurt dan de client vroeg. Dat gebeurd normaal nooit en dus werd er ook niet op gecontroleerd. Deze sleutel wordt echter geaccepteerd omdat OpernSSL intern nog steeds support heeft voor deze oude export-toegestande sleutels. Er werd simpelweg één software functie voor alle 4 de protocollen gebruikt.
Niemand had dat opgemerkt omdat normaal de client (jouw browser) kiest voor de sterke van het uitwisselingsprotocol en niet de server. Dus een server stuurt geen zwakke key terug als jij om een sterke vraagt. Echter bij een 'man in the middle' aanval zou de aanvaller de server kunnen doen geloven dan de client om een zwakke sleutel vroeg.

Wat deze onderzoekers gedaan hebben is expliciet rare situarties testen aan de hand van het officiele SSL/TLS state machine model. Elke stap werd getest en gecontroleerd ('fuzz testing' noemen ze dat) op robuustheid door express verkeerde volgorden uit te voeren en andere verkeerde zaken te doen. Deze bug is slechts een van diverse gevonden.
Zo blijken oude Java SDK versies helemaal kwetsbaar. Zo erg zelfs dat ze claimen dat SSL/TLS in die Java versies totaal gebroken is/was en nihil bescherming bood |:( In dat licht is deze bug nog slechts heel beperkt.
Anoniem: 483276
4 maart 2015 08:15
Mijn Nexus 4 op Android 5.0.2 met de nieuwste Chrome bèta geeft op de website in het artikel al aan dat ik niet kwetsbaar ben. Dus of die update zat al verwerkt in lollipop of het zit in de browser. En dat laatste zou betekenen dat gebruikers van oudere apparaten ook een fix kunnen krijgen door een andere browser te installeren.
Hier 4.4.4 op stock oneplus chrome versie 40.0.2214.109 en kwetsbaar .

Update : Beta geprobeerd en daar is het wel veilig.

Ingebouwd in de browser dus elkeen die zich wat veiliger wil voelen instaleert best die

[Reactie gewijzigd door k995 op 4 maart 2015 08:30]

IOS 8.1.3 op iPhone 6 kwetsbaar
Anoniem: 601896
@core_dump4 maart 2015 08:28
Op BlackBerry os 10.3 krijg je heel veel waarschuwingen, dan moet je selecteren dat je die begrijpt, en dan pas kun je klikken op de knop doorgaan.

Het grappige is wel, dat onze overheid websites volgens mij ook vaak gebruik maken van hetzelfde zwakke lagere ssl beveiligings niveau, want daar krijg ik dezelfde waarschuwingen ook.
Welke versie van welke webbrowser?
Hier ook Android 4.4.? en ook kwetsbaar met de laatste Chrome.
Firefox browser is niet kwetsbaar!
Anoniem: 483276
@k9954 maart 2015 08:42
Dan is er dus helemaal geen android update nodig en kunnen mensen met oudere android versies die geen update meer krijgen gewoon een andere browser installeren en is het probleem opgelost. Dat is op zich goed nieuws.
idd, op mijn IOS device is safari kwetsbaar maar Chrome niet. Lijkt dus in de browser te zitten/
Firefox op Android 4.2 heb ik getest en heeft het probleem ook niet kennelijk. Ed: Lijkt haast een "oudere versie webkit' probleem, niet?

[Reactie gewijzigd door kidde op 4 maart 2015 08:32]

De kwetsbaarheid zit in een encryptie library, niet in de render engine. Het is dus onafhankelijk van of er Webkit, Gecko, Trident etc. gebruikt wordt.
Chrome had het al gefixed, in de beta tenminste. Ik denk dat ze er al van op de hoogte waren voor dit artikel werd geschreven.
Ik heb een Nexus 4 op Android 5.01 draaien met de laatste Chrome 40.0.2214.109(geen beta) en ben wel kwetsbaar volgen de website.
Z3 op 4.4.4 met Chrome is kwetsbaar. Firefox heeft hier echter geen last van, dus mensen kunnen beter Firefox gebruiken tot Chrome of Android is gepatched. Ik denk dat alle browsers die geen WebKit gebruiken maar hun eigen engine niet kwetsbaar zijn, maar loop dat even na voor je eigen favoriete browser.
De kwetsbaarheid zit in een encryptie library, niet in de render engine. Het is dus onafhankelijk van of er Webkit, Gecko, Trident etc. gebruikt wordt.

Maar, verschillende browsers gebruiken verschillende encryptie libraries. Soms meegeleverd met de browser, soms gebruiken ze die van het onderliggende OS.
Zo blijkbaar ook op iOS (8.1.2):

- Safari: kwetsbaar
- Opera: kwetsbaar
- Chrome: niet kwetsbaar
Anoniem: 604167
4 maart 2015 08:27
Ook Windows 10 Mobile is gevoelig
Warning! Your client is vulnerable to CVE-2015-0204. Even though your client doesn't offer any RSA EXPORT suites, it can still be tricked into using one of them. We encourage you to upgrade your client.
typisch dat dat er niet bij vermeld wordt in het artikel, maar wel iOS en Android. Maar dat is niet zo vreemd:
"ontdekten onderzoekers van het Franse onderzoeksinstituut Inria en Microsoft Research."
typisch dat dat er niet bij vermeld wordt in het artikel, maar wel iOS en Android. Maar dat is niet zo vreemd:
"ontdekten onderzoekers van het Franse onderzoeksinstituut Inria en Microsoft Research."
Nah. Ik heb het alleen niet kunnen verifiëren, omdat ik zo snel geen Windows Phone voorhanden had. Maar het lijkt me ook raar dat Windows Phone getroffen is, die heeft toch een hele andere ssl-stack?

Heb je een screenshot, svenvNL?
Anoniem: 120539
@Joost4 maart 2015 09:53
Ook hier met de Windows Phone 10 via het Insider program.
Mogelijke (waarschijnlijke) reden is dat er een nieuwe engine wordt gebruikt, en dus niet zomaar een doorontwikkelde IE. Zie ook: http://blogs.msdn.com/b/i...l-preview-for-phones.aspx
De nieuwe rendering engine is een opgeschoonde versie van de oude. Verder heeft een rendering engine niks met SSL te maken maar is dit een aparte module in de browser.
Windows Phone 8.1 heeft nergens last van.

De Internet Explorer van Windows 10 (getest met IE 11.0.9800.0 update 11.0.8, dus ook de desktop versie), is volgens freakattack.com kennelijk vatbaar. De huidige IE 11 op Windows 8.1 (v 11.0.9600.17631, update 11.0.16) heeft dan weer nergens last van. Ook IE 11 op Surface RT (v 11.0.9600.17031, update 11.0.7) geeft dat de browser veilig is.

Zo te zien heeft Microsoft dit probleem (per ongeluk?) in de nieuwe 9800 branch (Windows 10) geintroduceerd.

[Reactie gewijzigd door the_shadow op 4 maart 2015 09:36]

Anoniem: 604167
@Joost4 maart 2015 09:17
Hier een screenshot. Met de laatste versie van Technical preview van windows 10 mobile http://1drv.ms/1M6aVzn
Ware het niet dat Windows 10 nog in Beta is, dus dat kan nog aangepast worden voor dat de final gereleased wordt.
De versies van iOs en Android zijn al officieel gereleased, dus des te kwalijker dat die kwetsbaar zijn.
WP8.1.1 niet, hij is dus nieuw in plaats van oud voor WP :)
Apart, ik heb het net even met Windows Phone 8.1 (Lumia met Denim) geprobeerd, en daar wordt geen fout gegeven.
Dat is dan ook nog niet beschikbaar voor normal gebruik. Hoe zit het met de huidige versies van Windows 7, 8 en 8.1?
Qua kwetsbaarheid kwam OSX en Ios en Android het slechtste uit de bus in 2014.
Het lijkt wel de omgekeerde wereld, Windows die goed scoort en OSX bovenaan met problemen en veiligheids issues...
zie deze reactie, windows phone 10 hefet het probleem ook ;)
Daar heeft Six9 het helemaal niet over. Het gaat hier om een recente test waarin o.a. OSX en Linux veel meer kwetsbaarheden vertoonden dan Windows. En dat was verbazingwekkend, omdat Windows juist de naam heeft.
Ah die ja, verbazingwekkend?
Het was een leuke headline maar de conclusie van dit artikel hierover:
http://betanews.com/2015/...erabilities-than-windows/
While it is the vulnerabilities linked to individual operating systems that are probably most attention-grabbing, the main problem still lies with third-party software. 83 percent of reported vulnerabilities were to be found in applications, compared to 13 percent in OSes and 4 percent in hardware.

Microsoft might celebrate coming ahead of Apple and Linux in one department, but Internet Explorer was found to be the most insecure web browser. IE had 242 vulnerabilities, compared to 124 in Chrome, and 117 in Firefox.
Op de bron van dit artikel is hierover meer te lezen:
http://www.gfi.com/blog/m...and-applications-in-2014/
O.a. een vergelijk bv IE met Safari is dan te maken:
IE: 242 total vulnerabilities 220 high severity 22 medium severity 0 low severity
Safari: 70 total vulnerabilities 3 high severity 67 medium severity 0 low severity
Alleen daarmee wordt de voorsprong van windows geheel teniet gedaan.

Verder spelen nog zaken mee als update beleid en hoe makkelijk het is om een update uit te stellen dan wel compleet te negeren. Op OS X staan java en flash standaard uit, scheelt toch weer 115 high severity vulnerabilities.

En last but not least, hoe makkelijk de gebruiker fouten kan maken/weerhouden wordt om, hum, minder verstandige dingen te doen. Dat is lastig in getallen uit te drukken maar heeft wel een flinke impact op de kwetsbaarheid.

Dat allemaal optellend denk ik dat de reputatie van windows vooralsnog niet onterecht is, ondanks dat Microsoft natuurlijk flinke vooruitgang heeft geboekt de afgelopen jaren.

edit: bij de Safari vs IE er toch maar bijgezet welke Safari is en welke IE.

[Reactie gewijzigd door curumir op 4 maart 2015 13:14]

Ik denk dat dat één van de belangrijkste redenen is om IE te vervangen in Windows 10. En het is natuurlijk leuk voor de bühne om te proberen dat af te zwakken, maar het blijft mooi (voor Microsoft en voor 90% van de gebruikers) te zien dat het is gelukt om Windows redelijk dicht te krijgen. Dat was in de XP tijd wel even anders. Natuurlijk is webbrowsen belangrijk, maar het OS zelf is m.i. toch nog wel even belangrijker. Een browser is tenslotte gemakkelijk uitwisselbaar.
Zelf gebruik ik overigens Ubuntu, om het in perspectief te plaatsen ;-)
Ware het niet dat Windows 10 nog in Beta is, dus dat kan nog aangepast worden voor dat de final gereleased wordt.
Maar dit ene probleem in win10 zal die balans van 2014 niet hevig doen verschuiven ;)
Ik zie geen verwijzing naar de FREAK attack op de ssllabs pagina? Weet je zeker dat deze nu al wordt meegenomen?
Anoniem: 656163
@Aikon4 maart 2015 10:57
Nee.

Zolang de server geen vintage export grade encryptie ondersteund is er niets (minder) aan de hand lijkt mij.
Android zou dat toch iets aan moeten doen. Je zou als gebruiker van een ouder model dan de keuze moeten geven om zelf iets te installeren of zo, als het door de manufacturer niet word ondersteund
Je kunt een andere browser installeren, die geen webkit gebruikt, of die niet de Android versie van webkit gebruikt, die worden vaak nog wel geupdate.
ik hoopte dat Ghostery browser veilig was, maar nee:
Android 5.01 met Ghostery Vulnarable
Android 5.01 met Chrome (nobeta) Vulnarable

[Reactie gewijzigd door makkie88 op 4 maart 2015 08:34]

is Ghostery niet gewoon Chrome / stock browser met een eigen skin / wat extra features?
OpenSSL was dus ook kwetsbaar, daar gaat de stelling "open" zorgt ervoor dat backdoor onmiddellijk gevonden worden
Reviewen blijkt ook maar een menselijke klus, als een kwetsbaar stuk code over het hoofd wordt gezien en darana niet meer naar gekeken, dan kan het lang blijven zitten.

Neemt niet weg dat veel zaken ook wel eerder gevonden worden. Dus nog altijd inzichtelijker dan closed software.
Backdoor is wat rare term voor dit issue.

In de jaren '90 was er een 'exportverbod' op te zware cryptografie (sleutels langer dan 56bits, als ik het goed herinner) Ik ben zelfs nog "internationale wapensmokkelaar" geweest, door op een speciale protest website een lange key te downloaden.

Er is in die zin geen "geheime" achterdeur. De voordeur is gewoon van bordkarton, zodat de Amerikaanse overheid hem makkelijk kon intrappen.

Dat exportverbod is al jaren opgeheven en ook naar de rest van de wereld mogen Amerikanen nu sterke keys versturen.

De echte bug lijkt daarmee een beetje op POODLE, waarbij een 'man-in-The-middels' een manier heeft gevonden om jou en een site van de ouderwetse zwakke key gebruik te laten maken.

Dat is de echte bug. De 'achterdeur' is geen achterdeur, maar gewoon bekende problematische zwakte.

[Reactie gewijzigd door Keypunchie op 4 maart 2015 08:47]

Klopt, dit voldoet niet aan de definitie van een backdoor. Een backdoor is een bewuste geheime toegang voor bepaalde partijen zonder dat gewone gebruikers het weten.
  • Het bestaan van dit Export Certificate is niet geheim (hooguit een beetje vergeten dat het nog actief gebruikt kon worden).
  • Zelfs de Amerikaanse overheid (inclusief de NSA!) was niet op hoogte van deze kwetsbaarheid anders hadden ze het bij hun eigen servers wel uitgeschakeld
  • Dit een kwetsbaarheid. Het levert geen directe toegang op. Als het een backdoor was geweest dan kon hij simpel worden geopend door de juiste partijen zonder te hoeven kraken. Dat is hier niet het geval.
Kortom, dit is geen backdoor maar een kwetsbaarheid, het is sensatiezoeken om te beweren dat het wel een backdoor is.

[Reactie gewijzigd door Maurits van Baerle op 4 maart 2015 09:26]

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee