Hacker News new | past | comments | ask | show | jobs | submit login

maybe it's better to switch to NSS, the original SSL library developed by Netscape (now by Mozilla, Google, etc.), that is available under better open source licenses, is used in Firefox, (Chrome), OpenOffice, etc. and has an optional compatible API to OpenSSL: http://en.wikipedia.org/wiki/Network_Security_Services



Curiously, the Heartbleed bug was found by the Google engineer who is working on replacing NSS with OpenSSL in Chrome: https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53...

From the Pros & Cons table, it doesn't seem that NSS is obviously superior to OpenSSL. Both seem to suffer from focus on extra features instead of maintenance and reliability.


The reasoning there is, certainly post-Heartbleed, very scary. Their conclusion boils down to that they want to use the system-provided OpenSSL on Android, rather than shipping NSS.

This might be fine if you're running a Nexus device that still gets updates to the latest Android (Nexus 4 and later?). But for everyone else, that's effectively forcing people to get a new Android phone if they don't want to get stuck with a horribly insecure phone.

Oh, I see the point already...


I mean couldn't you say the same thing if a vulnerability was found in NSS?


No, because Android system updates are slow to come (or may never happen), while anything coming from the Google Play store (like Chrome) is timely.


In the doc, Google says NSS would need to be added to the base Android image.. so it's not going to be updated any faster than openSSL.

When powering WebView, Chromium on Android uses the Android system-provided OpenSSL library - something not available to applications building with the Android NDK (like Chrome for Android or other Chromium-based Android applications). This helps reduce memory usage by having a single shared library in memory. To accomplish this with NSS, NSS would have to be part of the Android base image - which would still increase memory usage, as most other Android (native) services would still use OpenSSL.


It says "On Android, Chromium uses OpenSSL." in the background section. The question is whether they want to switch other platforms to OpenSSL (or Android to NSS, or keep using both).


"Both seem to suffer from focus on extra features instead of maintenance and reliability."

Unfortunately in the SSL/TLS world, true security is a product of both, as minor flaws in the actual protocol itself are a common enough discovery to make the introduction of new "features" often quite key to the security of the implementation.


Last I looked, libnss still relied on libnspr, which brings it's own amount of overhead.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: