[tor-bugs] #1250 [Tor - Tor client]: strange SOCKS error code when connecting to a hidden service using the wrong port

[Tor Bug Tracker & Wiki]

#1250: strange SOCKS error code when connecting to a hidden service using the
wrong port
---------------------------+------------------------------------------------
 Reporter:  ultramage      |         Type:  enhancement     
   Status:  new            |     Priority:  minor           
Milestone:                 |    Component:  Tor - Tor client
  Version:  0.2.2.7-alpha  |   Resolution:  None            
 Keywords:                 |       Parent:                  
---------------------------+------------------------------------------------
Changes (by nickm):

  * milestone:  Tor: 0.2.2.x-final =>


Old description:

> I set up two distinct hidden services, HTTP(80) and SSH(22) on my machine
> (since I didn't know you could put multiple records under a single
> service).
>
> Today I made the mistake of connecting to the HTTP service using port 22
> (took the HTTP service's url, stripped the http part, entered into
> PuTTY).
> The returned error code was 0x02 = connection not allowed by ruleset.
> This message made me very confused, since it somehow implies that my
> SOCKS
> settings were somehow blocking the connection. But that was not the case.
>
> What happened on the TOR back-end was, my request got received, the
> remote
> TOR server found that my port was not on the list of ports associated
> with
> that particular onion hostname, and rejected the connection attempt.
> Finally, my TOR client, trying to be as clever as informative as
> possible,
> returned that specific error code.
>
> While the error code does in some sense describe what happened
> internally,
> I do not think that 0x02 is appropriate for this scenario. I did not
> study
> the SOCKS specification, however I'm assuming that "ruleset" refers to
> the
> access control rules implemented on the daemon that's providing the
> tunnel,
> and not on the remote endpoint (the target machine is oblivious to SOCKS
> and just sees an incoming TCP connection, so it can't react in any way).
>
> My proposal is to change this error code to reduce confusion and help
> users
> identify the cause of the problem (between keyboard and chair in my case
> :).
> Which one to use? I suggest 0x05 = connection refused by destination
> host.
> "Connection refused" is what you normally get if the destination machine
> has
> nothing running on the requested port (and there's no firewall to hide
> that).
>
> Visualize a single hidden service as a physical machine running somewhere
> on the internet, with stuff listening only on ports associated with that
> HS.
> In that case, connecting to a wrong port would give TCP "connection
> refused".
> And TOR hidden service isolation seems to be making virtual servers like
> this.
> So why shouldn't it be returning this error code instead?
>
> PS: Also think of SOCKS client software that might get confused by this
> error code.
> PS2: You could test the effectiveness of this change by taking a group of
> people,
> giving them a setup like mine, asking them to troubleshoot the issue and
> timing them.
> Whichever group can figure out what the problem is faster has the better
> error code.
>
> [Automatically added by flyspray2trac: Operating System: All]

New description:

 I set up two distinct hidden services, HTTP(80) and SSH(22) on my machine
 (since I didn't know you could put multiple records under a single
 service).

 Today I made the mistake of connecting to the HTTP service using port 22
 (took the HTTP service's url, stripped the http part, entered into PuTTY).
 The returned error code was 0x02 = connection not allowed by ruleset.
 This message made me very confused, since it somehow implies that my SOCKS
 settings were somehow blocking the connection. But that was not the case.

 What happened on the TOR back-end was, my request got received, the remote
 TOR server found that my port was not on the list of ports associated with
 that particular onion hostname, and rejected the connection attempt.
 Finally, my TOR client, trying to be as clever as informative as possible,
 returned that specific error code.

 While the error code does in some sense describe what happened internally,
 I do not think that 0x02 is appropriate for this scenario. I did not study
 the SOCKS specification, however I'm assuming that "ruleset" refers to the
 access control rules implemented on the daemon that's providing the
 tunnel,
 and not on the remote endpoint (the target machine is oblivious to SOCKS
 and just sees an incoming TCP connection, so it can't react in any way).

 My proposal is to change this error code to reduce confusion and help
 users
 identify the cause of the problem (between keyboard and chair in my case
 :).
 Which one to use? I suggest 0x05 = connection refused by destination host.
 "Connection refused" is what you normally get if the destination machine
 has
 nothing running on the requested port (and there's no firewall to hide
 that).

 Visualize a single hidden service as a physical machine running somewhere
 on the internet, with stuff listening only on ports associated with that
 HS.
 In that case, connecting to a wrong port would give TCP "connection
 refused".
 And TOR hidden service isolation seems to be making virtual servers like
 this.
 So why shouldn't it be returning this error code instead?

 PS: Also think of SOCKS client software that might get confused by this
 error code.
 PS2: You could test the effectiveness of this change by taking a group of
 people,
 giving them a setup like mine, asking them to troubleshoot the issue and
 timing them.
 Whichever group can figure out what the problem is faster has the better
 error code.

 [Automatically added by flyspray2trac: Operating System: All]

--

Comment:

 Hm.  For the hidden service case, 0x05 "Connection refused" is indeed a
 better error for this case than 0x02 "Connection not allowed by ruleset."
 Unfortunately, the error that we're decoding here is
 END_STREAM_REASON_EXITPOLICY, which is not in general a matter of the
 target host refusing the connection but rather a matter of the exit node
 refusing it.

 In the longer run, we should add a new END_STREAM_REASON for all
 EXITPOLICY cases that aren't really exit policy, and have that one remap
 to 0x05 in socks codes.  For 0.2.2.x, though, it's not critical; waiting
 to 0.2.3.x will be fine.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1250#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online