4 ms·

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 addresse

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.

scintill76 12y ago
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/035412.html https://lists.torproject.org/pipermail/tor-talk/2014-October...
schoen 12y ago
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/035362.html 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.
mike-cardwell 12y ago
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 http://youronionaddress/Y - If you can do that, you control the .onion and can have an SSL cert for it.
- MertsA 12y ago
  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.

scintill76 12y ago

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/035412.html https://lists.torproject.org/pipermail/tor-talk/2014-October...

schoen 12y ago

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/035362.html 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.

mike-cardwell 12y ago

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 http://youronionaddress/Y - If you can do that, you control the .onion and can have an SSL cert for it.

MertsA 12y ago
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.