preview question
play

Preview question Officially the name of the Tor network is not an - PDF document

Preview question Officially the name of the Tor network is not an acronym, but the or part of the name originated from this technique it uses: CSci 5271 A. onion routing Introduction to Computer Security DoS, Tor, and usability combined


  1. Preview question Officially the name of the Tor network is not an acronym, but the “or” part of the name originated from this technique it uses: CSci 5271 A. onion routing Introduction to Computer Security DoS, Tor, and usability combined slides B. oatmeal reciprocity Stephen McCamant C. one-time resilience University of Minnesota, Computer Science & Engineering D. oilseed relaying E. oblivious ratcheting Outline DoS versus other vulnerabilities Denial of service and the network (cont’d) Effect: normal operations merely become impossible Anonymous communications techniques Software example: crash as opposed to code Announcements intermission injection Tor basics Less power that complete compromise, but practical Tor experiences and challenges severity can vary widely Usability and security Airplane control DoS, etc. Usable security example areas Compression DoS DoS against network services Common example: keep legitimate users from Some formats allow very high compression ratios viewing a web site Simple attack: compress very large input Easy case: pre-forked server supports 100 More powerful: nested archives simultaneous connections Also possible: “zip file quine” decompresses to itself Fill them with very very slow downloads Tiny bit of queueing theory SYN flooding SYN is first of three packets to set up new Mathematical theory of waiting in line connection Simple case: random arrival, sequential fixed-time Traditional implementation allocates space for service control data M/D/1 However much you allow, attacker fills with If arrival rate ✕ service rate, expected queue length unfinished connections grows without bound Early limits were very low (10-100)

  2. SYN cookies DoS against network links Change server behavior to stateless approach Try to use all available bandwidth, crowd out real Embed small amount of needed information in fields traffic that will be echoed in third packet Brute force but still potentially effective MAC-like construction Baseline attacker power measured by packet Other disadvantages, so usual implementations used sending rate only under attack Traffic multipliers “Smurf” broadcast ping Third party networks (not attacker or victim) ICMP echo request with forged source One input packet causes ♥ output packets Sent to a network broadcast address Commonly, victim’s address is forged source, Every recipient sends reply multiply replies Now mostly fixed by disabling this feature Misuse of debugging features Distributed DoS Outline Denial of service and the network (cont’d) Many attacker machines, one victim Anonymous communications techniques Easy if you own a botnet Announcements intermission Impractical to stop bots one-by-one Tor basics May prefer legitimate-looking traffic over weird Tor experiences and challenges attacks Usability and security Main consideration is difficulty to filter Usable security example areas Traffic analysis Nymity slider (Goldberg) Verinymity Social security number What can you learn from encrypted data? A lot Persistent pseudonymity Content size, timing Pen name (“George Eliot”), “moot” Who’s talking to who Linkable anonymity ✦ countermeasure: anonymity Frequent-shopper card Unlinkable anonymity (Idealized) cash payments

  3. Nymity ratchet? Steganography It’s easy to add names on top of an anonymous One approach: hide real content within bland-looking protocol cover traffic The opposite direction is harder Classic: hide data in least-significant bits of images But, we’re stuck with the Internet as is Easy to fool casual inspection, hard if adversary So, add anonymity to conceal underlying identities knows the scheme Dining cryptographers Dining cryptographers Dining cryptographers Dining cryptographers Dining cryptographers DC-net challenges Quadratic key setups and message exchanges per round Scheduling who talks when One traitor can anonymously sabotage Improvements subject of ongoing research

  4. Mixing/shuffling Anonymous remailers Anonymizing intermediaries for email Computer analogue of shaking a ballot box, etc. First cuts had single points of failure Reorder encrypted messages by a random Mix and forward messages after receiving a permutation sufficiently-large batch Building block in larger protocols Chain together mixes with multiple layers of encryption Distributed and verifiable variants possible as well Fancy systems didn’t get critical mass of users Outline Announcements: this week Denial of service and the network (cont’d) Anonymous communications techniques Next and final progress reports due Wednesday Announcements intermission night Tor basics Wednesday lecture will be electronic cash and Tor experiences and challenges blockchains only Usability and security Usable security example areas Outline Tor: an overlay network Denial of service and the network (cont’d) Tor (originally from “the onion router”) Anonymous communications techniques ❤tt♣s✿✴✴✇✇✇✳t♦r♣r♦❥❡❝t✳♦r❣✴ Announcements intermission An anonymous network built on top of the Tor basics non-anonymous Internet Tor experiences and challenges Designed to support a wide variety of anonymity use Usability and security cases Usable security example areas Low-latency TCP applications Tor Onion routing Stream from sender to ❉ forwarded via ❆ , ❇ , and ❈ Tor works by proxying TCP streams One Tor circuit made of four TCP hops (And DNS lookups) Encrypt packets (512-byte “cells”) as Focuses on achieving interactive latency ❊ ❆ ✭ ❇❀ ❊ ❇ ✭ ❈❀ ❊ ❈ ✭ ❉❀ P ✮✮✮ WWW, but potentially also chat, SSH, etc. TLS-like hybrid encryption with “telescoping” path Anonymity tradeoffs compared to remailers setup

  5. Client perspective Entry/guard relays “Entry node”: first relay on path Entry knows the client’s identity, so particularly Install Tor client running in background sensitive Configure browser to use Tor as proxy Many attacks possible if one adversary controls entry Or complete Tor+Proxy+Browser bundle and exit Choose a small random set of “guards” as only Browse web as normal, but a lot slower entries to use Also, sometimes ❣♦♦❣❧❡✳❝♦♠ is in Swedish Rotate slowly or if necessary For repeat users, better than random each time Exit relays Centralized directory How to find relays in the first place? Forwards traffic to/from non-Tor destination Straightforward current approach: central directory Focal point for anti-abuse policies servers E.g., no exits will forward for port 25 (email sending) Relay information includes bandwidth, exit polices, Can see plaintext traffic, so danger of sniffing, MITM, public keys, etc. etc. Replicated, but potential bottleneck for scalability and blocking Outline Anonymity loves company Denial of service and the network (cont’d) Anonymous communications techniques Diverse user pool needed for anonymity to be Announcements intermission meaningful Hypothetical Department of Defense Anonymity Network Tor basics Tor aims to be helpful to a broad range of Tor experiences and challenges (sympathetic sounding) potential users Usability and security Usable security example areas Who (arguably) needs Tor? Tor and the US government Onion routing research started with the US Navy Consumers concerned about web tracking Academic research still supported by NSF Businesses doing research on the competition Anti-censorship work supported by the State Citizens of countries with Internet censorship Department Reporters protecting their sources Same branch as Voice of America Law enforcement investigating targets But also targeted by the NSA Per Snowden, so far only limited success

  6. Volunteer relays Performance Tor relays are run basically by volunteers Increased latency from long paths Most are idealistic A few have been less-ethical researchers, or GCHQ Bandwidth limited by relays Never enough, or enough bandwidth Recently 1-2 sec for 50KB, 3-7 sec for 1MB P2P-style mandatory participation? Historically worse for many periods Unworkable/undesirable Flooding (guessed botnet) fall 2013 Various other kinds of incentives explored Anti-censorship Hidden services As a web proxy, Tor is useful for getting around Tor can be used by servers as well as clients blocking Identified by cryptographic key, use special Unless Tor itself is blocked, as it often is rendezvous protocol Bridges are special less-public entry points Servers often present easier attack surface Also, protocol obfuscation arms race (uneven) Undesirable users Intersection attacks Suppose you use Tor to update a pseudonymous P2P filesharing blog, reveal you live in Minneapolis Discouraged by Tor developers, to little effect Comcast can tell who in the city was sending to Tor Terrorists at the moment you post an entry At least the NSA thinks so Anonymity set of 1000 ✦ reasonable protection Illicit e-commerce But if you keep posting, adversary can keep “Silk Road” and its successors narrowing down the set Exit sniffing Browser bundle JS attack Tor’s Browser Bundle disables many features try to stop tracking Easy mistake to make: log in to an HTTP web site But, JavaScript defaults to on over Tor Usability for non-expert users A malicious exit node could now steal your password Fingerprinting via NoScript settings Another reason to always use HTTPS for logins Was incompatible with Firefox auto-updating Many Tor users de-anonymized in August 2013 by JS vulnerability patched in June

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend