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

[Michael Rogers]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 4660 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161006/a37756be/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161006/a37756be/attachment.sig>