Just a note on the patch, storing the digest of each router that uses the port
is a bit of a memory hog, and its only real purpose is to provide a count of
routers using that port when warning the user. That could be achieved when
warning the user by iterating through the routerlist instead.
On Tuesday 14 October 2008 23:16:12 Robert Hogan wrote:
> Motivation:
> Tor clients that are behind extremely restrictive firewalls can end up
> waiting a while for their first successful OR connection to a node on the
> network. Worse, the more restrictive their firewall the more susceptible
> they are to an attacker guessing their entry nodes. Tor routers that are
> behind extremely restrictive firewalls can only offer a limited,
> 'partitioned' service to other routers and clients on the network. Exit
> nodes behind extremely restrictive firewalls may advertise ports that they
> are actually not able to connect to, wasting network resources in circuit
> constructions that are doomed to fail at the last hop on first use.
>
> Proposal:
>
> When a client attempts to connect to an entry guard it should avoid further
> attempts on ports that fail once until it has connected to at least one
> entry guard successfully. (Maybe it should wait for more than one failure
> to reduce the skew on the first node selection.) Thereafter it should
> select entry guards regardless of port and warn the user if it observes
> that connections to a given port have failed every multiple of 5 times
> without success or since the last success.
>
> Tor should warn the operators of exit, middleman and entry nodes if it
> observes that connections to a given port have failed a multiple of 5 times
> without success or since the last success. If attempts on a port fail 20 or
> more times without or since success, Tor should add the port to a
> 'blocked-ports' entry in its descriptor's extra-info. Some thought needs to
> be given to what the authorities might do with this information.
>
> Related TODO item:
> "- Automatically determine what ports are reachable and start using
> those, if circuits aren't working and it's a pattern we
> recognize ("port 443 worked once and port 9001 keeps not
> working")."
>
>
> I've had a go at implementing all of this in the attached.
Attachment:
signature.asc
Description: This is a digitally signed message part.