On 24 May 2013 09:25, Andreas Krey <[email protected]> wrote: > On Fri, 24 May 2013 07:22:28 +0000, Tom Ritter wrote: > ... >> ... Actually that's not true. I could have bought a certificate for a >> .onion address, any .onion address, from any CA until the end of 2015. > > How that?
.onion is not a real TLD. CAs can (or could, they're phasing them out now in anticipation of the new gTLDs) issue publicly trusted certs for domains that are not publicly routable. Usually this is for stuff like mailserver.corp or redmine.internal or sharepoint.dell for use inside corporate networks. But there's no reason they couldn't do .onion >> They're starting to phase them out now so "any CA" is probably not >> correct some "some CAs" would be true. That's a mildly creepy >> thought, although the HS architecture should protect against that. > > Hmm. Actually, we already have a kind of certificate - the HS itself. > What point does certificate verification serve in https to onion > site at all? It wouldn't serve a security purpose, as far as I can devise. It would just be for not annoying the user with a "Invalid Cert" warning, when in fact HS are secure regardless of SSL cert presented. > Would it be possible to put the server's HS cert keys into the the > SSL negotiation as well and have the browser either verify that > the public key matches the HS name, or not verify at all? > (And take a null cyphersuite as well?) Sure, but at that point you're talking about altering the SSL stacks of the client and possibly server. Mike and I were brainstorming ideas that would require fewer engineering changes. -tom _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
