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

61–70 of 77 posts

Re: Chrome: From NSS to OpenSSL

#61

Post by doe88 »

tptacek wrote: post #34
agl wrote: post #29

Earlier quoted context omitted.

> NSS has more institutional constraints; random people in Germany can't, as a general rule, add support for new TLS extensions to it. Why not? NSS is handled by Mozilla. Mozilla prides itself on being open-source. People can submit patches to NSS by filing in Bugzilla. > 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 ex…

Am I wrong that it's easier to get code into OpenSSL, and thus into pretty much every product that uses OpenSSL, than it is to get code into the branch of NSS that Firefox and Chromium use?

> Am I wrong that it's easier to get code into OpenSSL

I might be wrong but the idea I have is that currently Google more or less owns OpenSSL and thus it is maybe more easy, makes more sense for them to get patches in OpenSSL and try to migrate exclusively toward OpenSSL.

Another question I have is since when the HeartBleed flaw was discovered by the Google's employee? Was it formally reported to the OpenSSL team or only to OpenSSL members working for Google? And if the other independant group of engineers had not independantly discovered the flaw would have it been disclosed as quickly as it has? Bottom line it seems to me (and I'd like to be wrong) that the current opacity of OpenSSL disserves everyone but Google.

Re: Chrome: From NSS to OpenSSL

#62

Post by gioele »

leccine wrote: post #54
gioele wrote: post #51

Serious question: why is GnuTLS very often not considered as an alternative to OpenSSL?

One but really important reason: https://gitorious.org/gnutls/gnutls/source/39aaa63a1a4cb8432... vs. http://www.openssl.org/source/license.html

GnuTLS is LGPL 2.1+: https://gitorious.org/gnutls/gnutls/source/39aaa63a1a4cb8432... not GPL 3 as that file seems to imply

Re: Chrome: From NSS to OpenSSL

#63

Post by nl »

doe88 wrote: post #61
tptacek wrote: post #34

Earlier quoted context omitted.

Am I wrong that it's easier to get code into OpenSSL, and thus into pretty much every product that uses OpenSSL, than it is to get code into the branch of NSS that Firefox and Chromium use?

> Am I wrong that it's easier to get code into OpenSSL I might be wrong but the idea I have is that currently Google more or less owns OpenSSL and thus it is maybe more easy, makes more sense for them to get patches in OpenSSL and try to migrate exclusively toward OpenSSL. Another question I have is since when the HeartBleed flaw was discovered by the Google's employee? Was it formally reported to the OpenSSL team or…

Another question I have is since when the HeartBleed flaw was discovered by the Google's employee? Was it formally reported to the OpenSSL team or only to OpenSSL members working for Google?

I think it is generally regarded as sensible practice to disclose major problems like heartbleed that have wide ranging impact directly to the people responsible instead of a catchall "security team" address whenever possible.

Re: Chrome: From NSS to OpenSSL

#64

Post by thrownaway2424 »

richm44 wrote: post #57
thrownaway2424 wrote: post #31

Earlier quoted context omitted.

Google has already written and released a complete crypto stack for Go. Where you restricting your comments to C/C++ implementations?

The last time I looked at it the go stack was very weak compared to any of the mature C SSL stacks. IIRC it only took me a few minutes to find a security bug (which I reported and is now fixed) that I'd reported against various browsers several years earlier. In short, I highly doubt the go SSL stack is production ready.

The above questioner didn't ask whether it was any good, only whether Google could write and release one.

Re: Chrome: From NSS to OpenSSL

#65

Post by tzs »

Wohui wrote: post #25
[deleted] wrote: post #22

Earlier quoted context omitted.

[deleted]

When the ratio of comments to article-upvotes reaches a certain point, threads are punished as 'flamewars'.

That will be a poor flame detection scheme if HN gets too many readers like me. I use up-voting as a way to mark articles/threads that I have NOT yet read but want to come back to. The HN interface actually implicitly suggests this use for up-voting, by naming the list of articles you have up voted your "saved stories" instead of "up-voted stories".

Re: Chrome: From NSS to OpenSSL

#66

Post by kbenson »

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…

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 remove: This would be a positive. Not having much of a mess to clean is hard to consider a problem.

Am I close with any of those?

Re: Chrome: From NSS to OpenSSL

#67

Post by codewiz »

The doc mentions this among the cons of NSS: "Certificate path building is C code designed to emulate Java code, through indirection of an average of 7 layers of macros, two platform abstraction layers, and then the remaining NSS abstraction layers (listed above)".

Re: Chrome: From NSS to OpenSSL

#69

Post by nvdk »

mike_hearn wrote: post #49
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.

every belgian citizen is issued a pkcs e-id, not supporting it means they all need another browser to do their taxes and log in to healthcare websites...

Re: Chrome: From NSS to OpenSSL

#70

Post by tekacs »

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.

This has nothing to do with what I asked. Also, this I know. Sorry? :P
Post reply on HN