Boring SSL

https://www.imperialviolet.org/2014/06/20/boringssl.html

by FredericJ • 12 years ago

161 41 12 years ago

imperialviolet.org

peterwwillis• 12 years ago

Yet another vendor implementation, yet more divergent behavior to be expected...

codezero• 12 years ago

What are some good examples of a vendor implementation that has divergent behavior that affects users negatively?

mappu• 12 years ago

"Embrace Extend Extinguish".

iancarroll• 12 years ago

Google and XMPP

tedunangst5• 12 years ago

F5 load balances are a good example, where they reject TLS packets between 256 and 511 bytes in length, requiring user libraries to pad packets in that range to longer lengths.

awda• 12 years ago

80s and 90s Unix.

piusvii2• 12 years ago

True but this implies that everyone should just use what's free so it can all be the same; even if the standard has many years-long unfixed bugs and is unresponsive to community fixes. I'm glad it's come to a head if it gets rid of a false sense of security.

matteotom• 12 years ago

So from what I understand, Google has a bunch of OpenSSL patches they use. They used to re-apply those patches to each new OpenSSL release, but now they're going to keep their own branch (BoringSSL) and pull and merge changes from OpenSSL?

What are the costs/benifits of one method over the other?

agl• 12 years ago

I think the costs and benefits are pretty much what you would expect. If your diff from upstream is small, then the tradeoff strongly favours rebasing against upstream and tracking it.

However, as the diff becomes larger, the tradeoff shifts. I think we passed that point a while back but, since we were going to switch models anyway, I took some time to clean up some bits of the code too.

ars• 12 years ago

I'm not so convinced about the tradeoff.

With your own patches you know exactly the reason and intent for each one - you wrote it! So you can rapidly figure out what to change to make them fit with the new release.

But in reverse you are going to have to grok every new change sent your way, and that it going to be a massive amount of work.

Some of it will be easy stuff: It's clear what they are doing, or it patches cleanly and you don't worry about it.

But then you'll run into more confusing changes and you're going to have a harder time. There is a human tendency to ignore that which you can not understand, and you'll have some of those, then a patch on top of them, and the final result is more work than you started with.

tedunangst5• 12 years ago

Fewer surprises. You don't wake up one day and discover that TLS heartbeats have appeared in your library as a result of previous upgrades. Every upstream change has to be reviewed because that's the only way it gets in. Also, local changes are much less likely to be lost as a result of merge conflicts.

The downside is that you may miss some upstream changes that you do care about.

fiatmoney• 12 years ago

How, if at all, is this envisioned to interact with the work going on in LibreSSL?

I realize LibreSSL is optimized for BSD and Google is primarily Linux, but it seems silly to fork the code in 2 different directions.

dchest2• 12 years ago

Penultimate sentence:

But we’ll also be more able to import changes from LibreSSL and they are welcome to take changes from us. We have already relicensed some of our prior contributions to OpenSSL under an ISC license at their request and completely new code that we write will also be so licensed.

gonzo2• 12 years ago

Not if you're tired of OpenBSD's "fund us to make it work for other platforms" screed.

yellowapple4• 12 years ago

I'm not tired of it at all. Programming ain't free, and if anyone could use some funding, it's them.

I mean, it's not like Apple's going out of their way to make Aqua work on non-OSX unixen, or systemd's going out of its way to work on non-Linux unixen. Just like how those rely on features of their host platforms, LibreSSL currently relies heavily on OpenBSD-specific security features in the kernel and userland, and it'll take quite a bit more effort to port that to other platforms in a secure and correct way.

Now granted, I'm an OpenBSD user, so my opinion on this is biased. However, it's the same opinion that many Linux-specific or BSD-specific or OSX-specific or Solaris-specific or Windows-specific or VMS-specific or MULTICS-specific or what-have-you-specific projects seem to already have: focus on your primary target(s), then help with porting efforts to secondary targets when it works well on the primaries.

vezzy-fnord2• 12 years ago

The OpenBSD Foundation has actually been one of the most receptive projects when it comes to software portability. Yes, they target OpenBSD first, but they provide compatibility shims for all other platforms. In general, their philosophy is that it's better to reuse tried and tested code, rather than reimplement poorly from scratch. And their politics reflect that.

gonzo2• 12 years ago

I see the openbsd down vote patrol arrived. Good on ya, fearless leader will be proud.

yellowapple4• 12 years ago

Android already uses the OpenBSD libc (IIRC), so it's not inconceivable that they'll eventually do the same thing with libssl and switch to the OpenBSD implementation.

What's great about this, though, is that Google's contributions are potentially helpful in LibreSSL's eventual cross-platform porting efforts; their willingness to adopt the ISC license for their contributions is already a promising sign of that collaborative potential.

vezzy-fnord2• 12 years ago

I'm pretty sure Bionic has diverged quite significantly from BSD libc.

briandh• 12 years ago

Android already uses the OpenBSD libc (IIRC)

It is a mix of code from OpenBSD, NetBSD, and FreeBSD [1][2]

[1] http://youtu.be/G-36noTCaiA?t=19m40s

[2] http://codingrelic.geekhold.com/2008/11/six-million-dollar-l...

piusvii2• 12 years ago

Totally agree. I love what libressl is doing and my great hope from this effort is that Google's people will port libressl PROPERLY onto Linux. That is critical for the parts where OpenBSD clearly states that the underlying OS must provide key pieces like random number generation, but the implementation must be done right and is often done poorly in initial ports.

tedunangst5• 12 years ago

The chacha20 support, for example, has already been pulled from googssl to libressl.

cnst• 12 years ago

If it was taken directly from goog ssl, shouldn't it have the ISC licence?

http://bxr.su/OpenBSD/lib/libssl/src/crypto/evp/e_chacha20po...

Istof• 12 years ago

offtopic... that is a pretty bad custom font (might as well stay with the defaults)

smackfu• 12 years ago

Looks fine to me on a Mac in Safari.

yellowapple4• 12 years ago

At least it's not Comic Sans as the OpenBSD/LibreSSL folks opted for ;)

borando• 12 years ago

Great news! Hopefully between LibreSSL and BoringSSL, OpenSSL will go away and never return. I think AGL and the LibreSSL team will be able to do some fantastic informal collaboration. I'm looking forward to a healthy TLS ecosystem.

x1798DE• 12 years ago

That's pretty brutal. One reason why Heartbleed was such a potential problem was the monoculture that tends to come when FOSS software becomes reliable and popular. Having more options out there is good, but I don't see why OpenSSL needs to go away. It had one major zero-day, then when people started paying attention to it, it got 1. a lot of attention to its security and 2. a not insignificant increase in much-needed financial support. Hopefully, we'll see more stable and well-tested TLS libraries out there, and the fact that there are now a few forks of OpenSSL is a good start.

currysausage• 12 years ago

Not that I necessarily disagree with you, but I do want to add two points for consideration:

1. a lot of attention to its security

That doesn't help if bug reports rot in the tracker for years. The developers' attitude might have changed under the current media attention, but for how long will that last? I have yet to read a public statement by the OpenSSL team on how they plan to improve code quality and processes in the long run.

2. a not insignificant increase in much-needed financial support

Even before Heartbleed, OpenSSL might not have been as poor as often reported: http://opensslfoundation.com/what.html http://www.openbsd.org/papers/bsdcan14-libressl/mgp00008.htm...

Again, I am too much of an outsider here to judge, I just want to add these points for consideration.

alanh• 12 years ago

Moderators: Name should be BoringSSL, not Boring SSL. It is the tentative name of Google’s OpenSSL fork.

nadaviv• 12 years ago

Yeah, I agree. I thought this was an article about someone claiming SSL is boring. BoringSSL makes it much clearer that its referring to something with that name.

mben• 12 years ago

Theo's opinion about BoringSSL and LibreSSL portability: http://article.gmane.org/gmane.os.openbsd.tech/37174

AlyssaRowan2• 12 years ago

Makes a hell of a lot more sense than rebasing 70-odd separate patches for your internal use! Making LibReSSL-portable is a good goal, and this work can be used to improve both (and OpenSSL, too - some of this found its way into the OpenSSL 1.2 branch).

I think the "safe" (EC)DSA nonce implementation is interesting but could use some review, and I've communicated that to the author: it's not as good as the proposal in RFC6979[1] (which uses HMAC_DRBG - which is good - to generate a truly deterministic DSA nonce, with test vectors and everything!). In particular, BN_generate_dsa_nonce from these patches uses modular reduction down into the prime order, which has a small bias towards 0 of course. The NIST prime orders aren't as close to powers of two as you might like to get away with that, and if I'm being honest, I'm not sure you can get away with anything with (EC)DSA - it is extraordinarily fragile in a way I think was always deliberate. The practical impact is probably limited, but I really don't want to take any chances there. (Ideally I'd want Ed25519, or something very like it - there really ought to be some more discussion on CFRG about that - although it's going to be quite some time before anyone can roll it out in certificates widely.)

Right now, it's still lipstick on a pig. OpenSSL is hairy as fuck. Long-term, I think the LibReSSL cleanup-via-demolition approach and then carefully rebuilding what's left over is what's needed. But I'm not sure I'd want to run LibReSSL in the middle of such fundamental reworking - and in the meantime, some of these patches look quite familiar to me. :) ___ 1. https://tools.ietf.org/html/rfc6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)

AlyssaRowan2• 12 years ago

Bug filed, btw, response received, it's probably going to be replaced with a better implementation.

Boring SSL

Related Stories