separately. It's important to keep them separate because internal
circuits have their last hops picked like middle hops, rather than like
exit hops. So exiting on them will break the user's expectations.
- Stop cannibalizing internal circuits for general exits, and stop
cannibalizing exit circuits for rendezvous stuff.
- Don't let new exit streams attach to internal circuits.
- When deciding if we have enough circuits for internal and for exit,
don't count the wrong ones.
- Treat predicted resolves as predicted port 80 exits.
svn:r5457
(intended to be cannibalized later for rendezvous and introduction
circuits), we were picking them so that they had useful exit nodes. There
was no need for this, and it actually aids some statistical attacks.
svn:r5453
- If we can't get to a dirserver directly, try going via Tor.
- Don't ever try to connect (as a client) to a place our firewall
options forbid.
- If we specify a proxy and also firewall options, obey the firewall
options even when we're using the proxy: some proxies can only proxy
to certain destinations.
svn:r5431
don't tell you (it happens!); and rotate TLS connections once a week.
1) If an OR conn becomes more than a week old, make it obsolete.
2) If it's obsolete and empty, kill it.
3) When an OR makes a second connection to you, allow it.
4) If we want to send a new create cell, but the best conn we've
got is obsolete, and the router is 0.1.1.9-alpha-cvs or later, ask
for a new conn instead.
5) When we time out on circuit building on the first hop, make that
connection obsolete.
svn:r5429
first few moments of their existence in CIRCUIT_STATE_OPEN, then
when Alice sent an extend request for a Tor that they're not connected
to, they switched to CIRCUIT_STATE_OR_WAIT and spent the rest of
their sorry little lives in that state, even when the connection
was established and they were shuttling relay cells back and forth.
And I'm not going to backport this (yet), because somehow it worked!
svn:r5427
just add the default ones directly to the trusted dirserver list.
This fixes a bug where people running controllers would setconf or
the equivalent, and Tor would start yelling at them about setting
their own DirServer lines.
svn:r5418
any answer at all. this is clearly a bug.
the more interesting bug is whether things like setconf, getconf,
and so on should return 250 OK if you give them no arguments. should
we have a new "you didn't ask me anything" response code, or just
leave it as is?
svn:r5412
don't recognize. now we just drop it. perhaps this will make us
more forward-compatible? or perhaps it will bite us? one day we
will find out.
svn:r5405
applications are using socks4, socks4a, socks5-with-ip, or
socks5-with-hostname. This way they don't have to keep mucking
with tcpdump and wondering if something got cached somewhere.
svn:r5399
