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

[kirk_hall at trendmicro.com]

Reposting Adrien's response with his permission

-----Original Message-----
From: Adrien Johnson [mailto:adrienj at adrienj.com] 
Sent: Monday, March 02, 2015 2:30 AM
To: Ryan Sleevi
Cc: Kirk Hall (RD-US); CABFPub
Subject: Re: [cabfpub] FW: [cabfquest] Ballot 114 - Security concerns on verifying "ownership" of .onion domain names

Ryan,

I agree wholeheartedly that the overall design of a .onion domain possesses much stronger technical security controls than any SSL certificate for a DNS name, and it is a significant improvement over DNS, if the .onion domain's keys remain safe. But if the .onion private key is compromised or a colliding public key is found, then the .onion domain becomes permanently worthless as a secure channel.

This could be from a rich attacker colliding your public key's SHA1, or factoring your 1024 bit RSA key, or much more often from simple server misconfiguration. It's not imaginary, .onion domains are compromised all the time. It may be easy to attack DNS to get a fraudulent SSL cert, but it's easy to hack an obsolete web server too, so this is not enough justification for dismissing the possibility of a .onion private key compromise.

- I did not mean to imply that Certificate Transparency was widespread today. I was illustrating that even in a scenario where CT is ubiquitous, it does not provide the same protection to .onion domains as DNS names.
- Obtaining past SSL certificates and hijacking DNS makes DNS SSL certs weaker, but not as weak as a .onion private key sitting on an unpatched server.
- If an attacker has the private key of a .onion domain, it requires no effort to hijack traffic. They simply publish a signed hidden service descriptor directing people trying to connect to that .onion domain to the attacker's server.
-SSL and HSTS only provide protection in a .onion compromise and traffic hijack scenario if the SSL certificate gives greater assurance that you are connected to the 'real' example.onion than the .onion certificate does, but this is impossible. Since they are EV certificates, they can provide you with assurance you are connected to a version of the .onion site which is operated by a particular company, but when you visit the url, you have no way of knowing which company's valid EV cert for that domain you will receive.  Certificate pinning could be use to block connections if you get the 'wrong' cert, but that would be just another extremely roundabout way of declaring one owner of a .onion domain arbitrarily as the 'real' owner.
-I did not make the assertion that an SSL cert is an indicator a site is secure and well behaved. I said that an SSL certificate is more than just an assertion that a party with practical control over a name has been issued a certificate. I was arguing that the non-revoked status of a .onion SSL cert is a weaker indication of security than for a DNS certificate since an attacker controlling the .onion and obtaining an SSL cert that way would never have cause to revoke his own certificate.  
You have explained that this was never meant to be a strong indicator in the first place, and it would still prove useful for a .onion domain in the classic case of an SSL certificate compromise without a .onion key compromise, so I withdraw my objection about this.
-I didn't address the protection offered by EV in my previous attack description because it seemed so slight. How often will a user who visits a familiar bookmark or clicks a familiar link and sees the padlock & green bar actually read the company name within it? Will they notice it change? I doubt it. Not even the most security-minded users would expect multiple valid EV certificates to be presented seemingly at random when they visit an unchanging url. And if they did notice it changing, would they be able to remember what it said before it started changing? Does the browser's visit history even distinguish between number of visits to example.onion operated by GoodGuy Inc. and the number of visits to example.onion operated by BadGuy Inc.?

As for the nuclear revocation already being supported, I deeply apologize for overlooking it, since it alleviates nearly all my concerns about SSL certificates and .onion domains. However I cannot find it in the ballot, what language supports it exactly?

I appreciate having my comments posted to the forum despite my not being a member, but treading on anyone's toes is not my intent either, so I understand.

Thanks for the advice, and I'll try to be more concise from now own Adrien

On 2015-03-02 3:02 AM, Ryan Sleevi wrote:
>
> Adrien,
>
> I have started a separate thread to clarify your status, but 
> unfortunately must omit your reply.
>
> Your scenarios - both in this message in your previous - fail to 
> demonstrate .onion as less secure. Indeed, if you evaluate them with a 
> critical eye to the threat model, you will find rather quite the 
> opposite - that it demonstrates .onion names possess stronger, 
> technical security controls than those based on global DNS.
>
> Now, I have already addressed in my previous message the threats that 
> exist when using the global DNS. We can and must presume that an 
> attacker who can factor a key or perform a collision attack on SHA-1 
> is, at best, demonstrating control over the DNS.
>
> Rather than reply with a similarly longly worded message, I will try 
> to distill to bullet points the flaws, in the hope they stand on their 
> own.
>
> - You presume Certificate Transparency for the DNS names. This is not 
> true for the Forum at large, and not true for Chrome at DV. Thus, 
> anyone who gains control over DNS, even temporarily, can create 
> certificates that are undetectable to the legitimate holder, and thus 
> irrevocable (largely).
> - Likewise, any certificate ever issued in the past, prior to you 
> assuming control of that DNS domain, remains a threat.
> - You nation state attacker performing factoring is equally capable of 
> directing traffic (such as DNS lookups) to then, but factoring 
> unquestionably requires more work (MITM+factoring > MITM)
> - Again, we see temporary and sustained DNS takeovers on a daily basis.
> - Your scenario of traffic manipulation is precisely why certificates 
> (and features such as HSTS) are useful for .onion names. You are
> *increasing* the effective security from simply being name bases (... 
> much like HTTP) to being end to end.
> - Your threat model fails to consider or evaluate the protections 
> built in to the ballot itself (such as requiring EV, rather than DV), 
> yet you describe the attacks presuming a DV level.
> - You make an assertion that an SSL cert is an indicator that the site 
> is secure and well-behaved. I'm sorry, that is patently false and 
> misleading, and while some CAs may continue to market it as such, it 
> is not and was not true. While the Forum cannot restrict its members 
> from making misleading statements, I can only fervently state that no, 
> it is NOT a promise of anything more than a name binding.
> - Your so called nuclear option is _already_ supported by the present 
> ballot, with no changes required.
>
> Overall, I hope you will find that, in every meaningful way that 
> matters, a factoring of a .onion name is no different than the far 
> more common DNS hijacking. Further, the structure of the ballot and 
> the certificate provide many more meaningful controls than exist for 
> DNS-based certificates, on a real and technical level, rather than 
> just policy.
>
> While I certainly do not intend to sound dismissive, I do think you 
> will find that as you apply your threat model, you will find we 
> discussed these rather comprehensively already. While our minutes of 
> our teleconferences often fail to capture much of the technical meat 
> of discussion, between the list discussions and what should hopefully 
> be an obvious security model, these issues were indeed considered and 
> addressed.
>


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