[tor-commits] [torspec/master] Add draft prop273 from Phillipp Winter et al.
nickm at torproject.org
nickm at torproject.org
Fri Oct 7 16:21:56 UTC 2016
commit c7c1bf18f4ea5c06f8c57ce8d5a2fd27f8ed7998
Author: Nick Mathewson <nickm at torproject.org>
Date: Fri Oct 7 12:21:49 2016 -0400
Add draft prop273 from Phillipp Winter et al.
---
proposals/000-index.txt | 2 +
proposals/273-exit-relay-pinning.txt | 223 +++++++++++++++++++++++++++++++++++
2 files changed, 225 insertions(+)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index cf2102d..ebe00eb 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -193,6 +193,7 @@ Proposals by number:
270 RebelAlliance: A Post-Quantum Secure Hybrid Handshake Based on NewHope [DRAFT]
271 Another algorithm for guard selection [OPEN]
272 Listed routers should be Valid, Running, and treated as such [FINISHED]
+273 Exit relay pinning for web services [DRAFT]
Proposals by status:
@@ -221,6 +222,7 @@ Proposals by status:
268 New Guard Selection Behaviour
269 Transitionally secure hybrid handshakes
270 RebelAlliance: A Post-Quantum Secure Hybrid Handshake Based on NewHope
+ 273 Exit relay pinning for web services [for n/a]
NEEDS-REVISION:
190 Bridge Client Authorization Based on a Shared Secret
NEEDS-RESEARCH:
diff --git a/proposals/273-exit-relay-pinning.txt b/proposals/273-exit-relay-pinning.txt
new file mode 100644
index 0000000..91c3763
--- /dev/null
+++ b/proposals/273-exit-relay-pinning.txt
@@ -0,0 +1,223 @@
+Filename: 273-exit-relay-pinning.txt
+Title: Exit relay pinning for web services
+Author: Philipp Winter, Tobias Pulls, Roya Ensafi, and Nick Feamster
+Created: 2016-09-22
+Status: Draft
+Target: n/a
+
+0. Overview
+
+ To mitigate the harm caused by malicious exit relays, this proposal
+ presents a novel scheme -- exit relay pinning -- to allow web sites
+ to express that Tor connections should preferably originate from a
+ set of predefined exit relays. This proposal is currently in draft
+ state. Any feedback is appreciated.
+
+1. Motivation
+
+ Malicious exit relays are increasingly becoming a problem. We have
+ been witnessing numerous opportunistic attacks, but also highly
+ sophisticated, targeted attacks that are financially motivated. So
+ far, we have been looking for malicious exit relays using active
+ probing and a number of heuristics, but since it is inexpensive to
+ keep setting up new exit relays, we are facing an uphill battle.
+
+ Similar to the now-obsolete concept of exit enclaves, this proposal
+ enables web services to express that Tor clients should prefer a
+ predefined set of exit relays when connecting to the service. We
+ encourage sensitive sites to set up their own exit relays and have
+ Tor clients prefer these relays, thus greatly mitigating the risk of
+ man-in-the-middle attacks.
+
+2. 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.
+
+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=2678400
+
+ The "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
+
+2.4 Defending against malicious websites
+
+ The purpose of exit relay pinning is to protect a website's users
+ from malicious exit relays. We must further protect the same users
+ from the website, however, because it could abuse ERP to reduce a
+ user's anonymity set. The website could group users into
+ arbitrarily-sized buckets by serving them different ERP policies on
+ their first visit. For example, the first Tor user could be pinned
+ to exit relay A, the second user could be pinned to exit relay B,
+ etc. This would allow the website to link together the sessions of
+ anonymous users.
+
+ We cannot prevent websites from serving client-specific policies, but
+ we can detect it by having Tor Browser fetch a website's ERP policy
+ over multiple independent exit relays. If the policies are not
+ identical, Tor Browser MUST ignore the ERP policies.
+
+ If Tor Browser would attempt to fetch the ERP policy over n circuits
+ as quickly as possible, the website would receive n connections
+ within a narrow time interval, suggesting that all these connections
+ originated from the same client. To impede such time-based
+ correlation attacks, Tor Browser MUST wait for a randomly determined
+ time span before fetching the ERP policy. Tor Browser SHOULD
+ randomly sample a delay from an exponential distribution. The
+ disadvantage of this defence is that it can take a while until Tor
+ Browser knows that it can trust an ERP policy.
+
+2.5 Design trade-offs
+
+ We now briefly discuss alternative design decisions, and why we
+ defined ERP the way we did.
+
+ Instead of having a web server *tell* Tor Browser about pinned exit
+ relays, we could have Tor Browser *ask* the web server, e.g., by
+ making it fetch a predefined URL, similar to robots.txt. We believe
+ that this would involve too much overhead because only a tiny
+ fraction of sites that Tor users visit will have an ERP policy.
+
+ 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.
+
+ 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.
+
+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?
+
+ o Are there any aspects that are unnecessarily tricky to implement in
+ Tor Browser? If so, let's figure out how to make it easier to
+ build.
+
+ o Is a domain-level pinning granularity sufficient?
+
+ o Should we use the Ed25519 master or signing key?
+
+ o Can cached ERP policies survive a Tor Browser restart? After all,
+ we are not supposed to write to disk, and ERP policies are
+ basically like a browsing history.
+
+ o Should we have some notion of "freshness" in an ERP policy? The
+ problem is that an adversary could save my ERP policy for
+ example.com, and if I ever give up example.com, the adversary could
+ register it, and use my relays for pinning. This could easily be
+ mitigated by rotating my relay identity keys, and might not be that
+ big a problem.
+
+ o Should we support non-HTTP services? For example, do we want to
+ support, say, SSH? And if so, how would we go about it?
+
+ 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?
+
+ o It is wasteful to send a 60-70 byte header to all browsers while
+ only a tiny fraction of them will want it. Web servers could send
+ the header only to IP addresses that run an exit relay, but that
+ adds quite a bit of extra complexity.
+
+ o We currently defend against malicious websites by fetching the ERP
+ policy over several exit relays, spread over time. In doing so, we
+ are making assumptions on the number of visits the website sees.
+ Is there a better solution that isn't significantly more complex?
More information about the tor-commits
mailing list