Protocol Encryption and Message Stream Encryption for WebTorrent

Brian Gu,Kelvin Lu MIT, 6.858 (Computer Systems Security) {bgu, kelvinlu}@mit.edu

May 12, 2018

Abstract

Message Stream Encryption (MSE), also known as Protocol Encryption (PE), is an extension to the Bittorrent Protocol that encrypts the Bittorrent stream and header information. The goal is to make Bittorrent traffic harder to detect by third parties (e.g. ISP’s) while maintaining high download speeds. In this paper, we assess the security of PE/MSE and why it was important to implement for WebTorrent, a Javascript-based Bittorrent client for web browsers and Node.js servers.

I. Introduction II. Background

Readers can find Related Pull Request/Code i. Bittorrent here and here. The goal of Message Stream Encryption The BitTorrent Protocol is one of the most pop- (MSE) and Protocol Encryption (PE) is to ob- ular protocols for peer-to-peer file sharing. The fuscate the header for third-parties to detect peer-to-peer file sharing network model dif- BitTorrent traffic by encrypting header infor- fers significantly from the typical client-server mation. This provides anonymity and con- model in that all participants (nodes) on the fidentiality for peers, which is important in peer-to-peer network are equally privileged: countries where ISP’s are allowed to ban peers all nodes both consume and supply resources. suspected of illegal file sharing. Furthermore, This contrasts with the client-server model, BitTorrent is a favorite target of ISPs for throt- where a central authority is needed to coor- tling mechanisms1, and PE makes BitTorrent dinate between clients. As of 2015, AT&T es- traffic harder to detect and throttle. Protocol timates that BitTorrent makes up 20% of all Encryption also provides defense against man- broadband traffic2. in-the-middle attacks, preventing third-parties To download a file from a BitTorrent net- from spying on plaintext data being sent over work, a peer user must obtain the correspond- the protocol. ing .torrent file or magnet URI to discover Section II and III give context as to what peers who currently possess the file. The user problem we are solving and what the threat then reaches out to each seeding peer and initi- model looks like. Section IV details the ates the BitTorrent protocol to download por- PE/MSE handshake protocol, and Sections V tions of the file from each seeder. Once the and VI discuss the protocol and our discover- user has downloaded the file, they are then ies while researching and implementing this also seeders of the file and other peers can protocol for WebTorrent. download the file from them.

1TorrentFreak, Comcast Throttles BitTorrent Traffic, Seed- 2AT&T, AT&T patents system to âAŸfast-lane⢠A˘ Z´ BitTor- ing Impossible rent traffic

1 PE/MSE Encryption • May 2018 • bgu, kelvinlu ii. WebTorrent Our goal is to make BitTorrent traffic look indistinguishable from other Internet traffic so WebTorrent is an open-source torrent client that ISP’s and other eavesdroppers cannot de- written in Javascript, which works both in- tect that we are using BitTorrent. We also want browser and as a Node.js application. WebTor- to ensure that the PE/MSE handshake itself is rent implements the BitTorrent protocol as well secure from detection by eavesdroppers and as a number of features that are interesting in attackers that use MITM attacks. the context of usability and security. It is important to note that PE/MSE is not When run in browser, the WebTorrent client meant to provide security against an untrust- uses a modified version of the BitTorrent proto- worthy peer. The original BitTorrent protocol col and WebRTC, which encrypts data streams. ensures that seeders cannot send a different The WebRTC protocol is important as the in- file than what was originally asked for without browser client does not support TCP and in- downloaders noticing, and PE/MSE is meant stead relies on WebRTC for transport. Our fo- to add an additional layer of security above cus is on the Node.js server implementation of BitTorrent without compromising any of its WebTorrent that uses TCP, as the browser client features. is incompatible with most BitTorrent clients and is already provided encryption (both a result of using WebRTC). IV. PE/MSE Protocol The current server implementation of i. Cryptographic Handshake Protocol WebTorrent does not provide PE/MSE, which is an issue for servers communicating with The BitTorrent protocol begins with a Diffie- peers with restrictive ISP’s. The lack of encryp- Helman key exchange and encrypts using a tion is also an issue for users with particularly RC4 keystream cipher. Suppose that Client A is strict firewalls. a BitTorrent client that is seeking to download a file, and suppose that Client B is a BitTor- rent client that is seeding the same file. When III. Threat Model Client A initiates a connection with Client B, the handshake proceeds in five blocking steps. The threat model which Protocol Encryption In the first two steps, the two clients exchange addresses is one in which attackers may read Diffie-Helman Public Keys in order to negoti- the data streams between peers, in order to ate a shared secret. In the next two steps, the possibly: two clients verify the shared secret and shared torrent info hash, and negotiate a shared en- • Passively eavesdrop, with the goal of pro- cryption method (usually RC4 cipher). These tocol or content identification. steps are described in more detail below.3 • Actively execute MITM attacks. 1. Client A sends their Diffie-Helman Public X . Key using Ya = G a (mod P). G and P An example of an attacker which may read are known constants. Client A then sends the data streams (i.e. TCP transports) between a random-length padding PadA between 0 peers is an Internet Service Provider, which and 512 bytes. may do so with the goal of identifying and 2. Client B sends their Diffie-Helman Pub- throttling BitTorrent traffic. Many ISPs are lic Key Y , along with a random-length easily able to identify unencrypted BitTorrent b padding PadB. By this point, Client A and traffic simply by reading the plaintext hand- Client B both can calculate a shared secret shake sent between clients; the unencrypted S = YXb (mod P) = YXa (mod P). handshake always begins with \19Bittorrent a b Protocol. 3Specification taken from Vuze Wiki

2 PE/MSE Encryption • May 2018 • bgu, kelvinlu

Figure 1: The PE/MSE handshake. Pluses are concatenations and quotations indicate string literals.

3. Client A sends over three to four items in 5. From here on out, Client A and Client B concatenation: communicate with the encryption method chosen by Client B (ENCRYPT2). This is • A SHA-1 hash of the string ’req1’ usually continuing the RC4 cipher, though concatenated with the Secret S. This some clients may opt to revert to plaintext allows Client B to resynchronize communication. their buffer after the random-length padding The stream key SKEY is the infohash of the • SKEY A SHA-1 hash of ’req2’ with torrent being requested. Client A will know xor’d with a SHA-1 hash of ’req3’ this because it is initiating the connection in with Secret S. Client B is able to iden- order to download a torrent with that infohash. tify which infohash Client A is re- In the current implementation of WebTorrent, questing with this, and initialize its a client may seed multiple files, so the seeding RC4 keystream. Client B will be able to determine which file • An encrypted concatenation of: a pro- Client A is requesting based on the hash of the VC tocol verification constant ( ), a list stream key. See Figure 1 for a summary of the of encryption methods Client B may handshake. select from (crypto_provide, meth- ods currently supported are plaintext and RC4 encryption), and a pad PadC ii. Handshake Security and its length (between 0 and 512 Here, we explain the security features provided bytes). by the components of the cryptographic hand- • (Optional) Client A may choose to be- shake. gin and encrypt the regular bittorrent protocol (IA) To ensure synchroniza- In the first two steps, each client sends a se- tion, Client A always sends the length quence of between 96 and 508 bytes that are in- of IA (0 if not sent) distinguishable from a random sequence. The purpose of concatenating PadA and PadB to the 4. Client B sends an encrypted concatenation ends of the respective clients’ DH public keys of: the same verification constant VC, an en- is to obfuscate the fact that both clients are cryption method crypto_select selected engaging in the MSE protocol; passive eaves- from the list of methods crypto_provide droppers would be able to more easily identify provided by Client A, and a pad padD and the protocol if a fixed length header was used its length (between 0 and 512 bytes). This instead. These two steps enable the clients to ends the handshake. establish a shared Diffie-Helman secret S.

3 PE/MSE Encryption • May 2018 • bgu, kelvinlu

The information sent by Client A in the third V. System Evaluation step allows Client B to identify the appropriate torrent (via the obfuscated hash of the stream We implemented PE for WebTorrent according key), in the case where Client B is seeding to the above specification. Through our test- multiple torrents. The encrypted verification ing, we found that WebTorrent clients with our constant allows Client B to verify that Client implementation are able to communicate with A agrees on the shared secret and stream key, each other, and also with other major torrent and crypto_provide provides Client B with a clients implementing PE (such as µTorrent). list of encryption methods to use. Currently, all As stated before, the goal of PE/MSE is to known implementations provide both plaintext provide fast encryption and make BitTorrent and RC4 encryption as options; in the future, traffic more difficult to detect4. However, in the perhaps more will be provided. Finally, PadC years since the PE/MSE protocol was originally may be used for future extensions to the MSE designed, further work has demonstrated key protocol. weaknesses and vulnerabilities. We evaluate how well PE/MSE is able to meet its goals The information sent by Client B in the given the current state of knowledge. fourth step includes the same verification con- stant, a selected encryption method, and a pad PadD. The verification constant allows Client i. Protocol Detectability A to verify that the two clients agree on shared secret and stream key; the selected encryption The main goal of PE/MSE encryption is to method completes the encryption method ne- make BitTorrent traffic undetectable to eaves- gotiation process; and PadD may be used in droppers such as ISP’s. ISP’s generally detect the future for extensions. BitTorrent traffic either by looking for the hand- shake protocol and looking for traffic shape (i.e. It is also of note that, because RC4 encryp- looking at the lengths of packets sent). tion uses a keystream, communication of the In terms of traffic shape detection, the encrypted verification constant helps to protect PE/MSE handshake hides itself very well. against MITM replay attacks. Each message is sent with a random-length padding whose length is either not sent or hid- den in an encryption. It is generally difficult to identify the PE/MSE handshake alone. How- iii. Fallback ever, ISP’s are still able to identify BitTorrent traffic using the shape of the rest of the Bit- Because many clients will not support Torrent protocol, which often involves large PE/MSE, clients must be prepared to "fallback" transfers of data in one direction. to the original unencrypted protocol. Deter- Though the encryption methods used (RC4 mining whether or not a peer implements pro- cipher, SHA-1) have been proven to be inse- tocol encryption can be done with little over- cure, in practice the protocol is still fairly effec- head: tive against passive eavesdroppers. In theory, Seeders who receive requests can check with enough computational power, an active the first several characters of the first mes- attacker certainly could exploit the vulnerabil- sage. The unencrypted protocol always begins ities in RC4 (Fluhrer attack) and SHA-1 (the with the ASCII encoded string \19BitTorrent SHAppening) for protocol/content identifica- Protocol. tion or MITM attacks. However, seeding ses- sions are generally not long enough for such Initiators who send requests can try to send attacks to occur, and thus Protocol Encryp- the beginning of the encryption handshake, and get rejected. Afterwards, they will know 4SourceForge, Identifying the Message Stream Encryption to send only unencrypted messages. (MSE) protocol

4 PE/MSE Encryption • May 2018 • bgu, kelvinlu tion still provides a reasonable level of security pull request is still currently under review by against passive eavesdroppers that are not ac- WebTorrent contributors. tively attempting to decode messages. Addi- We would like to acknowledge Feross tionally, the protocol takes basic precautions Aboukhadijeh, the creator of WebTorrent, for to mitigate the risks posed by these insecuri- suggesting this project to us, for providing us ties: for example, the RC4 cipher discards the with resources and guidance on BitTorrent and first 1024 bytes of the keystream to avoid the WebTorrent, and for reviewing our implemen- Fluhrer attack. tation. Overall, PE/MSE provides a very weak level of protection from detectability. It is generally References used against small ISP’s and other passive lis- teners who do not have the expensive resources [1] At&t patents system to ’fast-lane’ bittorrent to monitor traffic in detail. traffic, Aug 2015.

[2] Azureus, Message stream encryption, Jan ii. Performance 2006.

The PE/MSE protocol handshake only needs to [3] Ernesto, Encrypting bittorrent to take out traf- be initiated once per session between seeder, as fic shapers, Dec 2015. many times as the regular handshake is used. The methods used in the handshake (SHA-1, D- [4] SourceForge, Identifying the message stream H key exchange) are all relatively lightweight encryption (mse) protocol, Jul 2009. and add little overhead to the protocol. RC4 itself is also a fairly lightweight cipher algo- rithm, and so even full protocol encryption is not a large overhead for BitTorrent. In practice, we found that the cryptographic handshake added no significant overhead to the time it took to download a file.

VI. Conclusion

Overall, the Protocol Encryption and Message Stream Encryption protocols are fairly weak encryption methods. However,they follow a paradigm of opportunistic encryption and as a result they are fast and provide a first line of defense against ISP detection and throttling. This will be immensely helpful for WebTor- rent users who live in areas with non-standard ISP’s and in areas with high risk of MITM at- tacks/eavesdroppers. We hope that our contri- bution to the WebTorrent client will be helpful for BitTorrent servers and its torrents. As of 5/11/2018, our implementation is available online in two Github pull requests (here and here) to the open source WebTor- rent repository. Because this is a fairly signif- icant change to protocol implementation, the

5