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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev