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

[Roger Dingledine]

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