Opened 3 years ago

Last modified 2 years ago

#18037 new defect

Should the user be allowed to specify FQDNs for HS TARGETs?

Reported by: yawning Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Minor Keywords: tor-hs, dns, maybe-bad-idea, security-risk, single-onion
Cc: atagar Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Spinoff of #18029.

The current behavior is to accept any of a raw port, IP address + port, or FQDN + port. We also will accept oddball (historic) inet_aton() style IP addresses (raw hex) depending on if the system implements getaddrinfo() correctly or not.

I'm inclined to leave this as is, and if users care that the HS will hit up the system resolver at initialization time, it should be obvious that they need to specify the target by IP. That said, documentation clarification that an FQDN is acceptable would be ideal.

Since both torrc and ADD_ONION style HSes call into common code, changing the behavior to never hit up the resolver is trivial as well.

Child Tickets

Change History (16)

comment:1 Changed 3 years ago by atagar

That said, documentation clarification that an FQDN is acceptable would be ideal.

Thanks. If we update the docs then HiddenServicePort is the spot. Is there a compelling use case for FQDN hidden service targets? If it's useful then by all means keep it as-is, but if not I'd shy toward simplicity by just accepting IPv4/6 addresses. We can always add FQDN support in the future if use cases crop up.

comment:2 Changed 3 years ago by yawning

Summary: Should the user be allowed to specify FQDNs for HS VIRTPORTs?Should the user be allowed to specify FQDNs for HS TARGETs?

I'm not sure, maybe defining a HS backed by something DNS round robined? (But the correct thing to do there would be to specify multiple VIRTPORT/TARGET pairs with the same VIRTPORT).

Unless someone chimes in with a use case for FQDNs soon-ish, I'm likewise inclined to restrict this to IP addresses (and also deprecate supporting the old inet_aton() style IPv4 addrs).

comment:3 in reply to:  2 Changed 3 years ago by teor

Replying to yawning:

I'm not sure, maybe defining a HS backed by something DNS round robined? (But the correct thing to do there would be to specify multiple VIRTPORT/TARGET pairs with the same VIRTPORT).

This doesn't work anyway, because we only lookup the IP address once.

comment:4 Changed 3 years ago by asn

I also don't know of anyone using FQDNs as hidden service targets, or of any interesting use cases for this. We could maybe ask the community more broadly to see if someone wants this feature, because I'm not a good person to simulate the HS community.

teor's point that we only do a single DNS query probably disallows the more crazy use cases here like DNS round robin anyway.

Assuming we can't think of something smart here, I think it does make sense to kill this "feature".

Maybe we can try asking in the future #18018 mailing list about this? :/

comment:5 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.???

comment:7 Changed 3 years ago by arma

For a while, a nice person was running an onion service that pointed to irc.oftc.net. I think it's still up and in use. And we shouldn't want that person to hard-code just one of oftc's irc servers, right? Or even do some sort of dump of the current irc servers and hard-code that? This situation is what DNS is for.

(All of this said, our process for resolving onion service destinations is not great. There's #393 for one. And we have other klunky aspects to doing resolves while Tor is operating, like #10566 and #2106. I could see an argument for disabling the resolve for some of these, to simplify, but I don't think we can just rip out resolves in everything, or we'll hurt usability too much (like httpsproxy). And that makes ripping it out in some cases but still having to solve the other cases seem like a shame.)

comment:8 Changed 3 years ago by alecmuffett

I use all three forms of HSDir specification in torrc at different times, including for work.

1) port number - because lazy

2) IP address - because marginally less lazy and willing to type in 127.0.0.1 for localhost in reasonable certainty that it won't change

3) FQDN - because the loadbalancer VIP changes IP address from datacentre to datacentre and the FQDN is a safe way to record it

Given the recent controversy about Apache's special treatment of requests coming in from "localhost", I actually wonder if there ought to be a _fourth_ syntax, vaguely IPv6 inspired, along the lines of:

HiddenServicePort interface:eth0 80

or

HiddenServicePort interface%eth0 80

or

HiddenServicePort [eth0] 80

...which regularly queries the named network interface and asks what IP address it is currently bound to, directing requests to _that_ rather than "localhost"

Last edited 3 years ago by alecmuffett (previous) (diff)

comment:9 in reply to:  8 Changed 3 years ago by arma

Replying to alecmuffett:

Given the recent controversy about Apache's special treatment of requests coming in from "localhost", I actually wonder if there ought to be a _fourth_ syntax, vaguely IPv6 inspired, along the lines of:

HiddenServicePort interface:eth0 80

[...]

...which regularly queries the named network interface and asks what IP address it is currently bound to, directing requests to _that_ rather than "localhost"

Careful! At least in some cases, when I connect to my computer's external IP address from the same computer, the routing decides to send it "from" localhost. I suspect if we try one of these tricks we will learn that it is not reliable. I think the only reasonable answer is to either make the application not trust localhost too much, or to put the application on an actual different place (which would, in essence, be a variant on making the application not trust the Tor address too much).

comment:10 Changed 3 years ago by alecmuffett

Hi Roger - Yeah, plus I am being dumb. I just realised I meant *BindAddress/ListenAddress* not *HiddenServicePort* per the Apache config thing. I blame too much coding.

That said, there might be an argument from consistency for:

ListenAddress interface:eth0
HiddenServicePort: interface:eth0 80

...using such a mechanism to keep all traffic identifiable within one (virtual?) network interface?

comment:11 Changed 3 years ago by yawning

On sensible systems, it's possible for the kernel to notify you when interface status (eg: IP address, up/down, routing table) changes. Having generic support for receiving/using that sort of information will be useful (and can be emulated via polling on less sensible systems).

I'd be somewhat worried about race conditions, but the same considerations apply to things like DNS round-robin and the ilk, so I don't think we'd be in a worse situation.

comment:12 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:13 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:14 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:15 Changed 2 years ago by nickm

Keywords: maybe-bad-idea security-risk rsos added

comment:16 Changed 2 years ago by teor

Keywords: single-onion added; rsos removed

Now there's only one kind of single onion service, change rsos to single-onion

Note: See TracTickets for help on using tickets.