[tor-talk] trusting .onion services

[Guido Witmond]

On 01/16/16 22:22, Rejo Zenger wrote:
> Hi!
> 
> I'm wondering... 
> 
>  - How can a user reliably determine some .onion address actually
>    belongs to intended owner?

Hi Rejo,

I think that in general, .onion addresses are unauthenticated. That is,
there is no way of determining who an address belongs to.

All we know of an .onion address is that its tied to whomever holds the
private key. And given the risk of disclosure of the private key, all
bets are off. This is also true of GPG, where an adversary can create a
clone key bearing my name but their key. Erinn Clark of the Tor Project
has been a victim of such an attack.

In my pet project I'm using Hidden Services as a means for people to
connect to each other. One person opens a HS, send the onion address to
another in an encrypted message. The other connects to the service. Then
BOTH people authenticate to the other with their already exchanged keys
before their software lets the data flow commence. Knowledge of the
onion address or even having a copy of the private key won't get the
connection started.

In short, I built an authentication layer on top of hidden services.

That authentication layer uses PKI certificates and stuff to distribute
public keys to each other. And ultimately, the same issue reappears:
Whom am I talking to? And with risk of disclosure of the private key,
all bets are off.

I believe this to be a fundamental property of cryptography. The eternal
uncertainty of the identity of the other party. The more anonymous the
key exchange the higher the uncertainty. In other words: the higher the
need for secrecy and anonymity, the greater the uncertainty.

The answer you are looking for is to determine how much of a risk there
is with plain onion asdresses, or what extra authentication and
repudiation you need to build on top. And how much deanonymisation you
are willing to accept.

I believe it's ultimately a design trade off.


With regards, Guido Witmond.


>  - How is the provider of .onion service supposed to deal with a lost or
>    compromised private key, especially from the point of view from the
>    user of this service? How does the user know a .onion-address has
>    it's key revoke?
> 
> Let me explain...
> 
> 
> One of the advantages of using a .onion address to identify the service
> you are connecting to, is that you don't have to rely on a third party
> as you would do in a system with Certificate Authorities. By relying on
> the certificate signed by a trusted CA, the user can be sure the site he
> is connecting to is actually belongs to a particular entity. With a
> .onion address that is no longer needed since those address are
> self-authenticating. Sounds good.
> 
> Now, the problem I have is that the user doesn't have a reliable way to
> determine whether a given address actually belongs to the site he wants
> to visit. As far as I can tell, Facebook has two solutions to this: it
> mentions the correct address in presentations, blogs and press coverage
> wherever it can and its TLS-certificate mentions both the .onion address
> as well as it's regular address (as Subject Alt Names).
> 
> So, the first solution can't be done by everyone, not everyone has that
> much coverage. The second solution is nice, but falls back to the CA
> system. Ironic, isn't it? [1]
> 
> Or, to rephrase it: how can a user reliably determine the .onion address
> for a given entity without relying on the flawed CA system and without
> the entity having a lot of visibility?
> 
> 
> Given the fact that the hostname is a derivate of the private key used
> to encrypt the connection to that hostname, there is a bigger issue when
> the private key is stolen or lost (or any other case where the key needs
> to be replaced.)
> 
> When the key is lost (yes, shouldn't happen, but shit happens), the
> hostname changes. There is no reliable way for a user to learn what the
> new key, and therefor the hostname, is.
> 
> When the key is stolen (or compromised in any other way), the key should
> be replaced. This may be even more problematic than the case where the
> key is lost, which would render the site unreachable. When the key is
> stolen, the key may be used by an perpetrator. The problem: there is no
> way to tell the world that a particular key is compromised. [2] The
> administrator is able to make the site accessible via a new key and new
> hostname, but the attacker may keep running a modified copy of the site
> using the stolen key.
> 
> 
> 
> [1] Ironic, as Roger's blog on this topic makes clear there are all
> kinds of reasons why we do not want re-enforce this system, partly
> because it is flawed, partly because it costs money, partly because it
> undoes the anonymity that some hidden sites need, partly because...
> 
> https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs
> 
> [2] OK. Not entirely true, maybe. It may be possible to include those
> key in some listing of the directory authorities marking them as bad
> nodes. This is a manual process.
> 
> 
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20160228/3d882740/attachment.sig>