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...
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.
--
Rejo Zenger
E rejo@xxxxxxxxx | P +31(0)639642738 | W https://rejo.zenger.nl
T @rejozenger | J rejo@xxxxxxxxx
OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4
XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF
Signal 05 EB 38 5C 01 0B 55 6A 19 69 E1 EF C2 99 89 EC 9C
E4 88 3C 6F E3 7D 58 61 9B 32 E8 DB 9F ED 1B 2A
Attachment:
signature.asc
Description: PGP signature
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk