Internet censorship is everywhere Source: - PowerPoint PPT Presentation

Internet censorship is everywhere Source: https://freedomhouse.org/report/freedom-net/freedom-net-2016

Commonly censored content ● Unapproved news (Fake News!!111) ● Wikipedia (usually partially) ● Facebook ● Google (all services), YouTube ● Twitter ● Content prohibited by state religion

Censorship techniques

Censorship techniques

Censorship techniques

Censorship techniques

Decoy Routing: motivation Censors are sophisticated ● They drop connections by IP and trash Domain Name Service responses ● They (easily) detect and block open proxies ● They heuristically detect TOR traffic and then send out active probes to confirm and block Can we do something better, than cat-and- mouse game with proxies?

Decoy Routing: overview Not Blocked Blocked T apDance Station

Decoy Routing: overview Not Blocked Blocked T apDance Station

Decoy Routing: assumption ● There are uncensored websites. It is economically and politically infeasible to block everything. ● Client can establish connection to the unblocked website and then signal their actual intent to visit another website .

Decoy Routing: techniques Telex DR TapDance Slitheen Cirripede . Steganographic ClientRandom TCP ISN ClientRandom TLS ClientRandom channel Ciphertext No Inline No No No Yes No blocking Asymmetric No Yes Yes Yes No fmows Replay attack Yes No No No* Yes defense Traffjc/latency No No No No* Yes analysis defense *could and will be fixed

Decoy Routing: idea Client initiates connection to Decoy Server and signals his intent to visit Covert Server. Decoy Router, located on partner ISP's premises routes client there. Decoy Decoy Server Client Router (amazon.com) Covert Server (facebook.com)

Decoy Routing: TapDance Main difference of TapDance: it doesn't block the flow. Rationale: ISPs refused to deploy other Decoy Routing schemes with inline blocking. Decoy Server Client (amazon.com) Don't block the flow Duplicate traffic TapDance Covert Server Station (facebook.com)

TapDance: tag In the first application data packet the client sends a hidden tag, which: ● Can only be detected and decrypted by station. ● Contains key to Client↔Decoy connection. Hidden tag Decoy Server Client (amazon.com) Don't block the flow Duplicate traffic TapDance Covert Server Station (facebook.com)

TapDance: tag Problem: flow is not blocked, thus client must somehow remotely “mute” Decoy Server, so it stays quiet while Client and TapDance communicate. Solution: send incomplete HTTP request! Hidden tag Decoy Server Client (amazon.com) Don't block the flow Duplicate traffic TapDance Covert Server Station (facebook.com)

TapDance: Incomplete HTTP request Simplified request: GET /octocat.jpg HTTP/1.1\r\n Host: amazon.com\r\n X-Tag: < tag > Request is incomplete(no 2 newlines in the end), Decoy Server will wait for ending, which won't come.

TapDance: initial message Station uses information from tag to decrypt Client↔Decoy flow and inject messages into it. To censor it looks like Decoy Server sends those messages. Decoy Server Client (amazon.com) Hey, got your hidden message, what's up? TapDance Covert Server Station (facebook.com)

TapDance: initial message Now, when connected to TapDance station, client could request what it wants. TapDance Station simply proxies the connection at this point, like any other common proxy server. Decoy Server Client (amazon.com) Hey, connect me to that Covert server! TapDance Covert Server Station (facebook.com)

TapDance: initial response Station establishes connection to Covert Server and proxies the traffic. Decoy Server Client (amazon.com) TapDance Covert Server Station (facebook.com)

TapDance: recap No inline blocking: all traffic from client goes to Decoy. Client voluntarily gives out encryption key for Client↔Decoy, so station can decrypt the flow and set up tunneling of Client↔Covert. Decoy Server Client (amazon.com) Don't block the flow Duplicate traffic TapDance Covert Server Station (facebook.com)

TapDance: Request Format Tag's representative is then used to decrypt the payload. Payload has TLS session data, needed to decrypt the whole HTTP request and further connection.

TapDance: ciphertext channel 1 0 AES AES … P 1 P 0 00 00 00 00 00 .. 47 45 54 20 2f .. C 1 C 0 64 5e 59 48 d4 .. 26 5e df 61 22 ..

TapDance: ciphertext channel 1 0 AES AES … P 1 P 0 01 00 00 00 00 .. 47 45 54 20 2f .. C 1 C 0 64 5e 59 48 d4 .. 27 5e df 61 22 ..

TapDance: ciphertext channel 1 0 AES AES … P 1 P 0 27 5c dc 65 27 .. 47 45 54 20 2f .. C 1 C 0 64 5e 59 48 d4 .. 01 02 03 04 05 ..

TapDance: ciphertext channel 1 0 AES AES … P 1 P 0 07 0c 0c 05 07 .. 47 45 54 20 2f .. C 1 C 0 64 5e 59 48 d4 .. c1 92 43 64 f5 ..

TapDance: ciphertext channel GET /octocat.jpg HTTP/1.1 \r\n Host: www.amazon.com \r\n X-T: u]DhsYGxVxEvuZE…\r\n Encrypt ...1e 91 b2 ce 94 8a 6b 3c 5e ef 97 34 f1 2e c6 e6 f9 6a 0c ff 38 70 d7 63 3c 5e cf 57 3a f0 6e...

Client ● Logic is written in Golang, thus cross-platform ● Works on Android ● Many interesting challenges ● Fingerprintability ● Lack of root → inability to change tcp state

References See all papers on DecoyRouting.com . To list a few: ● Eric Wustrow, Colleen Swanson, and J. Alex Halderman. " TapDance : End-to-Middle Anticensorship without Flow Blocking." USENIX Security, 2014 ● Ellard, Daniel, Christine Jones, Victoria Manfredi, W. Timothy Strayer, Bishal Thapa, Megan Van Welie, and Alden Jackson. " Rebound : Decoy routing on asymmetric routes via error messages." IEEE, 2015. ● Bocovich, Cecylia, and Ian Goldberg. " Slitheen : Perfectly Imitated Decoy Routing through Traffic Replacement." ACM SIGSAC, 2016 ● Bernstein, Daniel J., Mike Hamburg, Anna Krasnova, and Tanja Lange " Elligator : Elliptic-curve points indistinguishable from uniform random strings." ACM SIGSAC, 2013

Link to slides To download the slides visit my blog: SergeyFrolov.github.io

Questions? Decoy Server Client (not blocked) Don't block the flow Duplicate traffic TapDance Covert Server Station (blocked)

TapDance: Request Format First application data packet, sent by client to Decoy Server, contains hidden tag. Station locates the tag by fixed offset from the end. Tag's representative is then used to decrypt the payload. Payload has TLS session data, needed to decrypt the whole HTTP request and further connection.

TapDance: Incomplete HTTP request Full request is as follows: GET /anything HTTP/1.1 Host: anyhost.tld X-E: <Future extensions> X-T: <Padding><Base64 encoded tag > Request is incomplete(no 2 newlines in the end), leaving Decoy Server waiting for ending, which never comes. Subsequent traffic sent by client will have wrong TCP SEQ number(wrong according to Decoy, as he didn't see TapDance station's response), so Decoy will ignore it. X-E stands for Extensions, X-T stands for Tag.

TapDance: Tag ● Elligator representative, when combined with station's private key, gets a secret, shared between client and station. ● The secret is used to encrypt/decrypt the payload. ● All fields are base64 encoded, thus take 33% more space on the wire. ● Additionally, TCP packet has 16 bytes of AES- GMAC(of TLS encryption of whole Request) in the end. ● As a result, station looks for the tag at (32+129+16)*8/6+16=252 bytes offset from the end.

TapDance: Payload ● Flags are needed for future extensions. ● Master key, Server and Client Random are needed to decrypt the rest of the connection and inject Station and Covert's traffic into conversation between Client and Decoy. ● Remote connection ID allows to resume old connection.

TapDance: Reverse Encryption Find plaintext for target ciphertext In order for station to be able to decrypt the tag, we have to find plaintext, which after being encrypted by user ssl lib, contains the target tag. To do that, client recovers the keystream of the cipher stream, that will be XORd with plaintext by TLS library later, and XORs desired ciphertext with that keystream. base64 encoding We cannot choose arbitrary plaintext, as we have to be in ascii range, and use base64 encoding, therefore first 2 bits of every byte are unusable. As a result, for every 8 bits of plaintext, we can only use 6.

TapDance: Elligator Ultimately, Elligator is a fancy way to hide a client's public key(which is a point on a curve), such that its representation looks random, thus indistinguishable for censor.