Slashdot Mirror
Google Forks OpenSSL, Announces BoringSSL
An anonymous reader writes Two months after OpenBSD's LibReSSL was announced, Adam Langley introduces Google's own fork of OpenSSL, called BoringSSL. "[As] Android, Chrome and other products have started to need some subset of these [OpenSSL] 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. So we're switching models to one where we import changes from OpenSSL rather than rebasing on top of them. The result of that will start to appear in the Chromium repository soon and, over time, we hope to use it in Android and internally too." First reactions are generally positive. Theo de Raadt comments, "Choice is good!!."
Just what I needed this Saturday, the announcement of yet another implementation of SSL by people I do not to trust
oh joy, oh rapture, etc. etc. etc.
Choice is good, but I am not sure whether mess is good too. How much time before the OpenSSL forks get incompatibles API?
A huge part of the problem with OpenSSL is the attitude that anyone but the "Anointed Few" are discouraged from getting involved with security research or the development of cryptographic software.
I know we're all familiar with the common saying, "Never roll your own crypto!" It's this attitude that drives good people away from even just analysing existing crypto code. Nobody wants to feel the unrelenting wrath of the security community toward outsiders, especially if you happen to find a flaw with something they created.
How will Google avoid this aspect of the problem? Fixing the software bugs are one thing, but the bugs within the community itself are probably far harder to fix.
In many cases, having one "standard" that everyone follows, and therefore everyone can communicate with is much better than "choice" of which vendor to be locked into or which web engines are worth programming for. Compare email (you can choose your provider, but regardless, you can email anyone) vs. social networking (if you choose Facebook and your friend is the one person on Google+, you're out of luck)
In this case, I don't see too much wrong with the fork, but I don't trust Google, and I'm afraid that if enough websites use "BoringSLL" (what the hell kind of name is that btw?) Google will do something evil involving advertising or selling your data.
In some ways the announcement makes sense in technical terms, yet still doesn't seem entirely straight. The core infrastructure initiative has for various reasons ended up supporting OpenSSL, and this might be Google's way of saying that libressl is the way to go.
I was about to write a witty reply to your comment, however the result would not have been interesting, tedious to read, dull, monotonous, repetitive, unrelieved, unvaried, unimaginative, uneventful, characterless, featureless, colorless, lifeless, insipid, uninteresting, unexciting, uninspiring, unstimulating, uninvolving, unreadable, unwatchable, jejune, flat, bland, dry, stale, tired, banal, lackluster, stodgy, vapid, monochrome, dreary, humdrum, mundane, mind-numbing, wearisome, tiring, tiresome, irksome, trying, frustrating, informaldeadly, ho-hum, dullsville, dull as dishwater, plain-vanilla and as boring as a one-man play.
Get free satoshi (Bitcoin) and Dogecoins
Google forking OpenSSL into their own brand of NSA friendly, privacy snooping SSL. Why not just help the OpenSSL folks strengthen an already great product and assist in regression testing and validation as well? No grow your own and fragment the community you say?
Harrison's Postulate - "For every action there is an equal and opposite criticism"
Seems like forking is out of control. If bugs are missed in the most premier open source version of ssl, how does forking solve this issue? It's not like the reason heart bleed happened was because of some strange stone walling by openssl. I would rather have some RFC compliant standard version of SSL instead of SSL behaving more like web browser javascript and html compat.
Of course I won't be surprised by all the Google fanboys jumping all over this. Google is probably worse than Microsoft, but people think Google is the evil you can trust.
Hey, I don't like your nickname. Thoughts?
Google makes a lot of money on your data. They mine the crap out of your email. Their CEO has said privacy online is silly since if you've done nothing wrong you have nothing to hide. Summed up: they're indifferent to your sense of privacy. But trust Google to protect it's own interests. It wants to control access to this data. They'll be happy to comply with government requests for data, but on their own terms, and not by willfully subverting the security itself and leaving the door wide open. Being the doorkeeper makes them powerful. Being a doormat is not in their interest.
For those having a hard time understanding the naming convention,
Boring: Not flashy, not exciting, not experimental, not sexy. Performs as expected.
In other words, exactly how I want my security libraries, my databases, and the other critical infrastructure that runs the planet to be described as. Boring is good. A choice between boring Plain Jane and Simple Sally? Even better. Thank you.
they call it BoringSSL because it contains a backdoor tunneling protocol.
They're forking it, but not like LibReSSL (I like that capital R - it makes a hell of a difference). Their library isn't actually meant to be used outside of their pet projects as far as I understand. If you're not Google, you're still expected to use vanilla OpenSSL, or LibReSSL when it becomes stable. I also get this feeling that when LibReSSL becomes stable BoringSSL might go away, and its stopgap role come to an end.
First reactions are generally positive. Theo de Raadt comments, "Choice is good!!."
The name "BoringSSL."
I am finding extreme difficulty in liking this name choice. What was Google thinking? Am I alone?
It's not "What was Google thinking?", it's "What was Adam Langley thinking?". As for what he was thinking, it's pretty simple: Fundamental security components like SSL/TLS should be very, very boring. They're not a place for innovation and experimentation, they're not a place for clever code that demonstrates the author's virtuosity (assuming there is any such place, outside of Obfuscated C contests). They're not a place for exploration of how the C preprocessor can be used to automatically generate much of the codebase (which is something that OpenSSL has done). They're where you want very simple, straightforward, boring implementations of industry best practice algorithms and protocols.
When it comes to security, boring is good.
As Langley said in his blog post, the name is aspirational. But it is his goal, to produce a security library which is completely boring. And it's a good thing.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
EnnuyeuxSSL
verb
make (a hole) in something, esp. with a revolving tool.
Without FIPS certification system engineers won't be able to include BoringSSL in US-government facing applications, since doing so will disqualify them from procurement lists. Since US gov't is largest consumer of cryptographic products in the North American market, BoringSSL must certify or stay irrelevant.
All I say is OUCH!
Look at the code you wrote yourself 10-20 years ago.
The simple boring code you still understand and still can compile and use today.
Now look at the code where you put in every trick in the book and then some. Can you understand? Does it compile today? Does it even have a useful function to use today? Is it bug free after all this time?
Unless you did a good job documenting it I am betting there is a no to one of those questions.
To put it bluntly, heartbleed was exciting and in security, exciting is bad.
If I have been able to see further than others, it is because I bought a pair of binoculars.
Actually this isn't silly. Intel has compromised CPU instruction set due to NSA influence (whether that was via a secret order or just because they bend over when asked is unknown). Just look at what this Google engineer said:
https://plus.google.com/+Theod...
So given the option of getting a back door inserted in the SSL protocol used by a huge chunk of the world - the NSA will try to corrupt it.
If served with a secret order, from a secret court on the desire of the NSA for "national security" reasons with orders to, of course keep it secret, Google would have no choice but to comply. The fact that it'll be open source would allow for the possibility of it getting caught (but only the possibility), and I doubt that would keep the NSA from trying to corrupt all 3 SSL protocols as they are being reworked currently. JMHO...
Your usage of informaldeadly is informaliffy, informalshady and informaldodgy, in my humble opinion.
Its name was, in fact, Boren.
...when you can have two.
At first I thought it was an April Fool's Day joke.
There's no guarantee that Intel was actually compromised, though they would have been an obvious target. More likely that effort was aimed at dedicated hardware RNGs, which have been a thing since well before RDRAND, but the final point of the post (about not trusting RNGs you can't audit) has obvious merit.
Also, while I think I know what you mean, "all 3 SSL protocols" makes no sense. There are currently four SSL/TLS protocols in use (SSL3, TLS1, TLS1.1, TLS1.2) plus a deprecated one (SSL2, which is broken; SSL1 was never published AFAIK). If you meant SSL implementations, there are at least seven: the three OpenSSL-derived ones (OpenSSL, LibReSSL, BoringSSL), BouncyCastle (which is technically two implementations, Java and C#, but they are supposed to be equivalent), GnuTLS, Mozilla's one (may be client-only?), Apple's one (I think does both client and server but could be wrong), and Microsoft's SChannel (client and server).
There's no place I could be, since I've found Serenity...
> they call it BoringSSL because it contains a backdoor tunneling protocol.
In fact, I was thinking: "Boring, my ass", but I didn't know exactly why.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
For SameOldSSL and SSLYourWAY
NSA decided to follow Google's path and annouced a fork of OpenSSL, they will call the new fork SuckingSSL. First reactions are generally positive.
Achille Talon
Hop!
May you live in interesting times is a curse for a good reason.
They'll be happy to comply with government requests for data, but on their own terms, and not by willfully subverting the security itself and leaving the door wide open.
I think people forget that regular ol' poor programming may leave things open--incompetence over malice.
OMG facts!
You mean FreedomSSL?
And response from security people have either been very positive or they weren't available for comment right now.
It's The Golden Rule: "He who has the gold makes the rules."
> Why not just help the OpenSSL folks strengthen an already great product and assist in regression testing and validation as well?
OpenSSL can't do alot of things they'd like to do because it would break binary compatibility with the old ABI. There are also a number of improvements that would change the API. OpenSSL has committed to sticking with not only the old API, but the old ABI, so you an old program can use the new openssl without even recompiling.
Google isn't restricted by those two things because they recompile Android daily or weekly anyway. Therefore, there's no reason they wouldn't make improvements that change the binary interface. They'd be forgoing significant improvements just for the sake of us the same bad abi that someone designed many years ago, which has no benefit in their products.
They can still send over improvements that they devfolks In some cases, it will be up to the OpenSSL folks to decide if they want to contort the new improvements to fit in the legacy ABI or API.
jejune, must remember that one...
"Largest consumer" means they buy more than ANYONE else, not more than EVERYONE else.
Does the world's largest man account for over half the weight of all humans? No, he's bigger than any other man, not bigger than all other men put together. A lot of people buy Android phones. Can you name a consumer who buys more than the US government.
LibreSSL maintains API and ABI compatibility with OpenSSL, so you can upgrade your encryption without rewriting all of your applications. That's one reason that people in general use LibreSSL rather than something completely different. Also, it's on its way to becoming the most thoroughly audited SSL/TLS library in the world.
Google doesn't mind recompiling their software, so they need only API compatibility, not ABI compatibility.
I think OpenSSL should be broken up into pieces that work together so different parts can be worked on separately. Needless to say I think the OpenBSD group has the better, more achievable for open source, path for the future of the library. I'm not a hater of all things Google; but, I don't think "in-house" code is a good choice for the GNU parts of Linux/BSDs
Having to work for a living is the root of all evil.
On the flip side of that, anything with BoringSSL will not be restricted from exporting outside of the U.S. /snark
Having to work for a living is the root of all evil.
they call it BoringSSL because it contains a backdoor tunneling protocol.
The first vulnerability should be called "crocodile tears".
Good points but a lot of speculation on Google's intentions. I think it'll be like everything else they've done for open source. Embrace, Extend and then Emprision (sic) much like "we don't like Java so we'll make our own" It's the Bender philosophy. Sure OpenSSL may have an older API/ABI however what's the driving factor for something new? There's just no way I can trust Google after the NSA revelations and their incessant tracking crap. First it was Facebook and all their damn trackers now Google Metrics, Google Analytics on almost every fucking webpage out there. Sorry do no evil is no longer valid at Google and I look at any attempt at embracing or forking and already existent open source project as suspicious and motivated by some shit that'll eventually get me condom ads.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
No surprise.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Yes, it's hard to get excited about BoringSSL.
"If anything can go wrong, it will." - Murphy
I thought that BoringSSL was named in honor of classic Superman artist Wayne Boring.
http://alternatives.rzero.com/
It's not speculation at all, I pretty much quoted the discussion that led to the fork. I just added a very brief explanation of the terms ABI and API.
> and I look at any attempt at embracing or forking
It appears that you refused to look at it at all, preferring to apply your preconceived conclusion without bothering to take 60 to read what is happening and why.
I'm not suggesting Google is impervious to coercion, only that the have an incentive to maintain as secure a platform as they are able. They are no more vulnerable to corruption than OpenSSL was (though it could even be argued that their political and economic clout makes them less vulnerable; but I wouldn't get behind that position).