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

Sun Mar 1 23:30:44 UTC 2015

Reposting for Adrien.

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

Thank you Ryan and Kirk,

I've read through the 5 most recent months of discussion on the .onion proposal and I see that the topic of weakness in the hash algorithm has been brought up already, that up to now the Tor Project has been comfortable using half a SHA-1 to uniquely identify public keys and guard against impersonation. I also see that upgrading to full SHA-256 .onion domain names is already on the Tor Project's timeline and is expected to be completed within the next 2 years. I don't have the math background to judge how imminent the threat of impersonation attacks is on current .onion domains using the half-SHA1 hash, so if the Tor Project is comfortable with their transition timeline, I don't see a problem.

I didn't see the topic of assigning strong SSL certificates to weak .onion certificates discussed in nearly as much depth at all though, and this is the issue I am confident enough to say is an oversight in the security model. You can't build a more robust, unique identity by assigning an SSL certificate to a Tor hidden service than already exists in the hidden service certificate. Not without serious compromises, such as building a central repository of who 'really' owns which .onion domain after all. Assigning a strong SSL certificate to a weak .onion certificate is irresponsible at best.

Imagine for example a weak keypair was used to set up a Tor hidden service at example634563456.onion. A very short key length, or a Debian weak key. Any attacker who wanted to could determine the private key for this onion domain, and thus would have equal 'control' over the domain example634563456.onion as anyone else who had the private key. Every single one of these people is equally entitled to an SSL certificate for that domain. If the SSL certificate uses stronger crypto than is actually provided in the .onion key, it would mislead anyone who visits a site using that SSL certificate into thinking they are visiting a unique example634563456.onion. If the SSL certificate uses 4096 bit RSA they might be especially reassured that they are securely communicating with the real example634563456.onion and that their traffic is not being eavesdropped, completely unaware that multiple CAs may have have issued multiple strong SSL certificates to multiple attackers all for that same domain name.

You might use certificate transparency to prevent a second organization from obtaining an SSL certificate for the same .onion domain, but there's no way to know whether the first organization to apply for the example634563456.onion is the "real" one, and you would be effectively creating a repository of 'legitimate' owners of certain .onion domains, which defeats the purpose of the independantly-provable-ownership .onion domain name system.

Right now a Tor hidden service using a 2048 bit RSA key is secure enough, but the same problem comes up if that 2048 bit .onion site requests a 4096 bit RSA SSL certificate. They wouldn't actually be getting 4096 bits of security, all an attacker would have to do is compromise the 2048 bit .onion key. The weak point for impersonation attacks is always the .onion key, not the SSL key, even if the SSL key is much shorter, since the SSL certificate can only be used over the .onion tunnel which is guaranteed to securely connect a visitor to someone who holds the .onion domain's private key. (Assuming the SSL certificate is valid for only .onion domains)

This is a unique situation. I don't think there has ever been a case where CAs have a definite responsibility to limit the strength of the certificates it issues to applicants. Where an applicant's ownership of their domain name, their verification of identity, is measured not in research hours and photos of identity documents, but directly in RSA key length. That is the case here though.

I almost wonder whether it's possible for CA's to sign the .onion certificates directly and have the Tor client pass those on to the browser, instead of issuing parallel SSL certificates that do almost the same thing, but cannot provide any more security than the .onion certificates. Reduce a certificate to a signature. That's what the SSL certificates would be doing for a .onion anyway, not actually used for additional security (since if the .onion key is compromised duplicate SSL certs can be obtained,) just there to name the organization that controls the .onion private key. That is the crux of it. The certificate isn't being used as a certificate in this case, it's being used as a signature.

However if issuing separate certificates is the path that is taken, the cryptographic strength of the issued SSL certificates should be no greater than the strength of the .onion certificate it is issued to. Anything higher gives a false sense of security. Kirk, I don't think a blanket "if your .onion certificate is 2048 bits or greater, you may have an SSL certificate of any length" is ideal. If the SSL certificate has higher strength than the 2048 bit .onion certificate, it's still only a false sense of increased security. But if requiring  CAs to limit the strength of the CSRs they sign is too burdensome,  it wouldn't be an immediate security concern to allow.

Ryan, I apologize for barging in with a long wall of text at the end of this months-long discussion and if I've completely overlooked how the system already accounts for this, I will apologize profusely! But I felt I had to speak up.

Thanks for the chance to participate,
Adrien Johnson

On 2015-03-01 1:59 PM, Ryan Sleevi wrote:

Fair enough.

I do, however, hope you take the time to review the past discussion, as it explains why Adrien's analysis and conclusions are not quite correct, and why the distinction of 1024-bit vs 2048-bit or, for that matter, of SHA-1 vs SHA-2, are nowhere near the critical hole they were presented as. I should also hope that the fact that it is I who am saying that - one of the most ardent opponents of weak crypto - should hopefully assuage some of those concerns.

Best
On Mar 1, 2015 9:33 AM, "kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>" <kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>> wrote:
I’m still interested in Adrien’s answer.

From: Ryan Sleevi [mailto:sleevi at google.com<mailto:sleevi at google.com>]
Sent: Sunday, March 01, 2015 9:30 AM
To: Kirk Hall (RD-US)
Cc: CABFPub
Subject: Re: [cabfpub] FW: [cabfquest] Ballot 114 - Security concerns on verifying "ownership" of .onion domain names

Kirk, Adrian,

I encourage you to read the discussion of and leading to the ballot, which is available on the public list archives. The discussion somewhat quite exhaustively covered these issues, and more importantly, provide a rather detailed explanation why they are not as critical as Adrian suggests.

All the best,
Ryan
On Mar 1, 2015 7:57 AM, "kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>" <kirk_hall at trendmicro.com<mailto:kirk_hall at trendmicro.com>> wrote:
Very good analysis, Adrien – thanks.

Would you otherwise be satisfied with the recent Tor ballot if it required 2048 bit keypair/SHA-256 or higher?  Apparently Tor can only do 1024 bit/SHA-1 right now, but perhaps they can upgrade their security.  Do you have any other changes to suggest?

Kirk R. Hall
Operations Director, Trust Services
Trend Micro
+1.503.753.3088<tel:%2B1.503.753.3088>

From: questions-bounces at cabforum.org<mailto:questions-bounces at cabforum.org> [mailto:questions-bounces at cabforum.org<mailto:questions-bounces at cabforum.org>] On Behalf Of Adrien Johnson
Sent: Sunday, March 01, 2015 4:11 AM
To: questions at cabforum.org<mailto:questions at cabforum.org>
Subject: [cabfquest] Ballot 114 - Security concerns on verifying "ownership" of .onion domain names

Hello,
I'm writing with serious concerns about the validation rules for .onion domains, which were voted on in Ballot 144<https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/> on February 18th 2015. The vote tally was 6 in favor, 2 against, and 13 abstaining, and the motion passed.

There are some major security concerns which have been overlooked in this document which pose a risk to anyone relying on certificates issued along its procedures.

These oversights are as follows:
1) The definition of "owning" or "controlling" a .onion domain has not been sufficiently addressed
2) There are no procedures for ensuring that the security of the SSL certificates issued by CAs for .onion domains is not undermined by weaker security in the underlying Tor system

A .onion domain is unlike a normal global DNS name because it does not have a definite "owner". With normal global DNS names, the owner is clearly defined as the person or organization who holds the registration of the domain at an accredited domain registrar. CAs can determine in a number of ways of varying rigour that the person/organization they give a certificate to is the legitimate owner of the domain, or their agent. The fundamental contract of the CA is to deliver a certificate to their client which provides no greater assurance of the client's identity than the CA was able to verify. Verified domain control earns a domain validated certificate, business records earn an EV cert, etc. The idea of ownership is different for .onion domain names. By design there is no central repository of .onion domain names, they are meant to be independently verifiable. In fact, a .onion domain name is simply an encoded hash of the public key of a Tor hidden service (a Tor service reachable by a .onion domain name.) When a browser connects to a .onion domain, all it says to the Tor service is "connect me to the server presenting a certificate whose public key has this .onion domain as a hash." Anyone who has a keypair that hashes to a .onion domain can be called the "owner" of that domain, and if more than one person has such a keypair, there is more than one "owner" and there is nothing to distinguish them.

By itself this idea of self-evident, cryptographically-provable domain ownership is not a problem, in fact it is more robust than a centrally controlled, centrally corruptible global registry, but it means the highest assurance SSL certificate a CA can responsibly issue has a fixed upper limit. The contract of the CA is to only certify a site owner's identity or a site visitor's security if the CA has independently verified that information. As I will show though, the maximum verification of identity and security that can be made of a Tor hidden service is currently alarmingly low, significantly lower than the CA/B Forum's guidelines for certificate issuance.

What is a .onion domain name? The Tor Project documentation<https://trac.torproject.org/projects/tor/wiki/doc/HiddenServiceNames> states:
If you decide to run a hidden service Tor generates an RSA-1024 keypair. The .onion name is computed as follows: first the SHA1 hash of the DER-encoded ASN.1 public key is calculated. Afterwards the first half of the hash is encoded to Base32 and the suffix ".onion" is added. Therefore .onion names can only contain the digits 2-7 and the letters a-z and are exactly 16 characters long.
This means two things: the .onion domain name is derived from the hidden service's keypair using an already deprecated hash function on public key, and then half the bits of the hash are discarded. SHA-1 was deprecated by CAs in fear a SHA-1 collision could be used to create a rogue intermediate CA certificate, as was done in 2008 using an MD5 collision. It would be somewhat harder to attack SHA-1 here to impersonate an already existing .onion domain because it would require a preimage attack instead of an arbitrary collision, as in the rogue CA scenario. Needless to say though, discarding half the bits of the SHA1 hash makes an attack significantly easier.

The second thing it means is hidden services all use 1024-bit RSA keys for communication and identity. Even if we ignore the weaknesses in the generation of .onion domain names and assume that a colliding keypair cannot be found, it's still only a 1024-bit RSA keypair, which is also deprecated. Given a 1024-bit public key, calculating the corresponding private key is currently within the reach of government and large corporate attackers, which is why the CA/B Forum has disallowed their issuance. 1024-bit RSA keys do not provide enough assurance that the holder of the private key is the same person or organization that was issued the legitimate certificate. If the 1024-bit RSA key of the hidden service is cracked or stolen, it cannot be revoked and reissued as an SSL certificate can. It must be abandoned and the service must move to a new .onion domain/keypair because controlling the 1024-bit RSA key itself is what defines "ownership" of the .onion domain.

No certificate issued to a .onion domain can currently have greater than 1024-bit RSA security. Even if a 2048-bit or greater key is issued to a .onion domain, the 1024-bit key conferring ownership of the .onion domain is still the weak link. When the 1024-bit key is defeated, the attacker has just as much ownership of the .onion domain as the first user, and would be able to obtain an SSL certificate for it from any CA issuing .onion SSL certificates, and may even be able to request revocation of the first SSL certificate.

Because the Tor system currently limits the certificate hash function used to generate .onion domains to the very weak half-SHA1, and because the maximum identity and security verification a CA can responsibly certify for a .onion domain is limited to 1024-bit RSA, less than the current CA/B guidelines for certificate issuance, no CA can responsibly issue SSL certificates for .onion domains at this time.

In order for SSL certificates to be responsibly issued for .onion domains, several changes would need to be made. The hash function used to derive .onion domains from the hidden service's public key should be strengthened to a modern alternative such as SHA-256, and all the bits of the hash should be encoded in the .onion domain. Tor hidden services should transition to keypairs stronger than the current CA/B Forum guidelines for certificate issuance, and in the SSL certificate issuance process the CA should ensure that it does not provide a certificate with greater cryptographic strength than the underlying Tor hidden service certificate. This is because the upper limit of identity and security a CA can actually verify for a hidden service is limited by the strength of the underlying hidden service keys. Any greater strength in the SSL certificate than the hidden service certificate represents a stronger promise of the hidden service's identity and security than is actually possible, and so would violate the CA's contract to only certify true information.

I deeply hope that the Tor service moves to stronger cryptography that meets the minimum requirements of the CA/B forum, and I hope modified procedures allowing SSL certificates to be issued to .onion sites are soon adopted, but unfortunately more work needs to be done before that can happen.

Regards,
Adrien Johnson

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.

_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

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.

_______________________________________________

Public mailing list

Public at cabforum.org<mailto:Public at cabforum.org>

https://cabforum.org/mailman/listinfo/public

<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/20150301/6cffcfaf/attachment-0003.html>