> NSS also has a fairly bad security record, with 6 CVEs in 2015 and 4 > in 2016 until now (with the most recent one fairly high-risk).
"number of CVEs over time" is a poor way to evaluate software security, because the number of issues found is proportional not only to code quality or development practices, but also to incentives to find and disclose those issues, which is tied to how commonly the software is used in practice. One could argue that more CVEs makes commonly-used libraries *more* secure than untested developmental libraries. I don't have a strong opinion about what the right decision here is, and see benefits to both options. But concluding that "NSS has a bad security record", based solely on the reasoning quoted above, is not a strong argument. Gavin On Fri, Aug 26, 2016 at 3:23 AM, Dirkjan Ochtman <dirk...@ochtman.nl> wrote: > Hi Diane, > > Thank you for bringing this discussion into the open. > > On Fri, Aug 26, 2016 at 2:13 AM, Diane Hosfelt <dhosf...@mozilla.com> wrote: >> 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. > > Another concern is that rust-openssl will need a bunch of work to be > able to work with the new OpenSSL 1.1.0 APIs. > >> 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. > > As I understand it, Servo is also a research project designed in part > to validate the capabilities of the Rust language for the kinds of > needs a browser has. It seems to me that the safety guarantees and > general ergonomics that Rust provides were designed in part to make it > significantly easier to build secure software. While that does not > mean that Servo should build its own crypto libraries, it seems more > sensible to me to adopt one of the Rust crypto stacks (provided it of > sufficiently high quality), and thus help validate Rust-for-crypto > while also supporting the development of crypto libraries for the Rust > ecosystem. > >> 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. > > NSS also has a fairly bad security record, with 6 CVEs in 2015 and 4 > in 2016 until now (with the most recent one fairly high-risk). This > does not yet include the necessarily immature Rust bindings that would > be provided on top of it. Also, most non-Mozilla projects seem to be > moving away from NSS. > >> 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 >> ). > > This discussion is fairly dated at this point. > >> 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. > > My counter-proposal is that Servo should use a TLS stack built on the > *ring* crypto library. *ring* is built around BoringSSL, and thus > inherits much of the well-audited low-level primitives that BoringSSL > provides (*ring* continues to merge the relevant BoringSSL work). > BoringSSL has a much better security track record than either NSS or > OpenSSL. *ring* is improving on this by moving as much as possible > into safe Rust. webpki is a Rust library by the same author as *ring* > (a former MoCo employee), which is implemented using the same design > as was used in the mozilla::pkix library used in Firefox. rustls is a > modern Rust TLS stack that builds on *ring* and webpki. > > While rustls and the underlying libraries are immature compared to > core NSS (but not any Rust bindings for it), I'm not sure the level of > maturity NSS (and OpenSSL) have at this point should be considered a > good thing, given their respective security track records. Instead, > Servo should strive to support Rust-based crypto and TLS, so that the > security of Rust code can be validated and further improved. > > Cheers, > > Dirkjan > _______________________________________________ > 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
