[ ijbswa-Feature Requests-3603913 ] socks5 message / error passthrough

Feature Requests item #3603913, was opened at 2013-02-08 22:10
Message generated for change (Comment added) made by grarpamp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=361118&aid=3603913&group_id=11118

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: grarpamp (grarpamp)
Assigned to: Fabian Keil (fabiankeil)
Summary: socks5 message / error passthrough

Initial Comment:
Privoxy 3.0.19 on FreeBSD 8.3 i386
 
With polipo I'd see helpful diagnostic messages from Tor's socks5 implementation
passed through polipo and eventually reaching wget's log file. Though I'm not sure
if it was the exact socks5 error code number, the text was still useful. Example...
 
1300 504 Connect to onion failed: SOCKS error: host unreachable.
    80 504 Connect to onion failed: SOCKS error: TTL expired.
    30 504 Connect to onion failed: SOCKS connection not allowed.
    15 504 Connect to onion failed: General SOCKS server failure.
    10 504 Connect to onion failed: SOCKS error: connection refused.
 
With Privoxy, I get vague 500 level messages that don't really tell me anything
about the far end. (I don't have relative counts for this example right now).
 
ERROR 500: Internal Privoxy Error.
ERROR 500: Internal Server Error.
ERROR 502: Server or forwarder response invalid.
ERROR 503: Service unavailable.
ERROR 504: Gateway Time-out.
Proxy tunneling failed: Internal Privoxy ErrorUnable to establish SSL connection.
 
So I'm hereby suggesting that...
1) more detailed messages be passed through wherever available from the far end.
2) these 'internal' errors receive more verbose or coded treatment as to what function
is kicking them out. (that's probably the bug-ish part of this feature-ish report).
 
Thx.


----------------------------------------------------------------------

>Comment By: grarpamp (grarpamp)
Date: 2013-02-09 18:18

Message:
Did more work on this...

https://tools.ietf.org/html/rfc2616

Per HTTP rfc2616 sec:10.5, user agents SHOULD display any entity...
ok, displayed - firefox, curl, elinks, lynx, telnet, netcat
broken, not displayed - wget, fetch, socat[!]

This entity, 'forwarding-failed', cannot know any more
info than the socks5 rfc1928 sec:6 reply itself.
We can pick an HTTP rfc2616 sec:10.5 error code to ride on top of.

Unusuitable since the error is already specifically defined...
502 Bad Gateway - invalid response from webserver (or auxiliary: Tor)
504 Gateway Timeout - timeout on webserver (or auxiliary: Tor)

The most sensible HTTP error code seems to be...
500 Internal Server Error - unexpected condition prevented fulfillment

Privoxy can pass that through from webserver when not using socks,
or when the socks5 reply code is 00h.

And when using socks5, if reply code of 01h through FFh occur,
Privoxy could then reissue the 500 in that case as...

500 Internal Server Error - Privoxy: SOCKS<ver>: <nn> <msg>

Where <ver> is socks version. If version 5, <nn> is 01~FF, and
<msg> is as shown in socks5 rfc1928 or highly abbreviated.

socks4 and socks4a follow similarly.

There is merit in optionally including the attempted URL in the 
'forwarding-failed' entity. I removed that file, so it emits this
header instead: 500 Internal Privoxy Error

Privoxy should probably not do that, or have a 'support fileless
normally' mode. That is for another ticket.


----------------------------------------------------------------------

Comment By: grarpamp (grarpamp)
Date: 2013-02-09 14:26

Message:
> Adding the socks error description to the response line seems useful to
me.
 
Ok, cool. Section 6 would be apropriate:
https://tools.ietf.org/html/rfc1928
 
> BTW, at least some of your example error messages don't actually come
from Privoxy
 
Ahh, so maybe there is ability to indicate in the status response header
from privoxy to
the client (wget), in general, if it was privoxy that generated the error.
A formatted
privoxy: label perhaps.
 
> Note that Privoxy already provides the details as part of the response
body
> I don't think discarding the problem description in the body ... [is]
reasonable
 
Hmm, I think wget deems any such reply body received along with an error
header
as erroneous to the intended body and thus does not save them to disk. I
will look
at this and possibly ticket or replace wget. Thanks.
 
> Privoxy already provides the details ... and properly logs them when
configured.
> checking Privoxy's log would make their origin more obvious.
> correlation socks errors to Tor circuits currently isn't trivial.
 
Yes, for reproducing the error as well. And matching up thousands of
lines in wget, privoxy, and Tor logs, from parallel fetches, is tough too.
Divide and conquer may work here for whatever is not done by this ticket.
In the meantime I'll bump 'debug' to see what privoxy currently thinks
about 'privoxy <--> Tor' regarding socks.
 
wget <--> privoxy <--> Tor <--> webserver
'far end' - I mean reply from the webserver (the far end) back through to
wget.
 
Thanks.


----------------------------------------------------------------------

Comment By: Fabian Keil (fabiankeil)
Date: 2013-02-09 03:28

Message:
Adding the socks error description to the response line seems useful to me.
Thanks for the suggestion.

Note that Privoxy already provides the details as part of the response body
and properly logs them when configured to do so.

Internal Privoxy Errors usually aren't bugs but configuration problems and
I don't think discarding the problem description in the body and only
looking at the response line is a reasonable debugging strategy, even when
doing it from the "far end".

BTW, at least some of your example error messages don't actually come from
Privoxy and checking Privoxy's log would make their origin more obvious.
Unfortunately correlation socks errors to Tor circuits currently isn't
trivial.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=361118&aid=3603913&group_id=11118

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb