I think directing users to an onion service would be significantly simpler and better in several regards. Aside from the 'onion severs can't get DV SSL certs' problem are there others Yawning or I have not mentioned?
As far as the proposal goes itself, I agree with Roger that the problem of user partitioning is pretty scary, and the 'network observation' approach is not a strong solution.
I like Roger's idea shipping pinning documents inside Tor Browser. As I mentioned in the tbb-dev thread, I think a OneCRL-like method would be a good solution for updating. Specifically Mozilla Kinto: https://wiki.mozilla.org/Firefox/Kinto which is designed for this.
Browsers currently have a problem with HPKP preloads wrt expiration and bricking. (As we saw recently!) Updating _that_ mechanism to use Kinto also might improve security and usability there as well, without impacting user partitioning either! And it might be something Mozilla is interested in doing themselves (meaning we don't need to build it.) If we got to this before them, we could always ship a static preload list per-version.
I have some comments on the draft itself, but the above higher-level ones take precedence.
On 5 October 2016 at 15:09, Philipp Winter phw@nymity.ch wrote:
- Design
2.1 Overview
A simple analogy helps in explaining the concept behind exit relay pinning: HTTP Public Key Pinning (HPKP) allows web servers to express that browsers should pin certificates for a given time interval. Similarly, exit relay pinning (ERP) allows web servers to express that Tor Browser should prefer a predefined set of exit relays. This makes it harder for malicious exit relays to be selected as last hop for a given website.
Web servers advertise support for ERP in a new HTTP header that points to an ERP policy. This policy contains one or more exit relays, and is signed by the respective relay's master identity key. Once Tor Browser obtained a website's ERP policy, it will try to select the site's preferred exit relays for subsequent connections. The following subsections discuss this mechanism in greater detail.
HSTS and HPKP include a 'preload' mechanism to bake things into the browser. I think TB would need the same thing, at a minimum, in addition to the header approach.
2.2 Exit relay pinning header
Web servers support ERP by advertising it in the "Tor-Exit-Pins" HTTP header. The header contains two directives, "url" and "max-age":
Tor-Exit-Pins: url="https://example.com/pins.txt"; max-age=2678400The "url" directive points to the full policy, which MUST be HTTPS. Tor Browser MUST NOT fetch the policy if it is not reachable over HTTPS. Also, Tor Browser MUST abort the ERP procedure if the HTTPS certificate is not signed by a trusted authority. The "max-age" directive determines the time in seconds for how long Tor Browser SHOULD cache the ERP policy.
After seeing a Tor-Exit-Pins header in an HTTP response, Tor Browser MUST fetch and interpret the policy unless it already has it cached and the cached policy has not yet expired.
2.3 Exit relay pinning policy
An exit relay pinning policy MUST be formatted in JSON. The root element is called "erp-policy" and it points to a list of pinned exit relays. Each list element MUST contain two elements, "fingerprint" and "signature". The "fingerprint" element points to the hex-encoded, uppercase, 40-digit fingerprint of an exit relay, e.g., 9B94CD0B7B8057EAF21BA7F023B7A1C8CA9CE645. The "signature" element points to an Ed25519 signature, uppercase and hex-encoded. The following JSON shows a conceptual example:
{ "erp-policy": [ "start-policy", { "fingerprint": Fpr1, "signature": Sig_K1("erp-signature" || "example.com" || Fpr1) }, { "fingerprint": Fpr2, "signature": Sig_K2("erp-signature" || "example.com" || Fpr2) }, ... { "fingerprint": Fprn, "signature": Sig_Kn("erp-signature" || "example.com" || Fprn) }, "end-policy" ] }
Fpr refers to a relay's fingerprint as discussed above. In the signature, K refers to a relay's master private identity key. The || operator refers to string concatenation, i.e., "foo" || "bar" results in "foobar". "erp-signature" is a constant and denotes the purpose of the signature. "start-policy" and "end-policy" are both constants and meant to prevent an adversary from serving a client only a partial list of pins.
The signatures over fingerprint and domain are necessary to prove that an exit relay agrees to being pinned. The website's domain -- in this case example.com -- is part of the signature, so third parties such as evil.com cannot coerce exit relays they don't own to serve as their pinned exit relays.
After having fetched an ERP policy, Tor Browser MUST first verify that the two constants "start-policy" and "end-policy" are present, and then validate the signature over all list elements. If any element does not validate, Tor Browser MUST abort the ERP procedure.
If an ERP policy contains more than one exit relay, Tor Browser MUST select one at random, weighted by its bandwidth. That way, we can balance load across all pinned exit relays.
Tor Browser could enforce the mapping from domain to exit relay by adding the following directive to its configuration file:
MapAddress example.com example.com.Fpr_n.exit
There is no mechanism to specify that this should include subdomains. And if it gets one, it should specify how to behave when a.example.com sets a different policy from example.com and example.com claims to be authoritative for a.example.com.
Additionally, one of the big pain points for HSTS/HPKP/OCSP Must Staple/RequireCT and many other proposals is third party domains. If you compromise the jQuery CDN you don't need to compromise the main website. TB must use the same circuit for all third party loads of a page though, right? (I'm embaressing myself in not knowing this.) Mentioning this requirement is important, especially because you have to key this data by the first party domain when you store it! Otherwise you get another fingerprinting attack.
ERP implies that adversaries get to learn all the exit relays from which all users of a pinned site come from. These exit relays could then become a target for traffic analysis or compromise. Therefore, websites that pin exit relays SHOULD have a proper HTTPS setup and host their exit relays topologically close to the content servers, to mitigate the threat of network-level adversaries.
I'm not sure which is easier:
- An attacker wants to do traffic analysis on example.com, which pins exits A, B, C. It obtains a network position at A, B, and C.
- An attacker wants to do traffic analysis on example.com, which accepts all exits. It obtains a network position just upstream of example.com
If the adversary can only do the former, this reduces security. If the adversary can do the latter, there is no impact.
It's possible to work around the bootstrapping problem (i.e., the very first website visit cannot use pinned exits) by having an infrastructure that allows us to pin exits out-of-band, e.g., by hard-coding them in Tor Browser, or by providing a lookup service prior to connecting to a site, but the additional complexity does not seem to justify the added security or reduced overhead.
Disagree on the preloading.
A pre-connection lookup would be horrendous on usability, so strong dislike on that one.
2.6 Open questions
o How should we deal with selective DoS or otherwise unavailable exit relays? That is, what if an adversary takes offline pinned exit relays? Should Tor Browser give up, or fall back to non-pinned exit relays that are potentially malicious? Should we give site operators an option to express a fallback if they care more about availability than security?
Yes, there should be a directive that allows websites to choose fail-open or fail-close.
o HPKP also defines a "report-uri" directive to which errors should be reported. Do we want something similar, so site operators can detect issues such as attempted DoS attacks?
In general, report-uri (and a report only mode) is one of those things that seems to be extra stuff but in hindsite has been the only thing that allows features like HSTS*, CSP, and HPKP to be deployed. In this case it could tell site operators how many failed circuits are made to exits and thus how this is impacting user browser experience...
* HSTS used CSP as a report-uri workaround.
-tom