Selective Security for TLS Marius Portmann”’, Aruna Seneviratne’ ‘School of Electrical Engineering and Telecommunications University of New South Wales, Sydney, Australia
[email protected],
[email protected] ’Computer and Networks Laboratory Swiss Federal Institute of Technology ETH CH-8092, Zurich, Switzerland
Abstract Today’s computing environments are becoming increasingly heterogeneous, mostly due to the growth of mobile computing. In this environment, application layer proxies that can adapt and tailor the content to the client’s needs and capabilities as well as to the available network resources are highly beneficial. The problem is that content adaptation proxies are generally incompatible with the notion of end-to-end security. The only generic solution to this problem is the concept of Selective Security. The idea is to apply security selectively only to the sensitive elements of a data stream and expose the rest to any intermediary system f o r potential content adaptation. None of the current securiy protocols in use provide an API f o r ,fine-grained control f b r applying security mechanisms to a data stream. In this paper, we propose a simple extension to the Transport Layer Security Protocol (TLS), which provides the application with an interface f o r selectively protecting elements within a data stream. We also discuss a generic application scenario that shows how the proposed extended features can be used in conjunction with content adaptation proxies.
1.Introduction The number of different types of terminals with which users connect to the Internet has dramatically increased over the last few years and will continue to do so, especially with the introduction of 3G mobile systems. These terminals can have very different capabilities in terms of media presentation, processing power and other features. Furthermore, the access network with which they connect will vary greatly in reliability and bandwidth. This increasingly heterogeneous environment presents a
1531-2216/01 $10.00 0 2001 IEEE
216
challenge fix a lot of applications that require to be usable o n any type of terminal over any type of network. We believe th,at application layer proxies will play an important role in helping to overcome the problems of increased h!eterogeneity. Proxies can adapt and tailor the content and its representation to the needs of the different terminals and networks that are involved. For example, a transcoding proxy can adapt an mp3 audio stream encoded at 128kbit/s to a more suitable rate of 1 6kbit/s for a client connected with a slow modem link. One of the main problems of content adaptation proxies is the conflict with the requirement of end-to-end security [ I ] . The goal of any end-to-end security technology is to deny access to the protected data stream to any potentially untrustworthy intermediary system. Unfortunately, this also prevents content adaptation proxies from providing their service. In the example of the mp3 audio stream, the proxy would not be able to perform the transcoding if the stream was encrypted or protected with a Message Authentication Code (MAC). There is only one really generic solution to resolve or reduce the incompatibility between content adaptation proxies and true end-to-end security: Security features must be selectively applied to only the sensitive parts of a data stream, whereas the non-sensitive parts can be left unprotected and exposed to intermediary systems for potential content adaptation. W e use the term Selective Security for this approach. The decision as to what data is sensitive and what is not can only be made at the application layer, since only the application can have the required semantic knowledge. For the application to be able to control the use of security mechanisms for specific parts of a data stream, we either have to use application layer security or a lower layer security protocol that provides the application with a suitable API. Any lower layer security protocols that are transparent to the application, like IPsec [ 2 ] , can obviously not be used in
this context. Transport Layer Security (TLS)' is by far the most commonly used protocol to provide end-to-end security in today's Internet. However, its API lacks the flexibility that lets the application selectively apply security only to certain parts of a data stream. In this paper, we propose a simple extension to TLS that gives the application a finer grained control over the use of security mechanism for different parts of the data stream, allowing content adaptation proxies and end-to-end security to co-exist. The rest of the paper is structured as follows. In section 2 we discuss in more detail the problem of end-to-end security for proxy based systems and we provide some possible solutions. Section 3 introduces the simple extension to TLS that we propose to make it more compatible with content adaptation proxies. In section 4 we discuss an application scenario and the requirements for a content adaptation proxy to be used in conjunction with the proposed new features of TLS. Finally, a brief discussion and summary are given in section 5.
2. Proxy architectures and end-to-end security
receiver to provide any kind enhancement to the data stream.
of
adaptation and
2.1 Co-locatedProxies There are several solutions to this problem. The first approach is to co-locate the proxies with the end-points of the communication, typically a client and a server. Here, security mechanisms like encryption and authentication are applied at the sender, after the proxies have provided their adaptation services. This solution has obviously several drawbacks. Firstly, it drastically restricts the flexibility of placing proxies at optimal locations in the network. Secondly, it is only compatible with lower layer security protocols that are transparent to the application since the data has to leave the application unprotected for the proxy to be able to adapt it. Thirdly, as a result of the constraint just mentioned, the type of security achieved is not truly end-to-end i.e., from application to application, but from a security gateway on the premises of the sender to one at the receiver end.
2.2 Trusted Proxies
Application layer proxies can provide valuable services such as content adaptation and filtering, especially in a wireless environment with limited resources and capabilities. The general idea is to insert a proxy (or several proxies) in the data path between a client and a server to transform the data into a format that is more suitable to the client capabilities and available network resources. A lot of research has been done and is still under way in the area of application layer proxy architectures [3][4][5][6][7]. These proposals vary in several ways but what is common to all of them is the general incompatibility with true end-to-end security. This is not a shortcoming of any of these proposals but rather a fundamental problem. The purpose of security mechanisms like encryption and authentication is to prevent any intermediary entity from reading and altering the data that is sent from a sender to the intended receiver. A data stream that has been encrypted with a secure cipher looks to an intermediary system like completely random data, revealing no inherent structure. If a data stream is only authenticated, i.e. it is protected with a Message Authentication Code (MAC), an intermediary entity can read it but not make any changes without having it rejected by the receiver. The mechanisms mentioned above are very successful in thwarting malicious attacks of any intermediary entity. Unfortunately, it also prevents proxies placed in the data path between sender and
' Also known as SSL or Secure Sockets Layer 217
The second solution is to only place proxies in trusted environments (secure enclaves) within the network. Since it is assumed here that the proxies and their execution environment can be trusted, they are given the necessary secret information shared between the communicating parties. This allows the proxy to decrypt the data, perform the required adaptation service and then re-encrypt and reauthenticate it before sending it again over the public part of the network to the receiver. As in the first solution, the choice of where to place proxies is restricted, although not as severely. There is also the problem of who is in control of choosing the proxy locations and manages the level of trust that is associated with them. Of the proxy architectures listed above, only [4] explicitly supports this type of solution by putting the server in control of setting up and configuring proxies to create the data path. Finally, the security achieved in this scenario cannot be regarded as truly end-to-end since an intermediary system is allowed access to the protected data.
2.3 Selective Security The third and most generic solution to the problem ut' combining end-to-end security and content adaptation proxies is what we call Selective Security. By this, we mean that security mechanisms like encryption and authentication are selectively applied only t o sensitive parts of a data stream, whereas the non-sensitive parts can be left unprotected and exposed to intermediary systems for potential content adaptation. This is the only solution
where we have true end-to-end security combined with the possibility of content adaptation by proxies at arbitrarily chosen locations in the network. There are several ways to implement selective security. They vary in their applicability for different types of data and also the granularity with which the application of security can be controlled. Element-wise XML encryption [ 8 ] is a proposed method for selectively encrypting certain elements of a XML document. The idea is very promising and is well suited for environments that require content adaptation by proxies. The downside of element-wise XML encryption is, as the same implies, that its application is limited to XML documents. Another technique to mix secure with insecure data in the same application is one currently used by some Web sites that provide secure web applications such as web banking etc. Here, a web page consists of a mix of sensitive and non-sensitive web objects. The sensitive objects are requested via a secure TLS connection (via https://), whereas the non-sensitive ones are requested via a normal TCP connection (via http://) and are therefore amenable to adaptation by a proxy2. The problem with this method is that the level of granularity for controlling the application of security is restricted to web objects. A web object can be anything that can be requested with a HTTP GET request like a HTML document, a picture, an audio file etc. The whole object is either transferred securely or not. There is no way to selectively apply security within a data stream. TLS does not provide an API for this. In the next section, we briefly introduce TLS and then present a simple extension that gives applications this fine-grained control over the protection of data elements in a stream.
other TLS specific higher layer protocols are the TLS Change Cipher Spec Protocol and the TLS Alert Protocol. The first (consists of a single message whose purpose is to signal a change of cipher suite to be used by the Record Layer. The Alert Protocol is used to convey TLS related alerts to the peer entity. Once the Handshake protocol has successfully completed, a secure channel between the two applications has been established. All application data exchanged thereafter is equally protected by the TLS Record Layer. There is no way for selectively applying security to only elements of the data stream and so being able to blenefit from the services of content adaptation proxies3.
3.2 Selective Security for TLS To overcome the shortcoming mentioned above, we propose a small extension to the current TLS protocol. We add a new Record type to the four existing ones of the TLS Record Layer. This new Record type, Cleartext Application Data, is used to transport the non-sensitive parts of the application data stream that can be transmitted unprotected and can be adapted to the client's needs by proxies. Figure 1 illustrates how the new Record Type fits in to the TLS protocol Stack. Simply adding a new Record Type does not change any of the more complex parts of TLS like the Handshake protocol and therefore minimizes the risk of compromising its security. By providing this new Record Layer type, we effectively add a virtual cleartext channel to a TLS connection. This virtual channel is logically separate from the rest of TLS and it does not interfere with any of its standard operations as they are specified in [9].
3. Selective Security for TLS 3.1 TLS The Transport Layer Security (TLS) [9] protocol offers security features such as confidentiality, authentication and data integrity between two communicating parties, typically a client and a server. TLS is layered on top of a reliable transport protocol like TCP. It is composed of two separate layers: the TLS Record protocol and the TLS Handshake protocol. The lower of the two, the Record Protocol, provides basic security services such as privacy and data integrity to higher layer protocols. One such higher layer protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before any application data is transmitted. The two
' In such a case, the browser usually notifies the user about this and asks if only the secure objects should be displayed.
218
Figure 1: TLS Protocol Stack with new Record type Cleartext Application Data
~~~~
Theoretically, it would be possible to turn security on and off within a data stream by using the Change Cipher Spec Protocol. However, this would involve a new handshake process with several messages being sent between the client and the server for every change. This makes it far to costly and impractical for this purpose.
3.3 API The main change that our extension requires is to the
API, to make this new virtual channel accessible to the applications. Since TLS only specifies the protocol and not an API, the required changes to the TLS specification are therefore minimal. By not having a standardized APT, the main part of the modifications necessary for our extension is implementation dependent. All implementations of TLS somehow hide the complexity of its inner workings from the application programmer with a layer of abstraction. Some implementations have the notion of a TLS socket, similar to a TCP socket, using a well-known interface. Our discussion will be based on TLS sockets since it is a familiar and simple concept. However, it would be easy and straightforward to apply our proposed changes to any implementation of TLS that uses another kind of abstraction. When a client creates a TLS Socket connecting to a TLS Server Socket, the TLS Handshake protocol first establishes the necessary context for the all the cryptographic computations. Once the Handshake is finished, a normal bvrite() call can be used on the socket to send application data via the TLS connection. The data passed to the TLS Socket via the br*rite() call is first divided into fragments of appropriate size. Then, a Message Authentication Code (MAC) is added to the fragment and the resulting data packet is encrypted with an algorithm negotiated during the Handshake phase. Finally, a TLS Record Layer header is prepended to the encrypted data, identifying it as being of Record type Applicafion Data. This TLS record is then passed to the TCP layer to be sent to the receiver. Here, the data undergoes the same treatment, only in the reverse order. The TLS Record header is removed, the data decrypted and the MAC is verified. Now the data can be read by the application via the read() call. To accommodate the features of the new virtual cleartext channel, a new method needs to be added to the TLS API. This new method, writLJ-clear(), takes the application data to be sent as an argument and divides it into fragments. In contrast to the normal ,\.rife() call. all the cryptographic operations are bypassed and we directly add a TLS Record Layer Header of the new type Clear.trst Appliccitioti Dcrta to the packet and send it to the receiving socket (see Figure 2). The application can multiplex protected and unprotected data on the same TLS connection by using thc two method calls accordingly. The implemcntation of TLS is rcsponsiblc o f maintaining the order of the data as it is sent by the application and thereby maintaining thc notion o l a strcam. When thc rccciving application rcads the data. i t must be able to determine if it was scnt securely or via the clcartcxt channel, to be able to trcat i t accordingly. For this, we add the new method t . ~ ~ ~ i ~ / - . ~ ~This , / f , ~ method t().
219
passes back a parameter to the application informing it if the received data was sent securely or not. With just these two added methods, application programmers can take advantage of the proposed extended features of TLS. The sending application can selectively protect sensitive parts of a data stream and expose the rest to intermediate systems and the receiving application can demultiplex data sent over the secure and insecure virtual channels of a TLS connection. Data sent via wire()
Data sent via wrire_c/ear()
Application Data
.’
J
.’
I
I
Fragment
Add MAC I
I
I
Figure 2: TLS Record Protocol Operation for application data sent via the methods wire() and write- clear()
4. Application Scenario T o use the proposed new features of selective security for TLS in an application scenario with content adaptation proxies. several requiremcnts have to be met. Firstly, the client and the server application have to support the enhanced version of TLS and use its extended API. In a case where only one o f the two participants in a TLS session supports the new features, the enhanced TLS implementation can detect this during the handshake and fall buck to conventional TLS behavior. where all application data is protected, thereby ensuring backwards compatibility. Secondly. a proxy that wants to provide content adaptation services for a TLS session has to understand the syntax of the TLS Record layer to be able t o separate the protected TLS records from the clcartcxt ones that are amenable to adaptation. Figure 3 shows the structure of such a proxy, providing content adaptation services for a connection protected with the proposed extended version of TLS. If adaptation is to be provided lor upstream and downstream traffic. this structure must he replicated for both directions of data tlow.
capabilities and resources like a PDA or mobile phone, requesting a document from a Web server over a secured TLS connection. The requested document which could be of a format like HTML, PDF, mp3 etc. might contain only very little sensitive information and the rest does not require any cryptographic protection. The server application then replies to the client’s request by sending the sensitive elements via the secure TLS channel and the non-sensitive elements via the virtual cleartext channel, using the extended TLS API. A content adaptation proxy on the data path is able to adapt the most part of the document to the limited capabilities of the client, using a structure discussed above, while the sensitive data remains protected.
Dispatcher
Figure 3: Structure of a Content Adaptation Proxy used in Conjunction with Selective Security fur TLS
This proxy reads the TLS records from the input socket and decides where to forward them based on the type of the TLS record header field. If the record is of any of the conventional types like Change-cipher-spec, Alert, Handshake or Application-data, it is forwarded directly to the proxy’s output queue. These types of records are either part of internal TLS signaling or protected application data that are therefore not amenable to the proxy’s services. However, if the records are of the new type Cleartext Application Data, they are forwarded to the adaptation engine within the proxy. This engine extracts the application data from the TLS records and applies the required transformation or filtering operations. The exact type of adaptation depends on the application at hand and the requirements of the client and network environment. The resulting data stream is then again repackaged in TLS records of the same type and subsequently forwarded to the proxy’s output queue. The adaptation will most probably result in a decrease or increase of data size with the possible effect of removal of entire records or insertion of additional ones. This is not a problem as long as the semantic correctness of the data stream is preserved. Additionally, the proxy has to guarantee the correct sequencing of the data in order to retain the notion of a stream. This can be done with the help of internal sequence numbers for the TLS Records within the proxy. The numbers are assigned when the Records enter the proxy. In the adaptation engine, where new Records can be created or existing ones deleted, the sequence numbers have to be updated accordingly. A dispatcher at the proxy’s output queue is responsible for multiplexing the two streams of TLS records back onto the one TLS connection while maintaining the correct order by using these sequence numbers. Our proposed extension to TLS is valuable for any kind of application that wants to partially and selectively protect elements of a data stream. A possible example could be a Web client on a terminal with restricted
220
5. Discussion We have presented a simple extension to the TLS protocol that allows applications to selectively protect data within a stream. The main advantage of this lies in the fact th,it it allows end-to-end security to co-exist with content adaptation proxies. This will become more important as we will see an increased heterogeneity of client devices that connect to the Internet. A further benefit from using Selective Security for TLS is that we save CPU cycles by applying the costly cryptographic computations only to the data that requires it. Again, this is especially important for wireless devices with limited resources. These tienefits do not come without a cost attached to them. First of all, the increased flexibility of the extended API also means increased complexity that the application programmtx has to deal with. It also means a higher risk of making mistakes, which could potentially compromise the security of the application. One of the main difficulties is for the sender to have the semantic knowledge of what parts of the data stream are sensitive and which ones are not. In general, this can be a hard problem but in cases where a document is created on the fly by a server application (cgi-script, servlets) this information can easily be made available. On the receiver side, the application has to treat the data elements received over the two different virtual channels accordingly. The data received from the cleartext channel cannot be trusted to be authentic or secret in any way. There are a few problems and added complexity in our approach to combine end-to-end security with the services of contenl. adaptation proxies but we believe it is worthwhile considered the benefits gained, especially in a highly heterogeneous environment.
References M. Portmann, “The Problem of End-to-end Security for Proxy based Systems”, in Proc. o f Protocols for Multimedia Systems, PROMS 2000, Poland), Oct. 2000.
(Cracow,
Kent, S. and R. Atkinson, ‘‘Security Architecture for the Internet Protocol”, RFC 2401, November 1998 A. Fox, S. D. Gribble, Y. Chawathe and E . A. Brewer, “Adapting to network and client variation using active proxies: Lessons and perspectives”, IEEE Personal Communications, Aug. 1998. P. Gunningberg and A. Seneviratne, “Services and architectures in the next generation internet using dynamic proxies”, in FTF99, (Bejing, China), Dec. 1999. M. Fry and A. Gosh, “Application level active networking”, Computer Networks, vol. 7, pp. 655-667, 1999.
Wei-Ying Ma, Ilja Bedner, Grace Chang, Allan Kuchinsky and Hong Jiang Zhang. “Aframework for adaptive content delivery in heterogeneous network environments”, Hewlett-Packard Laboratories, 2000: http://www.cooltown. hp.com/papers/adcon/MMCN20 OO.htm Mark Yaris, An-I A. Wang, Alexey Rudenko, Peter Reiher and Gerald J . Popek. “Conductor: Distributed adaptation for complex networks”, Technical Report CSD-TR-990042, UCLA, August 1999. H. Maruyama and T. Imamura. “Element-wiseXML Encryption”, April 2000. http://lists. w3.org/Archives/Public/xmlencryption/2000Apr/att-OOOS/ 01-xmlenc
Dierks, T. and C. Allen, “The TLS Protocol”, RFC 2246, January 1999.
22 1
