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

Cirripede

DR TapDance Slitheen

Steganographic channel

ClientRandom

TCP ISN

ClientRandom

TLS Ciphertext

ClientRandom

No Inline blocking

No No No Yes No

Asymmetric fmows

No Yes Yes Yes No

Replay attack defense

Yes No No No* Yes

Traffjc/latency analysis defense

No No No No* Yes

*could and will be fixed

Decoy Routing: idea

Client Decoy Server (amazon.com) Decoy Router Covert Server

(facebook.com)

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 Routing: TapDance

Client Decoy Server (amazon.com)

Don't block the flow Duplicate traffic

TapDance Station Covert Server

(facebook.com)

Main difference of TapDance: it doesn't block the flow. Rationale: ISPs refused to deploy other Decoy Routing schemes with inline blocking.

TapDance: tag

Client Decoy Server (amazon.com)

Don't block the flow Duplicate traffic

TapDance Station Covert Server

(facebook.com)

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

TapDance: tag

Client Decoy Server (amazon.com)

Don't block the flow Duplicate traffic

TapDance Station Covert Server

(facebook.com)

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

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

Client Decoy Server (amazon.com) TapDance Station Covert Server

(facebook.com)

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.

Hey, got your hidden message, what's up?

TapDance: initial message

Client Decoy Server (amazon.com) TapDance Station Covert Server

(facebook.com)

Hey, connect me to that Covert server!

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.

TapDance: initial response

Client Decoy Server (amazon.com) TapDance Station Covert Server

(facebook.com)

Station establishes connection to Covert Server and proxies the traffic.

TapDance: recap

Client Decoy Server (amazon.com)

Don't block the flow Duplicate traffic

TapDance Station Covert Server

(facebook.com) 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.

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

AES

P0 C0

AES

1 P1 …

64 5e 59 48 d4 .. 47 45 54 20 2f ..

00 00 00 00 00 ..

26 5e df 61 22 ..

C1

TapDance: ciphertext channel

AES

P0 C0

AES

1 P1 …

64 5e 59 48 d4 .. 47 45 54 20 2f ..

01 00 00 00 00 ..

27 5e df 61 22 ..

C1

TapDance: ciphertext channel

AES

P0 C0

AES

1 P1 …

64 5e 59 48 d4 .. 47 45 54 20 2f .. 27 5c dc 65 27 ..

01 02 03 04 05 ..

C1

TapDance: ciphertext channel

AES

P0 C0

AES

1 P1 …

64 5e 59 48 d4 .. 47 45 54 20 2f .. 07 0c 0c 05 07 .. c1 92 43 64 f5 ..

C1

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?

Client Decoy Server (not blocked)

Don't block the flow Duplicate traffic

TapDance Station Covert Server (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.