1. Introduction
This section is not normative.
Mixed Content [MIX] poses a problem for authors who wish to move their
content to secure transports [WEB-HTTPS]. The W3C recently standardied
the upgrade-insecure-requests directive to aid authors
that successfully migrated their user experience to an HTTPS URI scheme.
The upgrade-insecure-requests directive helps authors that
believe their own resources, as well as all of their subresources, are
ready for HTTPS. This assumption does not hold for a great many sites that
wish to migrate but have dependencies on HTTP-only subresources.
Each site unable to go full HTTPS contributes to a web of insecure dependencies unable to make the switch to secured transports. For example, if Site A needs to wait for Site B to migrate to HTTPS, Site B needs to wait for Site C, and Site C needs to wait for Site A, then no site is able to start the transition to HTTPS.
This document defines a transitional state, https-transitional, that breaks this cycle. When used,
content can be securely delivered as a subresource while maintaining a site’s
primary user experience at the HTTP URI scheme. This permits any individual site, no
matter its dependencies, to deploy secured transports in a low risk, low cost manner.
1.1. Goals
Like upgrade-insecure-requests, https-transitional is designed to reduce the burden of migrating websites from insecure origins by
reducing the negative side effects of mixed content blocking [MIX]. It pursues a
second goal of breaking insecure dependency cycles across origins. Finally, it
provides a semantic link between resources served over insecure and secure channels at
an Origin.
The https-transitional standard requires authors to
obtain a proper certificate and use a TLS and application server stack that
support necessary protocol extensions. Once acheived, enabling https-transitional is designed to be a low-risk, low-cost
configuration change. Once made, the following statements ought to hold:
- Authors should be able to deploy
https-transitionalwith no negative impact to users that visit their Origin using an HTTP URI scheme. In this case, security indicators will be consistent with those provided in a standard, insecure HTTP case. - Authors will be able to deploy
https-transitionaland securely provide subresources to embedding documents using properly secured TLS connections. Such resources will not be blocked if the embedding document’s settings block mixed content, and security indicators will not be degraded. - User agents will be able to optimistically upgrade resources referenced
with an http URI scheme any time the
https-transitionalALPN is advertised. This application protocol indicates a given request will effect the same change on the server and return semantically identical response content, security configuration aside, as if the same request had been made instead to the Origin’s insecure HTTP endpoint. - As with
upgrade-insecure-requests, authors should be able to achieve all these goals without editing a site’s content. This is particularly important for archived content and legacy systems. - Simliar to
upgrade-insecure-requests, authors should be able to pursue a gradual transition from insecure to secure, serving secure resources to clients that supporthttps-transitional, while supporting the HTTP URI for users that request it.
Note: Here is a stretch goal for discussion: Authors will be able to instruct user
agents to enforce a strict version of https-transitional. In such a case,
the user agent will disable fallback to insecure transports and enforce
mixed content restrictions identitical to those enforced within secure
documents today. In such a case, content served using the https-transitional
application will be treated as same origin with and receive identitical
security indicators as HTTPS. This, despite being still referenced with
the HTTP URI scheme.
Note: The mechanism defined here does not intend to supplant Strict
Transport Security [RFC6797] or upgrade-insecure-requests. See §5 Security Considerations.
for details.
1.2. Examples
In the examples that follow, three origins are all hosted using insecure http endpoints and are referenced using the http URI scheme. They reference each others' content as follows:
-
http://example-a.comserves content to users both within a top-level browsing context and as a subresource to embedding documents. - Documents at
http://example-a.comreference JavaScript code athttp://example-b/code.js. - Documents at
http://example-c.comreference HTML content athttp://example-a.com/content.htmlin aniframe.
The administrator of example-a.com wishes to move to secured
transports, but knows it is impossible until example-b.com migrates to HTTPS. The administrator does not want to block the migration
of example-c.com to HTTPS, so they deploy https-transitional.
1.2.1. Maintain Backwards Compatibility
http://example-a.com/simple.html. This
simple web page has no subresources. Her User Agent supports https-transitional, which is negotiated successfully
with the server. All content from example-a.com accessed
using a secured transport.
Though all content is delivered securely in this case, the URL bar for shows the HTTP URI scheme and security indicators are consistent with having used an insecure transport. This is consistent with the fact that this connection is opportunistically encrypted and can be downgraded by an active attacker.
1.2.2. Reference HTTP Subresources
http://example-a.com/sub.html. This
web page references JavaScript code at http://example-b.com/code.js.
As before, the User Agent accesses content from example-a.com over a secure transport. However, example-b.com does not support
HTTPS or https-transitional, so the User Agent falls back the
insecure transport. The JavaScript code from example-b.com is retrieved
and successfully used by example-a.com’s documents.
Even though the content from example-a.com is transported securely
while the content from example-b.com is transported insecurely, this
is not treated as a Mixed Content [MIX] scenario. As demonstrated in §1.2.1 Maintain Backwards Compatibility, security indicators for top-level documents accessed using https-transitional are consistent with an insecure transport.
Furthermore, the JavaScript from example-b.com is allowed to be
fetched and executed.
This behavior is consistent with that which would result from https-transitional being turned off. It is essential that deployment
of https-transitional be low-risk for administrators, and maintaining
identical user experience for HTTP URI top level documents is required to fulfill
this goal.
1.2.3. Reference https-transitional Content as a
Subresource
example-c.com recognizes that example-a.com deployed https-transitional and completes
her migration to HTTPS. She modifies example-c.com’s content to use
the HTTPS URI scheme and does the same for subresources that support it.
However, references to example-a.com are left with the HTTP scheme.
Even so, she deploys the upgrade-insecure-requests and block-all-mixed-content directives knowing they are compatible
with https-transitional.
Visitors to https://example-c.com access content through a secure
channel and receive security indicators consistent with that fact. When a visitor’s
user agent encounters the HTTP URI for example-a.com, it attempts to
access the TLS endpoint for that Origin, recognizes the https-transitional ALPN, and fetches content securely. Content
from example-a.com is incorporated into example-c.com’s
documents and positive security indicators are maintained.
Unlike scenarios where example-a.com content is viewed as a top level
document, the user’s expectation in this case is secure content access with example-c.com. User Agents will conform to this expectation by
preventing fallback to insecure transports when https-transitional content is included as a subresource to
content that restricts mixed content.
In short, subresource content served using https-transitional offers the same guarantees as if referenced using an HTTPS URI, and is treated the
same for purposes of mixed content restrictions, origin, and security indicators.
1.2.4. Maintain Security of Ancestor Frames
https://example-c.com content loads http://example-a.com/content.html within an IFRAME. As demonstrated in §1.2.3 Reference https-transitional Content as a
Subresource, this content is fetched securely and treated as if it were
referenced using an HTTPS URI.
Unfortunately, the HTML content served includes a reference to http://example-b.com/code.js. This Origin does not support HTTPS or https-transitional. A User Agent for such a scenario would fail to
connect to TLS on example-b.com, and neglect to retrieve the content
rather than degrade the security of example-c.com.
This scenario differs from §1.2.1 Maintain Backwards Compatibility in the user’s expectation of security.
When loaded as a top level document referenced with an HTTP URI, content served over https-transitional can successfully reference content served in
an insecure manner. However, when acting as a subresource, it must maintain the
security model of its ancestor frame.
1.2.5. Enforce HTTPS Transitional
It may be desirable to introduce an HTTPS-equivalent state to https-transitional. This would be the case if example-a.com wishes to maintain its location on the web at an HTTP URI. This can be accomplished
with a simple redirect, but this is both inelegant and has the potential of leaking
sensitive data.
A "make me HTTPS" state for https-transitional could enforce the
secure channel, never fall back to HTTP, and be treated as the same origin as HTTPS.
In short, provide the security gurantees and receive the same treatment as when used
as a subresource to a secure frame.
1.3. Recommendations
We recommend that authors who wish to ensure that user agents which support https-transitional are as secure as possible do the following:
- Always set the persist=1 flag on the Alt-Svc header.
- Set as long of a max age as you can. Short during experimental times. Long when it looks like it will work.
We recommend that user agents do the following:
- Attempt to negotiate https-transitional for all connections. Make this configurable if performance is a concern.
- Always attempt to negotiate https-transitional for subresources of https-transitional documents.
- Enforce HTTPS or https-transitional for subresources of HTTPS documents and those that otherwise block mixed content.
2. Key Concepts and Terminology
- Opportunistically secure - https-transitional with http fallback
- Reliably secure - https or https-transitional with no fallback
3. Accessing Content with HTTPS Transitional
HTTPS Transitional URI scheme
- https-transitional uses the http URI scheme
- Documents referenced with the https URI scheme or upgraded with upgrade-insecure-requests receive standard HTTPS treatment
Upgrading a request to https-transitional is based on the following configuration:
-
Settings objects and browsing contexts are given an
https-transitionalpolicy with three options:-
Do not attempt upgrade -
Attempt upgrade -
Enforce upgrade
-
- Settings objects and browsing contexts are given an
https-transitionalnavigations set which contains a set of origins paired with anhttps-transitionalpolicy. - Default policy for origins not in the navigations set should be set to
Attempt Upgradefor practical security. UA authors and/or user configuration may override this.
3.1. The https-transitional ALPN
A user agent may advertise its support of the https-transitional application protocol by including the https-transitional ALPN in its ClientHello
per [RFC7301]. The ALPN protocol is defined here in accordance with that RFC:
Protocol:https-transitionalIdentification Sequence:0x68 0x74 0x74 0x70 0x73 0x2d 0x74 0x72 0x61 0x6e 0x73 0x69 0x74 0x69 0x6f 0x6e 0x61 0x6cReference:This document
The presence of this token in a ClientHello indicates that the client is upgrading an insecure URI scheme in an opportunistic fashion, as opposed to using traditional HTTPS.
A server SHOULD indicate its selection of the https-transitional application protcool by including the https-transitional ALPN in its
ServerHello response to the client. This informs the client that server state changes
and response content are identical when made to the secured endpoint at the Origin
as they would be had the requests been made to the unsecured endpoint.
3.2. The https-transitional HTTP Alt-Svc Header
A server MAY instruct a user agent to configure https-transitional requests for an origin by sending an HTTP Alt-Svc header that advertises the
availability of the https-transitional service. For example:
Alt-Svc: https-transitional=":443"; ma=3600; persist=1 Alt-Used: TBD (draft suggests using uri-host [ ":" port], not space for protocol)
TBD - Client should respond with an Alt-Used. It is not clear what we would use at this time. It’s not standard, but it would help to be able to specify a protocol as part of Alt-Used.
When configuring the https-transitional header:
- Configure HTTPS Transitional policy for this Origin to
Enforce Upgrade. Insert Origin into settings' HTTPS Transitional navigations set.
TBD - need to see best practices for showing persist and ma settings from other ALPNs. Flags interpreted as per https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-08#section-3.1.
TBD - need to specify flag for secure tranquility. Another Alt-Svc? Would need to have client be able to inform server of protocol used, so need a non-standard Alt-Used. Flag modifiers for this ALPN? Need to specify non-standard modifiers beyond persist and ma.
3.2.1. Relation to "Mixed Content"
- A resource fetched over https-transitional should not be blocked as mixed content if the responsible document’s settings object restricts mixed content. Upgrade-insecure-requests is implied for documents embedded by such a resource.
- The settings object for a document fetched over https-transitional should not restrict mixed content. Security indicators should be consistent with unauthenticated responses.
3.2.2. Relation to "Upgrade Insecure Requests"
https-transitional SHOULD be the preferred method by which subresources referenced with the http scheme are upgraded. This is because the ALPN promises the semantic link between secured transport and http application content - a raw URI re-write does not.
- When upgrading an http scheme, connect to the https endpoint of the server at the indicated Origin
- Add the https-transitional ALPN at the highest priority
- Fall back to traditional https URI re-writing if https-transitional not supported
3.3. Reporting
TBD - Reporting is essential, but we don’t have an obvious infrastructure for this purpose. Piggy back on CSP violation reports? A better alternative?4. Processing Algorithms
TBD - Specify specific algorithms once goals and high level design is agreed upon.
5. Security Considerations
TBD - fill in details. Again, this will be more appropriate once the broad design is agreed upon.
5.1. Interaction with HSTS
Does not replace STS. Authors who can move to HTTPS only should do so and configure STS
5.2. Interactions with upgrade-insecure-requests
Does not replace upgrade-insecure-requests. "upgrade insecure" secures from the top down; this secures from the bottom up.
5.3. Violation Reports
Reports likely to have similar concerns as "upgrade insecure", but specifics will need to wait on the right place to put violation reports.
6. Performance Considerations
TBD - fill in details.
- Optimistic security will require unnecessary connections to origins that do not have TLS configured.
- Adds https-transitional ALPN to ClientHello and ServerHello TLS echanges
- Adds HTTP Alt-Svc [and Alt-Used] headers to HTTP exchanges
7. Authoring Considerations
7.1. Legacy Clients
Legacy clients which do support mixed content blocking [MIX], but do not
support the https-transitional protocol or the upgrade-insecure-requests directive will
continue to have a suboptimal experience on pages containing a priori insecure URLs.
8. IANA Considerations
The TLS Extension Values registry should be updated with the following registration: [RFC7301]
8.1. HTTPS Transitional
- Protocol name
https-transitional- Identification sequence
0x68 0x74 0x74 0x70 0x73 0x2d 0x74 0x72 0x61 0x6e 0x73 0x69 0x74 0x69 0x6f 0x6e 0x61 0x6c- Reference
- This specification
- Author/Change controller
- W3C
9. Acknowledgements
This form and some content of this specification borrows shamelessly from upgrade-insecure-requests.
The content of this specification is based on Brad Hill’s position paper on opportunistic encryption.