Proposal 273: Exit relay pinning for web services
The proposal is in draft state. We have several open questions that we are still wrestling with in Section 2.6. Any feedback is greatly appreciated. You can track the evolution of our proposal online: <https://github.com/NullHypothesis/exit-pinning> --- 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?
On Wed, 5 Oct 2016 16:09:15 -0400 Philipp Winter <phw@nymity.ch> wrote:
The proposal is in draft state. We have several open questions that we are still wrestling with in Section 2.6. Any feedback is greatly appreciated. You can track the evolution of our proposal online: <https://github.com/NullHypothesis/exit-pinning>
Seems reasonable, but.... How is this better than "Tor Browser will honor and aggressively utilize onion addresses in Alt-Svc headers[0]". Eg: Alt-Svc: onion="onionsarelongandsilly.onion:443"; ma=86400 Regards, -- Yawning Angel [0]: https://tools.ietf.org/html/rfc7838
On Wed, Oct 05, 2016 at 04:09:15PM -0400, Philipp Winter wrote:
Filename: 273-exit-relay-pinning.txt Title: Exit relay pinning for web services
Good topic! I'm glad people are still working on this one.
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.
Does that mean your expiration time might be served over an unauthenticated channel? That seems potentially really bad.
and "signature". The "fingerprint" element points to the hex-encoded, uppercase, 40-digit fingerprint of an exit relay, e.g., 9B94CD0B7B8057EAF21BA7F023B7A1C8CA9CE645.
(Minor point) Those are hexes, not digits. :)
The "signature" element points to an Ed25519 signature, uppercase and hex-encoded.
One day, Tor relays will have some other cryptosystem for their identities. Then you will wish that your document format included some sort of versioning, or specified the cryptosystem, etc.
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
Yow! So each user is tagged forever with whichever one they picked? That partitions the users across these exits, acting as a form of cookie.
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.
This issue is a big part of why, when I was pondering this idea for pinning websites to onion addresses, I wanted to make sure that all users got the same view of the pins. The way I had imagined doing it was to ship a series of pin documents inside Tor Browser (or inside https-everywhere or equivalent), and have some public observatories that crawl the sites periodically to keep the pinning documents up to date, and then the whole world can watch and audit and duplicate that process. This issue is important because a website could issue a new pinning document every hour or something, and it would totally get around the "fetch it from a bunch of locations" defense you describe here, yet one per hour is plenty of detail when it comes to distinguishing users who got their pinning documents weeks ago.
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.
Does the "everybody gets the same view" feature change your mind here? Also, as Yawning mentioned, it seems like some sort of pinning feature like this could be used to tie an https cert to an onion address too? So this could be (should be) extended to not just be about exit relays.
2.6 Open questions
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.
Great question. I think they can't get written to disk if they give away user activity, which really limits their effectiveness, especially for security-critical websites. I assume they should also get thrown away during new identity, else the user will be revealing that they've already been to this website (and when)? Wouldn't it be nice if all the users had the same view of pins, so we would be fine persisting them across restarts? :)
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?
Not just the number of visits, but also the increased visibility by a network adversary who is curious which Tor users visit that website. --Roger
On Wed, Oct 5, 2016 at 4:09 PM, Philipp Winter <phw@nymity.ch> wrote:
Also, Tor Browser MUST abort the ERP procedure if the HTTPS certificate is not signed by a trusted authority.
This is a problem for independant sites that choose not to pay the CA cabal, deal with what free CA will be around tomorrow, or run their own certs. And needs bypassed if users pin the site cert fingerprint in browser.
Tor Browser MUST fetch and interpret the policy
Big problem for any sort of debugging, observatory, geo selection, estimated risk of compromised exit, or simply refusal by the user. Must be disableable in browser config.
The "fingerprint" element points to the hex-encoded, uppercase, 40-digit fingerprint of an exit relay, e.g., 9B94CD0B7B8057EAF21BA7F023B7A1C8CA9CE645.
This should be lower case... https://trac.torproject.org/projects/tor/ticket/12799
The "signature" element points to an Ed25519 signature, uppercase and hex-encoded.
Ditto.
"start-policy" and "end-policy" are both constants and meant to prevent an adversary from serving a client only a partial list of pins.
This is https so it's unlikely and a bit moot, yet assuming it was plaintext, the set couldn't be asserted anyways without sig from site cert or from dnssec or even pgp.
The purpose of exit relay pinning is to protect a website's users from malicious exit relays.
Better the site run an onion to offer cover all users of all web tools, not just tbb, eliminate chance of compromised exit, and eliminate the ISP / GPA clearnet gap. And though not as sneaky a way to get more relays deployed, they can then still volunteer to run or pay for some.
If Tor Browser would attempt to fetch the ERP policy over n circuits
Perhaps costly / noisy without prebuilt circuits.
within a narrow time interval, suggesting that all these connections disadvantage of this defence is that it can take a while until Tor
if max-age < (interval or determination) then bad.
we could have Tor Browser *ask* the web server
Great for advertising demand for tor in logs. Great for blocking tor.
host their exit relays topologically close to the content servers, to mitigate the threat of network-level adversaries.
Moot given the implied traffic analyzing PA's. other:
(Minor point) Those are hexes, not digits. :)
[0-9A-F] are the complete set of *digits* making up base-16 "hex[adecimal]" *number* system. as are [0-7] base-8 "octal", [a-z] base-26, [whatever-chars] base-whatever. Some RFC's even refer to them as digits, 4291 IPv6 for example. They're more properly called "symbols representing values", spoken as digits, by aliens in their base [world].
some sort of versioning, or specified the cryptosystem, etc.
Speaking of RFC, ERP may be an idea, but who are the guniea pig supporting sponsor sites, and who's doing the RFC, and prepared to pin this thing for years? You could put the sites in the relay descriptors for client choice, but they'd still need crosschecked with site sigs, and could bloat consensus more.
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:
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.
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=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
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
Philipp Winter:
The proposal is in draft state. We have several open questions that we are still wrestling with in Section 2.6. Any feedback is greatly appreciated. You can track the evolution of our proposal online: <https://github.com/NullHypothesis/exit-pinning>
Hi Philipp, It might be interesting to use this in conjunction with Namecoin. In the same way that Namecoin can reduce some of the issues with HPKP (Namecoin gives all nodes the same view, doesn't rely on TOFU, and isn't specific to HTTP), it seems like allowing Namecoin domain names to specify exit relay pins might reduce those issues here. Of course, this only is helpful for services that have a Namecoin domain name. Would there be interest in this capability? Cheers, -Jeremy
On 05/10/16 21:09, Philipp Winter wrote:
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.
If I run a bad exit and intercept the user's first HTTP connection to the server, I can substitute the URL of a policy on my own server that permanently pins the user to my bad exit. Who cares if the policy has to be served over HTTPS, if I get to say where it's served from? A couple of possible mitigations: * Require the pin URL to have the same FQDN as the connection that supplies the header * Forbid the pin header from being served over plain HTTP, and apply the same trusted certificate rules to the connection that supplies the header as the connection that supplies the policy (sites that want pinning can use HSTS to upgrade HTTP to HTTPS before serving the pin header) Cheers, Michael
Won't comment on the entire content because I have one big comment which refers to the entire proposal or better say the concept of the proposal. I would reject this proposal's concept, because we have o excuse to over-engineer and complicate things in this manner. This is just too complicated for absolutely no gains, even worse opens the door for new stuff we don't need. Here are just a few reasons: 1. Websites need to build and maintain an up to date pinning policy. 2. Relays need to maintain a confirmation pinning policy, which complicates things from relay operator side and not to say Tor client side which needs to fetch both, compare, etc. 3. The descriptor of exit relays grows with pinning policy, putting extra load on the entire ecosystem including the clients. 4. Fetching the policy multiple times using different exit nodes will a) put extra load on the network and most important b) take a lot of time (in terms of user interaction) to load such a website -- we are trying to make an anonymous LOW LATENCY network, which is why we cannot afford this. If we wanted a HIGH LATENCY anonymity network there's so much better stuff we can do to mitigate attacks, but the price is not worth it -- Tor's main use case relates to the fact that it's a LOW LATENCY network, it's a fundamental design. If my website would take 60 seconds to load for Tor users for me it would mean that I hate those users, metaphorically speaking. 5. Opens new [unknown] attacks on anonymity, like setting up malicious pinned exit relays that only accept incoming connections from custom evil middle relays, increasing chances for guard discovery or total deanonymization. Combine this with the content data generated by the user on the website and you have a pretty narrowed list. 6. Opens attacks of DoS on the website, making it inaccessible through Tor by attacking the pinned exits (while we have CDNs and flood protection for clearnet websites, there is no such things for exit nodes -- you just need a big expensive server that has a bigger pipe than the attacker can fill). This will make it very expensive to run a website with pinned Tor exits reasonable immune to DoS attacks. We already have another solution to achieve this with no extra complications and using well tested stuff that does not overload the network, does not overload the clients, do not require significant changes to Tor Browser (besides coding Tor Browser to handle the string serving the onion url, does not even require a proposal -- just a good wiki page [which I made a sticky note to do]) and maintains the anonymity level for the clients: 1. Website that wants to be accessible via Tor should setup a hidden service mirror. Given that since it's also a clearnet website, we assume it does not need location anonymity, so single-hop [rendezvous] hidden services can be used which can scale to whatever that website needs. Say I have a 1 gbps line, I don't care about location anonymity because my website is clearnet public anyway and I want my website to handle many Tor users, just setup a bridge Tor instance on localhost (127.0.0.1) not published to the bridge authority, point the second Tor instance to use bridge 127.0.0.1:port and single hop hidden services. The bottleneck here is my own internet line (and CPU probably). Plenty of other solutions like OnionBalance are also available. 2. Website includes in HTTP headers the onion url instead of pinning policy. This MUST be over HTTPS so an user doesn't get redirected to a fake .onion mirror. You have more chances to convince website operators to include just this extra line rather than pinning policy + maintain pinning policy + exit nodes + exit nodes policy + maintain exit nodes policy. The same level of trust is on the CA, not more. 3. We do not necessarily need a SSL certificate for the onion common name, that's already encrypted end to end and self authenticated. We use the clearnet SSL certificate to make sure clients are pointed to the right onion mirror of a clearnet website so there's no additional cost for a second SSL certificate even, as opposite to running a reasonable number of exit relays pinned to a website. On 10/5/2016 11:09 PM, Philipp Winter wrote:
The proposal is in draft state. We have several open questions that we are still wrestling with in Section 2.6. Any feedback is greatly appreciated. You can track the evolution of our proposal online: <https://github.com/NullHypothesis/exit-pinning>
---
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 [...]
On 7 Oct 2016, at 00:22, s7r <s7r@sky-ip.org> wrote:
I don't care about location anonymity because my website is clearnet public anyway and I want my website to handle many Tor users, just setup a bridge Tor instance on localhost (127.0.0.1) not published to the bridge authority, point the second Tor instance to use bridge 127.0.0.1:port and single hop hidden services.
I don't understand why you have an extra bridge relay here. Can't you just use HiddenServicePort 80 ? T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------------
teor wrote:
On 7 Oct 2016, at 00:22, s7r <s7r@sky-ip.org> wrote:
I don't care about location anonymity because my website is clearnet public anyway and I want my website to handle many Tor users, just setup a bridge Tor instance on localhost (127.0.0.1) not published to the bridge authority, point the second Tor instance to use bridge 127.0.0.1:port and single hop hidden services.
I don't understand why you have an extra bridge relay here. Can't you just use HiddenServicePort 80 ?
Sorry - my bad, I thought of OnionBalance in general setups first (and that the bottleneck becomes the guard that also handles other clients) and mixed up in my mind different setup scenarios. HiddenServiceSingleHopMode 1 ensures that the hidden service server connects to the introduction points and rendezvous points directly, without going through a Guard, so there's no bottleneck here, case in which there's no need for an extra bridge relay.
On Wed, Oct 5, 2016 at 4:09 PM, Philipp Winter <phw@nymity.ch> wrote:
The proposal is in draft state. We have several open questions that we are still wrestling with in Section 2.6. Any feedback is greatly appreciated. You can track the evolution of our proposal online: <https://github.com/NullHypothesis/exit-pinning>
Added to the torspec repository. Please keep sending patches / merge requests to keep everybody synchronized. (Also, everybody, please be aware that picking your own proposal number sometimes causes collisions. This time, we all got lucky. No worries.) cheers, -- Nick
Hi, On Wed, Oct 05, 2016 at 04:09:15PM -0400, Philipp Winter wrote:
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.
I think that it would be good if the overview and motivation sections of the proposal discussed what concrete attack(s) the proposal aims to prevent, and why "exit relay pinning" is a better solution to address these attacks than any alternative method. Indeed, the only concrete attack mentioned is a man-in-the-middle attack. Some questions: - Are the "opportunistic" or "sophisticated, targeted" attacks all man-in-the-middle attacks, or are there other attacks? - How do the "opportunistic" attacks differ from the "sophisticated" ones? Are they actually different attacks, or just different strategies that malicious exits use to tamper with traffic? - If the attacks this proposal seeks to address really are all various flavours of man-in-the-middle attacks, why is end-to-end encryption (either using HTTPS, with or without pinning, or .onion addresses, or both) not sufficient to solve the problem? Moreover, I don't understand how it actually solves the problem of malicious exit relays tampering with traffic. Either the entity running the web service runs their own exit relays that they trust, or the entity running the web service pins to exits they don't control. In the first case, why wouldn't they just configure an (single) onion site, and get actual end-to-end authenticated encryption? In the second case, the web service operator has to somehow trust the exit operator (on what basis?) and in return for handing the "trusted" exit(s) the opportunity to MitM all their traffic, gets ... no extra assurance about data integrity. As has been noted by others in the thread, "exit relay pinning" amounts to allowing arbitrary (hostile) servers to store (arbitrary) information in the client's Tor instance, and alter the client's path selection algorithms. This seems like a lot of new attack surface to add, and I don't understand from the motivation section a) exactly what attacks exit pinning is meant to address; or b) why those attacks can't be addressed by HTTPS or onion services. Cheers, Henry de Valence
A concern with this proposal that I have not seen mentioned is that exit pinning would cause the Tor path itself to leak more information about the intended destination. For example, a destination could (possibly without malicious intent) pin a single exit that is otherwise unlikely to be used. Simply choosing that exit would thus make it appear much more likely to be visiting that destination from the view of an adversary that can identify the exit (e.g. by being chosen as the middle relay or by performing a congestion attack that identifies relays on a circuit). This gets worse when connections can be linked together as originating at the same client because without pinning it is unlikely to repeatedly choose the same exit (or from any small set of exits). Connections can be linked as originating at the same client by the guard (or anybody observing a guard) or by middle relays that observe the same guard being used in a short period of time, indicating activity by the same client. Best, Aaron
On Oct 11, 2016, at 7:58 PM, Henry de Valence <hdevalence@riseup.net> wrote:
Hi, On Wed, Oct 05, 2016 at 04:09:15PM -0400, Philipp Winter wrote:
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.
I think that it would be good if the overview and motivation sections of the proposal discussed what concrete attack(s) the proposal aims to prevent, and why "exit relay pinning" is a better solution to address these attacks than any alternative method. Indeed, the only concrete attack mentioned is a man-in-the-middle attack.
Some questions:
- Are the "opportunistic" or "sophisticated, targeted" attacks all man-in-the-middle attacks, or are there other attacks?
- How do the "opportunistic" attacks differ from the "sophisticated" ones? Are they actually different attacks, or just different strategies that malicious exits use to tamper with traffic?
- If the attacks this proposal seeks to address really are all various flavours of man-in-the-middle attacks, why is end-to-end encryption (either using HTTPS, with or without pinning, or .onion addresses, or both) not sufficient to solve the problem?
Moreover, I don't understand how it actually solves the problem of malicious exit relays tampering with traffic. Either the entity running the web service runs their own exit relays that they trust, or the entity running the web service pins to exits they don't control.
In the first case, why wouldn't they just configure an (single) onion site, and get actual end-to-end authenticated encryption? In the second case, the web service operator has to somehow trust the exit operator (on what basis?) and in return for handing the "trusted" exit(s) the opportunity to MitM all their traffic, gets ... no extra assurance about data integrity.
As has been noted by others in the thread, "exit relay pinning" amounts to allowing arbitrary (hostile) servers to store (arbitrary) information in the client's Tor instance, and alter the client's path selection algorithms.
This seems like a lot of new attack surface to add, and I don't understand from the motivation section
a) exactly what attacks exit pinning is meant to address; or b) why those attacks can't be addressed by HTTPS or onion services.
Cheers, Henry de Valence _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Sat, Oct 15, 2016 at 07:02:19PM -0400, Aaron Johnson wrote:
A concern with this proposal that I have not seen mentioned is that exit pinning would cause the Tor path itself to leak more information about the intended destination. For example, a destination could (possibly without malicious intent) pin a single exit that is otherwise unlikely to be used. Simply choosing that exit would thus make it appear much more likely to be visiting that destination from the view of an adversary that can identify the exit (e.g. by being chosen as the middle relay or by performing a congestion attack that identifies relays on a circuit). This gets worse when connections can be linked together as originating at the same client because without pinning it is unlikely to repeatedly choose the same exit (or from any small set of exits). Connections can be linked as originating at the same client by the guard (or anybody observing a guard) or by middle relays that observe the same guard being used in a short period of time, indicating activity by the same client.
Whenever the Tor client gets told which exit to use for a circuit, it uses a 4-hop path for that circuit, i.e., it uses 3 hops like normal and then the fourth hop is the chosen exit. Though it's actually more complex than that, because if it knows it'll be using a 4-hop circuit, the 2nd and 3rd hop are both chosen like middles, so "like normal" is not wholly true. It's effectively like choosing a 3-hop internal circuit and then appending your chosen exit. So some of the attacks you worry about shouldn't work, but I bet some of them still would. --Roger
Philipp Winter: [snip]
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.
I'd like to pick up a point Tom briefly mentioned. The intended behavior seems at first glance to violate Tor Browser's Tor circuit and HTTP connection unlinkability requirement (https://www.torproject.org/projects/torbrowser/design/#identifier-linkabilit...) which states: """ Tor circuits and HTTP connections from a third party in one URL bar origin MUST NOT be reused for that same third party in another URL bar origin. """ One could try to argue "well, we just make sure then that the middle relays are different depending on the URL bar domain" but I'd like to see an analysis if that actually helps. (fwiw: we could actually be fine with respect to the HTTP connection linkability but that needs double-checking at any rate) Moreover, I'd like to see an analysis about what exactly an attacker learns with your scheme if you take into account that websites are comprised of a mix of resources that are fetched from domains which might or might not have an ERP. Plus, I'd like to see some pondering about the usability fallout if suddenly not all resources are loaded over the same circuit anymore (because only some of the third party domains have ERP while others do not). My gut feeling is that it would break quite some websites. (it already broke things back then when we isolated to the FQDN, see below)
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.
I stumbled over this one: maybe "which MUST be served over HTTPS"?
o Is a domain-level pinning granularity sufficient?
I think we should definitely start with that one. See #15933 (especially comment 6) for some usability issues we run into when trying to isolate to the FQDN.
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.
That is tricky. Ideally not but on the other hand this is a security measure that loses much of its potential if not available over more than one session. Those policies would need to get cleared if a user requests a new identity at least. FWIW: Firefox is clearing HSTS state after a Private Browsing Mode session is closed. However, Tor Browser is using permanent Private Browsing Mode which does not do this currently (see: #18589). Georg
participants (13)
-
Aaron Johnson -
Georg Koppen -
grarpamp -
Henry de Valence -
Jeremy Rand -
Michael Rogers -
Nick Mathewson -
Philipp Winter -
Roger Dingledine -
s7r -
teor -
Tom Ritter -
Yawning Angel