Network traffic encryption is becoming a requirement, not an option. Enabling

encryption will be a communal effort so a solution that gives partial benefits until

fully deployed is needed. A solution that requires little changes to existing

infrastructure will also help as it can be quickly deployed to give immediate shortterm

benefits. We argue that tcpcrypt, a TCP option for opportunistic encryption

is the path of least-resistance for a solution against large-scale traffic encryption.

Tcpcrypt requires no changes to applications, is compatible with existing networks

(works with NATs), and just works by default. It is high performance, so it can be

deployed on servers without much concern. tcpcrypt attempts to maximize security

for any given setting. By default, it will protect against passive eavesdropping,

and also allows detecting large scale interception. With authentication, tcpcrypt

can provide full security against active attackers and so it is a complete solution

both for the short-term and long-term

Bittau, A

Boneh, D

Hamburg, M

Handley, MJ

Mazieres, D

Network traffic encryption is becoming a requirement, not an option. Enabling encryption will be a communal effort so a solution that gives partial benefits un-til fully deployed is needed. A solution that requires little changes to existing infrastructure will also help as it can be quickly deployed to give immediate short-term benefits. We argue that tcpcrypt, a TCP option for opportunistic encryption is the path of least-resistance for a solution against large-scale traffic encryption. Tcpcrypt requires no changes to applications, is compatible with existing networks (works with NATs), and just works by default. It is high performance, so it can be deployed on servers without much concern. tcpcrypt attempts to maximize secu-rity for any given setting. By default, it will protect against passive eavesdropping, and also allows detecting large scale interception. With authentication, tcpcrypt can provide full security against active attackers and so it is a complete solution both for the short-term and long-term

Andrea Bittau

Michael Hamburg

Mark Handley

David Mazieres

Dan Boneh

CiteSeerX

Simple Opportunistic Encryption

UCL Discovery

Simple Opportunistic EncryptionAndrea Bittau Michael Hamburg Mark HandleyDavid Mazie`res Dan BonehJanuary 15, 2014AbstractNetwork traffic encryption is becoming a requirement, not an option. Enablingencryption will be a communal effort so a solution that gives partial benefits un-til fully deployed is needed. A solution that requires little changes to existinginfrastructure will also help as it can be quickly deployed to give immediate short-term benefits. We argue that tcpcrypt, a TCP option for opportunistic encryptionis the path of least-resistance for a solution against large-scale traffic encryption.Tcpcrypt requires no changes to applications, is compatible with existing networks(works with NATs), and just works by default. It is high performance, so it can bedeployed on servers without much concern. tcpcrypt attempts to maximize secu-rity for any given setting. By default, it will protect against passive eavesdropping,and also allows detecting large scale interception. With authentication, tcpcryptcan provide full security against active attackers and so it is a complete solutionboth for the short-term and long-term.1 IntroductionCases of large-scale network interception are being uncovered [4] making the publicconcerned about data privacy. Unfortunately the Internet is clear-text by default (TCP)and only special traffic is encrypted (e.g., with TLS [7]). This is due for reversal, andall traffic will be encrypted by default in future.The first question in finding a solution is: what is the minimum change we needtoday to enable network encryption? Tackling the problem at the network layer, wecould enable IPSec [6] globally, but that comes at the cost of incompatibilities withNATs. Alternatively, we could tackle the problem at the application layer and use TLSin all our applications, though we’d be force to rewrite them. Clearly the choice of layeris important, and a promising new approach might be at the transport layer, which iscompatible with NATs and requires no application changes.The second question is: what is the best security that can be offered in any givensetting? When incrementally deploying a security solution, if the remote end does notyet support it, no security at all may be possible. When browsing a public web site thatdoes not require authentication, protection against passive eavesdropping is possiblewith an anonymous key exchange. When checking e-mail, mutual authentication is1possible using a weak-password and PAKE [3]. The level of security, and more pre-cisely authentication choice, depends on the particular application. This suggests thatauthentication should be left to the application, while privacy and encryption can beimplemented at a lower layer as they are generic, application agnostic, concepts.Based on the above observations, the choice of which layer is responsible for whichaspect of security is critical. In the next sections we discuss in more depth the benefitsof each layer. We then discuss tcpcrypt [2], a TCP option for opportunistic encryptionthat can be used to stop large-scale monitoring.2 Privacy and Integrity at the transport layerPrivacy and integrity are generic concepts that applications want and do not necessarilycare how they are done. This allows for their implementation at lower levels. Thebenefits of performing them at the transport layer are:• No changes to applications. This would be difficult at application layer.• Compatible with NATs. This would be difficult at IP layer.• Can piggyback on the existing 3-way TCP handshake for negotiation. This al-lows for low latency connections because packets in addition to the the 3-wayhandshake may not be needed. Being able to signal encryption in the SYN givesan opportunity to gracefully fall back to vanilla TCP if encryption is not sup-ported. All of these aspects cannot be implemented in the application layer in abackward compatible way.• Natural granularity for authentication and security statements. E.g., “this con-nection run by this user performed this action”. As opposed to, if operating atthe network layer, “this packet sent by this user”.3 Authentication at the application layerTraditionally, network protocols dealt with all security aspects in a single layer. Forexample, TLS and IPSec both provide privacy, integrity and authentication, all in asingle layer. It may be possible to split these aspects and implement them in the layerwhere they fit most naturally. For example, we already argued that the transport layeris a convenient place to implement privacy and integrity. Authentication, instead, isinherently an application-specific concept. The application may do no authentication,or it can use any mechanism like a password, cookie, certificate or something else. Infact, today, double authentication often occurs: e.g., at the transport layer with TLSusing certificates, and at the application layer using passwords. It is possible, instead,for the application to mutually authenticate a connection using passwords only (e.g.,using PAKE), not requiring any additional, lower-level, authentication steps (e.g., us-ing certificates). We therefore argue that authentication should be implemented at theapplication layer, whereas privacy and integrity should be implemented at the transportlayer because they are generic, non-application specific, concepts.2Because encryption and authentication occur at different layers, a mechanism tolink the two is needed. In tcpcrypt, we introduce the concept of a Session ID. TheSession ID is a hash that captures the key negotiation. Each connection yields a SessionID, and if equal on both ends, no man-in-the-middle attack occurred. This mechanismalone makes it possible to detect large-scale interception after the fact, even with noauthentication. One simply logs Session IDs and compares them after the fact.It is simple for applications to integrate transport security with their existing au-thentication mechanisms. For example, when comparing passwords, the applicationcan include the Session ID in the password hash to make sure that both the connectionis secure, and that the user is who he claims to be.This design maximizes security for any given setting. With no authentication, ap-plications are by default secure against passive eavesdropping, and they can also detectman-in-the-middle attacks after the fact. With any authentication (e.g., passwords-only,certificates), one is protected against active attacks too.4 tcpcrypttcpcrypt is a TCP option for opportunistic encryption. It has the following main fea-tures:• Anonymous encryption by default.• Provides hook for application-level authentication (Session ID).• Provides mechanism to probe whether application is tcpcrypt-aware. This isuseful for authentication.• High performance: high connection rate on servers by pushing expensive crypto-graphic operations on client; low latency connection set up by piggybacking onTCP’s existing handshake. This makes it possible to turn it on by default withouttoo much thought: i.e., it will not slow down the Internet.5 Deployment strategyOne of the main design goals of tcpcrypt was to make it incrementally deployable. Thefollowing time line is how we envisioned tcpcrypt’s deployment:1. Operating systems to support tcpcrypt. During this era, most of the traffic willeither be plain-text TCP (the other end does not yet support tcpcrypt), or unau-thenticated tcpcrypt. This will let the public detect large-scale eavesdropping.It will protect against passive attackers. This shows the advantage of operatingat the transport layer: it provides a backward compatible mechanism to signalwhether the option is supported or not, and one can gracefully fall back to vanillaTCP if needed. This luxury is not present at other layers.32. Applications to support tcpcrypt. During this era, most traffic will be unau-thenticated tcpcrypt, or authenticated (if both ends of the application supporttcpcrypt). This will protect against active attackers. Again, this shows the ad-vantage of operating at the transport layer: one can signal (in the SYN) whetherthe application supports tcpcrypt, something not easily done at other layers.3. Integration with other security initiatives. Once tcpcrypt is deployed, it canbe integrated with other security initiatives like DNSSEC [1] and DANE [5]to provide some authentication by default. For example, APIs that connect tohostnames can provide server authentication by default if certificates are held inDNSSEC. This can easily be done using tcpcrypt’s Session ID, by having theserver sign it. This shows that tcpcrypt has been designed from the start as acomplete security solution, and not just a short-term, opportunistic encryptionprotocol.6 Lessonstcpcrypt is not an attempt to reinvent the wheel. All of which is achieved in tcpcryptcan probably be achieved in other layers with some more complex modifications. Thetransport layer merely looks like the simplest place to apply encryption. In particular,we found that being able to signal tcpcrypt awareness and application awareness in theSYN is critical for backward compatibility. The rest of the tcpcrypt negotiation couldin fact occur at the application layer, but why give up extra round trips, when tcpcryptcan complete within the existing 3-way handshake when session caching? Everythingseems to point to the transport layer when it comes to convenience.A new concept introduced by tcpcrypt is the session ID, needed to tie in with ap-plication layer authentication. This can be implemented by other layers, but we foundthat the transport (or connection) most closely resembles a user session, often the gran-ularity needed for authentication, and so the transport seems like a natural place forexposing authentication hooks.7 ConclusionInternet traffic will be encrypted by default. There is an urgency to meet this require-ment, so a solution that is simple to incrementally deploy is needed. This solutionshould also be complete enough so that it can be used as the sole security system onceused by applications. We believe that the path to least resistance is providing privacyand integrity by default at the transport layer. This requires no changes to applicationsand is compatible with existing networks (NATs). We built tcpcrypt to satisfy this. Ap-plications can use tcpcrypt’s Session ID in their existing authentication logic to protectagainst man-in-the-middle attacks. tcpcrypt is complete enough that it will meet short-term opportunistic encryption needs, as well as longer-term full security requirementsneeded by applications.4References[1] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. DNS Security Intro-duction and Requirements. RFC 4033 (Proposed Standard), Mar. 2005. Updatedby RFC 6014.[2] A. Bittau, M. Hamburg, M. Handley, D. Mazie`res, and D. Boneh. The case forubiquitous transport-level encryption. In Proceedings of the 19th USENIX Confer-ence on Security, USENIX Security’10, pages 26–26, Berkeley, CA, USA, 2010.USENIX Association.[3] D. Boneh and V. Shoup. A graduate course in applied cryptography. Version 0.1,from http://cryptobook.net, 2008.[4] CNN. Latest NSA leaks point finger at high-tech eavesdropping hubin UK. http://www.cnn.com/2013/12/20/world/europe/nsa-leaks-uk/.[5] P. Hoffman and J. Schlyter. The DNS-Based Authentication of Named Entities(DANE) Transport Layer Security (TLS) Protocol: TLSA. RFC 6698 (proposedstandard), IETF, 2012. http://tools.ietf.org/html/rfc6698.[6] S. Kent and R. Atkinson. Security Architecture for the Internet Protocol. RFC2401, 1998.[7] E. Rescorla. SSL and TLS: Designing and Building Secure Systems. Addison-Wesley Professional, 2000.5

http://discovery.ucl.ac.uk/1521002/7/Bintau_simple_opportunistic_encryption.pdf

Simple Opportunistic Encryption

Abstract

Similar works

Full text

Available Versions

CiteSeerX

UCL Discovery