Google verbetert encryptie-algoritmen van Chrome op Android

Google heeft de encryptiemechanismes in de Android-versie van Chrome naar eigen zeggen veiliger en sneller gemaakt. Zo kan er voor het maken van een ssl-verbinding uit meerdere algoritmes worden gekozen.

De nieuwe algoritmes zijn met name bedoeld voor socs die geen hardwarematige versnelling bieden. Bij het toepassen van symmetrische encryptie heeft Google het ChaCha20-algoritme in Chrome geïmplementeerd. Voor het authenticatieproces is gekozen voor het Poly1305-algoritme.

Volgens Google is het ChaCha20-algoritme veiliger omdat het bijvoorbeeld resistent is tegen zogenaamde timing-aanvallen. Daarnaast draaien beide algoritmes efficiënter op ARM-socs, waardoor versleutelde browserverbindingen niet alleen sneller werken, maar er ook minder cpu-cycli en dus minder energie wordt verstookt.

Google gebruikt de nieuwe algoritmes al sinds februari als een Android Chrome-browser verbinding legt met een van zijn diensten. Uiteindelijk moeten de algoritmes onderdeel gaan uitmaken van Android; daarvoor zal de code in toekomstige Android-versies worden opgenomen.

Reacties (27)

[AmbroosV]

Ook op de desktop wordt ChaCha20 soms gebruikt in Chrome, het hangt af van de CPU. Recente CPU's die beter zijn in AES gebruiken AES, op oudere exemplaren (vooral CPU's van 2010 en eerder) krijgt ChaCha20 de voorkeur.

Er wordt gewerkt aan een implementatie van AES-NI voor Chrome, waardoor AES op recente computers een stuk sneller zou gaan. De voorkeursencryptie is daar een eerste stap voor.

[Armin]

Je bedoelt dat Chrome automatische de client cyper-volgorde gaat aanpassen aan de machine waar het op draait?

In de praktijk maakt dat echter niet heel veel uit, want in 99% van de gevallen bepaalde server de cypher, en chacha20 staat eigenlijk nergens bovenaan.

Niettemin wel een interessante ontwikkeling, al ben ik wat huiverig betreft deze nieuwe ciphers aangezien die nog erg weinig getest zijn. Zowel qua theorie, als vooral ook de implementatie zoals gebruikt. Veel zwakheden komen immers voort uit een kleine fout in de implementatie van een verder goed protocol/cipher.

[AmbroosV]

Yep, ongeveer een half jaar geleden maar 't zit pas in Chrome sinds 33 of 34 als ik me niet vergis.
https://codereview.chromium.org/75663004/

Servers kunnen wel rekening houden met de voorkeur van de browser. Ik merk bijvoorbeeld dat als ik naar YouTube surf met mijn laptop (i5-460M zonder AES-NI) dat er gebruik gemaakt wordt met ChaCha20 + Poly1305 in combinatie met ECDHE-ECDSA key exchange.

Als ik met m'n werk-iMac surf (model met AES-NI in CPU) wordt er gebruik gemaakt van 128bit AES GCM met ECDHE-RSA voor key exchange.

Het zou in ieder geval goed zijn moesten servers wél wat meer rekening gaan houden met de voorkeur van de brower (buiten onveilige varianten). Op een server is het verschil tussen AES en ChaCha20 niet altijd heel groot (hangt ook wat van de hardware af), terwij client-side de performantie misschien belangrijker is. Zeker voor mobiele apparaten.

Google doet het ook niet voor alle services. Voor YouTube doen ze 't wel, ik kan me goed voorstellen dat de performantie bij encryptie van grote videobestanden belangrijker is dan dat het videobestand niet te achterhalen valt. Voor Gmail (minder data maar belangrijker om geheim te houden) wordt er toch altijd AES met RSA gebruikt.

Het is in ieder geval indrukwekkend hoeveel moeite Google doet om 't internet sneller en efficienter te maken. SPDY (en vooral QUIC) zijn ook twee interessante dingen die op devices met hogere latency of minder bandwidth veel kunnen helpen qua snelheid en betrouwbaarheid.

[Reactie gewijzigd door AmbroosV op 2 augustus 2024 04:30]

[Armin]

Als ik met m'n werk-iMac surf (model met AES-NI in CPU) wordt er gebruik gemaakt van 128bit AES GCM met ECDHE-RSA voor key exchange.

Dat het anders is, is natuurlijk geen bewijs dat het andesr is omdat Chrome ervoor optimaliseert

https://howsmyssl.com

Ciper volgorde is heel vaak anders bij verschillende varianten van dezelfde software, om tal van redenen.

(Let wel, ik beweer niet dat je ongelijk heb, ik probeer alleen een bevestiging te vinden dat ze het dynamisch doen uit pure interesse .)

Op een server is het verschil tussen AES en ChaCha20 niet altijd heel groot (hangt ook wat van de hardware af), terwij client-side de performantie misschien belangrijker is.

Probleem is dat servers soms wel duizenden connecties per minuut moeten afhandelen, en dan maakt het soms wel uit. Zeker omdat veel grote bedrijven hardware encryptie doen via apparte modules en niet de CPU.

Plus natuurlijk dat symetrische-cipher volgorde slechts één van de 4 elementen van SSL/TLS is.

Qua security heb ik heb liever een AES-128 met goede eliptical-curve DH en SHA-2 signing, dan bijvoorbeeld een Chacha met non-eliptical curve 1024 bit (= 64bit AES equivalent ) en SHA1 signing (zoals bijna alle Apache servers doen)

Let wel, ik kan Google oprecht enkel complimenteren met hun werk, maar de meest zwakheden in het protocol zitten niet in de symetrische cipher. Nu is eerlijk is eerlijk, juist Google ook actief in die andere vlakken, maar veel andere OpenSSL servers juist niet. Ironisch was lange tijd de veiligste combo een Google server met Microsoft client, omdat non-Microsoft clients jarenang bizar achterliepen met cipher en protocol support, en Microsoft vreemd genoeg op hun eigen servers niet hun eigen laatste ciphers ondersteunden.

Mijn punt is echter meer dat ik zou hopen dat Google hun invloed meer zou gebruiken om uberhaup clients op de laatste beschikbare ciphers en key exchange protocollen te zetten, ipv een nieuw protocol te introduceren wat eerlijk-is-eerlijk de komende 5+ jaar waarschijnlijk niemand gaat gebruiken. Anders ondergaat Google hetzelfde lot als Microsoft die jarenlang als enige de laatste generatie key echange algorithmen ondersteunden, maar dat niemand ze gebruikte (tot 2 jaar geleden Google het dus oppikte).

40% van de internet servers prefereert nog steeds RC4, terwijl alle browsers - behalve uiteraard het creatieve Apple - al lang BEAST mitigatie voor TLS 1.0 hebben uitgevoerd. Allerlei moderne ciphers, key echanche algorithmen en signing wordt dan gewoon niet gebruikt ook al ondersteunen zowel server en client het. Dat is naar mijn smaak het werkelijke probleem. Microsoft heeft sinds IE11 als eerste en enige een truc die servers dan dwingt de RC4 dynamisch uit te schakelen (niet verwarren met statisch uitzetten), waardoor op IE11 je zelden meer op RC4 zit ook al probeert de server je dat op te dringen. Dat is wat werkelijk veiligheid vooruit helpt.

Ik zou dus willen dat een soortgelijke truc gebruikt werd om bijvoorbeeld betere signing of beter key exchange af te dwingen. Als Google en Microsoft dat samen zouden doen, zou je een enorm effect hebben. Een nieuwe cipher is leuk, maar ik vrees dat geen hond het zal gebruiken omdat de meeste servers de komende 5+ jaar nog steeds simpele AES-128_CBC gaan voorschotelen, zelfs nadat RC4 uitgefaseerd is.

[Adion]

..., ipv een nieuw protocol te introduceren wat eerlijk-is-eerlijk de komende 5+ jaar waarschijnlijk niemand gaat gebruiken....

Voor Google kan het gebruiken van een bepaald protocol al interessant zijn zelfs als er niemand is die volgt. Ik heb een vermoeden dat het verkeer google-client naar google-server nog steeds groot genoeg is om hier voordeel uit te halen.
Het is daardoor ook dat Google in een ideale situatie zit om het web te verbeteren, en ze makkelijk kunnen experimenteren met zaken als Spdy, WebM en WebP en dus ook encryptie-protocollen.

[Armin]

Behalve natuurlijk dat Google's eigen servers waarschijnlijk allemaal AES-NI hardware support hebben, in welk geval Chacha trager is ...

Nee, het is hoe meer ik er over nadenk eigenlijk een slechte zet van Google. Encryptie-protocollen behoren via een standardisatie-commite te gaan van onafhankelijke experts. Ik snap het wel, dat gaat traag, en past niet goed bij de cultuur van Google.

Echter juist het zelf-hobbywerk heeft in het verleden ernstige veiligheidslekken gegeven. Plus Chacha heeft eigenlijk weinig tot geen voordelen. Het is ruwweg even snel en ruwweg even veilig cryptografisch gezien. De wereld heeft crypotgrafisch gezien enkel behoefte aan 2 maximaal 3 ciphers. Een als hoofd, en een als backup indien plotsklaps de eerste gebroken is.

Wij hebben nu AES-CBC en AES-GCM als twee overal op aarde ondersteunde ciphers, en desnoods het oude en in software trage doch ongebroken 3DES als 3e indien écht nodig.

Juist standardisatie heeft de wereld veiliger gemaakt. Eerst was er letterlijk chaos in encryptieland waarbij experts en bedrijven allemaal het eigen wiel gebruikte en ook onderling moeilijk konden discussieren over wat veilig was en niet. Toen was er orde en kwam er DES hetgeen jarenlag veilig was, en diens afgeleide 3DES is tot de dag van vandaag nog steeds ongekraakt.
De opvolger van DES, werd AES en is ook ongekraakt en zelfs onaantastbaar voor de NSA!
Juist dit success is te danken aan het wereldwijd samenwerken van allerlei experts en explciet zeer traag en paranoide standaardiseren.

Even snel een eigen cipher inbouwen in je eigen producten is potentieel onveilig, en werkt bovenduen niet met producten van andere fabrikanten. Als Chacha nu een enorme doorbraak was goed, maar dat is het niet. Het is een 'me-too' cipher die bovendien nog relatief weinig onderzocht is.

Er zijn letterlijk talloze andere ciphers naast Chacha. Dus zelfs als je graag een andere cipher wilt naast AES, waarom dan bijvoorbeeld niet kijken naar een van de finalisten in de AES-competitie? AES is uiteindelijk uit letterlijk tientalle opties gekozen als beste op basis van een set van criterea van veiligheid en performance.

Let wel, ik wil Google niet aanvallen, aangezien ze op andere tereinen wel goed cryptografisch werk doen, maar dit is niet een van het sterkste momenten. Er is naar mijn smaak geen behoefte aan een me-too cipher.

[Verwijderd]

Dit is voor hun natuurlijk gewoon business. Er gaat zoveel verkeer naar hun servers dat een 1% reductie een energiecentrale minder kost...

[AmbroosV]

Ik weet het zo nog niet. Als ze servers met recente CPU's hebben (met AES-NI) kan ik me niet voorstellen dat ChaCha20 voor hun efficiënter is dan AES. Maar mobiele gebruikers die langer surfen omdat hun telefoon minder rekenwerk heeft = meer tijd voor de users om content te bekijken. En bij content horen ads. Slim businessmodel, dat van Google. Wint iedereen bij.

[NanoSector]

Mooi dat ze dit implementeren, maar als ze eens naar bugs gingen kijken...
Op mijn HTC One zijn dingen als XDA gewoon niet leesbaar in Chrome. andere browsers als Maxthon en Next Browser werken gewoon prima.

Toch mooi dat ze dit invoeren, de snelheden zien er iig netjes uit.

[Aionicus]

Ja dit had ik dus ook op mijn S4, mede hierdoor gebruik ik ook gewoon geen chrome op mijn telefoon , Opera blijft voor mij de snelste en meest relaxte browser. daarbij kan ik bij opera beter controleren wat er allemaal meegezonden word ten opzichte van chrome. En dan heeft opera nog de boost functie waardoor alles gecomprimeerd ingeladen word , heel handig voor als je bijna op het einde van je bundel zit.

[NanoSector]

Zelfs in Opera (de niet-Mini versie in ieder geval) blijft dit probleem; vast omdat het op Chrome gebaseerd is. Zelf gebruik ik Next Browser, die geloof ik ook Webkit gebruikt (gebruikt Chrome op Android al Blink?) maar ik vind het echt een zalige browser.

[Aionicus]

Ik heb een oudere versie van opera geinstalleerd , de versie die nog niet op webkit gebaseerd is. De nieuwe versie van opera laat ik links liggen , daar ben ik zo van geschrokken op de pc toen ik zag wat ze allemaal gesloopt hadden wat opera zo speciaal maakte : tabs op tabs stacken , heel snel , knopje om alle images te disablen en alleen frames te laten zien etc.... het grootste schrikpunt was het ontbreken van bookmarks en het uitrollen van de stash met hartjes.... wat een slechte keuze was dat!

probeer het met een oudere opera mini , ik heb geen probs op xda dev ermee.

[makreel]

ja revoked.grc.com wordt ook nog gewoon getoond

[O88088]

Ik heb het geprobeerd en XDA werkt gewoon prima. Net als alle andere websites, geen last van bugs ofzo..

[NanoSector]

Volgens mij ligt het eraan welke telefoon en ROM je gebruikt. Op Cyanogenmod werkt Chrome ook prima, helaas gebruikt het merendeel geen Cyanogenmod o.i.d.

[Reactie gewijzigd door NanoSector op 2 augustus 2024 04:30]

[keranoz]

Waarom überhaupt een andere browser gebruiken op een HTC telefoon? De standaard ingebouwede browser HTC is heel goed! (Heb een keer een mobiele browsertest gezien hier op T.net, weet alleen niet meer waar) Qua prestaties maar IMO ook qua looks!

On-topic:
Wat ik mij afvraag: NSA? Backdoors? Exploits? Ik hoop van harte dat deze algoritmes een stukje veiliger zijn!

[NanoSector]

Ik vind de standaard HTC browser op zich prima, maar Next Browser en Chrome synchroniseren ook met je Google account. Qua looks vind ik 'm maar meh (zeker vergeleken met Next Browser), qua prestaties weet ik het niet echt.

[mace]

Goed om te zien dat Google dit implementeert, ChaCha20 en Poly1305 zijn weliswaar nog geen onderdeel van de huidige TLS-standaard, maar deze wordt in de toekomst toegevoegd.

De IETF Draft ligt al klaar.

Zal wel TLS1.3 worden o.i.d.

[Verwijderd]

De "nieuwe" algoritmes stammen uit 2008, en zijn (bijv. in tegenstelling tot SPDY) niet door Google zelf bedacht.
http://cr.yp.to/chacha.html

[pizzafried]

Google moet eens zorgen dat netflix HTML5 kan gaan gebruiken icm met die encryptietechnieken voor het beveiligen van de videocontent....of zorgen dat silverlight toegang heeft tot hardware versnelling zodat HD content soepeler kan lopen...

[YaPP]

Zoals hierboven ook al aangegeven, het is heel belangrijk om op je server ook goede SSL ciphers en protocollen af te dwingen. Zonder dat is de kant groot dat je client verbinding maakt met een minder goede cipher.

Zie hier voorbeeld instellingen voor Nginx:

ssl_ciphers "ECDH+AESGCM ECDH+AES256 DH+AESGCM DH+AES256 ECDH+AES128 DH+AES ECDH+3DES DH+3DES RSA+AES RSA+3DES !RC4 !ADH !AECDH !MD5 !DSS";
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;


Je kunt op https://freescan.qualys.com/ kijken hoe deze instellingen uitpakken.

[Reactie gewijzigd door YaPP op 2 augustus 2024 04:30]

[MGutker]

Alsof internet ooit veilig zal worden....

Je kunt het wel sneller (en energie-zuinig) maken Goed bezig google!

[Reactie gewijzigd door MGutker op 2 augustus 2024 04:30]

[jleijdekkers]

Klinkt een beetje als de belastingdienst
"veilig kunnen we het niet maken, wel sneller"

[tellavist]

Maakten ze het maar sneller

[MGutker]

Ze doen in iedergeval een poging Anders als de belastingdienst, die vermoeden nogsteeds dat een vriend van mij vorig jaar €80.000 EXTRA heeft verdient dus die doen zeker niks aan de makkelijkheid