TLS Proxy Server Extension

Document Type Expired Internet-Draft (individual)
Last updated 2013-01-17 (latest revision 2012-07-16)
Stream (None)
Intended RFC status (None)
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


Transport Layer Security (TLS) is commonly used to protect HTTP and other protocols; it provides encrypted and authenticated conversations between a client and a server. In some scenarios, two TLS sessions are used, so that a third device can participate in the protected communication. In these cases, separate TLS sessions are run between the client and the middle device, on one side, and the middle device and the server on the other side. This provides the needed security, as long as the client, server, and middle device use appropriate and consistent security policies. However, this last part is problematic; how can the middle device know if a client trusts a server? At present, TLS provides no mechanism to coordinate policies, and there is no convenient way to do so. This note defines a TLS extension that allows a TLS server to provide a TLS client with all of information about the other TLS server (or servers) that are participating in the application layer traffic that the client needs to make a well-informed access control decision. This empowers the client to reject TLS sessions that include servers that it does not trust.


David McGrew (
Dan Wing (
Philip Gladstone

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)