[websec] fyi: HTTPS/HSTS support on www.w3.org servers

["Hodges, Jeff" <[e-mail]>]

see below for an interesting announcement re deploying HTTPS/HSTS support
on www.w3.org servers, but first, some quick background..

deploying HSTS [RFC6797] can be tricky for sites having non-trivial
existing deployments of insecure resources (e.g., accessed via
"http://..."), e.g.: www.w3.org.  A large reason this is tricky is "mixed
content blocking" [1], and in which order in user agents' overall
"fetch()" algorithm [2] HSTS and mixed content blocking are integrated.

the W3C WebAppSec WG is developing a means, known as "Upgrade Insecure
Requests" [3], to address this conundrum. Upgrade Insecure Requests
provides a means for webapp deployers (aka "authors") to finess their
migration to a fully secure site, and this along with HSTS is what the W3C
has deployed (see the forwarded announcement below)

[1] https://www.w3.org/TR/mixed-content/
[2] https://fetch.spec.whatwg.org/
[3] https://w3c.github.io/webappsec-upgrade-insecure-requests/


-------- Forwarded Message --------
From:  Wendy Seltzer <[e-mail]>
Organization:  W3C
Date:  Monday, January 11, 2016 at 11:42 AM
To:  "[e-mail]" <[e-mail]>
Subject:  Fwd: HTTPS/HSTS support on www.w3.org servers

Thanks to WebAppSec for the specs that helped to make W3C's HTTPS update
possible (and for the prodding to get there even sooner).

Please don't hesitate to share configuration suggestions or bug reports.

Thanks!
--Wendy

-------- Forwarded Message --------
Subject: HTTPS/HSTS support on www.w3.org servers
Date: Mon, 11 Jan 2016 08:01:05 -1000
From: Coralie Mercier <[e-mail]>
Organization: W3C


Dear Advisory Committee Representative,
Chairs,

W3C advocates [1] that the Web platform "actively prefer secure
communication." Thanks to recent work in the Web Application Security
Working Group [2] and supporting client implementations, and the
deployment work of the W3C Systems Team, we are now able to provide HTTPS
access to all W3C resources. All W3C documents, including Recommendations,
DTDs, and vocabularies will be available with the authentication,
integrity-protection, and confidentiality HTTPS supports.

HTTPS deployment posed some challenges based on our commitment to preserve
substantial archives of historic material (for which we could not simply
assume that all links were scheme-relative or convert all included content
to HTTPS) and the desire to maintain availability to older clients in the
field that might support only HTTP. Accordingly, our setup makes extensive
use of the Upgrade Insecure Requests [3] spec, but does not force HTTPS on
those who start from HTTP.

Up to now, our main servers have enforced access HTTPS access to protected
resources and HTTP for public resources. Today we upgraded our main
servers to support both HTTP and HTTPS access to public resources. This
change involves the following:

    - Support of the Upgrade-Insecure-Requests HTTP request header [3] for
transparently requesting the upgrade of HTTP requests to HTTPS ones. Note
that you will only get the benefits of this feature if your browser sends
this header.

    - Support of the Strict-Transport-Security HTTP response header (HSTS)
[4] for instructing browsers that they should transparently transform all
HTTP requests to HTTPS ones for all access to the www.w3.org domain. All
recent browsers support this header [5]. It allows to convert a site to
HTTPS without needing to revise the content of all the legacy resources
that may have hard-coded HTTP links. We have been supporting this header
in lists.w3.org and other domains for a long time. This status is cached
in the browser for a given time and will be refreshed each time you browse
an HTTPS link to www.w3.org.

    - We're not planning at this point of time to enforce server
redirection of all HTTP requests to HTTPS ones for public resources. This
is due to avoid breaking older software that can't be upgraded, such as
those in built-in devices. This will be done later at another milestone.
As a consequence, if your browser doesn't send the
Upgrade-Insecure-Requests header, you'll need to browse an HTTPS links
pointing to www.w3.org to get the benefits of using HTTPS on our site.

    - Note that this change has no effect on namespaces. The actual
namespace will continue to use HTTP, even if it is also served through
HTTPS. This applies as well for XMI DTD, Schema, and SGML DTDs resources.


There may be some side-effects you need to be aware of:

    - Infinite loops happening if due to server or proxy configuration
there are hard-coded redirects to an HTTP link after the HSTS header is
cached in your browser. Please send the URL to [e-mail] so that we
can fix it.

    - Mixed-content warnings. They will be raised if you're using a
browser that doesn't support Strict-Transport-Security. The solution here
is to update to a more recent browser.


If you have any other issue feel free to mail [e-mail].

Thank you,


Coralie Mercier, Head of W3C Marketing & Communications


[1] http://www.w3.org/2001/tag/doc/web-https
[2] http://www.w3.org/2011/webappsec/
[3] http://www.w3.org/TR/upgrade-insecure-requests/ (Note that the HTTPS:
1 header has been deprecated in favor of Upgrade-Insecure-Requests in the
Editor's draft https://w3c.github.io/webappsec/specs/upgrade/)
[4] http://tools.ietf.org/html/rfc6797
[5]
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#Browser_suppor
t


end