
Chrome: From NSS to OpenSSL - moonboots
https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1
======
tptacek
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 different stakeholders.

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

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

I don't know that anybody _loves_ NSS, but my perception is that more people
believe OpenSSL to be hopeless than believe NSS to be.

Talking to Brian and Ryan on Twitter yesterday, I proposed that someone
generate a list of questions to ask of a TLS codebase --- "what's the code
path from first ClientHello to validating the public key signature in a
certificate", or, "what's the code that determines which extensions are
enabled" \--- and we'd take a shot at answering them for NSS, SecureTransport,
and OpenSSL. My bet is that the answers to those questions will be more
favorable for NSS, even with the crappy certificate handling.

Maybe a fork of NSS would be a better plan.

However, to head off the drama HN is probably looking for here: one inevitable
result of Google transitioning fully to OpenSSL is that OpenSSL will get a lot
better, probably quickly.

~~~
agl
> 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
> expressed in NSS.

I agree with this to some extent (although I don't think it's quite as much
better as you suggest), and cleanups in that code are needed. Other parts of
NSS can certainly rival OpenSSL on the "dear god" scale however. I'll take the
low-level parts of OpenSSL over NSS any day.

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

This is true. We will have to rack our brains and our bug database for some of
the unwritten rules of TLS to port over to OpenSSL. I'm not too worried about
this in the long term however.

Ultimately the proof will be in the pudding. Ask again in 12 months :)

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

~~~
agl
I've submitted code to both. I don't feel that there's a huge difference.
(Although NSS has Wan-Teh reviewing, who is a great code reviewer.)

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

~~~
sleevi
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, far harder to reason
about any new code you might want to add, for who knows what grues are lurking
in those shadowy depths.

~~~
kbenson
_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?

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

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

~~~
rdudek
Considering how widely it's used, if Google could use some of their resources
to better it, I'm all for it!

~~~
Shish2k
Considering how widely SSL is used, and the resources of Google, I wonder if
they could come up with their own encryption toolkit? How hard can it be for a
company the size of Google to create a library that lives up to eg SQLite's
quality standards?

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

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

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

------
majke
And here is compulsory email thread explaining some context:

[https://groups.google.com/forum/?_escaped_fragment_=msg/mozi...](https://groups.google.com/forum/?_escaped_fragment_=msg/mozilla.dev.tech.crypto/4F3z644W8BM/aUq9UBh7rNYJ#!msg/mozilla.dev.tech.crypto/4F3z644W8BM/aUq9UBh7rNYJ)

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

~~~
ewindisch
This conversation circles back to Theo de Raadt's argument that developers are
caring too much about performance in security-critical applications.

~~~
pfortuny
Which is the typical point in which Theo de Raadt is right even though he may
be saying so quite singularly.

This is another instance of the lack of 'engineering' in Computer
Science/Programming/you name it. Engineers have long ago learnt that you need
"automatic" standards and compliance before, during and after building
anything, and that the best practice is always assuming thing will go wrong.

This, unfortunately, is not the case with programming as we can see time and
again.

But I digress.

------
fabian2k
I found the following part in the cons to NSS amusing, or maybe rather
frightening:

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

~~~
joshmoz
IIRC... That is in reference to libpkix, the certificate validation component
of NSS. I believe Mozilla developers are working on a replacement for it,
called mozilla::pkix, in large part due to libpkix being overly complex. Last
time I checked mozilla::pkix was pretty far along.

[https://bugzilla.mozilla.org/show_bug.cgi?id=915930](https://bugzilla.mozilla.org/show_bug.cgi?id=915930)

~~~
handsomeransoms
It landed on Nightly a week ago, check it out! You can help us by testing it
[0] or reviewing the code [1].

[0] [https://wiki.mozilla.org/SecurityEngineering/mozpkix-
testing...](https://wiki.mozilla.org/SecurityEngineering/mozpkix-
testing#Request_for_Testing) [1]
[https://wiki.mozilla.org/SecurityEngineering/mozpkix-
testing...](https://wiki.mozilla.org/SecurityEngineering/mozpkix-
testing#Request_for_Code_Review)

------
edwintorok
On Debian Chromium 33.0.1750.152-1 seems to be using GnuTLS, I didn't know
that the official Chrome used NSS:

    
    
      $ ldd /usr/lib/chromium/chromium|grep -E tls\|ssl
            libgnutls.so.28 => /usr/lib/x86_64-linux-gnu/libgnutls.so.28 (0x00007fbae0878000)
    

In fact on Debian most client software is using either NSS or GnuTLS, OpenSSL
is more popular server-side of course.

~~~
dtech
Due to (mostly ideological) licensing incompatibilities some package
maintainers and/or distributions link software with GnuTLS instead op OpenSSL.
GnuTLS provides a basic compatibility layer with OpenSSL.

So Chromium may in fact be programmed against OpenSSL but might work when
linked to GnuTLS

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

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

~~~
leccine
One but really important reason:
[https://gitorious.org/gnutls/gnutls/source/39aaa63a1a4cb8432...](https://gitorious.org/gnutls/gnutls/source/39aaa63a1a4cb8432e090887f38241afb2b264a6:COPYING)

vs.

[http://www.openssl.org/source/license.html](http://www.openssl.org/source/license.html)

~~~
runeks
Also, it uses `strlen` and `strcat` on binary data:
[http://www.openldap.org/lists/openldap-
devel/200802/msg00072...](http://www.openldap.org/lists/openldap-
devel/200802/msg00072.html)

------
higherpurpose
Can't they use Sodium instead?

[http://labs.umbrella.com/2013/03/06/announcing-sodium-a-
new-...](http://labs.umbrella.com/2013/03/06/announcing-sodium-a-new-
cryptographic-library/)

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

~~~
tekacs
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 call it NaCl given that it's a
fork of, or I suppose a refined implementation of NaCl?

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

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

------
thrillgore
Unless Google is going to clean OpenSSL up along the way, I don't see any
immediate benefit.

~~~
JosephRedfern
AFAIK Heartbleed was found during one of Googles code-reviews of OpenSSL.

