TLS Proxy Server Extension
draft-mcgrew-tls-proxy-server-00
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Authors | Philip Gladstone , David McGrew | ||
| Last updated | 2011-07-04 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)