Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome: From NSS to OpenSSL

docs.google.com

Post reply on HN
Print view View original

71–77 of 77 posts

Re: Chrome: From NSS to OpenSSL

#71

Post by tekacs »

aryastark wrote: post #42
tekacs wrote: post #27

Earlier quoted context omitted.

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.

Mm that's roughly the impression I got, but I hadn't thought of the papers - thanks for the clarification!

Re: Chrome: From NSS to OpenSSL

#72

Post by spoiler »

alextgordon wrote: post #45
tekacs wrote: post #27

Earlier quoted context omitted.

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.

Isn't it better to not include stuff that's insecure, even if they have historic value? Isn't this a big part of the problem of some (even OpenSSL) software?

Re: Chrome: From NSS to OpenSSL

#73

Post by crashandburn4 »

leoc wrote: post #47
thirsteh wrote: post #41

Earlier quoted context omitted.

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?

Hi, can someone help me understand what the significance of FIPS certification is? ( beyond the wikipedia page: http://en.wikipedia.org/wiki/FIPS_140-2 )

Re: Chrome: From NSS to OpenSSL

#74

Post by leoc »

crashandburn4 wrote: post #73
leoc wrote: post #47

Earlier quoted context omitted.

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?

Hi, can someone help me understand what the significance of FIPS certification is? ( beyond the wikipedia page: http://en.wikipedia.org/wiki/FIPS_140-2 )

AFAIK the US federal government (excluding the military, which obviously has its own hoops to jump through) generally can't use your hardware/software unless it has the appropriate FIPS certification(s). https://en.wikipedia.org/wiki/Federal_Information_Processing...

Re: Chrome: From NSS to OpenSSL

#75

Post by emn13 »

kbenson wrote: post #66
sleevi wrote: post #40

Earlier quoted context omitted.

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…

With NSS, it's far, far harder to remove code I'm not sure how to interpret that statement. It could mean any of the following, or something I'm not even thinking of: The code is inscrutable and/or the documentation is poor : That's obviously a problem. Commits removing code are delayed/ignored : Probably also a problem, but maybe there's valid reasons for this, such as more thorough testing? There's little cruft to…

It could also be that the public API is too large and exposes unnecessary bits that now make it hard to change even incidental, conceptually irrelevant behavior simply because some user probably relies on it. Even a clean, well documented implementation with active, capable maintainers is hard to refactor when the API is large and intrusive.

(I have no reason to believe this applies to NSS.)

Re: Chrome: From NSS to OpenSSL

#76

Post by jessaustin »

jessaustin wrote: post #35
[deleted] wrote: post #22

Earlier quoted context omitted.

[deleted]

I flagged it, and I presume many others did as well. I also flagged several other overtly political boycott stories recently, but that didn't seem to have as much effect.

I only regret that I posted but one comment for partisan dickheads to downvote; oh wait here's another one for you.

Re: Chrome: From NSS to OpenSSL

#77

Post by rockdoe »

mike_hearn wrote: post #48
higherpurpose wrote: post #44

Earlier quoted context omitted.

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.

Many of the review peers work at Google, so eh...
Post reply on HN