SPATor: Improving Tor Bridges with Single Packet Authorization

Paper Presentation by Carlos Salazar

• Each packet sent through the circuit is encrypted with the keys for each successive relay, this results in a layering of encryption (like an onion)

• All relays are listed in a public directory hosted by a directory authority

• Low-latency Anonymity Network

• Data is sent through a chain of relays known as a circuit

More Tor

• Adversaries will often restrict access to Tor by blocking all of the public relays.

• Unlisted relays have been created as a way to circumvent this problem

• Unlisted Tor relays are called bridges• Unfortunately, Tor’s implementation of

bridges has some issues…

Tor Bridges• Can be completely unlisted– Information spread by word-of-mouth

• Can be distributed by the Tor Project– Valid bridges are tracked by the bridge authority– Bridge info is stored and dispensed to clients by

the BridgeDB

• Goals of the bridge authority/BridgeDB:– Provide clients with ready access to bridge

information– Prevent an adversary from finding a large amount

of bridges in a short amount of time

Problems with Bridge distribution

• Does not account for attackers controlling multiple IP addresses

• A relay operator can discover bridges by attempting to start a bridge connection with any non-relay node that connects to their relay.

• The Bridge Aliveness attack could compromise the anonymity of a bridge operator who uses the same machine for web browsing

Bridge Aliveness Attack

1. Bridge Discovery– Collect a large list of bridge addresses and descriptors

2. Winnowing– Narrow the list down to possible bridges which may have

contributed material to a website by correlating timestamps with bridge aliveness information (by polling their bridge list)

3. Confirmation– Use circuit clogging and timing attacks to confirm the

suspected source of the website contribution

Mitigating the Bridge Aliveness Attack

• Remove the close relationship between a bridge operator serving other clients and using Tor as a client (targets winnowing)

• Prevent an entry relay from attempting to test whether or not its clients are bridges (targets discovery)

Enter SPATor

• Single Packet Authorization + Tor = SPATor

• Mitigates the risks of serving as a bridge while using Tor as a client– Obstructs the hoarding of bridge information– Makes it difficult to query bridge aliveness

• SPATor requires an extra per-bridge key be provided to users by the BridgeDB– Each key is only valid for a limited amount of time– Clients must prove knowledge of the key to

connect to a bridge– The key is used in the SPA protocol (SilentKnock),

so that failed authorization attempts do not reveal bridge aliveness

SilentKnock

• Conceals the existence of a particular service until the client sends a special TCP SYN packet to the target IP address and port.

• Uses covert channels in TCP/IP headers to hide a Message Authentication Code (MAC) in the TCP SYN packet– The MAC is in the lower 3 bytes of the ISN value

and the lower byte of the TCP timestamp

• Remote non-global adversary– Can query a large number of bridge descriptors– Can perform bridge aliveness tests by trying to

connect to bridges as a client– Has access to a website timestamps of

pseudonymous contributions by a bridge operator and can control some content on that site

Adversary for the Bridge Aliveness Attack

The Other Adversary

• More Capable than the first adversary– Active– Has full control of the local network in which the

client is present– Can monitor, inject, replay, shape, and drop

packets within the local network– Cannot view or control anything outside the local

network

The SPATor Protocol

• Uses a pre-shared key to generate MACs– MACs are used to determine whether or not a

bridge connection request is legitimate

• SPATor affects three parts of a Tor bridge’s life cycle– Bridge registration– Bridge request– Client Connection

Bridge Registration

• New bridges in Tor provide the bridge authority with:

• IP address• Port

• SPATor Adds:• SeedKey (a random 256-bit value)

– Used to generate a short-lived MACKey

• Key update frequency

Client Connection

• Client generates a MAC and embeds it in a TCP SYN packet

• Made with the current time and header Data of the inclosing TCP SYN packet • Keyed with a MACKey recently obtained from a bridge

authority• Truncated to 32 bits (from 256)

• Client sends the special TCP SYN packet

Unlisted Bridges

• SPATor is designed to work with unlisted bridges too– The bridge operator must distribute information

to clients somehow• Share the SeedKey & update freq out-of-band• Share only the current MACKey• (maybe) offer a SeedKey or MACKey unique to each

client’s address

Attacks on SPATor

• Bridge Aliveness– Only works if the attacker has access to a large

number of IP addresses in a short amount of time• All IP addresses must be distinct /24 network addresses

– Determining aliveness by guessing the correct MAC could take over 715 million guesses• A firewall should blacklist an IP that failed too many times

Bridge Client Detection Attacks

• A Passive Adversary can:– Learn that a client’s connection timed out– See that the client established a TLS connection– Distinguish Tor traffic from other types of traffic

(this is not changed by SPATor)

Active Adversaries

• Can attempt to use information from the client to connect to the bridge– Replay a previously seen TCP SYN packet• Requires the adversary to assume control of the client’s

IP address• Must be done before the MAC in the SYN packet

becomes stale

– Hijack the TCP connection as it is being sychronized and act as a Man-in-the-middle

How to prevent replay and MITM

• After a TLS connection is established, the client sends the full 256 bit MAC – The bridge should act like it’s something else until

this happens• This isn’t currently possible because the TLS certificates

for Tor bridges are distinguishable from other TLS certs.

• There is a (very small) delay imposed on connections made with SPATor– Just like there is with SilentKnock– This probably doesn’t matter

• Conclusive detection of SPATor use based on timing would require that the adversary:– Is fairly close to the network– Has collected a large amount of data

• An adversary could prevent SPA from succeeding by altering the sequence numbers on every packet.

• This is impractical for most large active firewalls• This doesn’t necessarily provide a way to prove that

SPATor is in use, because this will always break some IP extensions

Future Work

• Compatibility with other OSs (not just Linux)• SPATor does not work behind a NAT• Handle SYN retransmits correctly• Add changes to bridge authority and BridgeDB• Prevent other Aliveness checks• Pluggable transports?