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

[Ryan Sleevi]

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" <kirk_hall at trendmicro.com>
wrote:

>  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" <
> 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
>
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20150301/e5dde54d/attachment.html