Caching Secure HTTP Content using Blind CachesMozillamartin.thomson@gmail.comEricssongoran.ap.eriksson@ericsson.comEricssonchrister.holmberg@ericsson.comA mechanism is described whereby a server can use client-selected shared cache.Shared caches allow an HTTP server to offload the responsibility for delivering
certain content. Content in the shared cache can be accessed efficiently by
multiple clients, saving the origin server from having to serve those requests
and ensuring that clients receive responses to cached requests more quickly.Proxy caching is the most common configuration for shared caching. A proxy
cache is either explicitly configured by a client, discovered as a result of
being automatically configured, or interposed automatically by an on-path
network entity (this latter case being called a transparent proxy).HTTPS prevents the use of proxies by creating an authenticated
end-to-end connection to the origin server or its gateway that is authenticated.
This provides a critical protection against man-in-the-middle attacks, but it
also prevents the proxy from acting as a shared cache.Thus, clients use the CONNECT pseudo-method (Section 4.3.6 of ) with any
explicitly configured proxies to create an end-to-end tunnel and will refuse to
send a query for an https URI to a proxy.This document describes a method for conditionally delegating the hosting of
secure content to the same server. This delegation allows a client to send a
request for an https resource via a proxy rather than insisting on an
end-to-end TLS connection. This enables shared caching for a limited set of
https resources, as selected by the server.The words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” are used in this document.
It’s not shouting; when they are capitalized, they have the special meaning
defined in .This document uses the term “proxy cache” to refer to a proxy that
operates an HTTP cache .The secure content delegation mechanism defined in is used to create a
separate resource that contains encrypted and integrity protected content.A client that signals a willingness to support this feature can be provided an
response with an out-of-band encoding that
identifies this resource. The client can then make a request for that content
to a proxy cache rather than directly to the origin server.In this document, the origin server is able to act in the role of the CDN in
. However, all of the considerations that apply to having a third party
host content apply to the proxy cache. Thus, integrity and confidentiality
protections against the proxy cache are the primary consideration.Without a clear signal from the client that a caching proxy is present, an
origin is unable to send a response with out-of-band encoding. A value of
out-of-band in the Accept-Encoding header field might only indicate
willingness to use the secure content delegation mechanism.The BC header field indicates that a client is connected to a proxy cache that
it is willing to use for out-of-band requests. The value of the BC header field
is a simple boolean, represented as a “0” or “1”. A value that is present and
set to “1” indicates that a proxy cache is present and available for use. This
header field can be used even if the current request was not routed via a proxy.
What signal do we need from the proxy cache that it supports this mode of
operation? Can we expect that a proxy cache will happily accept a request for
an HTTPS URL?
Do we want to identify the proxy so that the origin can make some sort of
judgment about the proxy? Probably not. We shouldn’t be relying on the
origin server making judgments about the character of proxies.It is not sufficient to couple the acceptance and use of out-of-band content
encoding with the use of a proxy. Without an additional signal, a resource
using secure content delegation to a CDN could trigger a request via a
proxy.The security properties of delegation via a CDN and via a caching proxy are
similar only to the extent that a third party is involved. However, it might be
the case that the CDN has a stronger relationship with the origin server and
additional constraints on its actions, such as contractual limitations. Such
constraints might make delegation to the CDN acceptable to the origin server. A
caching proxy might not be considered acceptable.Therefore, a clear signal from the origin server is needed to allow the client
to identify which resources are safe to retrieve from a proxy-cache. A proxy
extension to the JSON format defined in is added
that signals to the client that the out-of-band content MAY be retrieved by
making a request to a proxy.The proxy attribute is a boolean value. In its absence, the value is assumed
to be false. If present and set to true, a client can send the request for the
out-of-band content to a proxy instead of the identified server.Clients MUST NOT send a request via a proxy if the message containing the
out-of-band content encoding does not include header fields for message
integrity and encryption, such as the M-I header field
or the Crypto-Key header field . Absence
of these header fields indicate an error on the part of the origin server, since
integrity and confidentiality protection are mandatory.
The proxy attribute might be replaced by a rule that stated that same-origin
out-of-band encoding implied permission to route via a proxy. However, the
gain here is minimal, it saves only on the explicit indication.This mechanism does not work with a transparent caching proxy. Since the
request is made over end-to-end HTTPS in the absence of a proxy, the feature
will not be used unless the proxy is known to the client.A proxy cache MUST therefore be expressly configured or discovered. This
produces a name and possibly a port number for the proxy. The proxy MUST be
contacted using HTTPS and authenticated using the configured or
discovered domain name.As noted in , the secondary request required by out-of-band content
encoding imposes a performance penalty. This can be mitigated by priming
clients with information about the location and disposition of resources prior
to the client making a request. A resource map described in might be
provided to clients to eliminate the latency involved in making requests of the
origin server for resources that might be cached.A client that makes a request of an origin server via an unprimed proxy cache will
suffer additional latency as a consequence of the cache having to make a request
to the origin server.The following options are possible:Clients can speculatively make requests to a proxy cache based on information
it learns from a resource map. To avoid a potential waste of resources as a
result of receiving complete responses, these might either be limited to HEAD
requests; HTTP/2 flow control might be used to allow only limited
information to be sent.The origin server might provide the proxy cache with “prefetch” link relations
in responses to requests for secondary resources. These link relations might
identify other resources that the proxy might retrieve speculatively. This
does not improve the latency of the initial request, but could improve
subsequent requests.All the considerations of apply. In particular, content that is
distributed with the assistance of a proxy cache MUST include integrity and
confidentiality protection. That means that the M-I header field
and the Crypto-Key header field
or equivalent information MUST be present
in responses that include an out-of-band content encoding.Clients that receive a response without the information necessary to ensure
integrity and confidentiality protection against a proxy cache MUST NOT make a
request to a proxy to retrieve that response. Clients could treat such a
response as failed, make the request directly to the origin server, or retry a
request without the out-of-band token in the Accept-Encoding header field (for
idempotent methods only).This document has no IANA actions. It should.Key words for use in RFCs to Indicate Requirement LevelsIn 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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.HTTP Over TLSThis 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.Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and RoutingThe Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.Hypertext Transfer Protocol (HTTP/1.1): CachingThe Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.Hypertext Transfer Protocol Version 2 (HTTP/2)This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.An Architecture for Secure Content Delegation using HTTPEncrypted Content-Encoding for HTTPThis memo introduces a content-coding for HTTP that allows message payloads to be encrypted.Merkle Integrity Content EncodingThis memo introduces a content-coding for HTTP that provides progressive integrity for message contents. This integrity protection can be evaluated on a partial representation, allowing a recipient to process a message as it is delivered while retaining strong integrity protection. The integrity protection can optionally be authenticated with a digital signature.Hypertext Transfer Protocol (HTTP/1.1): Semantics and ContentThe Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.'Out-Of-Band' Content Coding for HTTPThis document describes an Hypertext Transfer Protocol (HTTP) content coding that can be used to describe the location of a secondary resource that contains the payload.