On Tue, 2 Feb 2010 22:21:12 -0500 grarpamp <grarp...@gmail.com> 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 majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/