One document matched: draft-mcgrew-tls-proxy-server-00.txt
Internet Engineering Task Force D. McGrew
Internet-Draft P. Gladstone
Intended status: Informational Cisco Systems
Expires: January 5, 2012 July 4, 2011
TLS Proxy Server Extension
draft-mcgrew-tls-proxy-server-00
Abstract
Transport Layer Security (TLS) is commonly used to protect HTTP and
other protocols. HTTP is often proxied, for instance, to allow an
application-layer firewall to inspect the HTTP traffic between the
client and the server. A TLS session cannot protect traffic between
the client and server when an HTTP proxy is present. Separate TLS
sessions can be run between the client and the proxy, on one side,
and the proxy and the server on the other side. This provides the
needed security, as long as the client, server, and proxy device use
appropriate and consistent security policies. However, this last
part is problematic; how can a proxy know if a client trusts a
server? At present, TLS provides no mechanism to coordinate
policies.
This note defines a TLS extension that allows a TLS proxy to provide
a TLS client with all of information about the TLS server that the
client needs to make a well-informed access control decision.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
McGrew & Gladstone Expires January 5, 2012 [Page 1]
Internet-Draft TLS Proxy Server July 2011
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ProxyInfoExtension . . . . . . . . . . . . . . . . . . . . 8
3.2. ProxyInfoExtension . . . . . . . . . . . . . . . . . . . . 9
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
McGrew & Gladstone Expires January 5, 2012 [Page 2]
Internet-Draft TLS Proxy Server July 2011
1. Introduction
Transport Layer Security (TLS) RFC 5246 [RFC5246] is commonly used to
protect HTTP [RFC2616] as described in [RFC2818]. In many scenarios
an HTTP proxy is used, for instance, to allow caching, to provide
anonymity to a client, or to provide security by using an
application-layer firewall to inspect the HTTP traffic on behalf of
the client. A TLS session cannot protect traffic between the client
and server when a proxy is present. It is possible to have separate
TLS sessions between the client and the proxy, on one side, and the
proxy and the server on the other side, as show in Figure 1 . This
technique provides the appropriate cryptographic security (see below
for a discussion of why some other alternatives are less attractive).
But there is a problem: the presence of the proxy removes the
client's knowledge about the server. Without this knowledge, the
client has no way to decide what trust, if any, it should have in the
server. This is most problematic when the client trusts multiple
different servers for different applications, or trusts servers from
different domains.
Client Proxy Server
TLS Session #1 TLS Session #2
<------------> <------------->
HTTP
<----------------------------------->
A proxied HTTPS session, with two independent TLS sessions.
Figure 1
A further issue is that the client cannot determine the security
level of the TLS session between the proxy and the server. For
instance, a client can negotiate a high security ciphersuite between
itself and the proxy, but it will have no way of knowing what
ciphersuite is in use between the client and the server, which could
be using the obsolete 56-bit Data Encryption Standard (DES) cipher.
Another point of difficulty is the fact that there can be multiple
proxies on a particular path. To solve the security issues
introduced by TLS proxies in a way that is generally applicable, it
is necessary to accommodate scenarios involving multiple proxies.
We propose a solution in this note, by describing a TLS extension
that can be used by a proxy to provide information to a TLS client
about the TLS server. When this extension is used, the client is
well informed about the proxy as well as the server, and can make a
McGrew & Gladstone Expires January 5, 2012 [Page 3]
Internet-Draft TLS Proxy Server July 2011
knowledgeable access control decision about the server, using the
same processes that it uses when the proxy is not present. The data
in the extension are signed by the proxy in order to bind the
information about the server to a particular session between the
client and the proxy. When there are multiple proxies, the client is
informed about all of them. This extension also works for DTLS.
A separate issue is the provisioning of the proxy with information
about what servers (or rather, which certificates) should be trusted.
If the laptop has installed certificates that are specific to its
organization or to a particular domain, how can the proxy know to
trust these certificates on behalf of the laptop?
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Motivation
The following motivating example describes a typical situation with a
TLS proxy, as in Figure 1. A laptop trusts the server A for a
particular banking application, and trusts server B for a social
media application, and can authenticate both servers by using
standard PKIX certificate checking [RFC5280] and locally stored root
certificates. Or rather, the client trusts a set of root
certificates, and uses them to authenticate the TLS servers that it
connects with. The laptop also trusts the proxy, and has a
certificate by which it can authenticate the proxy. When making a
connection directly with B, the laptop can authenticate the server as
being trusted (that is, the server's public key appears in a
certificate that has been signed by the appropriate trusted
certificate authority), and it can also check the authorizations of
that server (that is, B is authorized to provide the social media
service, but not any other services such as banking). If the web
traffic from the laptop goes through an HTTP proxy, then the proxy
will need to know that it should trust both A and B to act as TLS
servers. Assuming that it does have this knowledge, it will proxy
TLS connections from both A and B. However, when the client attempts
to establish an HTTPS connection to A through the proxy, it has no
way of knowing what security checks the proxy has applied to the
connection between the proxy and A. The client cannot tell whether
the trusted certificate that it associates with A was used on the
connection between the proxy and A. The inability of the client to be
confident of the identity of the actual server forces the client to
trust all TLS servers indiscriminately.
McGrew & Gladstone Expires January 5, 2012 [Page 4]
Internet-Draft TLS Proxy Server July 2011
This obstacle could be overcome by pushing the client's policy (that
is, information about what servers it trusts for what applications)
onto the proxy, so that the proxy can make well-informed decisions on
behalf of the client. However, this alternative has significant
drawbacks: it requires that the proxy obtain and store a significant
amount of information about each client, and it requires the
construction of a syntax by which the client's policy can be
expressed and understood. In contrast, our solution moves the
information about the server to the client, which does not require
the communication or storage of any security policy between the
client and server.
3. Operation
In this note, a TLS proxy is a device that acts as a TLS server in
one session and acts as a TLS client in another session, and passes
all of the data from one session to the other, possibly modifying it
in the process. That is, it is a non-transparent proxy, in the terms
of [RFC2616].
TLS Session #1 TLS Session #2
Client <------------> Proxy <-------------> Server
Session #1 Session #2 Session #3
Client <---------> Proxy #1 <--------> Proxy #2 <---------> Server
A TLS session with a single proxy (top) and a TLS session with two
proxies (bottom).
Figure 2
The essential idea is as follows. When a TLS proxy is contacted by a
client, it does not respond to the client until it completes a TLS
session with the server. It then sends the client an assertion about
the server and the session, signed with the same private key that it
uses in its role as the TLS proxy server. When the client receives
this assertion, it checks the data in the assertion to determine
whether or not it trusts the server. The assertion is carried in a
ProxyInfoExtension, which is defined below.
This extension carries all of the information that is available to a
TLS client about a TLS server; thus the client can use existing
authorization checking processes. The client will need to verify the
hostname and/or address, and check to see if the certificate has been
revoked. The client authenticates the proxy server as usual during
the TLS session. This ensures that the client trusts the proxy, and
McGrew & Gladstone Expires January 5, 2012 [Page 5]
Internet-Draft TLS Proxy Server July 2011
because of the signature on the assertion, it should trust the server
certificate carried in the assertion. The proxy need not perform any
checking on the server certificate, because this check is done by the
client. Of course, by completing a TLS exchange with the server, the
proxy verifies that the server holds the private key associated with
that certificate.
It is required that proxies which implement this extension and
support TLS Session Resumption handle TLS Session Resumptions (from
the client) by requiring TLS Session Resumption with the server. In
particular, a TLS session that is resumed with a client SHOULD
correspond to the proxy successfully resuming the TLS session with
the same server. When a client resumes a session with a proxy, the
proxy SHOULD attempt to resume the corresponding session with the
server.
Because there may be more than one proxy in any path, the TLS
extension carries a list of assertions.
On receiving a ClientHello from the client, the proxy:
1. Checks for a ProxyInfoExtension in the ClientHello; if there is
no such extension, then the following steps cannot be performed
and are omitted,
2. Establishes a TLS session with the server (session #2 in
Figure 1); a ProxyInfoExtension is included in that session,
3. Constructs a ProxyInfo structure by populating it with
information about the server and the current session with that
server; if the sever sends back a ProxyInfoExtension, then the
ProxyInfo structure is included as the next_proxy_info,
4. Signs the ProxyInfo structure with the public key corresponding
to the server certificate it uses in session #1,
5. Completes the session with the client (session #1 in Figure 1)
and provides the ProxyInfoExtension in that session,
The proxy MAY
Perform revocation checking on the certificate chain of the server
in session #2, and indicate that it has done this in the extension
by setting performed_revocation_checking to "true".
Note that the entity acting in the role of the server in session #2
could be a proxy, but in the above it is referred to as a server
because that is the role that it performs in that TLS session.
McGrew & Gladstone Expires January 5, 2012 [Page 6]
Internet-Draft TLS Proxy Server July 2011
When TLS is used in HTTPS, the proxy MUST perform the Server Identity
checks described in Section 3.1 of [RFC2818].
The normal operation of the proxy is to accept the (extended)
ClientHello from the client and then send a ClientHello to the
server. It is recommended that the TLS Proxy support commonly
deployed TLS extensions (as defined in [RFC4366] et al). Any TLS
extensions present on the original ClientHello MUST be examined and
either ignored, processed or forwarded (possibly after modification)
to the TLS server as part of the new ClientHello.
The client:
1. Includes a ProxyInfoExtension in the ClientHello message,
2. Checks for ProxyInfoExtension in the ServerHello message; if
there is no such extension, then the TLS processing continues as
usual; otherwise,
3. Processes the ProxyInfo extension by checking the validity of the
digitally-signed struct, then performing the usual server
authentication and authorization checking on the
server_certificate_list in the ProxyInfo,
4. Checks the revocation_checking_performed flag in the ProxyInfo;
if it is "false", then the client SHOULD perform revocation
checking on the server_certificate_list,
5. Checks the ProxyInfoFlag in the next_proxy_info field; if it is
not_empty, then the client returns to step 3 and performs that
processing on the next_proxy_info.
In order to maintain backwards compatibility for existing TLS
clients, the TLS proxies MUST (by default) perform certificate
validation for the certificates that they receive from the server.
The use of the ProxyInfoExtension in the extended ClientHello is an
indication by the client to request the alternate processing defined
by this note. In particular, if this extension is present in the
extended ClientHello, then the TLS proxy should not use its own
private key to dynamically generate a certificate.
The proxy will relay the data between the client and peer data
connections. End-to-end flow control is maintained by the relay
process: if the relay process is no longer able to write data to the
destination of the relayed data, the relay process stops reading data
from the source.
McGrew & Gladstone Expires January 5, 2012 [Page 7]
Internet-Draft TLS Proxy Server July 2011
3.1. ProxyInfoExtension
The syntax of the ProxyInfo extension is as follows
struct {
PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 enc_key_length;
uint8 block_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm;
uint8 mac_length;
uint8 mac_key_length;
CompressionMethod compression_algorithm;
} ConnectionSecurityParameters;
enum { empty, not_empty } ProxyInfoFlag;
struct {
select (ProxyInfoFlag) {
case empty:
/* zero length body */
case not_empty:
digitally-signed struct {
ConnectionSecurityParameters connection_parameters;
ASN.1Cert server_certificate_list<0..2^8-1>;
Boolean revocation_checking_performed;
ProxyInfo next_proxy_info;
} SignedProxyInfo;
}
} ProxyInfo;
struct {
ProxyInfo proxy_info;
} ProxyInfoExtension;
In this extension, .
The ProxyInfo structure is defined recursively, so that the signature
of each proxy authenticates the information provided by the proxies
that follow it on the path. The ProxyInfo contains the
ProxyInfoFlag, which indicates whether or not the ProxyInfo is empty
(in which case it contains no other fields) or not (in which case it
contains a SignedProxyInfo structure). The SignedProxyInfo structure
is signed with the public key that the proxy uses in its role as the
TLS server (in session #1). That structure contains the
McGrew & Gladstone Expires January 5, 2012 [Page 8]
Internet-Draft TLS Proxy Server July 2011
connection_parameters that describe the security of session #2, and
the certificate chain of the server from session #2 in the
server_certificate_list. If the proxy has performed revocation
checking on that certificate chain, it indicates this by setting the
Boolean revocation_checking_performed. If the server in session #2
was actually a proxy itself, and it provides a ProxyInfo struct, then
that struct is included in the next_proxy_info field. Otherwise, the
next_proxy_info field contains an empty ProxyInfo.
enum {
/* ... */
proxy_info(TBD1), (65535)
} ExtensionType;
3.2. ProxyInfoExtension
4. Discussion
The ProxyInfo extension could contain information about the checking
that the proxy performed on the server and its certificate. For
example, if the DNS name of the server matched the subjectAltName,
this fact could be indicated. It may be desirable to enumerate the
ways in which the server can match its certificate, to allow the
proxy to indicate to the client which of those ways was positive for
a particular server.
A potential issue with the ProxyInfo extension is that it can be
large, because the certificate chains that it carries can be large.
Roughly speaking, the amount of certificate data presented to the
client is proportional to the number of proxies on the path. It is
undesirable to require that so much data be sent, but on the other
hand, the client does need all of the data in order to make a well-
informed access control decision. It appears that the data is the
minimum required, in the sense that removing any of the data would
make it impossible for the client to assess the security of the
entire path.
The proxy is required to do the authentication checking on the
signatures created by the server, but not the authorization checking
or revocation checking. The responsibility for authorization
checking is not put onto the proxy because it does not know the
security policy of the client; in particular, the proxy does not know
which servers the client trusts for which applications. The
responsibility for revocation checking is not put onto the proxy
because that process is better left to the client. The client can
perform revocation checking on all of the certificate lists for all
McGrew & Gladstone Expires January 5, 2012 [Page 9]
Internet-Draft TLS Proxy Server July 2011
of the proxies and the server in parallel, whereas if each proxy
performed the revocation checking, those processes would necessarily
be serial. Since revocation checking can take a significant amount
of time, the serial approach could add a significant amount of
latency to the TLS session, and potentially trigger retransmissions.
The parallel approach not only reduces the overall latency, but it
moves it outside of the client's retransmission timer for the
ClientHello message.
The ProxyInfo extension could convey the IP address of the server, or
other network layer information such as the DNS name. However, it is
not clear that this information is needed, so it was not included.
The ProxyInfo extension only provides information about proxies to
the client; it does not provide any information to the server about
either the client or other proxies on the path. This is acceptable
when there are no client certificates in use, which is (regrettably)
common in practice. It would be possible to generalize the ideas in
this note to also provide information to the server about the client
and other proxies on the path. Nonetheless, that goal is out of
scope for this note.
5. IANA Considerations
This document requests IANA to update its registry of TLS extension
types to assign an entry, referred herein as proxy_info, with the
number TBD1.
6. Security Considerations
In a situation with a proxy and a cryptographic protocol, the
appropriate security goals are to
preserve the security of the cryptographic protocol,
make the client aware of the proxy, able to authenticate the
proxy, and able to check that the device acting as a proxy is
authorized to act in that role,
allow the client to make access control decisions that are as
well-informed as when the proxy is not present.
The idea in this note meets these goals.
We briefly describe some alternative approaches that do not meet
these security goals. First, we consider the proliferation of
McGrew & Gladstone Expires January 5, 2012 [Page 10]
Internet-Draft TLS Proxy Server July 2011
private keys. In order to allow one device to act as a proxy for a
server, the private key of the server could be shared with the proxy.
This practice may be workable when there is a one-to-one
correspondence between proxies and servers, but it substantially
increases the security risk. If a proxy contains multiple private
keys, it becomes an attractive target for an attacker. Second, we
consider the session-key proliferation approach in which there is
only a single TLS session, negotiated between the client and server,
and the proxy participates in the session because either the client
or the server has passed the secret session keys to the proxy (using
some secure channel). If the proxy is completely passive, and it
only decrypts traffic from the TLS session and never modifies the
data in that session, then this method can be secure. However, if
the proxy rewrites the data inside the session, or originates
messages, then the security of the TLS protocol will be undermined.
Message authentication can be subverted because an attacker can
intercept a message sent by the server, and forward it on to the
client, bypassing the proxy. By interleaving messages sent by the
proxy with ones sent by the server, an attacker can potentially
confuse a client, and can certainly cause a denial of service.
Confidentiality may be undermined as well; if RC4 or AES-GCM is in
use, information about the plaintext will be leaked due to keystream
reuse. Session-key proliferation is not secure when the proxy needs
to edit the session. Most proxies do need to edit the session, and
we regard it as potentially hazardous to construct a TLS proxy along
these lines. Suppose that such a proxy were implemented because it
was anticipated that the application proxy would be read-only, but
then a future revision to the application protocol or the goals of
the application proxy made it necessary to have the proxy edit the
application session. If the session-key proliferation approach had
been used, the implementer would be in the awkward position of having
to choose between implementing a completely new approach that
preserved security, and in risking the security of the application.
With the ProxyInfo extension, there is no protection against the
proxy lying about the security characteristics of the onward
connection. However, in any proxying scenario, it is necessary to
trust the proxy, just as a client must trust the server. For
instance, any proxy (not just one using the ProxyInfo extension)
could choose to forward the plaintext from the session to untrusted
third parties, and violate the trust of the client. It is the
responsibility of the client to decide whether or not a particular
device should be trusted to act in the role of proxy. The ProxyInfo
proposal has the benefit of making the presence of the proxy obvious,
and allows the client to refuse to deal with untrusted proxies.
Many clients use password-based authentication within a TLS tunnel.
When a proxy is present, it can learn plaintext passwords, and it can
McGrew & Gladstone Expires January 5, 2012 [Page 11]
Internet-Draft TLS Proxy Server July 2011
gain the information needed to perform offline dictionary attacks
against authentication systems that use challenge-response methods.
This is a highly undesirable aspect of TLS proxying. The ProxyInfo
extension does nothing to directly help this issue. However, it does
indirectly improve the situation, because it empowers the client with
information that enables it to reject proxies and servers that it
should not trust. Since the TLS authentication (including both sever
and proxy authentication) takes place before the password-based
authentication, the client can protect itself by rejecting sessions
with inappropriate proxies, or inappropriate servers on the path
beyond the proxy.
In theory, the cryptographic proxying scenario could be considered as
multiparty security negotiation and key establishment. It may be
interesting to investigate such ideas because they can allow for more
equitable negotiation of session parameters, and additional security
properties. This note focuses on compatibility with existing
specifications and implementations, so these considerations are
beyond its scope.
7. Acknowledgements
Thanks are due to Dan Wing for suggestions and fruitful discussion.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
McGrew & Gladstone Expires January 5, 2012 [Page 12]
Internet-Draft TLS Proxy Server July 2011
8.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
Authors' Addresses
David A. McGrew
Cisco Systems
510 McCarthy Blvd.
Milpitas, CA 95035
US
Phone: (408) 525 8651
Email: mcgrew@cisco.com
URI: http://www.mindspring.com/~dmcgrew/dam.htm
Philip Gladstone
Cisco Systems
1414 Mass Ave
Boxborough, MA 01719
US
Email: pgladstone@cisco.com
McGrew & Gladstone Expires January 5, 2012 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 03:31:45 |