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

Ryan Sleevi sleevi at google.com
Sun Mar 1 17:29:55 UTC 2015


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" <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
>
>
>
> *From:* 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
> *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
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150301/17331d00/attachment-0003.html>


More information about the Public mailing list