Hi, Micah Lee wrote (25 Jun 2014 18:35:45 GMT) : > Rather than replying in-line to everything, I'll just summarise:
Thanks, that was a good read. In case torbrowser-launcher doesn't have a security design doc yet, this should be a pretty good start :) > * TLS/x.509 security: torbrowser-launcher doesn't rely on the CA > infrastructure. The only TLS it does is make HTTPS requests to > check.torproject.org and (if you haven't set a mirror) > www.torproject.org. When it connects to these hostnames, it uses a > hardcoded certificate. So none of the TLS PKI issues apply at > all here. I like the idea of using the Debian archive as a side-channel, presumably already somewhat trusted, to distribute the included certificate. @Debian maintainers: it might be nice to make the stable release team aware that this package will most likely need to be updated in stable point-releases, when the certificate changes. @Micah: I hope you've got a good, automated way to promptly detect changes in the certificate(s) used by www.torproject.org. And if you have one, I'd be glad to steal and re-use it :) > * Downgrade attacks shouldn't be possible, unless they're committed by > Tor devs themselves. If an attacker captures a valid old request to > https://check.torproject.org/RecommendedTBBVersions that claims that the > current version is an older version than what's currently installed, > torbrowser-launcher prevents it from installing. (And by "installing" I > mean extracting to the user's home dir.) > However, there is the scenereo where the user has set a third-party > mirror to download from instead of the default. The third-party mirror > could serve a tarball and sig that have filenames of the latest version, > but are actually an older version. This attack is mitigated by [...] When we've thought Tails incremental upgrades through, the best defense we've found against downgrade attacks is to encode the version information about a given target file (using the TUF specification nomenclature [1] here) as part of what's strongly authenticated (in this case, with OpenPGP), instead of trusting filenames in any way. That's what our upgrade-description files [2] are for. But even then, against an adversary who controls the web space that hosts the upgrade-description files, or who can break TLS, Indefinite freeze attacks are still possible. The only way I've see to mitigate it is short-lived signatures on meta-data. In the case of tor-launcher, it may be possible to drop the indirection layer (upgrade-description files), and protect against downgrade attacks simply by comparing the currently running version, with the version information that is, I guess, present in the target files, once they've been downloaded and authenticated. [I'm now realizing that the TUF spec has changed since last time I've read it. And Tor Browser's upcoming self-upgrade super-power may be a game changer.] [1] https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt [2] https://tails.boum.org/contribute/design/incremental_upgrades/ Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
