Google verruilt OpenSSL in Chrome voor eigen fork

Google gaat OpenSSL verruilen voor BoringSSL, zijn eigen fork van het OpenSSL-project. Daarbij worden veranderingen in de OpenSSL-code wel doorgevoerd. Volgens Google is het praktischer om een eigen fork van OpenSSL te hebben.

Tot nu toe gebruikte Google OpenSSL, een van de veelgebruikte ssl/tls-suites, in Google Chrome, Chrome OS en Android. Daarbij voerde Google zelf al patches door die door OpenSSL nog niet waren goedgekeurd. De zoekgigant gaat het nu echter anders aanpakken: het bedrijf integreert zijn eigen OpenSSL-fork BoringSSL in Chrome.

Daarbij zal het bedrijf inkomende patches vanuit het OpenSSL-team wel nog doorvoeren, en bugfixes doorgeven aan datzelfde team. Ook met LibreSSL, een fork van het OpenSSL-project door OpenBSD, zullen patches en bugs worden gedeeld. Het is nog niet bekend wanneer BoringSSL in de stabiele versie van Chrome zal worden toegevoegd. Op termijn moet ook Android BoringSSL in plaats van OpenSSL krijgen.

Het is onduidelijk in hoeverre de beslissing is ingegeven door Heartbleed, een omvangrijke bug in OpenSSL waarbij aanvallers het interne geheugen van de server konden uitlezen. Het BoringSSL-project was al opgestart voordat die bug aan het licht kwam.

Reacties (41)

[hub0]

In het artikel wordt aangegeven dat het onduidelijk is of de nieuwe ontwikkeling iets te maken heeft met de Heartbleed bug. Dit is bijzonder, want in de bron (https://www.imperialviolet.org/2014/06/20/boringssl.html) wordt uitgelegd dat het 'opruimen' van de google codebase mbt SSL al eerder was begonnen dan het bekend worden van de nu bekende grote problemen bij verschillende SSL implementaties. In deze zin staat dus eigenlijk het antwoord op de vraagstelling uit de slotzinnen van het artikel van Joost:

"Earlier this year, before Apple had too many goto fails and GnuTLS had too few, before everyone learnt that TLS heart-beat messages were a thing and that some bugs are really old, I started a tidy up of the OpenSSL code that we use at Google."

De verandering is dus niet ingegeven door de Heartbleed bug of een ander beveiligingsprobleem, maar door de praktische haalbaarheid van het gebruiken van een externe codebase die constant geport moet worden naar meer dan 70 patch-implementaties van SSL bij Google.

"But as Android, Chrome and other products have started to need some subset of these patches, things have grown very complex. The effort involved in keeping all these patches (and there are more than 70 at the moment) straight across multiple code bases is getting to be too much."

Er staat hier volgens mij vrij duidelijk waarom het project is gestart, en dat het niks te maken heeft met de recente OpenSSL-ellende. Er wordt geherimplementeerd om SSL beheersbaar te houden in de verschillende vormen waarin Google deze gebruikt.

[Reactie gewijzigd door hub0 op 25 juli 2024 20:51]

[MBV]

Niet 70 implementaties, 70 patches, als ik die quote van jou goed lees. Kennelijk hebben ze nu besloten dat ze voor Android en andere code-bases niet langer forken van OpenSSL en daarop een lijst patches in sync houden met alle code-bases, maar een eigen branch hebben gemaakt die ze (waarschijnlijk) regelmatig wilden syncen met OpenSSL. In dat opzicht is het niet zo'n schokkende verandering als het artikel suggereert.

[Armin]

Alleen zal de BoringSSL op termijn steeds verder gaan afwijken van OpenSSL.

Immers elke Google wijziging wordt per direct in BoringSSL toegepast, en dan (welicht) voorgesteld aan OpenSSL. Deze moet deze dan accepteren en porten naar OpenSSL. Of dat zal gebeuren valt echter geheel nog maar te bezien, alleen al ivm mankracht.

Andersom Google neemt enkel de OpenSSL patches die zij interessant vinden. Hoe groter de verschillen, hoe kleiner het aantal pacthes dan met zal innemen, met als gevolg een steeds sneller accellerende fork.

Apple deed hetzelfde een paar jaar geleden. Het is dus ook echt een fork, en geen parallele ontwikkeling die gegarandeerd min of meer gelijk zal blijven lopen.

[MBV]

Tja, ik denk dat je het OpenSSL team dat moet verwijten. Zij zijn altijd heel terughoudend geweest met het oplossen van bugs, dan krijg je dat. Hopelijk wordt BoringSSL de nieuwe standaard, zo'n wisseling van de wacht is vaker voorgekomen in de Open Source community (X11 v.s. X.org bijvoorbeeld).

Edit: ik bedoelde natuurlijk libressl.

[Reactie gewijzigd door MBV op 25 juli 2024 20:51]

[Rafe]

BoringSSL is vooral voor Google zelf zoals in het hierboven gelinkte artikel te lezen is ("There are no guarantees of API or ABI stability with this code: we are not aiming to replace OpenSSL as an open-source project."), dan kan je beter inzetten op LibreSSL.

[HollowGamer]

Het is wachten totdat we weer bij één alternatief uitkomen. Ik zie het namelijk niet echt zitten om 3 verschillende libs te onderhouden, zeker als je op dit gebied zit (waar je nogal wat kennis in huis moet hebben).
Zal Google btw. drastische veranderingen doorvoeren? Willen ze voordeel halen uit hun fork? Hiermee bedoel ik bijvoorbeeld makkelijker toegang tot bepaalde (user) info bij deze SSL fork?

Het internet zit sowieso vreemd in elkaar: waarom moet ik bij een certificaat boer mijn SSL halen, terwijl deze vaak zelf de beveiliging niet op orde hebben. Waarom kan de gebruiker niet zelf een SSL certificaat maken die vervolgens door de SSL-implementatie wordt gecontroleerd (welke verbindingen, welke gegevens, sterkte versleuteling, etc.). Maar misschien heb ik wel een verkeerd beeld?

[cyberstalker]

De reden is dat er met SSL twee doelen zijn: versleuteling en identificatie.

Het idee achter een CA is dat deze verifieert of jij bent wie je zegt te zijn voordat het certificaat wordt uitgegeven. Als iemand dan bijvoorbeeld een MITM attack uitvoert kan deze geen encryptie meer toepassen op het gedeelte naar jou toe, omdat jouw browser het certificaat niet vertrouwt.

In theorie is dit dus een aardig idee, maar de kwaliteit van menig CA laat helaas te wensen over waardoor het hele systeem eigenlijk waardeloos is.

[jaapzb]

Klopt, Armin Ronacher heeft hierover op Pygrunn een interessante talk gehouden. Basically, CA's zijn alleen nuttig om het groene balkje/slotje te krijgen in je browser. Als je zeker wilt zijn dat degene aan de andere kant van de SSL-lijn echt degene is die ze zeggen dat ze zijn, moet je handmatig fingerprints gaan checken.

[Reactie gewijzigd door jaapzb op 25 juli 2024 20:51]

[Kain_niaK]

Kunnen ze geen systeezinnen dat niet gebaseerd is op een centrale autoriteit? Bijvoorbeeld gebaseerd op de public keys die je gebruikt met bitcoin? Deze kunnen bijvoorbeeld een grote hoeveelheid bitcoins bevatten en bekend zijn bij het publiek. Als dit een partij is die iedereen vertrouwt. En als alle bitcoins opeens weg zijn van het address dan geeft je computer een waarschuwing: Pas op de betrouwbare eigenaar van dit bitcoin address heeft iedereen belooft om 666 bitcoins op dit address te laten staan en ze nooit te gebruiken. Er zijn nu geen 666 bitcoins meer op dit adres. Dit betekent dat de eigenaar niet meer betrouwbaar is.


Een centrale autoriteit blijkt gewoon niet meer iets van deze tijd te zijn. Computers en computer netwerken zijn slim en groot genoeg om dit in de toekomst om een manier te doen zonder dat er vertrouwen nodig is. Systemen die geen vertrouwen nodig hebben en toch werken; "zerotrust"


Dit is lange tijd onder computerwetenschappers een probleem geweest dat we niet konden oplossen. Het zogenaamde probleem van de byzantijnse generalen.

Sathoshi heeft dit opgelost op een praktische manier die in de praktijk lijkt te werken (bitcoin is het eerste experiment).

Er is geen enkele reden om dit principe niet verder te gaan toepassen op andere gebieden.

[MBV]

Je bedoelt het Web of Trust? http://en.wikipedia.org/wiki/Web_of_trust Dat zit standaard in de meeste GPG en PGP suites, en bestaat al sinds 1992. Jij maakt een private key aan, vraagt aan iedereen met PGP/GPG om te valideren dat jouw public key matcht met jouw identiteit (bij voorkeur offline), en daarmee bouw je 'kredietwaardigheid' op. Op die manier kan je met vrienden van vrienden van vrienden op een vertrouwde manier communiceren, en zelfs als je geen directe link hebt, kan je online zien dat er X mensen die key hebben gevalideerd en dat de identiteit dus waarschijnlijk klopt.

Ik zie trouwens niet in hoe je volledig geautomatiseerd, zonder centrale authoriteit, kan valideren dat iemand is wie hij claimt te zijn. Je kan andere centrale authoriteiten ervoor gebruiken (transactie met een bank, registratie in GBA, dat soort dingen), maar zonder centrale authoriteit zal je altijd op zo'n Web of Trust verhaal uitkomen.

[Reactie gewijzigd door MBV op 25 juli 2024 20:51]

[_Thanatos_]

Kunnen ze geen systeezinnen dat niet gebaseerd is op een centrale autoriteit?

Per definitie niet. Vertrouwen is een persoonlijke overtuiging gebaseerd op eigen ervaringen en kan niet opgedwongen worden. Vetrouwen kan daarbij nooit eenzijdig zijn.

Ik zie niet waarom dat op het web opeens allemaal niet meer hoeft te gelden, en vertrouwen eenzijdig opgelegd wordt door een centrale instantie.

[Reactie gewijzigd door _Thanatos_ op 25 juli 2024 20:51]

[svenslootweg]

Dat is nu juist het punt wat hij probeert te maken. En ook precies het probleem dat een web of trust probeert op te lossen.

[flabber]

In theorie is dit dus een aardig idee, maar de kwaliteit van menig CA laat helaas te wensen over waardoor het hele systeem eigenlijk waardeloos is.

Ik ben het helemaal met je eens dat de immens grote groep van CA's een flink aantal discutabele partijen bevat.
Echter, je gooit hierbij SSL en CA's op één grote hoop wat toch niet helemaal correct is.
SSL, en TLS, is een protocol dat de end-to-end versleuteling verzorgt tussen twee systemen.
X509 of "SSL-Certificaten" die uitgegeven worden door CA's zijn bedoeld om de 'identiteit' van een website te valideren.

Natuurlijk is het zo dat in de meeste toepassingen SSL en X509-certificaten (en dus CA's) hand in hand gaan, maar beide hebben toepassingen waarbij de ander geen rol speelt.
Zo is het prima mogelijk om SSL of TLS verbindingen op te zetten zonder certificaten te gebruiken.

SSL (TLS) is en blijft een zeer goed protocol, met dien verstande dat er zoals bij veel zaken nogal eens implementatiefouten blijken voor te komen. Maar dat neemt niet weg dat het protocol zelf goed is. Kijk maar naar google, ze blijven SSL gebruiken, alleen een meer eigen implementatie.

En zelfs de hele opzet van certificaten en CA's is goed, in beginsel.
Deze is gebaseerd op [gedelegeerd] vertrouwen en is eigenlijk heel transparant voor eindgebruikers. In een browser kun je heel makkelijk aangeven welke CA's je wel of niet wilt vertrouwen.
Je zou zelfs blanco kunnen beginnen door alle voorgebakken CA's te verwijderen en dan handmatig die CA's toe te voegen die je tegen komt en je, al dan niet na onderzoek, meent te kunnen vertrouwen.
Op die manier kan er nooit zomaar een certificaat worden vertrouwd van een of andere CA in Rusland, India of waar je ook maar bang voor bent.

Natuurlijk, Diginotar en andere major fails hebben een flinke deuk in dat benodigde vertrouwen gemaakt, maar zonder enig vertrouwen is de enige optie je PC uitzetten.

[svenslootweg]

En zelfs de hele opzet van certificaten en CA's is goed, in beginsel.

Nee, dat is het niet. Het is een leuke theorie, niet meer dan dat. Als het CA-model vandaag de dag voorgesteld zou worden, zou het breed uitgelachen worden omdat het zo onveilig is. Er is ook geen enkele manier waarop het CA-model veilig zou kunnen uitpakken.

De realiteit is dat handmatig een keuze maken uit een selecte groep 'autoriteiten' niet iets is waar gebruikers mee te maken willen hebben. Omdat het zo'n selecte groep is en de betreffende groep commercïele baat heeft bij het betrouwbaar lijken (en dat dus doet), is het heel logisch dat browsermakers dan bepaalde 'autoriteiten' als 'vertrouwd' aanmerken zonder daar een gebruiker van op de hoogte te stellen.

Het feit dat het niet uitmaakt wie een certificaat ondertekent betekent dat er slechts één rotte appel hoeft te zijn om het hele systeem onderuit te halen.

Hoe je het ook wendt of keert, het CA-model is gedoemd om te falen.

Met bijvoorbeeld een web of trust bestaat dit probleem niet; aangezien een WOT expliciet gebaseerd is op het vertrouwen van mensen die je fysiek kent, is het onwaarschijnlijk (zo niet onmogelijk) dat een dergelijke centralisatie door browsermakers ondernomen wordt. Er zíjn immers helemaal geen centrale veelgebruikte 'autoriteiten' om automatisch goed te keuren.

[flabber]

Maar de hele CA opzet is ook een web of trust.
Certificate chains kunnen erg lang zijn en zijn gebaseerd op het vertrouwen dat de bovenliggende partij zijn werk goed doet.
Natuurlijk voelt een directere vorm van controle, mensen die je persoonlijk kent of ontmoet hebt, veel prettiger aan dan een onbekende, verre partij.

Maar ook in zo'n kleine cirkel dichtbij blijft het een geval van vertrouwen en zijn er geen garanties. Organisaties zijn en blijven organisaties net zoals mensen mensen zijn en blijven. En dus kan dat vertrouwen geschaad worden.
Ik weet geen cijfers, maar ik dacht dat de meeste gewelds- en sexuele misdrijven nog steeds worden gepleegd die elkaar goed kennen of zelfs familie zijn.
Een van de meest directe web-of-trust's is toch wel de familie en daarbinnen blijkt het vertrouwen toch erg vaak misplaatst.

Of wat dacht je van een drankje in de kroeg?
Je drinkt het zonder meer omdat je je broer het aangeeft.
Die heeft het van het dienblad dat zijn vriend heeft gehaald en die heeft ze weer besteld bij de barman die er al tijden werkt.
Dus er gaat nooit iets fout? nou....

Kortom, om te kunnen (over)leven in deze wereld heb je vertrouwen nodig.
In je naasten, je collega's, je mede-tweakers en dan verder naar die barman, winkelpersoneel, banken, overheden en CA's.
Dat er rotte appels tussen zitten, zeker weten! En het zijn er te veel.
Maar vertrouwen is nooit hetzelfde als garanties, ook niet bij CA's.

[King4589]

Zal Google btw. drastische veranderingen doorvoeren? Willen ze voordeel halen uit hun fork? Hiermee bedoel ik bijvoorbeeld makkelijker toegang tot bepaalde (user) info bij deze SSL fork?

Google gebruikte OpenSSL met patches omdat dit nodig was voor Chrome(ium/os) en Android. Maar die zouden steeds meer custom software vereisen. En patches van Google werden niet altijd verwerkt in OpenSSL.

Door een eigen fork te maken hoeft google niet te wachten tot een patch door OpenSSL is goed gekeurd en / of mee genomen word in de main release.

nieuws: Google komt met fork van OpenSSL genaamd BoringSSL

[eborn]

Maar daarbij heeft Google weer het probleem dat hun eigen fork steeds iets meer van de standaard OpenSSL versie gaat afwijken. Waardoor je op een gegeven moment upstream patches niet meer (zomaar) kunt doorvoeren en alsnog werk moet verzetten om bepaalde bugs goed om te lossen. De hoeveelheid werk die dit kost verschilt natuurlijk per patch.

Misschien dat Google in zijn eigen fork onderdelen gaat weglaten die in hun ogen niet noodzakelijk zijn, maar wel weer potentiële bugs kunnen introduceren.

[Rafe]

Waarom moet jij 3 verschillende libraries onderhouden? Ook voor Heartbleed waren er al zat alternatieven voor OpenSSL.

De reden voor BoringSSL staat in het bericht, Google onderhield al een versie van OpenSSL met eigen patches en maakt daar nu een fork van. Meer uitleg in nieuws: Google komt met fork van OpenSSL genaamd BoringSSL

Qua het tweede deel: je kan prima een self-signed certificaat voor je site gebruiken. Die wordt alleen niet standaard vertrouwd door browsers en besturingssystemen, en krijgen mensen een waarschuwing. Certificaten ondertekend door certificaatauthoriteiten worden wel vertrouwd, omdat ze aan verschillende richtlijnen moeten voldoen en daar met regelmatige audits op worden gecontroleerd. Dan nog moet je individuele vendors (Microsoft, Apple, Mozilla, etc) overtuigen om op hun vertrouwde lijsten te komen.

[Reactie gewijzigd door Rafe op 25 juli 2024 20:51]

[bigbadbull]

Voordeel dat Google wil behalen met hun "fork" is net dat ze sneller patches, fixes ed. sneller kunnen doorvoeren;
ze werken ook samen met beide andere varianten.

ja je kan ook selfsigned certificaten aanmaken maar die zijn veel beperkter in gebruik omdat jij ze ook zelf moet verspreiden.
selfsigned slaat wel meer op die certificaten die je per sessie opzet.
maar je kan ook persoonlijke / bedrijfs certificaten gebruiken, maar dan moet je ze zelf verspreiden en geven toch steeds een waarschuwing omdat ze niet standaard herkend worden.

Dat is tot zover ik de hele certificaat meuk begrijp.

[Yzord]

Voordeel dat Google wil behalen met hun "fork" is net dat ze sneller patches, fixes ed. sneller kunnen doorvoeren;
ze werken ook samen met beide andere varianten.

Waar ik mee zit is dat Google een Amerikaans bedrijf is en dus aan regels gebonden is voor wat betreft encryptie en de export ervan, ondanks dat dat in 2000 is versoepeld. Eerlijk gezegd, en dat is niet om Google te bashen, vertrouw ik dit "systeem" voor geen meter. Het mag dan een goede fork zijn, er zal en moet een backdoor in zitten om bijv. de NSA rond te kunnen laten snoepen. Tenslotte is het een Amerikaans bedrijf welke moet voldoen aan bepaalde eisen.

Kan iemand hier een lichtje over geven? Ik vind het namelijk rete interessant om te weten hoe dat nu zit met Amerikaanse encryptie. Dus hopelijk word ik niet meteen weggemod omdat ik het niet vertrouw van Google.

[THA_ErAsEr]

Iedereen kan zijn eigen certificaten aanmaken en ondertekenen, maar deze zijn niet secure. Iedereen kan zeggen dat die Microsoft is...

[Navi]

Vreemde naamgeving, BoringSSL?

[Darkfreak]

"BoringSSL is just that:
A simple, safe set of functions that just works and doesn’t do anything too fancy."

[bigbadbull]

Dat is omdat ze verveeld waren met het wachten op goedgekeurde patches

[Armin]

Je krijgt offtopic, maar het is juist spot on (en tevens een leuke verwijzing naar een van de kritieken op OpenSSL).

Google had een hele reeks patches, aanpassingen en voorstellen ingediend naar OpenSSL maar steeds meer daarvan waren nog niet eens in behandeling. Google wilde er naar eigen zeggen niet meer op wachten, en besloot de zaak om te draaien. Immers hierdoor wordt integratie steeds moeilijker omdat men elke keer een steeds grotere berg patches moet toepassen op een OpenSL release.

Vanaf nu integreren zij de pacthes van OpenSSL die zij interessant vinden in hun 'OpenSSL fork' en laten het aan OpenSSL over of zij de Google voorstellen willen accepteren, weigeren of negeren.

Apple deed een paar jaar geleden overigens hetzelfde.

[Anoniem: 134536]

creatiever dan de zoveelste YA variant.
YASC bijvoorbeeld

(Yet Another Ssl Certificate)

[Glashelder]

Blijkbaar hadden die mensen dus écht geen inspiratie voor een naam

[[Yellow]]

Vind de naam juist briljant gekozen.
Heb je wel eens in de openSSL code gekeken? Die is inmiddels zo ongelooflijk complex en uitgebreid geworden dat ze het aloude 'every problem can be solved by adding a new level of indirection' tot een ware kunst hebben verheven!

Geef mij maar boring software waar ik in een oogopslag de members en fields van kan begrijpen. Zeker als het om beveiliging gaat.

[robvanwijk]

Als ze de code dusdanig gaan herstructureren, is het dan nog wel mogelijk om bugs en patches te delen met OpenSSL...? Ik betwijfel of ze echt zo drastisch een andere kant op willen.

[Neko Koneko]

Blijkbaar hadden die mensen dus écht geen inspiratie voor een naam

Ach, het is orgineler dan overal "open" of, als dat al in gebruik is, "free" of "libre" voor te plakken

[Darkfreak]

Benieuwd hoe dit gaat uitpakken. Het heeft op zich wel het voordeel dat BoringSSL ook open-source is, waardoor LibreSSL en OpenSSL eenvoudig zaken kunnen implementeren binnen hun eigen structuur als ik het goed begrijp.

Zo houdt Google de 'veiligheid' en beheer in eigen huis en kunnen ze direct en gericht eventuele patches maken en doorvoeren, zonder iemand in de weg te staan of wat dan ook. En tegelijkertijd de overige SSL-projecten juist helpen.

[GeoBeo]

Iedereen die de OpenSSL code wel eens bekeken heeft zal deze beslissing van Google helemaal snappen en zal ook snappen hoe een bug als heartbleed erin heeft kunnen sluipen

[Dubbeldrank]

Dat zegt natuurlijk nog meer over de mensen die de code gezien hebben en allemaal de heartbleedbug over het hoofd gezien hebben. Een hoop mensen roepen wel dat open source beter is omdat iedereen de code kan inzien en verbeteren, in dit geval bleek dat verre van de realiteit.

[njitter]

heartbeat functie is iig helemaal eruit gesloopt. En zo nog een aantal zaken meer.

[gabba25]

Lijkt me duidelijk, dit is het gevolg van heartbleet

[svennd]

Lijkt me net niet eigenlijk, ze hadden heartbleed ook helemaal niet kunnen voorkomen en gezien ze nog patches van openSSL overnemen, kunnen ze evengoed ook zelf bugs implementeren ... Ik geloof dat dit gewoon iets gemakkelijker werkt dan steeds weer openSSL patchen.

[Anoniem: 609277]

Uit het artikel:

"Het is onduidelijk in hoeverre de beslissing is ingegeven door Heartbleed (...) Het BoringSSL-project was al opgestart voordat die bug aan het licht kwam."

[johnkeates]

Was PolarSSL ook niet goed genoeg?

[Anoniem: 481662]

Vraag me af hoeveel de NSA voor de backdoor betaalde.