Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Google Forks OpenSSL, Announces BoringSSL

Soulskill posted about a month ago | from the if-you-want-something-done-right dept.

Security 128

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

cancel ×

128 comments

Yaaaay! (5, Insightful)

Anonymous Coward | about a month ago | (#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:Yaaaay! (3, Insightful)

TheGratefulNet (143330) | about a month ago | (#47288239)

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??

Re:Yaaaay! (5, Funny)

grub (11606) | about a month ago | (#47288277)


Google SSL... Now with a side channel for ads.

Re:Yaaaay! (4, Interesting)

Megane (129182) | about a month ago | (#47288345)

Yes. Because they don't want anyone else to have that data that they have gone to such effort to collect.

Or at least not without paying for it.

Re:Yaaaay! (0)

Anonymous Coward | about a month ago | (#47288385)

Well, that's a great reason. Now, go eat more crumbs, capitalist pig.

Re:Yaaaay! (2, Informative)

Opportunist (166417) | about a month ago | (#47288503)

I prefer to eat capitalists.

Re:Yaaaay! (1)

danomac (1032160) | about a month ago | (#47289029)

What do you do about the aftertaste afterwards?

Re:Yaaaay! (1)

armanox (826486) | about a month ago | (#47289155)

Vodka, comrade

Re:Yaaaay! (1)

Zeek40 (1017978) | about a month ago | (#47289949)

You expect to be billed for it. With interest.

Re:Yaaaay! (2)

swillden (191260) | about a month ago | (#47289681)

Yes. Because they don't want anyone else to have that data that they have gone to such effort to collect.

Or at least not without paying for it.

FYI, Google does not sell user data.

Re:Yaaaay! (0)

Anonymous Coward | about a month ago | (#47289901)

Yes, they take payments to exploit your data on behalf of third parties.

Re:Yaaaay! (0)

Anonymous Coward | about a month ago | (#47288541)

Whom can you trust, really?

Choice is good (1)

manu0601 (2221348) | about a month ago | (#47288157)

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

Choice is NOT ALWAYS good (0)

Anonymous Coward | about a month ago | (#47288211)

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.

Re:Choice is NOT ALWAYS good (4, Insightful)

colfer (619105) | about a month ago | (#47288291)

BoringSSL is a great name and directly addresses what got OpenSSL into trouble most recently, implementing a new protocol parameter based on a student's idea for a degree thesis. Innovation for innovation's sake, that was. Hurriedly applied for some reason.

And it's not something a website would "use," if you mean a high level protocol akin to "https." It's a library to implement common standards.

Re:Choice is NOT ALWAYS good (3, Informative)

NotInHere (3654617) | about a month ago | (#47288401)

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)

That's one of the reasons why I have email, jabber, and sms (and webrtc), but no social network.

Re: Choice is NOT ALWAYS good (1)

aojensen (1503269) | about a month ago | (#47289537)

If I recall correctly, OpenSocial tried to solve exactly that problem?

Re: Choice is NOT ALWAYS good (1)

aojensen (1503269) | about a month ago | (#47289541)

If I recall correctly, OpenSocial tried to solve exactly that problem? http://opensocial.org/ [opensocial.org]

Re:Choice is good (1)

neoform (551705) | about a month ago | (#47288251)

I'd assume once a clear winner is chosen as to which is better...

I don't see the open source SSL library 'market' being the next browser war where incompatibility makes one product win over another...

Re:Choice is good (0)

Noah Haders (3621429) | about a month ago | (#47290523)

problem is if one solution is good for everybody but google implements boringssl in all their services and products, then everybody will be using boringssl regardless.

What a name! (-1)

bogaboga (793279) | about a month ago | (#47288201)

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?

Re:What a name! (5, Funny)

ArcadeMan (2766669) | about a month ago | (#47288261)

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.

Re:What a name! (0)

Anonymous Coward | about a month ago | (#47289015)

Your usage of informaldeadly is informaliffy, informalshady and informaldodgy, in my humble opinion.

Re:What a name! (1)

ChunderDownunder (709234) | about a month ago | (#47290867)

jejune, must remember that one...

Re:What a name! (0)

Anonymous Coward | about a month ago | (#47288321)

Hey, I don't like your nickname. Thoughts?

Re:What a name! (5, Funny)

Anonymous Coward | about a month ago | (#47288439)

they call it BoringSSL because it contains a backdoor tunneling protocol.

Re:What a name! (1)

Anonymous Coward | about a month ago | (#47288881)

All I say is OUCH!

Re:What a name! (1)

marcello_dl (667940) | about a month ago | (#47289521)

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

Re:What a name! (1)

AchilleTalon (540925) | about a month ago | (#47289863)

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.

Re: What a name! (1)

Terrasque (796014) | about a month ago | (#47290477)

You mean FreedomSSL?

And response from security people have either been very positive or they weren't available for comment right now.

Re:What a name! (0)

Anonymous Coward | about a month ago | (#47291179)

they call it BoringSSL because it contains a backdoor tunneling protocol.

The first vulnerability should be called "crocodile tears".

Re:What a name! (5, Informative)

swillden (191260) | about a month ago | (#47288567)

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 [imperialviolet.org] , the name is aspirational. But it is his goal, to produce a security library which is completely boring. And it's a good thing.

Look at your own code (1)

Anonymous Coward | about a month ago | (#47288927)

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.

Re:What a name! (2)

Qzukk (229616) | about a month ago | (#47288945)

To put it bluntly, heartbleed was exciting and in security, exciting is bad.

Re:What a name! (0)

Anonymous Coward | about a month ago | (#47289977)

May you live in interesting times is a curse for a good reason.

Re:What a name! (0)

Anonymous Coward | about a month ago | (#47289327)

At first I thought it was an April Fool's Day joke.

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

Anonymous Coward | about a month ago | (#47288205)

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.

Re:How will they address the attitude problem? (4, Interesting)

colfer (619105) | about a month ago | (#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:How will they address the attitude problem? (1)

Anonymous Coward | about a month ago | (#47288783)

. 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:How will they address the attitude problem? (1)

Anonymous Coward | about a month ago | (#47289981)

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 idea what they're babbling about.

People love to rant on how OpenSSL failed with heartbleed, how all communities they're not part of are evil. But when the time comes to do the work, for free (go look how many millions OpenSSL doesn't make), it's only those with an "attitude problem" who get things done.
Here's an idea: create your own crypto library and run it with your own rules. You can even fork an existing project.

Google now backs libressl? (0)

Anonymous Coward | about a month ago | (#47288247)

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.

Worrysome (2)

Virtucon (127420) | about a month ago | (#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 (4, Insightful)

drinkypoo (153816) | about a month ago | (#47288355)

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.

Re:Worrysome (1)

Virtucon (127420) | about a month ago | (#47288669)

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.

Re:Worrysome (1)

drinkypoo (153816) | about a month ago | (#47288697)

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.

Re:Worrysome (2)

Fnord666 (889225) | about a month ago | (#47288913)

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 (-1)

Anonymous Coward | about a month ago | (#47289463)

There are two kinds of people in this world. Those that say diversity and forking are OK and those that run around yelling and screaming "AHHH!!!!! END OF THE WORLD AHHHH FRAGMENTATION AHHHH!!!!!!! OMG EVERY INSTANCE OF FRAGMENTATION IS THE END!!!!! AHHHH!!!!"

Re:Worrysome (1)

drinkypoo (153816) | about a month ago | (#47289639)

There are two kinds of people in this world.

Oh no! We need more kinds of people!

Re:Worrysome (0)

Anonymous Coward | about a month ago | (#47289731)

If only we didnt have so much fragmentation between people...

Re:Worrysome (3, Insightful)

NotBorg (829820) | about a month ago | (#47289429)

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

Citation needed.

because Google doesn't need two major limitations (1)

raymorris (2726007) | about a month ago | (#47290689)

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

How does this help? (0)

Anonymous Coward | about a month ago | (#47288313)

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.

Re:How does this help? (3, Interesting)

bmajik (96670) | about a month ago | (#47288349)

Bugs weren't missed in mainline openSSL. Bugs were logged, sat around for years, and didn't get fixed.

The project management and software engineering practices for openSSL were/are simply not acceptable.

The code is salvageable. The people and processes that allowed the code to get that way are not.

"This code under new management"

Re:How does this help? (2)

owlstead (636356) | about a month ago | (#47288579)

So where is the heartbleed bug report that was ignored?

Re:How does this help? (3, Informative)

jones_supa (887896) | about a month ago | (#47288667)

OpenSSL Gets Patch for 4-Year-Old Flaw [eweek.com]

That one had a public CVE sitting for 4 years while nobody took the responsibility to fix it.

Re:How does this help? (1)

Electricity Likes Me (1098643) | about a month ago | (#47290399)

That description isn't very good for the bug: a specially crafted buffer overwrites Alice's data - what? I presume they mean that Bob could takeover Alice's connection, but the description isn't very good.

Moreover, it very much ignores an important issue: just because a bug is spotted, doesn't mean the fix is trivial. In security software the fix might very well open up a different vulnerability.

Debian's SSH flaw was exactly something like this - inappropriately commented weird looking code was removed to "improve" things. And it's exactly that sort of problem which I suspect LibreSSL is going run straight into at some point as well.

"Can't trust Google cuz they're NSA buds" = silly (2)

cyrus0101 (1750660) | about a month ago | (#47288381)

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.

Re:"Can't trust Google cuz they're NSA buds" = sil (2)

sasparillascott (1267058) | about a month ago | (#47289007)

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

Re:"Can't trust Google cuz they're NSA buds" = sil (1)

cbhacking (979169) | about a month ago | (#47289359)

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

Re:"Can't trust Google cuz they're NSA buds" = sil (1)

hattable (981637) | about a month ago | (#47290005)

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 (5, Informative)

ctime (755868) | about a month ago | (#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.

Re:It is hip to be square (1)

owlstead (636356) | about a month ago | (#47288571)

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.

Re:It is hip to be square (1)

Opportunist (166417) | about a month ago | (#47288573)

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 calling bullshit along the lines of sunshine units and differently abled.

What remains is that it is done by the company whose core business is data collection and selling it to the highest bidder.

Re:It is hip to be square (3, Insightful)

Jiro (131519) | about a month ago | (#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:It is hip to be square (1)

tepples (727027) | about a month ago | (#47288867)

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?

Re:It is hip to be square (1)

discord5 (798235) | about a month ago | (#47288939)

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.

Re:It is hip to be square (1)

lannocc (568669) | about a month ago | (#47289811)

GIMP's UI is OK, but it really requires a hardware graphics tablet to be used properly.

Re:It is hip to be square (1)

LookIntoTheFuture (3480731) | about a month ago | (#47289971)

Gimp wars! I've gone back in time!

Re:It is hip to be square (0)

Anonymous Coward | about a month ago | (#47289055)

You have to have one giant window which everything is stuck inside, and buttons you hold down to get other buttons. Adobe is the pinnacle of UI achievement.

There are serious problems with GIMP professionally (CMYK, HDR, etc etc). The UI and name (just call it the GNU Image Manipulation Program if you don't like the acronym) are not.

Re:It is hip to be square (2)

Electricity Likes Me (1098643) | about a month ago | (#47290423)

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:It is hip to be square (0)

Anonymous Coward | about a month ago | (#47291019)

GNU Image Retouching and Editing ( GIRE )
GNU Image Retouching Lab ( GIRL )
GNU Adaptable Image Tool ( GAIT )
GNU Users' Foto FudgER ( GUFFER ) - Ah, I should have quit while I was ahead.

Thi5 FP fNor GNAA (-1)

Anonymous Coward | about a month ago | (#47288411)

and the BaZZar parts of you are

Not a general use library (0)

Anonymous Coward | about a month ago | (#47288519)

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.

Re:Not a general use library (0)

Anonymous Coward | about a month ago | (#47288775)

The capital R just unprofessionally makes it look like leetspeak.

Re:Not a general use library (1)

Kremmy (793693) | about a month ago | (#47289167)

That's a reading comprehension issue on the user end.

fork in 3.. 2.. (0)

Anonymous Coward | about a month ago | (#47288683)

EnnuyeuxSSL

boring (0)

Anonymous Coward | about a month ago | (#47288695)

verb

make (a hole) in something, esp. with a revolving tool.

Certify it (2)

sinij (911942) | about a month ago | (#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.

Re:Certify it (2)

rubycodez (864176) | about a month ago | (#47289199)

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.

Re:Certify it (0)

Anonymous Coward | about a month ago | (#47289227)

The point is not whether FIPS-certified cryptographic systems are, or are not, any good. The point is that if you don't have a FIPS-cerified cryptographic system, forget about selling anything to US government agencies.

Re:Certify it (2, Insightful)

Anonymous Coward | about a month ago | (#47289969)

And if you do have a FIPS-certified cryptographic system, thanks to the NSA's shenanigans, the rest of the world now views it with disdain and suspicion, so forget about selling anything to anyone who ISN'T a US government agency.

They can make their own damn crypto, or follow the lead of independent cryptographers leading independent research. Appeasing governments is off the menu.

Re:Certify it (0)

Anonymous Coward | about a month ago | (#47290261)

The point is not whether FIPS-certified cryptographic systems are, or are not, any good. The point is that if you don't have a FIPS-cerified cryptographic system, forget about selling anything to US government agencies.

Abstract the cryptographic operations and have two implementations of it, FIPS-certified OpenSSL or whatever and the library that's actually secure. US government can use the FIPS-certified thing while everyone else goes with the more secure version. I doubt there is rule that forbids that (in the case you cannot ship non-FIPS-certified cryptographic libraries, just remove the binary for the other library from software shipped to US government)

Re:Certify it (0)

Anonymous Coward | about a month ago | (#47291265)

wrong. FIPS certifcation has just been proven to be meaningless

Meaningless technically perhaps, but not from a compliance standpoint.

Instead, those with a brain will chose the superior alternative being developed

Not in the real world where its "less risky" to go with a stable release with a few known defects. You also assume "those with a brain" are in charge.

those in government will have to follow leadership and make a better standard

In 10 years. Until then check the checkbox for FIPs compliance.

Sorry for being cynical in this response, but you apparently have NEVER worked with a company or government agency with bureaucracy. P.S. Are you hiring?

Re:Certify it (0)

Anonymous Coward | about a month ago | (#47289223)

I'm so glad they had *you* to tell them.

Or maybe they'll just build a good crypto library which will be used all over the world where actual security matters more than some braindead certification.

Re:Certify it (1)

swillden (191260) | about a month ago | (#47289689)

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.

Re:Certify it (1)

Electricity Likes Me (1098643) | about a month ago | (#47290431)

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.

Re:Certify it (1)

swillden (191260) | about a month ago | (#47291059)

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.

Re:Certify it (0)

Anonymous Coward | about a month ago | (#47291101)

What products does Google sell to the US government?

You.

Re:Certify it (1)

swillden (191260) | about a month ago | (#47291505)

What products does Google sell to the US government?

You.

A) That's not true. Do you have a citation?

B) Even if it were, it wouldn't be relevant to this thread, in which the claim is that not making BoringSSL FIPS-compliant will somehow make it irrelevant because it would impact Google's ability to sell products to the government. If Google did sell information to the government, the lack of FIPS certification on BoringSSL clearly wouldn't be an obstacle.

Re:Certify it (1)

bill_mcgonigle (4333) | about a month ago | (#47290267)

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 doesn't mean the majority (1)

raymorris (2726007) | about a month ago | (#47290999)

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

Certify it (1)

sgt scrub (869860) | about a month ago | (#47291129)

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

Re:Certify it (0)

Anonymous Coward | about a month ago | (#47291257)

I don't understand why you would think that compliance with some US government standard is so important. Google and the rest of the large technology companies don't make any significant money from the federal government. Google activates more Android handsets in a couple of days than there are employees in US government.

The only thing that matters is the security of the library.

Re:Certify it (0)

Anonymous Coward | about a month ago | (#47291475)

Government & ad revenue ?

BorenSSL (1)

bAdministrator (815570) | about a month ago | (#47289031)

Its name was, in fact, Boren.

Why have one attack footprint... (0)

Anonymous Coward | about a month ago | (#47289097)

...when you can have two.

broken shit is broken. (-1)

Anonymous Coward | about a month ago | (#47289499)

Scrap that codebase completely. There is no need to keep around that piece of shit big-int library. Start from some other base like the GNU multiple precision libs, or one of the several SSL libs that are clean, simple, and not OpenSSL based, esp. the ones for embedded systems. Fuck, it's Google, you'd think they could use their own search engine.

Any moron using LibreSSL or OpenSSL is just that.... wait, I see what the problem is. All the SSL libs that aren't shit are actually (L)GPL licensed. HAHA! No seriously, go look! Search "OpenSSL alternative". Guys, it's license wars all over again. GNU 1, BSD 0, Apache 0.

Eat dick freedom haters.

compatibility, so you don't rewrite all applicatio (2)

raymorris (2726007) | about a month ago | (#47291025)

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.

Cannot Wait (1)

Chad Smith (3448823) | about a month ago | (#47289845)

For SameOldSSL and SSLYourWAY

It needs to go the "XWindows path" (1)

sgt scrub (869860) | about a month ago | (#47291125)

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

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...