
Boring SSL - FredericJ
https://www.imperialviolet.org/2014/06/20/boringssl.html
======
mben
Theo's opinion about BoringSSL and LibreSSL portability:
[http://article.gmane.org/gmane.os.openbsd.tech/37174](http://article.gmane.org/gmane.os.openbsd.tech/37174)

------
matteotom
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
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
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.

~~~
forrestthewoods
There is no singular "you". Google is a 50,000 person company. The 70 patches
were likely written by dozens of different employees for different projects
with different code bases. Some of authors may no longer even work at Google.

~~~
moonfern
It's not a matter of trust:

[http://users.skynet.be/bs939021/artikels/group%20versus%20in...](http://users.skynet.be/bs939021/artikels/group%20versus%20individual%20performance.pdf)

Are N+1 heads better then one? The group is better then the average head.
Heads are worse then the best head.

I do not know however if Google makes reviewing the patches more time
intensive then it should be, it all depends on the rate of progress, isn't it?

------
borando
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
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
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://opensslfoundation.com/what.html)
[http://www.openbsd.org/papers/bsdcan14-libressl/mgp00008.htm...](http://www.openbsd.org/papers/bsdcan14-libressl/mgp00008.html)

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

------
fiatmoney
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.

~~~
yellowapple
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.

~~~
piusvii
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.

~~~
yellowapple
I'm hopeful for that, too. Many of the qualms with the preliminary libressl
ports revolve around (IIRC) the lack of exploit mitigation features in the
operating systems being ported to; perhaps a proper port would be yet another
encouragement for those features to be implemented in non-OpenBSD unixen
(given that - from what I understand - both FreeBSD and Linux already have the
code to support those features, and just need them to be enabled)?

------
AlyssaRowan
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](https://tools.ietf.org/html/rfc6979) \-
Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic
Curve Digital Signature Algorithm (ECDSA)

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

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

~~~
nadaviv
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.

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

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

~~~
iancarroll
Google and XMPP

~~~
lnanek2
That history has been really sad from the Android side too, not just the users
who can't chat together any more. In the first Android beta there were a lot
of XMPP classes that were really powerful, if you had all the right
permissions and the user had the other people friended and running the same
app, you could fire system events (intents) right in the other app through
them. But in the second beta the XMPP classes were renamed GoogleTalk classes,
and then on release they were all taken away. Now every app has to include a
huge smack lib to have even less power than they had in the beta.

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

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

