Re: client bug in 0.2.2.7-alpha and a new bad exit: exoassist

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Tue, 2 Feb 2010 22:21:12 -0500 grarpamp <grarpamp@xxxxxxxxx> wrote:
>> One is in the HTTP(S) header, which can indeed be stripped by privoxy.
>
>HTTPS cannot be terminated, stripped and re-encapsulated by privoxy.
>It passes straight through. I still offer a gold doubloon to anyone who knows

     Right you are.  I was definitely sloppy there.  Thanks for pointing
that out.

>of a good unix TLS proxy/munger. One can dream.
>
>> tor handles a .nickname.exit passed to it in a unique way
>
>Nicknames are not unique. People should be specifying fingerprints instead.

     True, but irrelevant to what I wrote.  I was describing tor's handling
of the nickname.exit (or, of course, the $fingerprint.exit) notation, not
commenting upon nicknames.

>ie: fingerprint.exit
>
>> technicalities of SOCKS proxies... certain that .exit notation caused errors
>> from destination servers... it's not a new problem.
>
>It's not a socks issue. Until a TLS proxy is available, the most
>direct 'fix' would
>be a browser plugin that strips it off the host header when it is seen
>in the URL...
>before the browser does ssl on it. The two results would then get
>stuffed through
>socks as usual.

     True as well.  The bug exposed is that tor, in this case, appears to
have passed the name to the exit node for SOCKS name-to-address resolution as
"fibrlink.net.exoassist.exit" rather than as "fibrlink.net".  That should
never happen.  Also, as I noted in an earlier posting, using a different exit
node in a .exit request got the correct result of a connection failure that
was reported to me by privoxy on my own system, rather than by software on
the exit node.
>
>> Of course some servers aren't running virtual hosts and so don't care about
>> the "Host: example.com.nickname.exit" header
>
>That's why, failing enhancement of MAPADDRESS, keeping .exit around would
>be handy for clued people... ssh [example.com|10.0.0.69].fingerprint.exit...
>is much simpler than managing a MAP. Yet unclued people don't know exit
>can bite them in URLbars, so they complain, so there is desire to kill URLbars
>to kill complaints from the unclued. Not to mention it isn't a fully
>capable method
>to begin with.
>
>> Perhaps one of the developers could weigh in on whether Tor itself should be
>> modifying the Host header
>
>It should not, Tor only provides passive transport services, and rightly so.
>I'm not a dev. And the world is going TLS. So if Tor does anything to

     I agree with that, certainly.  My complaint is that the SOCKS service
provided by tor was incorrect in this particular case of .exit usage.

>'fix' this,
>it should enhance the MAPADDRESS functionality as proposed earlier.
>And possibly provide a friendlier human 'domain2exit selection' interface to
>it via Vidalia or whatever windows people need.
>
>> - it may be moot as .exit notation is deprecated now

     But until a suitable replacement is available for explicitly testing
exit node behavior, it should work correctly when enabled and used.
>
>It is deprecated in your URLbar. But not in the MAPADDRESS function.
>Exit MAPADDRESSing is still needed given the world's penchant for
>screwing up how their own services work based on where you're coming
>from.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/