Beveiliging websites mogelijk in gevaar door ssl-kwetsbaarheid

Twee onderzoekers zeggen een proof-of-concept te hebben ontwikkeld waarmee volgens de tls 1.0-standaard versleutelde ssl-verbindingen kunnen worden gekraakt. Daarmee komt de beveiliging van een groot aantal websites in gevaar.

Beveiligingsonderzoekers Thai Duong en Juliano Rizzo kondigen de ssl-hack deze week aan op de Ekoparty-conferentie in Buenos Aires. In tegenstelling tot bij eerder openbaar gemaakte kwetsbaarheden in de ssl-standaarden, gebruiken de beveiligingsonderzoekers geen man-in-the-middle-methode, maar een decryptieproces in de browser. Tijdens hun presentatie zouden de beveiligingsonderzoekers willen aantonen dat zij een authenticatie-cookie van betalingsverwerker PayPal kunnen kraken en zo de ssl-beveiliging weten te doorbreken, zo meldt The Register.

De hack, Beast geheten en geschreven in javascript, ontsleutelt ssl-data met behulp van een sniffer. Beast maakt gebruik van een kwetsbaarheid in tls 1.0 waarbij voor het versleutelen van plaintext-datablokken de data van een voorgaand blok wordt gebruikt. Hackers zouden dit proces kunnen manipuleren om zo alsnog de data in handen te krijgen.

Tot nu toe werd deze kwetsbaarheid in tls 1.0 als een zuiver theoretisch probleem gezien en daarom moeilijk uitvoerbaar. De javascript-code van Beast zou echter in staat zijn om authenticatie-cookies te kraken, maar snel is het proces nog niet. Bij de huidige implementatie zou Beast circa twee seconden nodig hebben om elke versleutelde byte te decrypten. Zo zou het ontsleutelen van een ssl-cookie een half uur duren. De onderzoekers zouden er echter in geslaagd zijn om dit proces met codeoptimalisaties flink te versnellen.

Hoewel de methode van Beast niet werkt op tls-versies 1.1 en 1.2, gebruiken vrijwel alle websites die https-verbindingen aanbieden nog tls 1.0. Ook veel browsers ondersteunen de verbeterde tls-encryptie nog nauwelijks, terwijl de ontwikkelaars die de veelgebruikte OpenSSL-bibliotheek bouwen, nog steeds tls 1.2 in de code moeten implementeren. Bovendien zijn veel website-eigenaren huiverig om tls 1.1 of hoger op hun sites te implementeren en af te dwingen, omdat veel bezoekers er dan niet in zullen slagen om een https-verbinding op te zetten.

Reacties (51)

[bartsidee]

Chrome heeft optie TLS 1.0 hier aanstaan, enig idee of beveiiging juist omhoog of naar beneden gaat als ik die uitschakel?

[To_Tall]

Als je TLS 1.0 uitzet dan werkt dat mechanisme niet. met andere worden. Je zult je beveilig omlaag halen.

[Verwijderd]

Dit is volgens mij incorrect: Als TLS 2.0 aanstaat en je zet TLS 1.0 uit dan zou je zeggen dat de beveiliging naar boven gaat. De beste beveiliging is als je alles uitzet. Deze hack is dan ook vrij simpel ongedaan te maken: zet Javascript in je browser uit.

[.oisyn]

Dit is volgens mij incorrect: Als TLS 2.0 aanstaat en je zet TLS 1.0 uit dan zou je zeggen dat de beveiliging naar boven gaat.

Onzin natuurlijk. Als een website TLS 1.1 ondersteunt dan zal je browser gewoon van TLS 1.1 gebruik maken, ookal staat TLS 1.0 aan. Door TLS 1.0 uit te zetten zorg je dus alleen maar dat er in geval van een TLS 1.0 webserver een nog slechter ondersteund protocol gebruik gemaakt wordt (SSL 3.0 of lager), of dat er helemaal geen verbinding wordt gelegd.

[Reactie gewijzigd door .oisyn op 23 juli 2024 12:56]

[kimborntobewild]

dat er in geval van een TLS 1.0 webserver een nog slechter ondersteund protocol gebruik gemaakt wordt (SSL 3.0 of lager), ...

Dan deugt er iets niet. Als je TLS1 uitschakelt, moet natuurlijk alles wat daaronder zit ook uitgeschakeld worden.

...of dat er helemaal geen verbinding wordt gelegd.

Dat is natuurlijk ook de bedoeling!! Dat er helemaal geen verbinding wordt gelegd. Je schakelt TLS1 natuurlijk alleen uit omdat je onveilige verbindingen niet meer wilt accepteren.

[Reactie gewijzigd door kimborntobewild op 23 juli 2024 12:56]

[Auroram]

Onjuist, alleen de best mogelijke verbinding die aan beide kanten is geaccepteerd kan worden gebruikt. Tenminste voor zover ik weet.

Simpel voorbeeldje:

Site heeft TSL 1.0 aan staan
Mijn pc heeft TSL 1.0 en TSL 1.1 aan staan

Mijn pc verzend de ondersteunde methodes, met als hoogste voorkeur TSL 1.1

Site accepteerd geen TSL 1.1 en zal voor de eerstvolgende hoogste op de voorkeurslijst gaan, in dit geval 1.0

Mijn pc accepteerd TSL 1.0 en dit zal dan gebruikt worden bij het opzetten van de beveiligde verbinding

Geen van beide kanten kan de ander dwingen om een versie te gebruiken die geweigerd word. Of ik moet me al heel erg vergissen.

[s.stok]

Hun programma is geschreven in JavaScript, wat tegenwoordig ook als los programma kan worden gebruikt via Rino of Node.JS

Daarnaast zou Paypall/de bank dan beginnen te piepen dat JavaScript moet aanstaan voor die website.

[Foxpat]

Beveiliging wordt er niet beter op als je het uitzet. Een beetje beveiliging die kraakbaar is is altijd nog beter dan geen beveiliging at all.

[Brantje]

Omlaag, want je schakeld helemaal de TLS1.0 uit.
Verder zullen hun de enigen zijn afaik.

Betekend nog niet dat we dit niet serieus moeten nemen.
Integendeel, TLS 1.1 of 1.2 afdwingen onder de gebruikers zouden ze moeten doen.

[actionInvoke]

Ja lekker boos worden op onderzoekers die aan geven dat iets onveilig is. Vooral klokkeluidende hackers aanpakken en je kop in het zand steken, dan zijn er vast geen problemen.

Criminelen zijn er, zijn er altijd geweest en zullen er altijd zijn. Dit soort mensen behoren een prijs te verdienen omdat ze zich inzetten voor de veiligheid van anderen. Dat is heel wat nuttiger dan menig tweaker hiero (yt included).

Als je boos wilt zijn, wees het dan op de overheid die laks en incompetent is op ict gebied en meestal achter het net vist op blackhat hacker gebied.

En trouwens, wat jij zegt over inbrekers. Er zijn gewoon mensen die analyseren waar gaten in de beveiliging van een gebouw zit, soms door voorbeeld.

[Fiander]

Tja,
Je heb aan de ene kant inbrekers die je huis leeg roven. En aan de andere kant mannetjes in dienst van oa de verzekerings bedrijven die zwakheden in sloten in kaart brengen, om zo de inbrekers te vertragen.

[varkenspester]

Het gaat hier om een proof of concept in een labo.
Er is geen enkele bestaande website gehacked, ze hebben enkel in labo aangetoond dat het mogelijk is.

Of steek jij gewoon liever je hoofd in de grond, geen onderzoek, geen beveiliging en maar hopen dat de onderwereld dit ook doet??

[Max Hunt]

Het gaat hier niet om "jou huis", het gaat hier om een beveiliging die door heel veel websites wordt gebruikt. Iedereen gebruikt dit omdat ze denken dat het veilig is, iedereen vertrouwt erop dat het goed gaat omdat het veilig zou zijn.

Of met jou "huis" voorbeeld:
Er is een slot te koop voor je deur waarvan wordt gezegd dat niemand dit slot kan openbreken. Iedereen koopt deze sloten voor hun huizen en denkt dat ze veilig zijn. Nu komt er echter iemand die een manier heeft bedacht waarmee je toch deze sloten open kan maken.

Ze zijn alleen uit op eigen gewin.

Hoe doen ze dat dan in dit geval? Ze zouden hier gebruik van kunnen maken om van alles ermee te doen, in plaatst daarvan publiceren ze deze informatie. En websites hoeven alleen even over te stappen op een betere vorm van beveiliging en alles is opgelost.

[colvano]

Klinkt ingewikkeld en potentieel gevaarlijk. Blijft vreemd dat bedrijven nog steeds voor de makkelijkste oplossing gaan i.p.v. gebruik te maken van veiligere dingen die gewoon al op de plank liggen..

[Verwijderd]

Ja, maar daar is weinig ondersteuning voor. Eenheidsworst wordt toch nog het meest verkocht, kijk maar naar Windows (of Apple).

[Eagle Creek]

Maatwerk kost geld. Door gebruik te maken van bestaande (standaard) oplossingen kun je besparen.

Daar komt nog bij: wanneer jij jouw webshop beveiligd met een techniek die de helft van je bezoekers niet kan gebruiken, loopt je inkomsten mis.

Als een nieuwe techniek doorgevoerd moet worden, leer de geschiedenis ons dat er een paar grote jongens het voortouw moeten nemen en de rest dan volgt. En deze grote jongens doen dat meestal uit financiele motieven. Soms uit (min of meer) idiologische, maar dat is meer uitzondering dan regel.

[Olaf van der Spek]

In tegenstelling tot bij eerder openbaar gemaakte kwetsbaarheden in de ssl-standaarden, gebruiken de beveiligingsonderzoekers geen man-in-the-middle-methode, maar een decryptieproces in de browser.

Gebruikt deze methode meer data dan beschikbaar via een man in the middle? Zo ja, welke data?

[arjankoole]

[...]

Gebruikt deze methode meer data dan beschikbaar via een man in the middle? Zo ja, welke data?

Ja. De browser heeft namelijk toegang tot zowel de encrypted, als de decrypted data. Dat staat er ook. De hack gebruikt plaintext decrypted data uit het vorige blok, om het encrypted blok te decrypten. Een standaard man in the middle heeft dat niet. (niet zonder de certificaten te hebben)

Je zou kunnen stellen dat de browser of het javascript de 'man in the middle' is, maar in weze is dat niet echt zo, het is immers de client, dus het eindpunt.

[Reactie gewijzigd door arjankoole op 23 juli 2024 12:56]

[Olaf van der Spek]

Als je toegang hebt tot het vorige plaintext blok heb je (zeer waarschijnlijk) toch ook gewoon toegang tot het huidige plaintext blok?
En hoe (en waarom) heeft JS toegang tot plaintext en ciphertext?

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 12:56]

[actionInvoke]

Waarom javascript, zou het niet veel sneller kunnen met andere browser implementaties die de cpu of zelfs de gpu beter gebruiken?

[arjankoole]

Waarom javascript, zou het niet veel sneller kunnen met andere browser implementaties die de cpu of zelfs de gpu beter gebruiken?

javascript is een vrije slome en eenvoudige taal, die wel toegang heeft tot de benodigde informatie binnen het browserproces. (eigelijk zou je moeten verhinderen dat de scripts bij de encrypted blokken kunnen komen).

Het is vooral ter illustratie van hoe simpel het is, dus.

[actionInvoke]

"Het is vooral ter illustratie van hoe simpel het is, dus."

Ah. Ja ik zou zelf iets snellers gebruikt hebben, ik kan me niet voor stellen dat JS het enige is dat toegang heeft tot de benodigde resources.

Then again, ik geloofd dat intel op het punt staat js boekjes vrij te geven die veel efficiënter gebruik maken van de cpu's.

[Dlocks]

Ik begrijp niet helemaal hoe dit in de praktijk zou moeten werken. Moet een gebruiker dan eerst malware installeren?

En er staat dat het decryptieproces in de browser plaatsvindt en dat hier maximaal 10 minuten voor nodig is (zie bron artikel op theregister.co.uk). Betekent dit bijvoorbeeld bij PayPal dat het laden van een pagina max. 10 minuten kan duren?

Na bovenstaande te hebben geschreven zie ik onderstaande staan in de bron (theregister.co.uk)

“BEAST is like a cryptographic Trojan horse – an attacker slips a bit of JavaScript into your browser, and the JavaScript collaborates with a network sniffer to undermine your HTTPS connection,”

Dat maakt het -voor mij- al wat duidelijk.

[hackerhater]

Het lijkt me, tenzij de site zelf server-side gehacked wordt (maar waarom dan deze hack?), dat de noscript je hiertegen zal beschermen.

[Verwijderd]

Is het niet zo dat alleen sommige sleutels onveilig zijn, en niet zozeer het protocol? Of maken onveilige sleutels het hele TLS protocol juist onveilig?

Volgens mij snapt niemand dat echt goed, daarom snapt ook de schrijver van dit stukje het zelf ook niet....... Mogelijk is heel internet in gevaar dus?

[wootah]

Volgens mij snap jij het gewoon niet

Lees het volgende:

Tot nu toe werd deze kwetsbaarheid in tls 1.0 als een zuiver theoretisch probleem gezien en daarom moeilijk uitvoerbaar.

Er word dus gezegd dat het theoretisch is.
Iedere sleutel zou te kraken zijn die gebruik maken van TLS 1.0, er is ook TLS1.1 en TLS1.2 uit maar die worden nog niet echt gebruikt in het dagelijks leven.

Maar deze kwetsbaarheid zal net zoals een virus zich op iemands computer nestelen, het is dus gewoon nog steeds belangrijk dat je goede anti-virus en anti-spyware beveiliging hebt, in dat geval zal het al een stuk lastiger worden om verbindingen te kraken

Het hele internet is altijd in gevaar, maar op dit moment nog niet veel meer door zo'n kwetsbaarheid. Het is juist goed om kwetsbaarheden te laten vinden door whitehat hackers, dan worden ze tenminste gefixt voordat de black hatters er iets mee kunnen doen

[pvdberge]

Het is echt ongelooflijk dat er al vijf jaar nieuwe versies van het protocol bestaan, maar deze nauwelijks geïmplementeerd zijn. Terwijl beveiliging bij elke browserontwikkelaar voorop zou moeten staan. De enige browsers die TLS 1.1 en 1.2 ondersteunen zijn Internet Explorer en Opera, maar daar staan die opties standaard uit?! Iemand enig idee wat daarvan het nut is?

Als het (nog) niet afgedwongen kan worden door gebrekkige ondersteuning in browsers, waarom wordt dit dan in ieder geval niet aangeboden door servers waar die mate van beveiliging van belang is? Over de te gebruiken versie van het protocol wordt namelijk onderhandeld in de handshake. Als de client (webbrowser) en server beide TLS 1.2 ondersteunen, dan zal deze versie gebruikt worden. Alle grote Nederlandse banken gebruiken ook TLS 1.0 voor het internetbankieren. DigiD gebruikt ook TLS 1.0.

[Verwijderd]

2 seconden decryptie tijd per byte, en ze zijn al bezig met het versnellen van het proces.
Zou het dan al niet stukken sneller gaan met die parallelle dataverwerking plug-in voor firefox van Intel? ( RiverTrail )

Best interessant allemaal, dit lijkt wel het jaar van de hack waar een loopje wordt genomen met beveiligingen die schijnbaar dus niet deugen?

[spoor12b]

Opera was al een tijdje bezig met het onderzoeken van de gebruikte TLS versies door middel van hun TLS prober.