Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security Android Chrome Chromium Google

Google Forks OpenSSL, Announces BoringSSL 128

Posted by Soulskill from the if-you-want-something-done-right dept.
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!!."
This discussion has been archived. No new comments can be posted.

Google Forks OpenSSL, Announces BoringSSL More

Google Forks OpenSSL, Announces BoringSSL

Comments Filter:

  • Yaaaay! (Score:5, Insightful)

    by Anonymous Coward on Saturday June 21, 2014 @08:34AM (#47288129)

    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.

    • Re: (Score:3, Insightful)

      by TheGratefulNet ( 143330 )

      right. google IS the premier spy company. they want ALL your data.

      and so, we are supposed to trust google on things about SECURITY and where user TRUST is involved?

      scuze me??

  • Choice is good, but I am not sure whether mess is good too. How much time before the OpenSSL forks get incompatibles API?

  • How will they address the attitude problem? (Score:2, Interesting)

    by Anonymous Coward

    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 somethin

    • Re:How will they address the attitude problem? (Score:5, Interesting)

      by colfer ( 619105 ) on Saturday June 21, 2014 @09:03AM (#47288257)

      Maybe by assigning people to the project who have not chosen security as a career field. On the Mozilla commits I used to follow, the personalities in the security arena were a different kettle of fish from the other developers. They had to maintain FIPS compliance, so were conservative about changes, but it was more than that. Not to mention, there's a possibility of workers with ulterior motives. All the more reason to develop a wider community than just self-selected specialists.

      The billion dollar companies can afford it, and should have a long time ago.

      • Re: (Score:1)

        by Anonymous Coward

        . They had to maintain FIPS compliance, so were conservative about changes

        IIRC OpenSSL also had to maintain FIPS compliance, it was one of the excuses used to claim why the very limited manpower wasn't used to improve actual security.

    • Re: (Score:1)

      by Anonymous Coward

      Don be ridiculous. Nobody is preventing you from reading the source code of FOSS crypto libraries. If you somehow manage to find a flaw and explain how it is a flaw (it isn't always obvious), there won't be an "unrelenting wrath of the security community toward outsiders" against you.

      If you want to use libraries written by amateurs that is your problem. That makes as much sense as getting a random person to fix a complex problem in your car because you think mechanics are hostile toward people who have no i

    • How will Google avoid this aspect of the problem?

      By putting such a horrible UI on it that nobody uses it. And then dropping it in about 6 months.

  • Worrysome (Score:3)

    by Virtucon ( 127420 ) on Saturday June 21, 2014 @09:07AM (#47288271)

    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?

    • Re:Worrysome (Score:5, Insightful)

      by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Saturday June 21, 2014 @09:23AM (#47288355) Homepage Journal

      Diversity is good, especially if they wind up diverging and actually being diverse. Not all implementations wind up being vulnerable to the same attacks, except when there are weaknesses inherent to the protocol. Even then a diverse... crap, I can't think of a non-buzzword to use here, landscape, ecosystem, argh. Sorry. Anyway, where was I? More variants means more approaches are likely to be attempted to solving the same problem, hopefully the best one wins and we get the best approach out of several options instead of whatever the single vendor comes up with.

      • I understand that but in the case of it being Google who has a tendency not to make their technology, like Android, forkable. [arstechnica.com] It's a one way street with them and I wouldn't trust any security implementation blessed by them. If it were Red Hat or even Microsoft I'd trust it more.

        • It's a one way street with them and I wouldn't trust any security implementation blessed by them

          Good! That should limit uptake, and encourage still more alternatives.

      • Diversity is good, especially if they wind up diverging and actually being diverse. Not all implementations wind up being vulnerable to the same attacks, except when there are weaknesses inherent to the protocol.

        Just be sure that as a developer you write an abstraction layer between the application and the library so that when the interfaces diverge too much you have a single class to rewrite. Diversity in implementations is a good thing. Diversity in the interfaces can be a pain in the butt.

    • Re:Worrysome (Score:4, Insightful)

      by NotBorg ( 829820 ) on Saturday June 21, 2014 @01:53PM (#47289429)

      Why not just help the OpenSSL folks strengthen an already great product

      Citation needed.

      • OpenSSL is the swiss army knife of encryption technologies.

        It can encrypt data with whatever cipher floats your boat. It can do hashing with whatever algorithm floats your boat. It can do SSL negotiations, it can examine, manipulate, and create X.509 certificates and containers like PKCS etc. Hell, it has all of the tools necessary to build an entire PKI up to and including creating Root Certificate Authorities, managing Certificate Revocation Lists, etc.

        There may be vulnerabilities in it, but Oh My God can

        • Re: (Score:2)

          by NotBorg ( 829820 )
          Because only positive facts are relevant?

          • Because negative facts dominate?

            • Re: (Score:2)

              by NotBorg ( 829820 )

              Positive: The device won't cut off your hands.
              Negative: The device will cut off your head.

              Maybe it's not so bad?
              Positive: It won't cut off your head.
              Negative: It will cut off your hands.

              Still no?
              Positive: It won't cut off your head, your kids are entertained and happy because...
              Negative: For about 20% of uses shocks the shit outta you.

              Still not enough? Ok
              Positive: This device is great, doesn't chop off your head or hands and it doesn't shock you.
              Negative: After about 3 months of heavy usage a small

    • > 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 becau

      • 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 M

        • 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 did read that, don't assume. Also don't assume anything Google does is for the benefit of anybody except Google. Google is a business and it still amazes me that people believe, with a straight face, that they won't shaft over everybody if corporate conscious comes between them and a buck.

  • 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
    • 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... [google.com]

      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"

      • 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

      • 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).

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

  • It is hip to be square (Score:5, Informative)

    by ctime ( 755868 ) on Saturday June 21, 2014 @09:34AM (#47288409)
    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.
    • Yes, but that's not what this seems to be about:

      We have used a number of patches on top of OpenSSL for many years. Some of them have been accepted into the main OpenSSL repository, but many of them don’t mesh with OpenSSL’s guarantee of API and ABI stability and many of them are a little too experimental.

      For something that includes experimental patches, *boring* would be an extremely stupid part of the name.

    • And if they called it snoozeSSL, the name doesn't matter. A name is a designation that should enable us to distinguish it from something of a similar kind, preferably it should be unique to avoid confusion. Since human beings are better at keeping names than numbers (usually, I'm not), we tend to label things with names.

      The point is, though, that this name means jack. Whether it is called BoringSSL or SuperspecialawesomeSSL doesn't matter. It is a name. Nothing else. Everything else is just the usual name c

      • Re:It is hip to be square (Score:4, Insightful)

        by Jiro ( 131519 ) on Saturday June 21, 2014 @10:28AM (#47288635)

        And if they called it snoozeSSL, the name doesn't matter. A name is a designation that should enable us to distinguish it from something of a similar kind...

        The point is, though, that this name means jack

        So *you're* the guy who named GIMP..

        Names actually do matter. Think of a name as a type of user interface, and a bad name as an ugly user interface.

        For that matter, think of a name as a way to deal with people, and a poorly named project as showing geekish lack of social skills. Saying "please" serves no function other than making people feel better. It doesn't mean anything more than the name. But that still means a lot, because we're human beings, and doing things with no technological effect is part of how we deal with other human beings.

        • Re: (Score:2)

          by tepples ( 727027 )

          Think of a name as a type of user interface, and a bad name as an ugly user interface.

          So how would you redesign this aspect of the user interface of, say, the GNU Image Manipulation Program?

          • So how would you redesign this aspect of the user interface of, say, the GNU Image Manipulation Program?

            Please, let's not mention Gimp and UI in the same sentence unless you're looking for an internet fight.

          • GNU Image Editor (GIE)

            GNU Raster Editing And Touchup (GREAT)

            GNU Image Manipulator (GIM)

            The last one is the one I'd go with. Simple and straight forward - drop the P, and you lose the weird sexual double entendre while gaining a nice verbage: "that image is a bit big. take it to the gim" "run it through the gim" etc.

            OSS seriously needs to be mindful of these things. There's some remote desk manager called "gigolo". Bravo to whoever named that - I can absolutely never install it on my kid's computers.

        • Re: (Score:1)

          by Anonymous Coward

          This. When will (some) programmers learn that humans have an API too, and that they're using it wrong?

  • Certify it (Score:3)

    by sinij ( 911942 ) on Saturday June 21, 2014 @10:43AM (#47288713)
    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.

    • wrong. FIPS certifcation has just been proven to be meaningless, and in fact the reason openssl was such dung. Most FIPS certfied systems have multiple known vulnerabilities now.

      Instead, those with a brain will chose the superior alternative being developed, and those in government will have to follow leadership and make a better standard.

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

      Right, because Google is irrelevant.

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

        Right, because Google is irrelevant.

        It will be if it can't sell products to the US government.

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

          Right, because Google is irrelevant.

          It will be if it can't sell products to the US government.

          What products does Google sell to the US government? And, in general, it's not like the government is the only customer in the world.

    • US gov't is largest consumer of cryptographic products in the North American market

      This doesn't make any sense. There are more Android phones than government employees, for instance (and thank goodness).

      Vis-a-vis LibreSSL - screw FIPS, Dual EC DRBG, and weak NSA coefficients - let the feds use OpenSSL if they want to.

      • "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.

    • On the flip side of that, anything with BoringSSL will not be restricted from exporting outside of the U.S. /snark

  • Its name was, in fact, Boren.

  • For SameOldSSL and SSLYourWAY

  • 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

  • I thought that BoringSSL was named in honor of classic Superman artist Wayne Boring. [wikipedia.org]

Slashdot Top Deals

news: gotcha

Close