[tor-dev] Proposal 273: Exit relay pinning for web services

[Tom Ritter]

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 at 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