TorHS Does Not Exists vs Not Reachble

[fpietrosanti]

It has been identified that current version of Tor does not allow to know if a Tor HS exists or not and this reflect a bug of #31 .

So Tor2web is not able to distinguish between the two following error conditions:

• Host not found (TorHS does not exists)
• Host unreachable (Tor HS exists but is not reachable)

A ticket for fixing on Tor has been documented https://trac.torproject.org/projects/tor/ticket/6031

The fix for https://trac.torproject.org/projects/tor/ticket/6031 has been implemented by hellais.

The patch can be installed as follow:

wget -O patch_hs.patch 'https://gitweb.torproject.org/user/art/tor.git/patch/f6d3dc3d9e0e70f2c553ce254b49630bd98910e9?hp=ca525db02dbb026bda4305881476dada754c3ca3'

patch -p1 < patch_hs.patch

Procedure to apply the patch has been documented on https://github.com/globaleaks/Tor2web-3.0/wiki/Getting-started-with-tor2web .

Twisted Socks client must be improved to support the new return code (to be used with error handling) and Tor2web use it.

Part of this ticket will be cross-documenting the implementation also on Tor Project's Trac ticket 6031 to explain.

[evilaliv3]

I'm testing the patch and working on this issue and these are my actual considerations:

• the Tor patch proposed is for socks5 protocol and actually we implement only socks4.
• i dont think useful to have socks5 implementation in tor2web actually as IMHO we will not make use of any of the socks5 additional features; in fact, regarding socks authentication and security, Tor will be present on the same machine of Tor2web so it's safe to use socks4a permitting only local connections and the use of socks5 would result in a pure overhead of parsing (Tor2web side / Tor side).

So, in our strict tor2web interest, we have to take decision on the protocol:

• Socks4a
• Socks5,
• Both with selection by config file.

If we decide to adopt socks4a we NEED a new Tor patch. irrespective of this decision, I propose to implement it. The patch would be simple to write, because the socks4 specification document (http://ftp.icm.edu.pl/packages/socks/socks4/SOCKS4.protocol), while not talking directly about unspecified values, make effectively use of a byte for the status response and use only 4 values to represent it.

[fpietrosanti]

I don't have an answer, but imho the logic should depend on whenever Tor Project is focusing most on socks4a code or socks5 code.

I wrote on irc #tor-dev: naif Hi all, is tor implementing/focusing more on Socks4a or on Socks5? the fix on https://trac.torproject.org/projects/tor/ticket/6031 is done for Socks5 code But on Tor2web we have Python socks4a code so the matter is a) implement ticket #6031 on Socks4 code in Tor b) Implement a Socks5 client in Tor2web/Python ? I would say that this depends on which is the strongest focus of Tor, whenever Socks4a or Socks5

Still no naswer.

In case we want to just add/introduce Socks5 code in python for twisted: http://twistedmatrix.com/trac/ticket/1330

[fpietrosanti]

Nick Matwinson said: nickm net here is bad so I can explain much, but I don't think that SOCKS4 even supports error codes. There is one defined value for success, and one for failure. IIRC. adding a new error value would not merely be an extension, but a standards violation

So, it seems that socks5 python code on twisted/tor2web maybe a good path from nick's point of view.

Is it a major issue?

[evilaliv3]

Socks4/4a is not a standard or rfc, but only a proposal become a de facto standard. However I fully agree with Nick, such a patch probably would break some clients not handling unspecified values.

Allright so i'm going to implement Socks5 in place of Socks4a. No problem at all.

[evilaliv3]

socksv5 implemented and errors handled with reference to Hellais Tor path. https://github.com/globaleaks/Tor2web-3.0/commit/c956ab93483f0c5ca78734204043446e232ad20a