[cabfpub] Ballot 144 -.onion domains

[kirk_hall at trendmicro.com]

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



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 01D046CE.C86B58F0]



-----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); Ben Wilson (Ben.Wilson at digicert.com)
Cc: CABFPub (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



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

<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: <http://lists.cabforum.org/pipermail/public/attachments/20150212/96755d93/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/96755d93/attachment-0003.png>