6 ms·

Boring SSL

161 points by FredericJ 12y ago

peterwwillis 12y ago
Yet another vendor implementation, yet more divergent behavior to be expected...
- codezero 12y ago
  What are some good examples of a vendor implementation that has divergent behavior that affects users negatively?
  - mappu 12y ago
    "Embrace Extend Extinguish".
  - iancarroll 12y ago
    Google and XMPP
    - lnanek2 12y ago
      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.
  - tedunangst 12y 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 12y ago
    80s and 90s Unix.
- piusvii 12y 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 12y 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 12y 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 12y 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.
    - tedunangst 12y ago
      The trade off is that your patches are for things that you clearly care about, and do not want to lose. Having played this game several times, several ways, whichever branch the "patches" come from is lossy.
    - forrestthewoods 12y ago
      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.
fiatmoney 12y 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.
- dchest 12y 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.
- deleted 12y ago
  [deleted]
- gonzo 12y ago
  Not if you're tired of OpenBSD's "fund us to make it work for other platforms" screed.
  - yellowapple 12y 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-fnord 12y 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.
Istof 12y ago
offtopic... that is a pretty bad custom font (might as well stay with the defaults)
- deleted 12y ago
  [deleted]
- smackfu 12y ago
  Looks fine to me on a Mac in Safari.
- yellowapple 12y ago
  At least it's not Comic Sans as the OpenBSD/LibreSSL folks opted for ;)
borando 12y 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 12y 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 12y 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://opensslfoundation.com/what.html http://www.openbsd.org/papers/bsdcan14-libressl/mgp00008.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 12y ago
Moderators: Name should be BoringSSL, not Boring SSL. It is the tentative name of Google’s OpenSSL fork.
- nadaviv 12y 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 12y ago
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
acntjustforthis 12y ago
Here's a somewhat related question, Why is Google forcing a broken cipher (RC4) in Youtube? IE11 disables RC4 completely. Specifically, the server that actually serves the video only accepts RC4 connections over TLS. You can also connect to the same server over plain HTTP. See https://support.mozilla.org/en-US/questions/990082 https://support.mozilla.org/en-US/questions/990082 r19---sn-ab5l6nel.googlevideo.com
AlyssaRowan 12y 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 https://tools.ietf.org/html/rfc6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
- AlyssaRowan 12y ago
  Bug filed, btw, response received, it's probably going to be replaced with a better implementation.

Boring SSL

161 points by FredericJ 12y ago

peterwwillis 12y ago

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

codezero 12y ago
What are some good examples of a vendor implementation that has divergent behavior that affects users negatively?
- mappu 12y ago
  "Embrace Extend Extinguish".
- iancarroll 12y ago
  Google and XMPP
  - lnanek2 12y ago
    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.
- tedunangst 12y 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 12y ago
  80s and 90s Unix.
piusvii 12y 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 12y 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 12y 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 12y 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.
  - tedunangst 12y ago
    The trade off is that your patches are for things that you clearly care about, and do not want to lose. Having played this game several times, several ways, whichever branch the "patches" come from is lossy.
  - forrestthewoods 12y ago
    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.

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

dchest 12y 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.
deleted 12y ago
[deleted]
gonzo 12y ago
Not if you're tired of OpenBSD's "fund us to make it work for other platforms" screed.
- yellowapple 12y 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-fnord 12y 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.

Istof 12y ago

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

deleted 12y ago
[deleted]
smackfu 12y ago
Looks fine to me on a Mac in Safari.
yellowapple 12y ago
At least it's not Comic Sans as the OpenBSD/LibreSSL folks opted for ;)

borando 12y 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 12y 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 12y 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://opensslfoundation.com/what.html http://www.openbsd.org/papers/bsdcan14-libressl/mgp00008.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 12y ago

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

nadaviv 12y 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 12y ago

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

acntjustforthis 12y ago

Here's a somewhat related question, Why is Google forcing a broken cipher (RC4) in Youtube? IE11 disables RC4 completely. Specifically, the server that actually serves the video only accepts RC4 connections over TLS. You can also connect to the same server over plain HTTP. See https://support.mozilla.org/en-US/questions/990082 https://support.mozilla.org/en-US/questions/990082 r19---sn-ab5l6nel.googlevideo.com

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

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