Skip to content

London Security

Lars Bergstrom edited this page Jul 10, 2016 · 2 revisions

How do we choose our SSL library? Immediate and long-term.

  • ekr: OpenSSL, BoringSSL, NSS are all plausible. No experience with libressl. With the API stable, BoringSSL is good. BUT, vendored code. We don't have as much influence there. Probably limited OpenSSL API compat desires.
  • ekr: NSS maintained by us. No plans to move Firefox off of it. Continuing to invest.
  • ekr: Already landed TLS 1.3 drafts. Ahead of boringssl, which is ahead of openssl. BoringSSL probably more ahead on new crypto
  • jack: Mainly for computation reasons, not strength?
  • ekr: Yes. Also newly developed, in the open. And easier to implement a constant-time impl.
  • ekr: Support will help here.
  • jack: Can we put Rust bindings for NSS in-tree?
  • martin: Yes, if you help with the CI work, we'll land and ship it.
  • B: It's all a C API.
  • jack: Either we can use our resources to switch hyper over or if we build our own thing.
  • ekr: Maintain API & ABI stability, guaranteed.

rust PKI

  • diane: Use the rust community PKI implementation.
  • ekr: Don't use the OpenSSL or NSS ones. Use mozpks. It's C++, but designed with C-style APIs.
  • jack: Lives in m-c? Can we land rust bindings?
  • martin: As long as you land it in gecko.

rust rewrites

  • ekr: Less attractive for porting over C code that might introduce new logic errors, since that might introduce security errors.

  • ekr: Interested in ProVerif-related translations to add formal protocol verification. They do it on JS, but we might be able to do it against a subset of Rust. Removes loops, etc.

  • jack: No filter & map?

  • ekr: Separately verified. Gotta see if the tooling is close to good enough to use it. Provably correctly implemented libraries are an interesting point.

  • martin: Verifiability of Rust code to match the protocol would make it more attractive for us to rewrite portions of NSS/libssl.

  • jack: Make pks & nss post including info about our path.

  • ekr: djb has been doing some more implementations recently

  • martin: ekr's explanation about

  • jack: We can do the CI stuff & hook it into Cargo.

0-days

  • larsberg: What do we do? NOT yet for Servo.
  • ekr: We'll coordinate with the Servo security person when that happens.

demo browser

  • jack: Our release in June will have no locks, etc. Dissuading people from banking.
  • martin: When you support banking

handing security vulnerabilities

  • larsberg: Want to do it in bugzilla. Github has no facilities here.
  • ekr: We will put somebody from Servo on the list, triaging the bugs, etc.

soliciting vulnerabilities

  • jack: How do we get people to look into security issues in Rust/Servo?
  • ekr: Apply to the Mozilla grant program for security audits. gerv runs the program.
  • larsberg: We could probably find money to source the same kinds of audits.
  • ekr: Do you have scanbuild?
  • larsberg: We have no static analysis tools in place right now.
  • ekr: I can send you lists of what the analysis tools check for you to try to figure it out.
  • ekr: I think that there are likely some unsafe idioms in Servo/Rust and it would be best to identify them now. Do that early.
  • ekr: Are you sponsoring any work on academic analysis of Servo/Rust? I can look around. I'd assume some group would be interested in this.
  • diane: That was our hope.

web security

  • ekr: Have you had anybody look into web security?
  • larsberg: Not yet.
  • ekr: Origin violations; sandbox violations.
  • ms2ger: Origin stuff is probably broken.
  • ekr: Colin Jackson at Google. There might be some tools for compliance with origin policy. I can ask around on that.

sandboxing

  • ekr: Using chromium?
  • jack: Just the OS-level sandboxing now.
  • ekr: They find vulnerabilities in the OS-level sandbox. Check out pwn2own. Have you look at trust between parent & child processes?
  • larsberg: We tried to, but nobody with a security hat has done it well.
  • ekr: Gotta filter at the proxy for what the child can do. If the parent always trusts the child, there was no point in the sandbox.

getting feedback

  • ekr: Need to get Servo to a state where Servo is "good enough" but not actually shipping to get real attention.

sandboxing C code

  • ekr: Thinking about using the nacl compiler & the x86 sandbox (not the process sandbox) w/ C bindings.
  • ekr: Attractive for Gecko for the users; Servo b/c we already have bindings in place.
  • jack: Interesting for NSS?
  • ekr: All the SFI can help prevent violations to Firefox, and limit the issues to leaking info from the crypto module.
  • ekr: Have you looked into CFI for the Rust code? The C code could violate your Rust code calling it. You have an advantage of being 100% on LLVM. In general, making the C++ code not a threat to the Rust code is great.

co-authorship of a blog post

  • ekr: Talk with richard barnes
Clone this wiki locally