4 ms·

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

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.

icebraining 10y ago
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.
- detaro 10y ago
  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.
Nullabillity 10y ago
> 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.
- johncolanduoni 10y ago
  > 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.
  - Nullabillity 10y ago
    > 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.
    - johncolanduoni 10y ago

icebraining 10y ago

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.

detaro 10y ago
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.

Nullabillity 10y ago

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

johncolanduoni 10y ago
> 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.
- Nullabillity 10y ago
  > 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.
  - johncolanduoni 10y ago