One advantage of the status quo is that DigiCert won't be issuing certs for "facebookcorehttp.onion" or "facebookrotflbbq.onion" or whatever else you might be able to brute-force. If they were issuing those certs, it'd be hard to tell if you were on the actual hidden service operated by the entity known to humans as Facebook -- given how ad-hoc the name "facebookcorewwwi.onion" is, the cert isn't making a useful statement the same way a cert for "facebook.com" is.

And that's not even considering the fact that Tor's transport to hidden services implies authenticity... DigiCert is unable to usefully contribute to the claim "these people own facebookcorewwwi.onion" or "these people own facebookrotflbbq.onion" because Tor is already making that claim strongly, so the only claim they can help with is "these people are/aren't who you think of as Facebook".

If DigiCert were able to issue an EV cert for "Facebook, Inc. [US]", that would be another matter entirely, but the industry rules on EV certificates are tight, and in particular I think there are rules about being in the public DNS. I'd imagine one thing they're working on is being able to issue EV certs for .onion domains.

A .onion cert is pretty useless though, besides being revocable I guess. Access to .onion domains is already secured.

One use:

On https://example.com/ I add:

  <script src="//example.onion/x.js"></script>

x.js contains:

  alert(
      "I notice you can access Tor hidden services. We have"
    + "a hidden service address at example.onion by the way"
  );

The only way this would work when you are using SSL on example.com is if you are also using SSL on example.onion.

That sounds like a flaw that the Tor Browser Bundle should fix by treating all URLs from .onion domains like they treat https: URLs.

TBB is just a repackaged Firefox, I don't think they make any changes or patches to the actual browser code like that.

Certs don't secure the connection; they establish the identity of the server you're connecting to (i.e. trust).

This should help that. You can be more confident that it's not being man in the middled.

The point is that you should already be confident, because the .onion address itself establishes the identity of the server.

.onion establishes the identity of the key. If they ever lost control of the key and had to replace it, they would need a new .onion domain.

I had a friend that used the wikipedia page on the silk road to get the silk road address, and he fell for a fake version of the website (someone had changed the wikipedia entry). A cert could protect against that.

A certificate could pin an .onion key to a real entity, if the entity in question wants to do that.

But for a Silk Road-like marketplace? Uh, sure: why don't they incorporate, print business cards, lease an office, do an IPO and invite the FBI to the opening party while they're at it? ;-)

First there needs to be an accepted good way of testing whether it's the right .onion address.

Of course, it will be quite superfluous, because .onion addresses are themselves truncated hashes of keys. Tor's already looking into improving all that.

Well, I'm sure you used "will be" advisedly -- until the improvements you mention come about, TLS to hidden services is valuable even though Tor already provides transport encryption. The keys in question aren't really appropriate for modern cryptographic practice, as the Tor developers have been acknowledging. I wrote a little more about this at

https://lists.torproject.org/pipermail/tor-talk/2014-October...

I didn't mention the part about how the public keys are 1024-bit RSA, but it adds to the sense that native hidden service transport encryption is using dated crypto.

Testing if somebody controls a particular .onion address should be quite easy. The SSL provider could just say for example: Create a temporary file containing X at http://youronionaddress/Y - If you can do that, you control the .onion and can have an SSL cert for it.

Or have them sign something with the private key for the onion address. There would also be a much lesser need for certificate revocation as anyone who has access to that private key has total control over the onion address permanently. Also, if they grab the SSL cert off the server they can probably also grab the Tor private key as well. Revocation could only be used to warn others to not trust that onion address but what we need is a way to flag your own onion address as compromised by signing some self destruct note with the private key.

Well, isn't it the point, that the user can confirm, with help from the browser, that DigiCert has verified that this .onion address is actually Facebook? Maybe you meant something different by "right."

Also, Facebook made a "vanity address" that is pretty memorable, facebookcorewwwi.onion [0]. So, someone else could brute-force a similar address and lure people to it, but presumably they wouldn't be able to get a trusted CA to issue a cert authenticating that they're "the same entity as the one operating facebook.com" (from the article -- I presume facebook.com is also named in the cert, which shouldn't happen unless the CA vetted it.)

[0] https://lists.torproject.org/pipermail/tor-talk/2014-October...