Hacker News new | past | comments | ask | show | jobs | submit login

It does for hidden services, but HTTPS allows the browser to know the connection is secure, which lets it apply different rules, like mixed content blocking (if, say, you're browsing a .onion forum and someone links to an image hosted on a non-onion address).



Then perhaps browsers should whitelist .onion as "secure" regardless of protocol?

I'd also like to see whitelists for the reserved-for-private-use IPv4 ranges and a .local or .home TLD, since those are circumstances where HTTPS doesn't give you much either, and where getting a certificate is unreasonably difficult.


This is a terrible idea, since nothing stops the onion TLD from being spoofed. The way the browser requests resolution of .onion names is no different than any other; to visit them you need to be communicating through some sort of proxy (possibly on your own computer) that intercepts both your DNS requests and the HTTP requests to the returned address. HTTP does not provide any way to validate that your are connecting to the intended proxy instead of a malicious one.

These same thing applies to .local, .home, and private IPv4 ranges, which can all be spoofed depending on where an attacker is in your network.


> This is a terrible idea, since nothing stops the onion TLD from being spoofed. The way the browser requests resolution of .onion names is no different than any other; to visit them you need to be communicating through some sort of proxy (possibly on your own computer) that intercepts both your DNS requests and the HTTP requests to the returned address. HTTP does not provide any way to validate that your are connecting to the intended proxy instead of a malicious one.

Presumably you wouldn't be visiting a .onion address if you're not already connected through a Tor instance you know about.

> These same thing applies to .local, .home, and private IPv4 ranges, which can all be spoofed depending on where an attacker is in your network.

Which would be exactly the point, those are OK to spoof, since you'd only be visiting them through a trusted network, where nothing can be externally verified anyway.


> Presumably you wouldn't be visiting a .onion address if you're not already connected through a Tor instance you know about.

How about a link? Or even more problematically, using its now trusted status to load inside an HTTPS page!

> Which would be exactly the point, those are OK to spoof, since you'd only be visiting them through a trusted network, where nothing can be externally verified anyway.

What? How is it okay for safe-place.home to be trusted when an attacker can spoof the DNS resolution upstream (like ISPs already routinely do to point you to ads)?

The whole point of distinguishing HTTPS connections is that they provide some way of guarding against spoofing of name resolution/packets and snooping. Nothing about how .local, .home, .onion, or local-reserved IP ranges are handled by browsers prevents these from being attacked, in many cases even from outside your network. If you curl 192.168.80.1 (assuming that's not within your subnet), your router will happily shoot some packets at your ISP. The situation for the others is even worse.


> What? How is it okay for safe-place.home to be trusted when an attacker can spoof the DNS resolution upstream (like ISPs already routinely do to point you to ads)?

I guess I was unclear, my point was that I think some TLD should be dedicated for home networks, with ICANN and especially browsers recognizing that.

ISP spoofing wouldn't be an issue because if you used these TLDs then legitimate requests would never reach that far anyway. If not, well, you wouldn't be visiting such domains anyway and there would be nothing to spoof.

> If you curl 192.168.80.1 (assuming that's not within your subnet), your router will happily shoot some packets at your ISP.

But that's not an issue, because if it's not on your subnet then you wouldn't be visiting it in the first place. Any snooping ISP could just as easily make you visit some other address instead that actually did have a TLS certificate, as they could make you visit that. In the worst case, you could make the browser check your subnet mask. But since the contents on those IPs will be unique from local network to local network anyway, I really don't see the point in bothering.


> I guess I was unclear, my point was that I think some TLD should be dedicated for home networks, with ICANN and especially browsers recognizing that.

If it's for home networks, .home resolution would usually occur at the DNS server on your router. How does the browser know that your router follows the new rules and won't route that DNS request up to your ISP, and therefore should trust the request?

> But that's not an issue, because if it's not on your subnet then you wouldn't be visiting it in the first place.

Unless your attacker can get you to click a link? That's a pretty easy thing to get users (especially the unexperienced) to do. Or they can sneak it into a secure page and monitor requests/serve malicious assets.

> In the worst case, you could make the browser check your subnet mask. But since the contents on those IPs will be unique from local network to local network anyway, I really don't see the point in bothering.

This ignores the case where your local network is either (a) infiltrated (b) a coffeeshop. The second being super common, and would need to be guarded against by the browser having some sort of Windows-style public/private network distinction, which users would remember to configure correctly.

> But since the contents on those IPs will be unique from local network to local network anyway, I really don't see the point in bothering.

I'm not seeing the connection. If someone with control of your public internet connection (i.e. what HTTPS is designed to guard against) sends a response when your browser requests something from that address, what does it matter what that address does in another local network?

Everything I've described here has been an element of a real attack where something somewhere was more trusted than it was supposed to be. This would add a massive array of attack vectors, and at best would indicate to the user trust in something that has no reason to be trusted.

If you're doing something on your local network, it makes a lot more sense to just create a self-signed CA and put the root on your devices. In the onion case, you should use HTTPS between you and your proxy (e.g. with a *.onion wildcard cert) to make sure you actually connect to your proxy.


EDIT: Sorry, you're right, the browser would need a secure way to check this, which it currently doesn't.

This is not true; a .onion address is also a fingerprint of the public key of the node, so even if the connection is hijacked, the other node won't be able to authenticate itself.


Which the browser can't validate if it just talks HTTP to a proxy that connects to Tor (or a malicious proxy instead), as the parent post described. Doesn't apply to all Tor setups, but it's a risk.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: