Binary Transparency for Firefox
wiki.mozilla.org
wiki.mozilla.org
In that manner they can piggy-back on top of the CT ecosystem (including existing logs, including existing search / monitoring tools, and presumably gossip if/when that's solved).
This seems like a really cool hack! The state of binary software distribution is really pretty scary when you think about it - techniques like this have the potential to restore a lot of confidence.
Interesting. I assume this either helped with the evidence for - or was developed because of - the whole Symantec CA dustup going on?
[0] https://security.googleblog.com/2015/09/improved-digital-cer... [1] http://searchsecurity.techtarget.com/news/450411573/Certific... [2]
https://arstechnica.com/security/2017/01/already-on-probatio...
> Ayer discovered the unauthorized certificates by analyzing the publicly available certificate transparency log
That article also links to the primary source, https://www.mail-archive.com/dev-security-policy@lists.mozil... which in turn links to a public viewer for Certificate Transparency logs.
If FF is already doing any log inclusion proofs for certificates, then I think including one more (for the FF release itself) would be pretty much line noise.
I think an interesting question arises as to how well with the CT logs themselves would scale to handle the same kinds of certificates for all binaries, if this ends up taking off as a good idea in general. They've had to handle quite an explosion in X509 certificates over the past year or two due to Let's Encrypt. Some of Google's logs now show more than 80,000,000 certificates [0] in there - IIRC 2 years ago it was a low single digit million.
One is that log bloat is indeed a problem, not so much for the logs, but for those that want to monitor them.
The other is CT has made some tradeoffs to allow cert issuance to be quick. I don't believe binaries need the same tradeoffs, and, for example, instead of an SCT, they should come with an inclusion proof (something I'd like to see for certs, too, in the long run).
http://blog.airbornos.com/post/2015/04/25/Secure-Delivery-of...
The one worry that comes to mind, though, is that once a binary transparency log check is made mandatory for any update to a piece of software, there is a risk that a bug in the log checking code makes it impossible to ever upgrade the software again. (This reminds me of the HPKP Suicide attack, but is not quite the same).
Obviously it should be possible, with Firefox at least, to manually download a new copy of the installer and install it from scratch, but I feel there should be a fall-back mechanism where, say, a release signed with a special offline key should be allowed to skip the transparency check (perhaps only if the transparency check has been failing on an offered upgrade for more than a month).
An up-side to not having a fall-back mechanism is that you can't produce a secret update. No matter many 5$ a wrenches the NSA can afford (https://xkcd.com/538/).
edit:
IMHO mozilla should orient its transparency effort towards its decision process first so we don't end with a binary transparent browser no one use because management decided to remove user choice and break the UI (to look more like chrome), break extensions that contributed to firefox success (to be more like chrome), require pulseaudio and drop alsa and so on.
Binary transparency ensures that there's a complete, public list of all updates sent out. It's an additional level of verification showing that the source isn't up to any shenanigans.
It's more of a deterrent though. It doesn't prevent sending a custom update; it just makes it difficult to hide.
If people are combining Reproducible Builds with Binary Transparency, then the attacker probably has to release the same binary to everyone, and release the source code containing the malicious change.
It remains to be seen whether enough people would audit the source code diffs of each release of Firefox, say, to stop a malicious update from affecting a large number of users. In particular, mechanisms would need to be put in place to stop users updating to a release which was discovered (or reported and then verified) to be compromised.
The trick is to be confident that you're getting the same hash as everyone else - and that's what requiring a proof that it be added to a CT logs gives you some level of assurance about.
Why should one care about (1)? All that really matters is (2). As long as I'm using a genuine release, does it matter what the rest of the world is using? Unless I wish to establish trust in a binary based on how popular it is, or unless I care about interoperability between the version I have and the version others have, it doesn't really matter what version everyone else has.
I wonder if the author has heard about Nix or Guix? The purely functional software deployment model pioneered by Nix solves (2) trivially, for practically all applications in general, not just Firefox specifically. It also solves many other problems in the field of software deployment that this article doesn't even mention.
Long story short, don't reinvent the wheel. Use Nix or Guix. Learn more by reading the first chapter of Eelco Dolstra's thesis, which describes the problems and how the Nix model solves them:
https://nixos.org/~eelco/pubs/phd-thesis.pdf
Edit: Even if one is concerned about (1), the Nix model enables ways to verify that the origin is actually sending a binary that was built from the source it claims to use. For example, consider "guix challenge":
https://www.gnu.org/software/guix/manual/html_node/Invoking-...
In the case with neither binary transparency or reproducible builds, a nefarious actor can target a single user with a tainted binary and it's unlikely that the user will find out and difficult for them to rule out the possibility of tampering up-front.
In the case with binary transparency but no reproducible builds, a nefarious actor must target all users which makes it more likely that someone will notice, but still difficult for people to rule out tampering up-front.
In the case with reproducible builds but no binary transparency, it's easy for people who are paranoid to rule out tampering with the binary, but people who aren't paranoid are unlikely to discover that their specific binaries were tampered with, so a targeted attack will still probably go undetected.
In the case with both reproducible builds and binary transparency, it only takes one paranoid person discovering a tampered binary to alert the whole world that their own binaries have been tampered with. It's safety in numbers, even for those not technically-literate enough to determine (or even suspect) tampering.
I am not simply saying "They should use Nix" as if that would magically accomplish their goals. I am saying that they could build on top of, or at least learn from, the novel techniques that Nix has contributed to the field of software deployment.
This also includes, perhaps, (1d) there are some secret antifeatures in the software whose existence the developer hopes to conceal from the general user population.
For some of these cases, "you" might include not just one person, but also users in a particular country, language community, or income bracket.
Edit: I agree that there may be technical solutions other than binary transparency in particular that can also address some of these concerns.