Servo has been using the cryptographic library, OpenSSL (via the Hyper library) for securing communications. As the project transitions to shipping nightly builds and hopefully products, we need to make a more explicit decision about our library usage. As a web browser, there’s a high standard to meet, resulting in requirements that are possibly stricter than those of other projects.
Requirements - Production ready library, opportunities for auditing and reviewing - Actively maintained, up to date on current state of the art, implements all common algorithms used on the web - Full CVE/disclosure plan in place: In order to be a fully-fledged browser engine, we will need to have the ability to report and fix critical vulnerabilities - PKI support: PKI forms the backbone of trust on the Internet, and it’s essential that we fully support certificate verification. Options 1. Continue to use existing OpenSSL bindings 2. Contribute to a new or existing library in Rust 3. Create bindings to another existing library Option 1: This is our current solution. While trying to distribute nightlies, the team discovered that the Rust bindings for OpenSSL need some work1. Additionally, many projects are moving away from OpenSSL; for example, when Google2 and OpenBSD forked OpenSSL into BoringSSL3 and LibreSSL4, one motivation was to create a leaner codebase. It will take some work to enhance and broaden these bindings. Another concern for Servo is the difficulty of multi-threading with OpenSSL. It’s not thread safe by default, and requires callbacks to lock and unlock an array of locks5. Option 2: There's interesting work going on in the Rust crypto ecosystem, and it's worth keeping an eye on. For the time being, Servo needs production-ready libraries. At least for now, building crypto infrastructure is out of scope for the team. But we should keep our options open for the future, and see if there are ways we can support these efforts. Option 3: A third option is to create Rust bindings for a currently existing SSL library. Some options I investigated were BoringSSL6, LibreSSL, or NSS. A significant con is that we don’t have significant expertise in either LibreSSL or BoringSSL, or the resources to devote towards developing it. Furthermore, BoringSSL is explicitly not recommended7 for general use because there are no guarantees of API/ABI stability. NSS is the current library used to secure Firefox, so using it in Servo is mutually beneficial to both projects. Additionally, we have access to significant NSS expertise, and NSS is committed to providing stable API and ABI. API stability will allow Servo to more easily upgrade versions and stay current with security patches, while reducing our maintenance overhead. ABI stability will allow Servo to distribute security fixes to the DLL in the wild without recompiling the executable. Proposed Development I propose to create Rust bindings for NSS, which is the crypto library used to secure Firefox. Not only does it fulfill all of Servo’s requirements, but it already has support for future work like TLS 1.3. I also propose that we create bindings for Mozilla:pkix8 for certificate validation. I spoke to the NSS team to see if they would be able to support an effort like this, and they were interested in helping. This is a practical way to get trusted, tested crypto into Servo and the wider Rust community. For more information on these discussions, you can see the current Rust security projects (http://libs.rs/cryptography/) and a discussion of cryptographic development in Rust ( https://internals.rust-lang.org/t/why-is-a-trusted-feature-complete-crypto-library-not-a-top-priority-for-the-rust-community/3125 ). I'd like to hear your comments about this proposal here (or privately). I know that this is an area that a lot of people are interested in, and it's important that we do it right. *TL;DR *Servo needs to make an explicit decision about how to do TLS, and I think we should use NSS. Thanks! -Diane | avadacatavra *References:* 1. https://github.com/servo/servo/issues/12015 2. Google's comparison of OpenSSL and NSS <https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?usp=sharing> 3. BoringSSL took OpenSSL from 468k lines of code to 200k, even with adding additional tests 4. LibreSSL initially removed over 90k lines of code 5. https://www.openssl.org/docs/man1.0.2/crypto/threads.html 6. https://www.imperialviolet.org/2015/10/17/boringssl.html 7. https://boringssl.googlesource.com/boringssl/ 8. https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate-verification-in-gecko/ _______________________________________________ dev-servo mailing list [email protected] https://lists.mozilla.org/listinfo/dev-servo
