Curious about the way Tor makes cells [Was: Re: TTL settings for Tor]

["F. Fox" <kitsune.or@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

misc wrote:
(snip)
> For example, should DefaultTTL be increased, so that packets don't expire
> in transit? What TCPWindowSize is better suited for Tor?
> 
> My browser connection constantly times out, even though I set timeout to
> 1200 (as opposed to usual 300). 
> 

I know that on many of my systems, I've increased the TTL to the maximum
(255). It's probably overkill... but why not? The Internet's a different
place than it used to be.

(If someone presents a convincing argument as to why this is harmful,
though, I may change it.)

I don't know if it really makes all that much of a difference for Tor,
though, because I don't fully understand the internals of how it deals
with individual packets. For example, I know that it wraps them in three
layers of encryption (for standard outproxy traffic), and pads packets
that are less than 1500 bytes with random data up to that size, before
they're encrypted into cells (to prevent traffic analysis by size).

What I don't know is, are we talking about encapsulation (like a VPN
would do), or a complete rewrite of packets as they're encrypted into cells?

I'm pretty sure it's closer to the latter, due to:

1.) Tor offering a SOCKS interface (which means applications are aware
of a proxy being there);
2.) I remember reading that Tor prevents many OS fingerprinting
techniques (based on packets, not probing a system, of course) from
being reliable.

Sorry to take over your thread, but I'm very curious now. Does anyone
have any helpful links where I can find out these juicy details? =;o)

- --
F. Fox
AAS, CompTIA A+/Network+/Security+
Owner of Tor node "kitsune"
http://fenrisfox.livejournal.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSAJ9rOj8TXmm2ggwAQg8UhAAv86pSgm17C0Qc1N0coxzdgpZ2CpgAvNF
k9fOxNvNunUchJxF23JbBwo1RpRlrHsUTCGSw/HcnqlLkOCao3rczz3nhfvh6ZVE
Ifbad7a6RQnXddrFmXmzER/R8lO2fvC4b1BUZOGCZdbQOldRj9iI8FwpeXN3h8nZ
bCnBjfAVKWaBVBDyRjdDpHB5VN5Seepw3zjMhqWbQ4pM7oGsrh6KNojlNzcnMC+H
kdlFDmOYLb01Xv9iAhmMBCXWmU4RNFxdWuDxv9DOpvtUV0DwWHuJlQS8bF8JjGd5
7sQMviOMdm1h0WcfAqkZmy0q1rFv57IDQUbFr7BYDrTa0fuGTAzfIH9RSLkIC7sl
eeB3cpshYm3IxzStlo4s2pH1lEch3nZfREsfre+4TJc3nNV5xB87clGofInHH4t2
RXBhWHXD7JvzXgPjDMAmPgNfsBFF4w0u5+G/L8DL5QruUTbboqurEa3epwJs2DXQ
k2wgA7PaNn/Xd1k+JoDpBz7rrSZKxdO7KzO9vF1/E/GCGg4yRp5KIONYOjm8jx8i
BGpEcNnQn7hOkY+FbpXmmHIOht+udD6QbfWOkSw7hD9jIbdeXX6Q4SD3iev93H2p
A1iyJYMst+o4OzwzNamInJqMr7LtUtWHC8LW9shSynwlxgYXoDmuwk3QzVT3XY5O
xxL+ofAWgm4=
=1nMd
-----END PGP SIGNATURE-----