Onderzoekers vinden beveiligingsprobleem in tls-protocol

Britse beveiligingsonderzoekers hebben een kwetsbaarheid gevonden in het transport layer security-protocol waardoor het mogelijk wordt om versleutelde data te kunnen ontsleutelen. De 'lucky thirteen'-aanvalsmethode is echter complex.

De aanvalsmethodiek op het tls-protocol en het afgeleide datagram tls-protocol, die beide gebruikt worden bij het maken van https-verbindingen, wordt beschreven door Nadhem AlFardan and Kenneth Paterson. Een aanvaller dient als man-in-the-middle https-sessies uit te kunnen lezen. Vervolgens wordt een bekende kwetsbaarheid in het door tls gebruikte encryptiealgoritme benut: een pakketje waar 'onzindata' aan is toegevoegd wordt verstuurd naar de ontvangende server. Omdat een gemanipuleerd pakketje meer verwerkingstijd vraagt van de server, en dit meetbaar is, kunnen de aanvallers met behulp van complexe statistische berekeningen versleutelde data alsnog uitlezen.

Voor de lucky thirteen-aanvalsmethode zijn grote hoeveelheden samples nodig, al konden de onderzoekers de benodigde tijd om de encryptie te kraken sterk reduceren door andere bekende kwetsbaarheden in het tls-protocol te combineren. Ook kan er sneller data worden ontsleuteld als een deel van de data bekend is, zo stellen de onderzoekers. Bij servers die gebruik maken van OpenSSL konden datapakketjes geheel van encryptie worden ontdaan, bij de GnuTLS-implementatie tot op vier bits.

Ondanks dat de kwetsbaarheid complexe berekeningen en veel tijd vergt, en daarmee momenteel een bescheiden risico vormt, stellen de onderzoekers dat de ssl- en tls-beveiligingsprotocollen verbeterd moeten worden. Browserbouwer Opera en de ontwikkelaars van de PolarSSL-library zouden het gat al hebben gedicht, terwijl onder andere de developers van OpenSSL en CyaSSL aan een patch werken. Verder willen de Britse onderzoekers de gebruikte code niet vrijgeven maar wel overhandigen aan andere security-researchers.

Reacties (17)

Het is mij nu alleen niet helemaal duidelijk of het dus in de nabije toekomst zo is dat een https versleutelde verbinding niet als integer beschouwd kan worden?

De onderzoekers zelf schrijven:

There are effective countermeasures against our attacks and we have worked with a number of TLS and DTLS software developers to prepare patches and security advisories.

The attacks can only be carried out by a determined attacker who is located close to the machine being attacked and who can generate sufficient sessions for the attacks. In this sense, the attacks do not pose a significant danger to ordinary users of TLS in their current form.

Voorlopig hoeven wij (als consumenten) ons er dus nog niet echt druk over te gaan maken.

Behalve dan dat spyware maanden SSL traffic met je bank kan gaan bewaren en periodiek gaan doorsturen. Dan hebben ze ineens wel voldoende sessie informatie..
Om voorlopig de kans op misbruik zo klein mogelijk te houden wordt ook de code niet openbaar gemaakt.

Als Spyware zich in je netwerk stack weten te worstelen (vergelijkbaar met firewall- en anti-spyware software) dan kunnen ze dezelfde gegevens zien als je provider. De spyware kan daarnaast zijn bijhouden welke websites jij bezoekt. Een gebruiker welke regelmatig (financiele) beurzen en lifestyle websites bezoekt is in de regel interessanter dan gebruikers welke Tweakers bezoeken.. Op basis van het profiel kunnen criminelen dan keuzes maken welke TLS sessies ze willen gaan onderscheppen..

Het is niet de software welke het probleem bevat, maar de TLS standaard zelf. Dat betekend dat elke TLS implementatie aangepast moet worden waarbij de browsers en webservers veruit het belangrijkst zijn.. De impact voor de gemiddelde consument kan inderdaad vrij snel beperkt worden. Alleen zijn er ontzettend veel (zakelijk) maatwerk pakketten welke zelf een TLS library hebben gelinkt en deze zullen minder snel gepatched worden. Maar daar staat tegenover dat deze minder snel doelwit van een dergelijke aanval zal zijn..

Als malware/spyware inmiddels al op een systeem geïnstalleerd is, is een SSL-traffic-analyse nogal omslachtig. Gewoon direct de browser - de al ontsleutelde - interessante informatie laten doorsturen is dan veel eenvoudiger

Maar natuurlijk zou deze aanval wel bijvoorbeeld kunnen worden gedaan op sommige (on)beveiligde draadloze netwerken. Vaste bezoekers zouden dan doelwit kunnen worden, zeker als het netwerk zelf gecompromitteerd is.

Als spyware in je netwerkstack zit heeft geen enkel beveiligingsprotocol zin, immers is alle data dan als plaintext beschikbaar.

Het gaat mij ook iets boven het hoofd, maar zo erg is het ook weer niet. Het is een man-in-the-middle attack die ook met gewone http verbindingen mogelijk is, alleen een niveau hoger, en veel meer mogelijke gevolgen.

gaat dit nou over tls of over ssl?
de titel zegt mij tls, maar als ik het artikel lees is het puur de ssl layer die faalt?
Of gaat het over tls 1.1 of 1.2 dat is ook een verschil, 1.0 was al gekraakt een paar jaar geleden.
http://nl.wikipedia.org/wiki/Secure_Sockets_Layer

TLS = SSL, gewoon een nieuw naampje voor hetzelfde beestje. Je gebruikt dus of SSL of TLS, niet allebei. Zie ook de uitleg op de wiki pagina die je zelf al aanhaalt. Na SSL 3.0 kwam TLS 1.0 etc.

De aanval is zowel van toepassing op bepaalde versies en implementaties van TLS, als op bepaalde implementaties van SSL.

Zie: http://www.isg.rhul.ac.uk/tls/#Version

Which versions of TLS and DTLS are affected?

The attacks apply to all TLS and DTLS implementations that are compliant with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2. They also apply to implementations of SSL 3.0 and TLS 1.0 that incorporate countermeasures to previous padding oracle attacks. Variant attacks may also apply to non-compliant implementations.

Extra verwarrend daarbij is natuurlijk dat een populaire implementatie OpenSSL heet, terwijl die library zowel SSL als TLS implementaties biedt.

[Reactie gewijzigd door Orion84 op 4 februari 2013 20:33]

Je spreekt jezelf tegen

TLS = SSL

terwijl die library zowel SSL als TLS implementaties biedt.

In werkelijkheid is TLS een doorontwikkeling van SSL 3.0. TLS 1.0 wordt soms dan ook (foutief) SSL 3.1 genoemd. Een belangrijk verschil is dat SSL een aparte port vereist voor beveiligde data terwijl bij TLS beveiligd en onbeveiligd verkeer over dezelfde port kan.

Bij ontcijferen van berichten helpt ieder beetje informatie

- Dat de server is langer bezig met "foute" pakketjes dan met goed ge-encrypte pakketjes is informatie!
- Wat ENORM helpt is als je al wat van de inhoud van het ge-encrypte pakketje weet.
hier weten ze de inhoud van de header eigenlijk al, dus dat helpt.

Een interessant stukje historie hierover:
http://en.wikipedia.org/w...gma#Crib-based_decryption

Echt zorgen maak ik me nog niet, je moet er EN tussen komen, en je berekeningen doen.
En als ik het begrijp heel veel proefpakketjes versturen, en dat zou toch te detecteren moeten zijn!
Dus geruisloos lijkt mij deze methode allerminst

Ik denk dat het bij een beetje drukke server onbegonnen werk word om "foute pakketjes" / proefpakketjes te gaan herkennen. Dit betekend namelijk weer overhead en dat kost tijd + cpu kracht = geld.

Hmm. Ik denk dat dat mee valt. Als die pakketjes inderdaad meer tijd kosten en er veel worden verstuurd haal je ze er met heel eenvoudige statistiek zo uit. Misschien geen oplossing voor het probleem maar wel een tijdelijke fix misschien?

Bij een man in de middle attack krijgt de gebruiker al een melding dat de website niet overeenkomt met het certificaat, dus het lek lijkt mij ook niet heel ernstig. Desondanks moet het lek natuurlijk wel verholpen worden, maar actief misbruik maken van dit lek lijkt me erg moeilijk.

Een man-in-the-middle attack kun je ook op andere wijzen uitvoeren zonder dat beide eindpunten daar iets van merkt, zoals bijv. met behulp van packet sniffers.

Een man-in-the-middle attack kun je ook op andere wijzen uitvoeren zonder dat beide eindpunten daar iets van merkt, zoals bijv. met behulp van packet sniffers.

Echter moeten er in dit geval ook pakketjes worden gemodificeerd en naar de desbetreffende server worden verstuurd.
(een pakketje waar 'onzindata' aan is toegevoegd wordt verstuurd naar de ontvangende server)
Dus het is nog wat lastiger.

Ze hebben hier een heleboel SSL implementaties onder de loep genomen: http://www.isg.rhul.ac.uk/tls/#Patches

Maar ik mis informatie over de op 1 na meest gebruikte (vermoedelijk) degene die in de Microsoft Crypto API is opgenomen.

Iemand hier info over?

Handig voor landen, die al het verkeer willen monitoren zoals bijvoorbeeld Iran en Australie. Dit kan je eenvoudig implementeren als een transparent proxy op de gateways naar het buitenland.