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

[grarpamp]

On Wed, Oct 5, 2016 at 4:09 PM, Philipp Winter  wrote:
> Also, Tor Browser MUST abort the ERP procedure if the HTTPS
>  certificate is not signed by a trusted authority.

This is a problem for independant sites that choose not to pay
the CA cabal, deal with what free CA will be around tomorrow,
or run their own certs.
And needs bypassed if users pin the site cert fingerprint in browser.

> Tor Browser
>   MUST fetch and interpret the policy

Big problem for any sort of debugging, observatory, geo selection,
estimated risk of compromised exit, or simply refusal by the user.
Must be disableable in browser config.

>The "fingerprint" element points to the
>hex-encoded, uppercase, 40-digit fingerprint of an exit relay, e.g.,
>9B94CD0B7B8057EAF21BA7F023B7A1C8CA9CE645.

This should be lower case...
https://trac.torproject.org/projects/tor/ticket/12799

> The "signature" element
>   points to an Ed25519 signature, uppercase and hex-encoded.

Ditto.

> "start-policy" and "end-policy" are both constants
>   and meant to prevent an adversary from serving a client only a
>   partial list of pins.

This is https so it's unlikely and a bit moot, yet assuming it was
plaintext, the set couldn't be asserted anyways without sig
from site cert or from dnssec or even pgp.

>   The purpose of exit relay pinning is to protect a website's users
>  from malicious exit relays.

Better the site run an onion to offer cover all users of all web tools,
not just tbb, eliminate chance of compromised exit, and eliminate
the ISP / GPA clearnet gap. And though not as sneaky a way to get
more relays deployed, they can then still volunteer to run or pay for some.

>   If Tor Browser would attempt to fetch the ERP policy over n circuits

Perhaps costly / noisy without prebuilt circuits.

>   within a narrow time interval, suggesting that all these connections
>   disadvantage of this defence is that it can take a while until Tor

if max-age < (interval or determination) then bad.

> we could have Tor Browser *ask* the web server

Great for advertising demand for tor in logs.
Great for blocking tor.

>   host their exit relays topologically close to the content servers, to
>   mitigate the threat of network-level adversaries.

Moot given the implied traffic analyzing PA's.


other:

> (Minor point) Those are hexes, not digits. :)

[0-9A-F] are the complete set of *digits* making up base-16
"hex[adecimal]" *number* system. as are [0-7] base-8 "octal",
[a-z] base-26, [whatever-chars] base-whatever. Some RFC's
even refer to them as digits, 4291 IPv6 for example.
They're more properly called "symbols representing values",
spoken as digits, by aliens in their base [world].

> some sort of versioning, or specified the cryptosystem, etc.

Speaking of RFC, ERP may be an idea, but who are the
guniea pig supporting sponsor sites, and who's doing
the RFC, and prepared to pin this thing for years?

You could put the sites in the relay descriptors
for client choice, but they'd still need crosschecked
with site sigs, and could bloat consensus more.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [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  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 

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

[Jeremy Rand]

Philipp Winter:
> The proposal is in draft state.  We have several open questions that we
> are still wrestling with in Section 2.6.  Any feedback is greatly
> appreciated.  You can track the evolution of our proposal online:
> 

Hi Philipp,

It might be interesting to use this in conjunction with Namecoin.  In
the same way that Namecoin can reduce some of the issues with HPKP
(Namecoin gives all nodes the same view, doesn't rely on TOFU, and isn't
specific to HTTP), it seems like allowing Namecoin domain names to
specify exit relay pins might reduce those issues here.  Of course, this
only is helpful for services that have a Namecoin domain name.

Would there be interest in this capability?

Cheers,
-Jeremy




signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[s7r]

Won't comment on the entire content because I have one big comment which
refers to the entire proposal or better say the concept of the proposal.

I would reject this proposal's concept, because we have o excuse to
over-engineer and complicate things in this manner. This is just too
complicated for absolutely no gains, even worse opens the door for new
stuff we don't need. Here are just a few reasons:

1. Websites need to build and maintain an up to date pinning policy.

2. Relays need to maintain a confirmation pinning policy, which
complicates things from relay operator side and not to say Tor client
side which needs to fetch both, compare, etc.

3. The descriptor of exit relays grows with pinning policy, putting
extra load on the entire ecosystem including the clients.

4. Fetching the policy multiple times using different exit nodes will a)
put extra load on the network and most important b) take a lot of time
(in terms of user interaction) to load such a website -- we are trying
to make an anonymous LOW LATENCY network, which is why we cannot afford
this. If we wanted a HIGH LATENCY anonymity network there's so much
better stuff we can do to mitigate attacks, but the price is not worth
it -- Tor's main use case relates to the fact that it's a LOW LATENCY
network, it's a fundamental design. If my website would take 60 seconds
to load for Tor users for me it would mean that I hate those users,
metaphorically speaking.

5. Opens new [unknown] attacks on anonymity, like setting up malicious
pinned exit relays that only accept incoming connections from custom
evil middle relays, increasing chances for guard discovery or total
deanonymization. Combine this with the content data generated by the
user on the website and you have a pretty narrowed list.

6. Opens attacks of DoS on the website, making it inaccessible through
Tor by attacking the pinned exits (while we have CDNs and flood
protection for clearnet websites, there is no such things for exit nodes
-- you just need a big expensive server that has a bigger pipe than the
attacker can fill). This will make it very expensive to run a website
with pinned Tor exits reasonable immune to DoS attacks.


We already have another solution to achieve this with no extra
complications and using well tested stuff that does not overload the
network, does not overload the clients, do not require significant
changes to Tor Browser (besides coding Tor Browser to handle the string
serving the onion url, does not even require a proposal -- just a good
wiki page [which I made a sticky note to do]) and maintains the
anonymity level for the clients:

1. Website that wants to be accessible via Tor should setup a hidden
service mirror. Given that since it's also a clearnet website, we assume
it does not need location anonymity, so single-hop [rendezvous] hidden
services can be used which can scale to whatever that website needs. Say
I have a 1 gbps line, I don't care about location anonymity because my
website is clearnet public anyway and I want my website to handle many
Tor users, just setup a bridge Tor instance on localhost (127.0.0.1) not
published to the bridge authority, point the second Tor instance to use
bridge 127.0.0.1:port and single hop hidden services. The bottleneck
here is my own internet line (and CPU probably). Plenty of other
solutions like OnionBalance are also available.

2. Website includes in HTTP headers the onion url instead of pinning
policy. This MUST be over HTTPS so an user doesn't get redirected to a
fake .onion mirror. You have more chances to convince website operators
to include just this extra line rather than pinning policy + maintain
pinning policy + exit nodes + exit nodes policy + maintain exit nodes
policy. The same level of trust is on the CA, not more.

3. We do not necessarily need a SSL certificate for the onion common
name, that's already encrypted end to end and self authenticated. We use
the clearnet SSL certificate to make sure clients are pointed to the
right onion mirror of a clearnet website so there's no additional cost
for a second SSL certificate even, as opposite to running a reasonable
number of exit relays pinned to a website.


On 10/5/2016 11:09 PM, Philipp Winter wrote:
> The proposal is in draft state.  We have several open questions that we
> are still wrestling with in Section 2.6.  Any feedback is greatly
> appreciated.  You can track the evolution of our proposal online:
> 
> 
> ---
> 
> Filename: 273-exit-relay-pinning.txt
> Title: Exit relay pinning for web services
> Author: Philipp Winter, Tobias Pulls, Roya Ensafi, and Nick Feamster
> Created: 2016-09-22
> Status: Draft
> Target: n/a
> [...]



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Tor Relays on Whonix Gateway

[bancfc]

Should Whonix document/encourage end users to turn clients into relays 
on their machines?


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [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


0x9FC527CC.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev