1. SPATor: Improving Tor Bridges with Single Packet Authorization Paper Presentation by Carlos Salazar

2. 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

3. 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, Tors implementation of bridges has some issues…

4. 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

6. 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

7. 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

8. 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

9. 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)

10. 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

11. 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

12. 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

14. 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

15. 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

16. 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 bridges life cycle – Bridge registration – Bridge request – Client Connection

18. 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

19. 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

22. 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 clients address

23. 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

24. Bridge Client Detection Attacks A Passive Adversary can: – Learn that a clients 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)

25. 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 clients 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

27. 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 its something else until this happens This isnt currently possible because the TLS certificates for Tor bridges are distinguishable from other TLS certs.

29. There is a (very small) delay imposed on connections made with SPATor – Just like there is with SilentKnock – This probably doesnt 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 doesnt necessarily provide a way to prove that SPATor is in use, because this will always break some IP extensions

30. 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?