[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: DNS related Assertions with Tor 0.1.2.1-alpha



Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:

> On Wed, Sep 20, 2006 at 12:15:27PM +0200, Fabian Keil wrote:
> > With Tor 0.1.2.1-alpha running on FreeBSD 7.0-CURRENT
> > my exit nodes used to hit:
> > 
> > [err] dns.c:596: dns_cancel_pending_resolve: Assertion !
> > resolve->expire failed; aborting.

> Okay; we've had a fix for this one in the subversion repository for
> while; the fix should come out in the next alpha. 

OK.
 
> > several times a day, until I replaced the assertion with
> > a simple warning. Before the assertion is triggered,
> > launch_resolve() always complaints about:
> > 
> > 'eventdns rejected address "$URL": error 1.'
> > 
> > $URL always is a complete urlencoded URL
> > and never a valid host name as it's supposed to be.
> > 
> > While this isn't Tor's fault, I think it would make
> > sense if the Tor client did some simple URL sanity
> > checks before passing forward any requests. From time to
> > time these broken URLs contain usernames and passwords.
> 
> That's quite weird; it looks like somebody is trying to resolve URLs
> rather than hostnames. How bizarre!

I assume most of these URL are caused by Privoxy 3.0.3
in combination with broken URLs. The fast-redirects
action in Privoxy 3.0.3 doesn't decode urlencoded URLs
before checking for redirection URLs.

If the redirection URL is properly encoded, Privoxy 3.0.3
will just miss it, but if "http://"; is not encoded and the
rest of the URL is, Privoxy 3.0.3 will cause a redirect
to the mostly urlencoded URL.

Privoxy 3.0.5 beta (released yesterday) can decode the URLs
before checking, and should no longer cause these broken
redirects.

> Ordinarily, this shouldn't be showing up in your log unless you have
> SafeLogging turned off, or unless we screwed it up in 0.1.2.1-alpha
> (it works now).

I intentionally enabled SafeLogging for debugging purposes.
 
> But yeah, I agree that we should check that hostnames are plausible
> before trying to resolve them.  I'll add that to the 0.1.2.x TODO
> list.

Great.

> > Another assertion that I only got once so far is:
> > 
> > [err] purge_expired_resolves(): The expired resolve we purged didn't
> > match any in the cache. Tried to purge delb.myspace.com (0xb948200);
> > instead got delb.myspace.com (0x804b99c). [err] dns.c:319:
> > purge_expired_resolves: Assertion removed == resolve failed; aborting.
> 
> I think we solved this one too, but let me know if it comes back,
> especially after the next alpha release is out.  A stack trace there
> might be really handy.

OK.

Fabian
-- 
http://www.fabiankeil.de/

Attachment: signature.asc
Description: PGP signature