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

[kirk_hall at trendmicro.com]

Reposting

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

Ryan,
Thank you for this new perspective.

I hadn't considered how weaknesses in verifying domain control under the global DNS corresponds to hidden service key weaknesses in .onion domains. I also hadn't considered how the insecurities we accept when verifying the owner of a global DNS name translate to insecurities we might also choose to accept in .onion names. I can see how the CT and revocation mechanisms provide a layer of safety for global DNS certificates, but I do not see that they provide any safety with .onion domains.

For instance, exactly what should happen when CT detects multiple SSL certificates for the same domain have been issued to multiple parties? 
Or if duplicate SSL certificates are detected by other means? In the global DNS it is easy, there is a defined owner of the domain, and with enough investigative effort, that owner can be identified to any level of confidence desired, the SSL certificates issued to anyone else can be revoked or distrusted, and the rightful owner is able to maintain control of his domain name and reestablish secure communication with his users. The fact this safety net exists is what allows us to accept some insecurity when verifying control of a global DNS name. If SSL certs are issued incorrectly, it can be fixed and we can find out what went wrong.

This margin of safety does not exist for .onion names. If duplicate SSL certificates are found to have been issued to multiple parties for the same .onion domain, what happens? An SSL certificate for a .onion domain is only useful to someone able to receive connections at that domain, meaning they have the private key for and are as much an "owner" of the domain as anyone. So CAs are prevented from unilaterally revoking any certificates, only the domain owner who was issued a certificate can request its revocation. You rightly point out that even though there  is no technical distinction between co-owners of the .onion domain, in considering the threat model we can label one of them the legitimate owner and all the others as attackers. What behavious would we expect to see from the legitimate owner and the attackers? The attackers would want to be able to intercept traffic for as long as possible with as much apparent legitimacy as possible and so would not revoke their certificates. The legitimate owner would want to redirect all his visitors to a new .onion domain that he has sole control over, and would not want to give up the apparent legitimacy of an SSL certificate either, so none of the SSL certificates would be revoked. The attackers can appear like the legitimate owner in every way, they too can redirect visitors to new .onion domains that the attackers have sole control over, and which MitM proxy to the legitimate owner's new .onion address. 
The user visiting the original .onion domain may be connected to the legitimate owner's service or any of the attackers'. He is told the .onion domain he is using has been compromised and he is given a new .onion domain he has never seen before Whether he is on the attacker's page or the legitimate owner's, he sees an SSL certificate stating he is connected to the real .onion domain he intended to visit, and none of the SSL certificates have been, or are going to be revoked. The legitimate owner will never regain sole control of the original .onion domain name. He must warn his users out-of-band of the Tor network what the new legitimate .onion domain for his service is. If the legitimate owner cannot cannot communicate with his users out-of-band, a large portion of his users may be redirected not to his new legitimate .onion domain, but to MitM proxies controlled by the attackers which by the very design of the Tor network, neither the legitimate owner nor the users can easily detect.

Now to be fair, this scenario is possible only if the .onion key is compromised, which is the hidden service operator's fault, not the CA's. 
SSL certificates cannot do anything to prevent the .onion key from being compromised and the security of a .onion domain from being permanently lost, all we would ask is that if the .onion key is compromised, the SSL certificates don't make things worse. And they fail at this spectacularly. Both the legitimate owner and the attackers all present valid SSL certificates for the domain, and none of those certificates can be revoked. Certificate transparency has alerted everyone to the fact the .onion key has been compromised, but that doesn't let the legitimate owner stop the attackers or help a visitor decide whether he's looking at the legitimate owner's page or an attacker's. If the underlying .onion key is compromised, all the safety mechanisms of SSL certificate issuance fail, and they provide nothing but a false sense of security.

An SSL certificate is more than an assertion that a party with practical control over a name has been issued a certificate. It is also an promise to a site's visitors that safety mechanisms are in place, that the issuance and use of the certificate is monitored, that if SSL certificates are found to have been issued to multiple parties for the same domain, falsely issued certs can be revoked. An SSL certificate issued to a .onion domain breaks these additional promises.

One suggestion I can think of that would prevent SSL from malfunctioning in this scenario is to allow anyone who can demonstrate they control a .onion domain to perform a 'nuclear' revocation of all SSL certificates issued to that domain, present and future, for all CAs. This would only be done in cases where the .onion key was compromised and the security of the .onion domain was lost. It would not allow the legitimate owner to regain sole control of the .onion domain, it would only be used as a 'scorched earth' policy, preventing anyone from getting the benefit of a misleading SSL certificate for that domain, and removing the legitimate owner's incentive not to revoke for fear of appearing less legitimate than the attackers who chose to keep their SSL certificates. Best of all, it doesn't require CAs to judge who is legitimate and who is an attacker. If there are multiple parties who able to hit the nuclear switch, all the more reason it should be pressed.

I hope I have shown why losing control of a .onion key is a more serious compromise than a falsely issued certificate for a global DNS name, and why the safety mechanisms which have been adequate in other situations are not yet up to the task of dealing with a compromised .onion private key.

Regards,
Adrien Johnson

On 2015-03-01 5:11 PM, Ryan Sleevi wrote:
>
> Adrien,
>
> While I unfortunately cannot post your response to the list, I think 
> you will find that if, in your threat model, you replace "1024-bit 
> .onion key" with insecure DNS, you will find the same conclusions - or 
> worse.
>
> That is, from a client's perspective, any on-path adversary may me 
> modifying DNS traffic. Note that DNSSEC doesn't change this - there is 
> still ample opportunity for on-path tampering (albeit more so through 
> legal and extralegal means than technical). Likewise, from the point 
> of view of an issuing CA, there is ample opportunity for a CA to have 
> issued an attacker a certificate, due to the CA's reliance on DNS.
>
> This does not mean that the effective security of an SSL certificate 
> is zero. If you apply your logic - that is, that the weakest link is 
> the .onion name - to DNS, then SSL provides zero effective security 
> for DNS-based issuances. While there are some more radical parties 
> that would happily argue that, I do hope that is not the position you 
> would take.
>
> Instead, we should look at it for what it is - an assertion that a 
> party with practical control over a name has been issued a certificate.
>
> While the certificates issued for these .onion names are not required 
> by the Forum to be logged in Certificate Transparency logs, they are 
> in practice required so if someone wants to use these with Chrome.
> This is not to suggest that CT serves as a dispute resolution 
> mechanism - both parties are valid for the domain - it allows the 
> legitimate party (for we are talking threat models) to be aware of the 
> conflict and take appropriate steps.
>
> Again, I think it is important to evaluate how issuance presently 
> works for DNS, despite the attractiveness of focusing on more esoteric 
> aspects such as factoring. In today's model, an attacker only need 
> gain temporary control over the DNS to obtain such a certificate, and 
> it would be virtually unknown (until CT is used for all certificate 
> types). We see registries hacked on a daily basis, so this is not in 
> the realm of esoteria. However, with .onion, an attacker who either 
> factored such a key or generated a collision (the former which, I 
> agree, we should consider within the realm of well-funded nation 
> states and corporations), then the best the attacker has done is 
> compromise the DNS. Further, due to the (effective) logging 
> requirement applying to all of .onion, this provides _greater_ signal 
> than any issuance possible by any CA today. That is, while an attacker 
> of DNS can downgrade EV to DV, an attacker of .onion cannot.
>
> I think you will see that these concerns of yours were very much the 
> forefront of the discussion, and that your conclusions on the 
> effective security levels or misrepresentation of strength, while well 
> intentioned, are unfortunately (or fortunately...) off the mark.
>
> Hopefully this will assuage your concerns. As I said, if there is 
> still conflict or concern, it would be best to think first in terms of 
> "how would this attack apply to DNS," and explore the similarities and 
> differences.
>
> Cheers
>


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