Chrome: From NSS to OpenSSL • Hacker News Board

Re: Chrome: From NSS to OpenSSL

#41

Post by thirsteh » Thu, Apr 10, 2014, 6:59 PM UTC

crashandburn4 wrote: post #6

sgarlatm wrote: post #5

It may actually be a good thing if Chrome migrates to OpenSSL. With their resources, perhaps they can do some testing to see if there are any more vulnerabilities out there. At the very least, their continued eye on the project should help it be more secure going forward.

Those were my thoughts exactly, I think OpenSSL just needs a bit of care and refactoring (possibly a lot depending on which blogs you read) for which they need devs and resources, both of which google has.

The problem with OpenSSL is that it's really problematic to simply fix and refactor stuff given their FIPS certification.

Re: Chrome: From NSS to OpenSSL

#42

Post by aryastark » Thu, Apr 10, 2014, 7:01 PM UTC

tekacs wrote: post #27

tptacek wrote: post #17

Earlier quoted context omitted.

No. Not only is Sodium (more accurately: NaCl) not a TLS library, but it doesn't even implement the primitives that TLS needs; it can't really even serve as a component of another TLS library.

Not that you're not absolutely right about NaCl & Sodium, but isn't the GP talking explicitly about Sodium and not NaCl? When you say 'more accurately: NaCl', is there something particular you're getting at, or are you speaking from experience of NaCl rather than Sodium (or are you talking about the fact that the bindings seem to be named/built for the original NaCl?) Edit: or do you just think it's still better to c…

it's more accurate to discuss NaCl since that's what libsodium is. NaCl is the combination of crypto primitives and the "box" abstraction. libsodium is just the repackaging and clean-up of the original NaCl implementation. If you're discussing crypto, you're going to be looking at the papers on NaCl.

Re: Chrome: From NSS to OpenSSL

#43

Post by peterwwillis » Thu, Apr 10, 2014, 7:01 PM UTC

tptacek wrote: post #20

Though Ryan disagrees strongly, I think this is unfortunate. I think a case can be straightforwardly made that NSS is the better library. Here's a shotgun blast of reasons: * NSS has more institutional constraints; random people in Germany can't, as a general rule, add support for new TLS extensions to it. * NSS has a clearer identity, as the TLS core for Firefox and Chromium. OpenSSL is a grab bag with hundreds of d…

> NSS has more institutional constraints; random people in Germany can't, as a general rule, add support for new TLS extensions to it.

This is horrible for a large scale open-source project. Glibc, gcc, as examples. Trying to get them to fix their broken crap or reverse their idiotic decisions takes decades. If OpenSSL is less opposed to change, it's probably a good thing, considering the purpose of it.

> NSS has a clearer identity, as the TLS core for Firefox and Chromium. OpenSSL is a grab bag with hundreds of different stakeholders.

Do you not remember the myriad bugs that came out of Microsoft's, Netscape's and others' independently-developed SSL implementations when their only relevant benchmark was their own tools? They didn't give a shit if it broke someone else's tool because they didn't make it to support someone else's tool.

> The most important code in both NSS and OpenSSL is the SSL state machine. The code for that state machine is incontrovertibly clearer and better expressed in NSS.

So clean up the OpenSSL code! If your previous claim that it's easy to get code into OpenSSL is true, fix it! Don't throw the baby out with the bathwater!

> NSS has had better battle-testing as a clientside browser TLS library than OpenSSL, which, apart from Android Chrome, isn't a big factor in TLS clientsides.

OpenSSL is used in hundreds of TLS clients in all kinds of environments around the world. It's the de facto client library for 90% of open source tools. As opposed to whatever environments run NSS applications which is far fewer.

It seems like these are arguments for OpenSSL, not against it.

Re: Chrome: From NSS to OpenSSL

#44

Post by higherpurpose » Thu, Apr 10, 2014, 7:06 PM UTC

tptacek wrote: post #20

Though Ryan disagrees strongly, I think this is unfortunate. I think a case can be straightforwardly made that NSS is the better library. Here's a shotgun blast of reasons: * NSS has more institutional constraints; random people in Germany can't, as a general rule, add support for new TLS extensions to it. * NSS has a clearer identity, as the TLS core for Firefox and Chromium. OpenSSL is a grab bag with hundreds of d…

This makes me wonder what will happen with the level of security in NSS, now that Google is quitting it. Can Mozilla keep maintaining it properly on its own?

Re: Chrome: From NSS to OpenSSL

#45

Post by alextgordon » Thu, Apr 10, 2014, 7:07 PM UTC

tekacs wrote: post #27

tptacek wrote: post #17

Earlier quoted context omitted.

No. Not only is Sodium (more accurately: NaCl) not a TLS library, but it doesn't even implement the primitives that TLS needs; it can't really even serve as a component of another TLS library.

Not that you're not absolutely right about NaCl & Sodium, but isn't the GP talking explicitly about Sodium and not NaCl? When you say 'more accurately: NaCl', is there something particular you're getting at, or are you speaking from experience of NaCl rather than Sodium (or are you talking about the fact that the bindings seem to be named/built for the original NaCl?) Edit: or do you just think it's still better to c…

Any SSL implementation worth its salt needs to implement historical primitives like RC4 and MD5. libsodium will not and should not implement these because they conflict with the goal of providing an idiot-proof crypto library.

Re: Chrome: From NSS to OpenSSL

#46

Post by blinkingled » Thu, Apr 10, 2014, 7:17 PM UTC

sleevi wrote: post #40

tptacek wrote: post #38

Earlier quoted context omitted.

Ok, wait: the code you've submitted to both has also probably been more obviously applicable than, say, the Heartbeat extension. "Chromium developer has elliptic curve code accepted by NSS: film at 11."

Part of the reason it's so hard to get code into NSS is because no one really knows who owns those bits, and so they linger in obscurity. I think my TLS Channel Bindings patch is lingering on 3 or 4 years now. However, I think you're doing a disservice if you only look at how easy it is to add code. As important is how easy it is to remove code. With NSS, it's far, far harder to remove code - and that makes it far, f…

Not being able to easily add or remove code is good from a security standpoint though. I would take a bugfix only, stable-API NSS over anything that is in constant flux. So it's not how fast you can add features that should be in focus for a mature product - it's how safely you can add bug-fixes, including security fixes. Unless you are saying you have a security fix lingering for 3-4 years, I think Mozilla is doing it right.

Edit: Not to ignore the valid point - having a designated code owner that responds would of course be good.

Re: Chrome: From NSS to OpenSSL

#47

Post by leoc » Thu, Apr 10, 2014, 7:37 PM UTC

thirsteh wrote: post #41

crashandburn4 wrote: post #6

Earlier quoted context omitted.

Those were my thoughts exactly, I think OpenSSL just needs a bit of care and refactoring (possibly a lot depending on which blogs you read) for which they need devs and resources, both of which google has.

The problem with OpenSSL is that it's really problematic to simply fix and refactor stuff given their FIPS certification.

Ooh, OpenSSL's FIPS certification. The fellows who've been fighting for years to take it away http://www.itnews.com.au/News/65016,openssl-in-a-fips-flap.a... must be crowing right now. (Regardless of whether their own stuff is any better or no.) Another decertification incoming?

Re: Chrome: From NSS to OpenSSL

#48

Post by mike_hearn » Thu, Apr 10, 2014, 7:42 PM UTC

higherpurpose wrote: post #44

tptacek wrote: post #20

Though Ryan disagrees strongly, I think this is unfortunate. I think a case can be straightforwardly made that NSS is the better library. Here's a shotgun blast of reasons: * NSS has more institutional constraints; random people in Germany can't, as a general rule, add support for new TLS extensions to it. * NSS has a clearer identity, as the TLS core for Firefox and Chromium. OpenSSL is a grab bag with hundreds of d…

This makes me wonder what will happen with the level of security in NSS, now that Google is quitting it. Can Mozilla keep maintaining it properly on its own?

They don't maintain it properly today. Go look at bugzilla, there are quite a few new feature patches from Google that just never get reviewed, let alone merged.

Re: Chrome: From NSS to OpenSSL

#49

Post by mike_hearn » Thu, Apr 10, 2014, 7:43 PM UTC

majke wrote: post #4

And here is compulsory email thread explaining some context: https://groups.google.com/forum/?_escaped_fragment_=msg/mozi... > Strange that "PKCS#11 support" is listed as a "con" for NSS > It was not accidental that it was listed under "Con", nor do I see ENGINE_pkcs11 as a "Pro"

Smartcard support is pretty important for a lot of people. If Chrome drops that feature, that would be a huge shame.

Re: Chrome: From NSS to OpenSSL

#50

Post by tptacek » Thu, Apr 10, 2014, 7:52 PM UTC

peterwwillis wrote: post #43

tptacek wrote: post #20

Though Ryan disagrees strongly, I think this is unfortunate. I think a case can be straightforwardly made that NSS is the better library. Here's a shotgun blast of reasons: * NSS has more institutional constraints; random people in Germany can't, as a general rule, add support for new TLS extensions to it. * NSS has a clearer identity, as the TLS core for Firefox and Chromium. OpenSSL is a grab bag with hundreds of d…

> NSS has more institutional constraints; random people in Germany can't, as a general rule, add support for new TLS extensions to it. This is horrible for a large scale open-source project. Glibc, gcc, as examples. Trying to get them to fix their broken crap or reverse their idiotic decisions takes decades. If OpenSSL is less opposed to change, it's probably a good thing, considering the purpose of it. > NSS has a c…

It's the de facto client library for everything but the most important TLS clients.

Ryan's argument that it's too hard to remove NSS code is compelling, but making it to easy to add code is exactly the problem we just had with OpenSSL. Heartbeat wasn't just bad code; it was code that was inappropriate for inclusion by default.