Fun topic! Rust crypto is super important. My perspective on this is from someone who wants the greatest benefits for Rust. Whatever the decision I hope you enjoy hacking on Servo.
On Thu, Aug 25, 2016 at 5:13 PM, Diane Hosfelt <dhosf...@mozilla.com> wrote: > 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. > Not all of these may be near-term requirements, though for full productization they look important. Particularly with the current focus on upstreaming Servo tech into Firefox, Servo has more freedom to do research and less pressure to deliver a fully-compatible stack. Still, they all look reasonable and I think could be accomplished with any of the potential approaches, with more or less effort and time. > > > 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. > There are many benefits to this approach. Advancing Rust crypto is perennially a high-priority strategic nice-to-have in Rust, but so far we have not been able to find the right motivation to put weight behind it. Any time there is a glimmer of opportunity for Mozilla to accelerate Rust crypto we should try our hardest to take it. It is notable that we have not done so yet. Rust is probably, if not obviously, one of the best platforms there is for cryptographic and security software, and delivering a high-quality solution would generate widespread attention and goodwill for Mozilla, and have compounding effects for the entire Rust ecosystem. Porting Servo to NSS has less significant benefits. As I understand it the biggest concern with using experimental crypto in Servo is that the more users Servo has the greater risk there is from a serious security flaw. This is of course an important concern, but it's not clearly outweighed by the benefits of pursuing Rust-oriented security research. There may be mitigation strategies that would allow Servo to pursue a Rust solution while protecting itself from a high-profile security disaster. Making high-quality NSS bindings available to the greater Rust community would be valuable, but less valuable I think than one might expect. Today the Rust ecosystem generally uses OpenSSL and the biggest practical problem with that is build complexity. Any time one has to bail out of Rust to C or any other language the portability of your build tanks, and Rust aims to be highly portable. OpenSSL is a big offender, particularly in that it's not simple to build on Mac and Windows. I don't know that NSS is better or worse in this regard, but as a general principle it's better for Rust projects to be written in Rust. Because of this issue the direction TLS support is going for general Rust code ISTM is to defer to the platform's TLS stack where appropriate, particularly on Mac and Windows [1]. This isn't appropriate for a web browser, but for general Rust software is a great simplification. This calculus might change with a pure-Rust TLS stack, or if a hybrid Rust/C/C++ TLS stack becomes so simple that it just works everywhere rustc does. [1]: https://github.com/sfackler/rust-native-tls > 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. > Of these, I think the reduced maintenance burden on Servo is the most compelling. I don't see that this approach it has mutual benefits though. How would using NSS in Servo benefit Firefox? ABI stability isn't a clear need for Servo. Distributing security fixes via DLL isn't obviously important for Servo, particularly in the near term. > > 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 > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
