Hacker News Reader

Comment by duskwuff | Hacker News Reader

It's the sensible, pragmatic thing for them to do. Allowing .onion to be allocated as a "real" TLD would just be disruptive and confusing at this point.

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. :)

View on HN

Digicert has already issued at least one certificate to a .onion address[0]. See [1] for additional info

[0]: https://blog.digicert.com/anonymous-facebook-via-tor/

[1]: https://blog.digicert.com/the-current-state-of-onion-certifi...

blockchain.info also has an SSL cert on their .onion site

Fun fact: Cyph's certificate from DigiCert is the first EV cert ever deployed to a .onion address (https://cyphdbyhiddenbhs.onion).

What are the benefits to using SSL/TLS certificates on a hidden service?

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.

EV certificates add green buttons with company names. Registrar checked that this company indeed exists and legal. So you can be sure, that you didn't mistype URL. And may be some users are comfortable with HTTPS scheme.

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.

> EV certificates add green buttons with company names. Registrar checked that this company indeed exists and legal. So you can be sure, that you didn't mistype URL. And may be some users are comfortable with HTTPS scheme.

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.

Washington Post, Gawker, and others who use the SecureDrop software for soliciting leaks are a great use case for .onion+EV. You get the assurance that your connection is encrypted and, as much as possible, anonymous from the person you're connecting to; you get the assertion of the person you're leaking to that they are who they claim to be; and you get a 3rd-party validating with high confidence that someone authorized to represent that company set up the domain you're leaking to.

> be serving .onion mirrors of their regular domains.

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.

That's not true. One of the points of TOR services is that they can't be (easily) blocked by governments and/or ISPs. There's a huge HUGE difference between a TLD and .onion.

Well, it would encrypt the traffic from your TOR endpoint to the application. Usually this is on the same box so it's not a big deal, but not always.

All traffic to TOR hidden services is encrypted end to end, SSL can add additional level of authentication tho.

If it's not a hidden service then you can't really use an .onion address anyhow.

You're correct, but I think his point was that the Tor endpoint (i.e. the host connected to the Tor network) and, e.g., the host actually serving up the content aren't necessarily one and the same (although they usually are).

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).

Authentication. You're talking to foo.onion, not a man in the middle - either at the start, or the end of the Tor pipeline.

I thought each onion layers is already encrypted and authenticated?

Yes, within a Tor, if you access certain hidden service, you are pulling data from the node that has the corresponding private key. I guess the threat model is when there's some MITM between a user agent and Tor, perhaps via some type of malware. (Because your browser can't tell if you are really accessing hidden service or not.) At this least verifying against certificate coming from a hidden service server would verify that it is coming from the host intended.

Usually the Tor client runs on the same machine as the browser, so if you have a MITM, you probably already lost (e.g. the malware probably could have simply injected its own CA root cert into your browser).

It's somewhat of rhetorical, indeed. But it does give at least additional checks in the place. (Also potentially helps to prevent a certain class of vulnerability with hidden service, whether they are caused by a bug or attacks.)

Facebook does Tor - load balancer - SSL terminator - servers, and the load balancers might not be trusted. So here using SSL protects against malicious load balancers.

Reply on news.ycombinator.com