Does OpenID, SAML pose a threat to Tor's anonymity? How can I protect from a compromised .exit node?

Question

This is a thought experiment on the interaction between Tor, OpenID and one (or more) compromised nodes in the secure path. I'm focused on how to use technology in a way that adds value to a secure cloud solution. I have no interest in using this technology for nefarious purposes.

Use case

Suppose I have a multi-tenant server where each customer determines the visibility of their domain. For example: x.myhost.com can choose to be "public" and xyz.myhost.com is private and only accessed by a hidden .onion address.

As I understand it there are two ways for a server to interact with Tor:

1. Do nothing, use SSL, and trust that the last exit node has not been compromised
2. "Hook" into the Tor network using a hidden service and a .onion address

Threats

From what I understand, the session is vulnerable to a compromised .EXIT node. Some hacks I've read about include:

• disclosure of data protected by SSL
• Loss of anonymity if the user uses many services over the same Tor network, enabling correlation

Question

Now that the world is moving to claims-based authentication, SAML, and OpenID, how should Tor be used with these technologies, considering that .exit nodes could be compromised? Given that correlation hacks exist, should OpenID/SAML be used at all? Some questions that affect architecture include

• Is public OpenID less secure than those with forms-based authentication?
• Does using OpenID/SAML enable session correlation? Are some OpenID providers better than others?
• Should the OpenID/SAML server has a .onion address? Will that help prevent correlation attacks?
• Are there benefits of using a public OpenID server (Google/Yahoo) to a private one (Microsoft ADFSv2)

Answer 1

I don't fully understand your question, but there are 2 ways of interacting with TOR users

1) They reach the Internet through TOR. This should utilize SSL/TLS. As a TOR user who connets to the global Internet, I often utilize an SSL/TLS Proxy, such as CGIProxy or PHProxy on Apache with valid PKI (e.g. SSL certificates). I also often specify an exit node with .exit -- often selected by sorting country-of-origin and performance lists in Vidalia. The reason for this is because exit nodes do not encrypt your outgoing traffic by default, so the only safe web destinations are SSL/TLS destinations (unless you use an SSL/TLS Proxy).

2) They are trying to reach a TOR hidden node on the .onion hierarchy. If this is the case, you don't really need SSL/TLS because the traffic is encrypted. However, in order to maintain sessions, you will want to lean on the typical HTTP mechanism: cookies (or similar such as hashses of Panopticlick-like data if it is disparate enough). This would be completely independent of the TOR network, so I don't see any reason why you can't use any of the technologies you mentioned to produce valid cookie-based sessions.

Answer 2

I have seen websites that run an onion router instance (.onion address) as well as a public instance.

That being said, if you want the website to be public, then there is no real reason to make any efforts to support tor on your end. If the people connecting to your services are using tor without understanding the risks or are inadvertently exposing their legitimate traffic because of their tor use, then that's totally on that client.

I guess i am just misunderstanding why tor has anything to do with this situation. If i learned of users connecting to my service via Tor, then my only questions would be "what is going on with my site that would warrant the use of Tor?" Do you run an Adult site, a hate site, a political site, a blackhat site, or something to that effect? In that case, I would say have a conjoined tor anonymous web service, or even solely run a tor web service. If none of this is true and there is no reason for your users to obscure their identity, then they are taken unneeded risk.

A proper installation of Tor will be sand-boxed enough not to allow for any type of persistent sessions (correct me if I'm wrong, but i don't believe that openID would even work with the default tor/vadalia/polipo installation bundle). So, if you're users are properly using Tor, they should be taking as many steps as possible to keep their identity obfuscated (i.e. not logging onto your site via tor).

I know that I didn't address your actual questions regarding OpenID, but i believe that this is the appropriate answer seeing the basis for your questioning. It should be less of a question of how do I make sure OpenID is secure via tor, and more a question of why tor is being used to access/authenticate to your site and if those users know the risks.

Answer 3

In practice, almost everybody now uses Tor's "browser bundles" which includes a modified FireFox called Aurora with various protections like HTTPS Everywhere enabled by default. As I understand it, all you usual internet traffic should pass through your main internet connection unless you explicitly do ssh -l marlowe -2 1.2.3.4 -o ProxyCommand="/usr/local/bin/connect -4 -S localhost:9050 %h %p" or whatever. In consequence, you biggest risk looks like sharing an account between Tor's Aurora and another browser.

Answer 4

It sounds like you are running a public web site, but some of your users are using TOR to reach your web site. If that's what you mean:

Then you don't need to do anything special. Use any standard mechanism for session management (e.g., session cookies, whatever). It should work fine for TOR users. Nothing special needed.

Alternatively, if that's not what you meant to ask, please edit the question to explain more clearly what your constraints are.