1 / 30

SPATor : Improving Tor Bridges with Single Packet Authorization

SPATor : Improving Tor Bridges with Single Packet Authorization. Paper Presentation by Carlos Salazar. Low-latency Anonymity Network Data is sent through a chain of relays known as a circuit.

anika
Download Presentation

SPATor : Improving Tor Bridges with Single Packet Authorization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Low-latency Anonymity Network • Data is sent through a chain of relays known as a circuit • 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

  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, Tor’s 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

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

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

  7. Bridge Aliveness Attack • Bridge Discovery • Collect a large list of bridge addresses and descriptors • 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) • Confirmation • Use circuit clogging and timing attacks to confirm the suspected source of the website contribution

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

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

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

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

  12. Adversary for the Bridge Aliveness Attack • 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

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

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

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

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

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

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

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

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

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

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

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

More Related