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

Sun Mar 1 10:33:20 MST 2015

I’m still interested in Adrien’s answer.

From: Ryan Sleevi [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

<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: https://cabforum.org/pipermail/public/attachments/20150301/801eda6e/attachment-0001.html 