[cabfpub] FW: FW: [cabfquest] Ballot 114 - Security concerns on verifying "ownership" of .onion domain names

[kirk_hall at trendmicro.com]

Reposting Adrien’s response to my question BELOW, with his permission.

The fact that multiple Tor hidden services with the same public key could exist on Tor and that “a visitor could be routed to any one of them, depending on which of them most recently published a hidden service descriptor” (if true) without the user being able to detect the deception is very troubling to me.

This could lead to the following scenario:

1.  National spy agency or uses brute force to get a key pair that resolves to a high value target .onion domain (remember, you can see the Facebook .onion domain in the SANs field of the cert that secures htps://www.facebook.com, so the targets are known).

2.  Spy agency sets up fake Facebook page (with Login section to collect user credentials) using the same .onion domain as Facebook.

3.  To give users greater assurance they are at the real Facebook .onion address, spy agency gets DV cert for its duplicate .onion domain using the permitted verification method (remember, there is no identity authentication for DV so a CA can’t block this).  OR maybe the spy agency goes the extra mile and gets an OV or EV cert by fooling the CA with extra effort.

4.  Spy agency now has an https / padlock .onion sign-in page.  Users type in facebookwwwcore1.onion and are taken to the spy agency site, at least for some period of time.  Browsers show https and the encryption padlock even though the spy agency does not uniquely “own or control” this .onion domain – multiple parties do.

And before anyone says it would be really, really too hard to come up with a key pair that resolved to facebookwwwcore1.onion remember (1) Facebook was able to get to that domain through brute force (I imagine it would be easier for a national spy agency – maybe they are working on that right now), and (2) it was really, really too hard to compromise MD5, 512 bit certs, 1024 bit certs, SHA-1, etc. – until it wasn’t that hard.

From: Adrien Johnson [mailto:adrienj at adrienj.com]
Sent: Sunday, March 01, 2015 5:56 PM
To: Kirk Hall (RD-US)
Cc: CABFPub
Subject: Re: [cabfpub] FW: [cabfquest] Ballot 114 - Security concerns on verifying "ownership" of .onion domain names

Hi Kirk,

I have reached out to the Tor Project for an answer on this, but this week turns out to be annual Tor Winter Dev Meeting and most of the developers are attending, so getting a hold of people is a bit harder. From reading the current Tor Rendezvous specification<https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt?id=7908c8d> and Directory Protocol specification<https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt?id=7908c8d>, I believe it works like this:

1. The holder of a tor hidden service secret key/.onion domain sets up encrypted links to a set of medium-term "introductory point" Tor nodes.
2. The holder of that hidden service secret key periodically creates a signed "service descriptor" which links their .onion domain to the introductory points it is currently using. This has a short lifetime, and expires on the order of hours.
3. The holder of the hidden service secret key uploads their service descriptor to a hidden service directory, and it propagates to other hidden service directories.
3. The holder of the hidden service secret key is able to issue a new hidden service descriptors whenever its information changes, subject to some rate limiting for network health.
4. A user attempting to visit the hidden service asks the network of hidden service directories for the most recent hidden service descriptor for that .onion domain. They then make initial contact with the hidden service through one of the introductory nodes listed in the service descriptor, and an encrypted tunnel is established between them.

So if there was more than one party with the same hidden service secret key, any of them could publish a service descriptor for that hidden service which listed introductory points that would funnel visitors to their server. The user would find themselves talking to a server which possesses the valid secret key for that hidden service, and would happily establish a connection.

So if multiple hidden services with the same public key are publishing contradictory hidden service descriptors, a visitor could be routed to any one of them, depending on which of them most recently published a hidden service descriptor and the propagation delay in the hidden service directory network.

Thankfully, it seems like this would be easy to detect. If a hidden service sees a service descriptor in the network that they did not publish, they would know their key is compromised and they have to move to a new .onion domain/keypair. It would be harder for a user of the hidden service to tell if multiple parties were publishing service descriptors for the same service though, depending on how much back-and-forth contradicting there seems to be.

Thanks,
Adrien Johnson


On 2015-03-01 6:38 PM, kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> wrote:
Adrien, you have raised a concern that I had – the non-uniqueness of .onion names and certificates (including names that will appear meaningful, like facebookwwwcore1.onion, which Facebook is using but which a hacker could also obtain through a brute force approach to generating key pairs).

I asked before how Tor would resolve a user request to go to the address facebookwwwcore1.onion (or another .onion domain with a random set of characters) if there were multiple sites/certificates with that name, but I don’t recall whether the question was ever answered.

Do you know the answer?

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20150302/9e78655b/attachment-0001.html