[cabfpub] Ballot 144 -.onion domains

Thu Feb 12 22:33:23 UTC 2015

The 40-bit attack only applies in a scenario like the following:

1.       I generate 2^40 RSA key pairs.  I now (probably) have two RSA key pairs with the same 80-bit URL.

2.       I convince someone to use one of the two as their hidden service name

I now have a second RSA key pair that can masquerade as the first.  But that’s not horribly useful to me, as I also have the first key pair as well!  I can convince them to use the key I generated (#2), without having to first generate a collision, and achieve the same result.

There is an actual issue (the pre-image attack), where I just generate key pairs until I do collide, but:

1.       That’s 2^80 / #hiddenservices key pairs.  That’s a lot.

2.       I have no control over which hidden service I accidentally collide with.

If hidden services become widely used and there are lots of them, this conceivably becomes an issues sometime in the future, which is why I expressed concern about it on the management call.  It really is time for the Tor folks to fix this before it becomes a problem.

But the existing state of the .onion world is so bad, that allowing EV certificates and HTTPS for Tor is a significant improvement.  The size and potential weakness of the onion hashes merit continuing attention, and perhaps a timeline to phase them out, but they’re not a practical attack today.

-Tim

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Thursday, February 12, 2015 5:19 PM
To: Gervase Markham; Jeremy Rowley (jeremy.rowley at digicert.com); Ben Wilson (Ben.Wilson at digicert.com)
Cc: CABFPub (public at cabforum.org)
Subject: Re: [cabfpub] Ballot 144 -.onion domains

Responding both the Ryan and Gerv.

Ryan -- you are correct that concerns (1) and (2) are related -- (1) relates to accidental clashes that give different customers the same domain.  Gerv -- you are right, the change is extremely small -- but giving the same domain to different customers is something not allowed today, so it would be quite a change to allow it.

This link has some information on the subject, but I really don’t understand the explanation of why clashes aren’t a concern.

https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames<http://scanmail.trustwave.com/?c=4062&d=06bd1NDNyitNeRu7PAd2ei4rReZfm42vwvHq-Aye6Q&s=5&u=https%3a%2f%2ftrac%2etorproject%2eorg%2fprojects%2ftor%2fwiki%2fdoc%2fHiddenServiceNames>

On (2) – this concern is of an intentional clash created by a hacker for evil purpose – a much more serious issue.  I notice that in Facebook’s existing .onion cert, they managed to get the following .onion domain:

*.m.facebookcorewwwi.onion

See screen shot below or attached.

I’m sure that didn’t happen randomly, so there must have been some very serious computing that happened to get that particular 16 digit “random” hash of a Facebook public key, facebookcorewwwi.  If Facebook can reverse engineer to get that .onion domain, couldn’t a hacker (or googlegoogle.onion, for another example) do the same and get a duplicate cert with the same domain?

[cid:image001.png at 01D046E8.B2667340]

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Thursday, February 12, 2015 1:41 PM
To: Kirk Hall (RD-US); Jeremy Rowley (jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>); Ben Wilson (Ben.Wilson at digicert.com<mailto:Ben.Wilson at digicert.com>)
Cc: CABFPub (public at cabforum.org<mailto:public at cabforum.org>)
Subject: Re: [cabfpub] Ballot 144 -.onion domains

On 12/02/15 20:43, kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com> wrote:

> For example, Evil Corp. and Angel Corp. could each submit a request

> for a .onion cert and get the same domain: _[same 16 digit hash of

> their public keys].onion_ if their public keys hash to the same value.

> One cert would say O=Evil Corp. the other would say O=Angel Corp., so

> that a .onion domain would not be uniquely identified with one

> subject.  While unlikely, it could happen.

Have you been able to put a figure on the likelihood of this occurrence?

I think I could calculate it, but I'm interested in what figure you came up with that led to your concern.

> (2)  Does this also create an opportunity for a hacker?  For example,

> one of the .onion domains in the SANs field of the Facebook cert you

> created is _*.xx.fbcdn23dssr3jqnq.onion_ – could a hacker create a

> public key that would hash to the same value in order to get a cert

> with the same .onion domain and imitate the Facebook cert?  (This is

> maybe the more serious case.)

Being able to create some text which hashes to a specific, defined value that you are targetting would be what's called a Preimage attack:

http://en.wikipedia.org/wiki/Preimage_attack<http://scanmail.trustwave.com/?c=4062&d=1Kbd1DcsoIiM28iB8TpHOt2pwq4Xal25iEgt6dbC6g&s=5&u=http%3a%2f%2fen%2ewikipedia%2eorg%2fwiki%2fPreimage%5fattack>

SHA-1 has no known preimage attacks.

Tor .onion names use 80 bits of the SHA-1 hash, which is not the full hash, so it's possible that they might be slightly easier to attack.

While there are no known attacks, my understanding is that the Tor people are looking at moving to SHA-256 as a precautionary measure.

> (3) Another concern is there is no central registry to identify the

> owner of a .onion domain (of course, there could be multiple owners of

> the domain under the scenario above).  If there is no Subject info in

> the O field, etc., with no registry there is no real way to contact

> the domain (or cert owner).

.onion certs are going to be EV, right? So they would have Subject info in the O field.

Gerv

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.

________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150212/7d18c61c/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 51544 bytes
Desc: image001.png
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150212/7d18c61c/attachment-0003.png>