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

[Georg Koppen]

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-linkability)
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161018/afaeaa16/attachment.sig>