[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Empty TLS application records being injected in Tor streams
Recently I've been looking into how Tor sends packets out on the wire.
My goal is to understand the detail of how the data is packaged up, in
order to improve Tor's traffic analysis and censorship resistance, as
well as performance.
To do so, I've written some code to decode TLS sessions, and patched
my Tor client to save the keys needed to do. I've done two test-runs
so far -- both are from a Tor client with a cached directory, so it's
mainly data downloads. I cleared the guards between the two runs, and
as it happens test run 4 uses the old TLS handshake and run 5 uses the
new one.
The strange thing I noticed about both test runs is that almost every
second application record is empty (only contains a 5 byte TLS header,
20 byte TLS-level MAC, and 12 bytes of padding). It's not every
application record, as for example there are application records with
two cells, and even 6.
From my test case 4, there are 885 empty application records (each
taking up 37 bytes) and 884 non-empty ones. If we dropped the empty
ones we would save about 4% of network traffic. It's not huge, but not
trivial either.
We would save even more if we could coalesce more cells per packet and
application record (currently 72% of non-empty application records
have one cell and 81% of packets have one cell or less).
I am not sure why empty application records are being sent. It is a
good idea to send one at the start, to prevent an attack (see point 2 of
http://www.openssl.org/~bodo/tls-cbc.txt). Maybe we're seeing the
empty application records as a side-effect of this countermeasure.
The data can be seen here:
http://www.cl.cam.ac.uk/~sjm217/volatile/tor-patches/log-keys/testrun4/
http://www.cl.cam.ac.uk/~sjm217/volatile/tor-patches/log-keys/testrun5/
testrun4 and testrun5 are the two runs. The Tor log files are there
(debug.log and info.log), the tcpdump file (packet.dump), and the
decrypted TLS application record listing (decoded.txt).
Does anyone have ideas on how to remove the redundant TLS application
records, or otherwise improve the efficiency?
Steven.
--
w: http://www.cl.cam.ac.uk/users/sjm217/