briansmith

I see I didn't do a good job of explaining why that doesn't work so well. See, papers on high-performance elliptic curve cryptography tend to give formulas for implementing calculations using the three-operand style I mentioned. One reason for having a DSL is to make it so that we can copy/paste, with minimal changes, those formulas into our programs so that we can easily see that we're implementing the formula from the paper exactly. If you C++-ify or Rust-ify them, then you lose that obvious "this is the same" comparison ability. Also, for the kinds of code where such a DSL would be relevant, you really don't want a C++ or Rust compiler's optimizer to be involved at all. And, if you want to prove the correctness of your ECC code, you don't really want to have to first (1) Define a formal semantics for C++ or Rust, (2) Prove that your C++ or Rust compiler is correct with respect to that formal semantics, and (3) Prove that your transliterations of the original formulas are equivalent to the original formulas.

I've already written a prototype that compiles that DSL into C, which requires a leap of faith that the C compiler won't ruin things for us. That prototype convinced me that it would likely be much less work to go the DSL route than the C++/Rust library route. Note that I prefer writing C++ and Rust libraries to creating DSLs, so this was a disappointing conclusion for me.

I am not like Google, but I'm already doing something like that: https://github.com/briansmith/ring and https://github.com/briansmith/webpki.

> 6. Someone points out that in higher level languages it's hard to write code that is resistant against timing attacks. The discussion dies.

This doesn't matter, because the code that should be resistant to timing attacks should be written in assembly language or a language specially designed for that purpose (that doesn't exist yet) anyway. High-level languages have ways of accessing code written in assembly language.

Anyway, my point is that all these things are solvable.

> 5. People poo poo any alternative to OpenSSL because it's not 100% feature complete and besides the best crypto people are already working on OpenSSL so what do these schmucks know?

Here's a strategy:

Take OpenSSL, remove a bunch of stuff that almost nobody needs, rearrange the code to make it clearer. You will get BoringSSL.

Take the BoringSSL code, remove more stuff that people outside of Google generally don't need. Temporarily remove the X.509 code and the TLS code so that you can remove even more stuff.

Next, write bindings for the remaining code for a safe language like Rust, so that the replacement X.509 and TLS code can be written in the safer language, while still using the OpenSSL crypto code.

Then, write the new X.509 code, focusing on what really is needed and ignoring all the extra cruft that was added to X.509 but which doesn't actually improve security.

Then, over time, refactor the the language bindings so more code is written in the safe language and less code is written in C, with the goal of almost all the code that isn't implementing directly crypto algorithms being in the safe language.

Then, add a good, clean TLS implementation in the safe language, that focuses on the good parts of TLS, and that avoids all the legacy cruft that makes TLS seem complicated.

I've been doing an experiment along these lines. I've open sourced two parts so far:

1. https://github.com/briansmith/ring 2. https://github.com/briansmith/webpki

It is a big project, but I am pretty sure it is going to succeed.

If Rust doesn't work on Windows XP then generally Firefox can't use Rust, because Windows XP support is a requirement for Firefox.

I'm glad y'all are working it out. The licensing for that stuff really is confusing, and discourages the use of that code.

It's worse in OpenSSL because the x86 and ARM adaptations are licensed under the OpenSSL/Cryptograms licenses instead of BSD/Apache. Big chunks are labeled as transliterations of the X64 code, so I'd expect them to also be BSD/Apache licensed. Also, it isn't clear what Andy Polyakov's significant improvements of the the X64 code mean for the copyright, licensing, and re-licensing from Apache to dual BSD/Apache. In other words, it seems the copyright lines should, at a minimum, mention Andy's copyright, and it should be made clearer whether Andy agrees to dual license his contributions under the BSD/Apache dual license.

Not if the computer is configured to only run signed code, which is an option on Windows.

Some implementations--most unfortunately, Apple's--do not implement name constraints.

Speaking from personal experience, writing code to correctly validate x509 certificates isn't as hard as it looks.

In Mozilla's implementation, name constraints are applied to the CN field. I believe Chrome is the same way. Also, browsers "validate domain names" against the CN attribute and the dNSName entries in the subjectAltName extension.

Source: I wrote all that code in Mozilla's implementation.

There is something called "name constraints" in X.509 that can be used to control which domain names, email addresses, etc. a sub-CA certificate can issue certificates for. See [1]. CAs are using them more and more frequently, especially after Mozilla added items #9 and #10 [2] to its inclusion policy a couple years ago.

[1] http://tools.ietf.org/html/rfc5280#section-4.2.1.10

[2] https://www.mozilla.org/en-US/about/governance/policies/secu...

I made the change to remove the version UI from Firefox. I made that change for two reasons:

(1) It sped up the implementation of TLS 1.1 and TLS 1.2. Removing the UI meant I didn't have to redo the UI when I added TLS 1.1 and TLS 1.2 support. Keeping that UI would have caused TLS 1.1 and TLS 1.2 to be delayed even further.

(2) Our measurements showed that ~1% of users had disabled TLS 1.0, leaving only SSL 3.0 enabled. I was worried that the UI encouraged people to make that mistake. Also, it is the application's responsibility to do the right thing automatically. People shouldn't have to fiddle with such options to be secure.

If you are referring to https://bugzilla.mozilla.org/show_bug.cgi?id=1036765, that was an unrelated change that was made well in advance of my knowledge of this issue.

> There are a lot of places where it's totally not important.

See my other replies on this page for some reasons why I think there are no pages where HTTPS is not important.

I agree with you regarding the UI issues and the potential to generate apathy by crying wolf. That's why I think that the specifics of the linked-to proposal won't work. But, I think the general idea is worth investigating. It just requires some user research.

Also, the fact that browsers support a non-HTTPS mode at all is really the bigger UI issue. Imagine if HTTPS was the only option. The biggest UI security problems would instantly vanish! That's a big reason why a lot of people are actively working so hard on finding ways to make HTTPS work for everybody on every site.

Regarding (B): A few years ago Mozilla did some user research that showed that a significant percentage of people do perceive the passive[1] negative security indicators as indicating a problem with Firefox instead of the web page. Thus, such a change does have to be done carefully. But, I think it is worth trying to find a way to do it that users can understand.

[1] Passive indicators are things like the red/broken lock icon. Active indicators the the things that stop the page load, like the "Stop! This is probably a phishing page!" error page. IIRC, users overwhelmingly appreciated the active indicators but tend to misunderstand the passive ones.

FWIW, ~33% of all pages are loaded over HTTPS already in Firefox, according to the metrics collected by the browser. And, over 50% of all HTTP requests (including subresources like images and scripts embedded on a page) are over HTTPS, again according to the usage data collected by the browser.

Browsers completely stop the page from loading and show a full-page error for a certificate error. There's a huge difference between that and a small icon in the location bar. Plus, if the red icon that is suggested in that bug report is too loud, a less loud indicator could be used instead.

There's a lot more to designing a UI for this than just changing the icon. For example, when you type "foo.com" into the address bar, browsers generally default to "http://foo.com" instead of "https://foo.com." And, consequently, browsers tend to show "http://foo.com" as "foo.com" to suggest that you don't need to type the "http://" part. All of that needs to change to become a lot smarter in order for this type of idea to succeed. However, it doesn't seem completely unreasonable to consider making all those changes. In fact, I think these changes should be a high priority for browsers makers.

tl;dr: I suggest people brainstorm ways to improve upon the idea to make it workable, instead of trying to shoot it down.

Aggregating the content of the web pages you have read can be used to deduce your identity, and/or the content of the web pages can be used to select you for targeting, like in the article I linked to above.

For example, let's say you wrote a blog post about fixing a configuration issue for touchpad issues on a ThinkPad X1 Carbon on Ubuntu 12.04. Imagine that a passive MitM saved the IP address of everybody who read that blog post in a database. Then, if an "interesting" person is known to be a ThinkPad X1 Carbon owner that uses Ubuntu 12.04. They can use that list of IP addresses of readers of that specific blog post to help narrow the search for the possible locations (via geo-IP) of that user.

Right now it is pretty easy to distinguish which webpage on your blog the reader is reading through traffic analysis, even when HTTPS is being used. But, people are working on things that make that traffic analysis more difficult.

You can see the CT peoples' comparison of CT to other technologies here: http://www.certificate-transparency.org/comparison

One serious concern I see about TACK from the browser's perspective is the support burden of dealing with server admins' lost TACK keys. HPKP has similar risks, but it seems to manage this risk in a way that is more comfortable for browsers to deal with. However, I also think that at least at Mozilla we've become more worried about the risks of HPKP than we were originally, and so there are plans to build the same kind of mechanism for dealing with DoS due to HPKP that a browser would need to build for TACK. It may be too late to get browsers to do TACK because they seem pretty committed to HPKP already and it is harder to convince them to do both. However, if you still want to try then I'd suggest presenting more clearly how browsers could deal with the "I lost my TACK key" scenerio.

The other major negative thing about TACK is that it requires the server admin to do work that can't be automated in a way that is reasonable (because the TACK key should not live on the web server). HPKP leaves more of an open door for future web servers to automatically apply it automatically (e.g. by generating pins for the end-entity, intermediates, and root keys in the chain, on the assumption that the server admin will never lose control of the private key of the end-entity at the same time he/she needs to switch CAs) or with very simplified UI.

Mozilla tends to announce projects when they begin so people can contribute to them right away. I think that's a good thing and that's one of the reasons I work for Mozilla.

By the way, I think this is an awesome effort by Josh and the others working on this. I work mainly in security and networking, and I'm excited about anything we can do to make end-to-end communication more efficient because these kinds of improvements help enable more use of HTTPS and help reduce (hopefully eliminate) the need for content transforming proxies.

I believe this merge shows the C code that implements the crush functionality: https://github.com/mozilla/mozjpeg/commit/c31dea21188b48498d...

First, define "properly."

Even though Firefox and Chrome both use the same TLS implementation (NSS's libssl), the ways in which Firefox and Chrome use it differ. Based on discussions with the credited researchers and with other members of the NSS team, Firefox doesn't need to implement such a restriction, so there's nothing to worry about as far as Firefox is concerned. And, that's about all I should say about it at this time, I think.

> (it's the TLS library for Firefox and Chrome)

The False Start bug in NSS that you are talking about (CVE-2013-1740) never affected a released version of Firefox; we found the bug during testing of False Start in preparation for enabling it in Firefox 26. We pushed back the enabling of False Start to Firefox 28 (which will be released next month) so that we could fix this bug first.

It would be hard to convince them to line up.

Firefox stopped using it on 2011-08-16. If you've seen Firefox using it recently when connecting through proxies, please let me know.

Ivan, it would be helpful to define what a "long max-age" is, exactly. In order to qualify for Firefox's HSTS preload list, max-age=10886400 or higher is required. Are you using the same boundary, or a different one?

Regarding #1 & #2: We need to find a way to drastically reduce (literally to zero) exploitable defects. Browsers, and especially Firefox, can go a lot farther here than they historically have. In the case of Firefox in particular, we'll figure out a way to make sandboxing work for Gecko and there's good reason to expect that Servo can succeed. But, even sandboxing and memory-safe languages cannot prevent logic problems. For example, https://bugzilla.mozilla.org/show_bug.cgi?id=919877 is up there as one of the worst SSL implementation bugs of all time, and Chrome's sandboxing did nothing to stop it, and neither would using a memory-safe language. (Edit: that bug never affected any Firefox release, as we found & fixed the bug before enabling that feature in the upcoming Firefox 28.) Ultimately, openness, and the verifiability that bolsters it, will be essential for getting to zero security vulnerabilities no matter what defense-in-depth mechanisms we put in place.

RE #3: I don't think the NSA even needs to try this yet, given #1 and #2. There are too many vulnerabilities going into browsers accidentally for anybody to bother deliberately adding one.

Re #4: On Windows, SSL is a defense-in-depth measure for protecting Firefox downloads/updates. Windows's Authenticode check is another defense-in-depth measure. I agree that both aren't perfect, but they aren't completely useless. More importantly, though, Firefox updates on Windows are signed and verified using a mechanism that is completely separate from the public PKI world. This is the primary defense (IMO) and this is something we should extend to updates on other platforms. (B2G has its own, different, wholly-separate signing mechanism too.) The design is sound though I wouldn't be surprised if there were things we could do operationally to improve things further; I don't know since I'm not in opsec.

> In other words, if we're serious about securing our browsers against this adversary, we need to think a lot bigger than just verifying that the binaries on our FTP servers match our source.

I don't think that anybody is going to disagree with this. However, this statement being true doesn't mean that verifiable, open-source builds are useless. Especially in the long term, as we improve in #1 and #2 in particular, verifiability and openness is very important.

Also, I miss you.

I don't know the exact plan since I'm not working on this, but it would be relatively easy for us to do:

1. Insist that the exact build configurations used by Cisco be open-sourced along with the rest of the code. 2. Require that every binary distributed by Cisco by tagged with the revision control revision ID. 3. Internally at Mozilla, build that revision of the code and compare the result to the binary blob that we would download from Cisco. Note we'd never distribute the outputs of our internal builds; we'd use those builds only to verify that the source code matches what we'd download. 4a: When we verify that the outputs match exactly, update some embedded hashes within Firefox to approve those versions of the binary blob for download/install, or 4b: Cisco could ask Mozilla to sign these blobs for them, and Mozilla would sign the blobs after doing the above checks. Then, the Firefox client would just verify that the blobs were signed by Mozilla's public key.

AFAICT, we (Mozilla) are trying to solve TWO problems:

1. We need a video codec that everybody agrees on for WebRTC.

2. We need a way to play H.264 on Windows XP and other operating systems that don't provide native H.264 playback, for compatibility with almost all HTML5 <video> content on the web.

If it weren't for problem #2, then I would agree with you more. But, really what Mozilla seems to have said is "Hey, if you provide a free H.264 decoder without field-of-use restrictions, then we'll compromise on WebRTC so we can make sure everybody on every platform can play all the HTML5 video content available on the web."

I don't have an opinion on VP9. But, there's no VP9 content on the web now. There's tons of H.264 content on the web. Mozilla got burned waiting for other players to help with WebM adoption before. Waiting for VP9 would probably just end up with us getting burned again.

FWIW, I work at Mozilla but not on this stuff, and I learned all I know on this topic from Brendan Eich's blog post.