[tor-talk] trusting .onion services

[Mirimir]

On 01/16/2016 02:22 PM, Rejo Zenger wrote:

> Hi!
> 
> I'm wondering... 
> 
>  - How can a user reliably determine some .onion address actually
>    belongs to intended owner?
> 
>  - 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...

<SNIP>

> 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?

I GnuPG sign pages on http://dbshmc5frbchaum2.onion and have the public
key online in four other independent places. I recommend that users
first verify that all five places provide the same public key. Then they
can verify that the signatures are valid.

> 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.

Well, the key should be backed up, so we can ignore this issue.

> 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.

If the key has been stolen, an adversary could use it to spoof the site.
If both the real site and spoofed site are up, users will generally
reach the one where the tor process has restarted most recently. And if
the site owner generates a new hostname, the real site looks like a spoof.

But GnuPG signing resolves the issue. The private GnuPG key never leaves
the operator's machine. For best security, the private GnuPG key never
leaves an air-gapped machine.

> [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.