Onion names reserved by the IETF
blog.torproject.org
blog.torproject.org
The implications with regard to SSL certificates are interesting, though, and I'm curious how long it'll take for SSL providers to start supporting that. :)
[0]: https://blog.digicert.com/anonymous-facebook-via-tor/
[1]: https://blog.digicert.com/the-current-state-of-onion-certifi...
Perhaps a better question is: are there any benefits other than just providing an additional layer of encryption that a potential attacker would have to defeat -- there's already end-to-end encryption when using hidden services (even if there isn't any encryption at the application layer)?
ETA: I just remembered that hidden services use 1024-bit RSA keys and there's been some arguments lately that that may not be enough bits. For some sites, using (at least) a 2048-bit key may be necessary.
If it's not a hidden service then you can't really use an .onion address anyhow.
In those instances, an SSL certificate would provide encryption all the way from the "Tor client", through the Tor network, the rendevous point, Tor endpoint, and to the actual application server. Without additional encryption in use at the application layer, the link from the Tor (hidden service) endpoint and the actual server would not be encrypted and, thus, vulnerable.
To (perhaps) explain better, this would be similar to how Cloudflare offers SSL for all sites and while the path from the end user to Cloudflare is (can be) encrypted, the link from Cloudflare back to the origin server isn't necessarily encrypted. Alternatively, think of the link from an SSL terminating device to the backend web servers. Again, in most cases, this is a non-issue but there certainly are some instances in which it would apply (and this is probably more likely the bigger a site (hidden service) is).
Another concern is that major browsers might obsolete HTTP scheme, so their UI will warn user about insecure connection. I'm not sure whether browsers will be able to distinct between onion sites and regular sites in that aspect.
Yeah, but those are companies that might as well have non-hidden websites, or be serving .onion mirrors of their regular domains.
The main "use case" for .onion domains are people for whom EV certificates would defeat the whole point.
Which is an excellent usecase for a cert to make sure that you actually are connected to the mirror. They could even have a cert that works for both domains, linking those together.
edit: Though with a quick Google, I'm led to believe that an exit node is only important when you are leaving the onion network (i.e. when entering into the Internet), and thus it sounds like SSL on a hidden service would indeed be superfluous to me.
However, SSL also proves authenticity, not just encryption. It would let you know that the hidden service you are accessing is indeed who you think it is.
So do .onion address; they are an hash of the key pair you get when you generate a new one, and the client verifies that the server it's connecting to does in fact control the associated private key.
By abdicating readable domains, the Tor hidden services system eliminates the need for external authentication mechanisms like CAs; the address is all you need.
I'm not saying Tor doesn't cover authenticity, but that SSL provides an additional authenticity check on top of that.
edit: On the topic of bruteforcing, the linked Stack Overflow post leads me to believe it's not terribly infeasible.
Additionally, stealing the .onion's key would likely expose the SSL private key as well (as you'd likely have access to the server at that point), unless the .onion's key is exposed due to misconfiguration or another form of human error.
I also think, lastly, that the point about the browser understanding its dealing with a secure connection and enforcing general browser SSL rules has merit.
edit 2: Forgot the link - https://security.stackexchange.com/questions/29772/how-do-yo...
Also, you're wrong about bruteforcing the domain implying you can decrypt if not for ssl. If you bruteforce (for millions or billions), you won't get the same key. You'll get a key that shares the first 80 bits of its hash with the other key used. So you can use it to mitm or impersonate the site, but you can't use it passively to decrypt connections to the onion.
People still using this insecure garbage?
Granted, I'm not sure the HTTPS cert infrastructure guarantees that either. I'd love to be more informed about this.
EV (Extended Validation) certificates actually require the CA to verify that you are who you claim to be. This is mostly used by banks and payment processors, as it costs more money. Most browsers will identify an EV cert by turning the URL bar green, and/or displaying the name of whoever owns the cert.
https://en.wikipedia.org/wiki/Domain-validated_certificate
https://en.wikipedia.org/wiki/Extended_Validation_CertificateIs there any reason in particular why the TLD approach was settled upon instead of a scheme-based approach?
Think of TOR as acting like a VPN or point-to-point tunnel. You can conceptually think of it as another network interface plugged into your network. The policy you choose what to route over it is your own. It doesn't affect how any other protocols function.
I can still access regular sites over TOR. I can also access regular websites over a VPN. openvpn+http:// isn't exactly useful either for the same reason.
And there are other special tld. Your multicast domain group (e.g. .local) is also special. Your dns resolver sees the TLD and resolves it specially. But once again, doing multicast DNS doesn't impact http, git, ssh, etc. So it be silly to have to write mdns+http://... as well.
And if you where to join them, then you have to describe what kind of behaviour should happen if, for example, on openvpn+http://foobar.tld you hit a hyperlink to http://baz.tld. Do I rewrite this to prepend openvpn+? Fail? etc.
You can use fb from tor, so they have an interest in that staying the case. The reason was that their fraud detection was going off on tor users, so they just made a service https://www.facebook.com/notes/protect-the-graph/making-conn...
If they can make sure that not only they can get your data, but also that noone else can get it too, that's a win in their book.
Personally believe that nothing less than a wholesale transport-layer alternative to the internet is necessary to maintain communications freedom. Not far fetched to suggest that rooftop antennae running peer-to-peer mesh networks will gather momentum in coming years. Not to replace the internet, just as backup, to keep centralised government interests and moneymen at bay.
This is ignoring the technical and legal challenges not to mention the fact that people have tried this for a very long time now and they've failed to get anywhere significant for just as long.
The network is worthless not because it works badly, they fail to create an accessible one to begin with.
I rest my case. There is demand for such a thing even if it's far from perfect. Not everybody is willing to trust the increasing encroachment by the authorities into the mainline internet. They're willing to experiment to ensure that technologies are being worked on that permit independence from potential authoritarianism (corporate or government).