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 <wselt...@w3.org> Organization: W3C Date: Monday, January 11, 2016 at 11:42 AM To: "public-webapp...@w3.org" <public-webapp...@w3.org> 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 <cora...@w3.org> 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 sys...@w3.org 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 sys...@w3.org. 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 _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec