Applying Unauthenticated Transport Layer Security (TLS) to Hypertext Transport Protocol (HTTP) Connections
Cisco Systems, Inc.
mamille2@cisco.com
apps
With the pervasiveness of passive monitoring and ubiquity of unencrypted Hypertext Transport Protocol (HTTP), it is desirable to mitigate passive monitoring without causing an undue burden on HTTP user agents and servers. This document describes the rationale and process for using Transport Layer Security (TLS) in an unauthenticated manner for exchanging HTTP messages. The application of unauthenticated TLS – particularly when Perfect Forward Secrecy (PFS) algorithms are used – change monitoring from being a passive attack into an active attack.
The exchange of information through the use of Hypertext Transport Protocol (HTTP) is widespread, with the vast majority of such traffic exchanged in the clear. As described in , passive monitoring is seen as an attack on the privacy of users and organizations. The ubiquity of unencrypted HTTP coupled with the pervasiveness of passive monitoring means that the vast majority of HTTP traffic can be (and often is) captured without the knowledge or consent of the primary parties – namely the HTTP user agent and HTTP server – and with negligible effort on the part of the passive monitor.
Therefore, it is desirable to apply apply encryption to the HTTP exchange in the form of Transport Level Security (TLS) . Traditionally, TLS has only been seen as useful if at least the server is authenticated in the handshake, and that authentication is done almost exclusively using PKIX certificates. However, using TLS in an unauthenticated manner can mitigate passive monitoring attacks by requiring the attacker to act as a man-in-the-middle, thereby increasing the effort passive monitoring requires to be effective. Forgoing TLS authentication eliminates the burden of obtaining properly issued PKIX certificates, reducing the effort it takes to deploy an encrypted HTTP server.
In this document, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in BCP 14, RFC 2119 .
This document reuses HTTP terminology from , , and . It reuses PKIX terminology from and .
When given a “http:” URI, the user agent attempts to establish a TLS connection to the indicated origin. The exact processes used to upgrade the connection to TLS is out of scope for this document; it could use the Upgrade process documented in , or attempt to connect to the server on the IANA-registered port for HTTP over TLS (HTTPS) if the requested origin uses the IANA-registered port for HTTP. During the TLS establishment, the user agent and server ignore any certificate verification errors it might encounter with regards to naming (e.g., self-signed certificate, or none of the certificate identifiers not match the input URL).
Once established, the user agent and server then exchange HTTP messages as if the connection were unencrypted. The use of HTTP basic authentication is still NOT RECOMMENDED, and user agents MUST NOT indicate in any way that the HTTP connection is protected (e.g., display a “locked” or “protected” indicator with the HTTP resource).
The benefits of unauthenticated TLS are only realized if it is less costly for an attacker to actively interject itself into the TLS session than to passively collect all traffic and later compromise the TLS handshakes. Forward secrecy prevents a passive monitor from decrypting the TLS session if it has compromised the server’s private key. Software MUST use algorithms that provide perfect forward secrecy (e.g., TLS_DHE, TLS_ECDHE, or TLS_DH_anon) when relying on unauthenticated TLS.
If the TLS connection could not be established, user agents need to determine whether to continue based on their own policies. For instance, a user agent might (among other possibilities):
prompt the user that communications with the server can be monitored and asking whether the user wishes to proceed anyway;
abandon the connection altogether, informing the user that privacy protection could not be applied to the connection; or
silently continue without any encryption. Note this can effectively lead to downgrade attacks.
A user agent SHOULD cache the success or failure to establish a TLS connection with a given origin. How much information about a successful (or failed) attempt at establishing a TLS connection is implementation and deployment specific, but needs to at least indicate if unauthenticated TLS was used.
This cached information can then used for subsequent connections. If a previous upgrade was successful, the user agent can decide to fail if a subsequent TLS establishment fails. If a previous upgrade used a specific certificate chain, the user agent can fail if a different chain is presented.
This entire document discusses security.
This document has no actions for IANA.
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
1350 Mass. Ave.
Cambridge
MA 02138
- +1 617 495 3864
sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
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.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Hypertext Transfer Protocol -- HTTP/1.1
Department of Information and Computer Science
University of California, Irvine
Irvine
CA
92697-3425
+1(949)824-1715
fielding@ics.uci.edu
World Wide Web Consortium
MIT Laboratory for Computer Science, NE43-356
545 Technology Square
Cambridge
MA
02139
+1(617)258-8682
jg@w3.org
Compaq Computer Corporation
Western Research Laboratory
250 University Avenue
Palo Alto
CA
94305
mogul@wrl.dec.com
World Wide Web Consortium
MIT Laboratory for Computer Science, NE43-356
545 Technology Square
Cambridge
MA
02139
+1(617)258-8682
frystyk@w3.org
Xerox Corporation
MIT Laboratory for Computer Science, NE43-356
3333 Coyote Hill Road
Palo Alto
CA
94034
masinter@parc.xerox.com
Microsoft Corporation
1 Microsoft Way
Redmond
WA
98052
paulle@microsoft.com
World Wide Web Consortium
MIT Laboratory for Computer Science, NE43-356
545 Technology Square
Cambridge
MA
02139
+1(617)258-8682
timbl@w3.org
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
HTTP Over TLS
This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]
Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]
Pervasive Monitoring is an Attack
Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.
Upgrading to TLS Within HTTP/1.1
This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. [STANDARDS-TRACK]
The Transport Layer Security (TLS) Protocol Version 1.2
This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]