Force HTTPS and add Strict Transport Security #4328
Comments
|
👍 |
|
Let me know if there's any more information I can provide here to make the case. |
|
Just tagging @ryankirkman too |
|
@terinjokes do we have any schedule on it? Thanks! |
|
@ryankirkman Do you want to chat about this? I was backpacking Europe when this issue was created, and I forgot about it. |
|
@terinjokes Sure thing! |
|
@terinjokes I remember that cloudflare has this feature for normal websites thay applied cloudflare cdn, hope I did not remember it wrong, and i think this feature cam also prevent http to https redirect so that also speed up the websites still using http or relative protocol to access our website, we have changed the url in website to include https prefix.for a while, so I think we can just turn it on, what do you think @ryankirkman |
|
@terinjokes may I ask is there any updates here? Thanks you. |
|
cdnjs still allows HTTP requests for its libraries: http://cdnjs.cloudflare.com/ajax/libs/jquery/3.0.0-beta1/jquery.min.js And isn't currently setting an HSTS header for the secure versions: Fixing both of these would be an easy way for CloudFlare to greatly improve user security for anyone visiting a site using a cdnjs library. |
|
In fact, Cloudflare.com is in the HSTS preload list: So the modern browsers will automatically use https for it. |
|
@PeterDaveHello Unfortunately, this isn't the case. Cloudflare's entries are line 4382 to 4834:
The |
|
hmmmm ... okay, I didn't check the entries in detail, thanks @konklone |
|
@ryankirkman and I looked at a time slice of CDNJS traffic and the protocols being used. 63% of the traffic was over HTTPS. There was some concerned that forcing HTTPS for the remaining 37% might slow down TTFB. On the other hand, modern browsers can pipeline requests over HTTPS connections, which might improve the overall page performance. Unfortunately, CDNJS is not in a good position to measure this. In this light, my suggestion on how we could move forward:
How does this sound to everyone else? |
|
From my perspective, this would be outstanding progress. You will need to get the domain added to the preload list by contacting the Chrome team directly, in part because it's a subdomain and in part because you will not be redirecting HTTP->HTTPS automatically. However, I think it highly likely your request would be granted. |
|
@konklone Yes, we've got a ticket internally to get the preload list changed to |
|
It'll be interesting to see what the % of HTTPS traffic is after the domain spends a while in production preload lists (I don't know what the rollout timeline is like for Firefox, Safari, and IE11/Edge). |
|
@konklone At least for Chrome, the preload list is rolled out in the standard release pipeline. So for it will likely take a few months to get from committed to in a stable release. |
|
Sounds good to me @terinjokes |
|
Amazing work! Sounds like it could take a long time for that redirect to take place though, although security is great, it is probably more of an impairment to those not fortunate enough to be on modern browsers. |
I'm not sure I agree, but the practical benefit for browsers that don't support HSTS wouldn't be that great, because the HTTP->HTTPS redirects they'd keep hitting would be just as insecure as downloading the content directly over HTTP. Where a redirect would help is in more rapidly introducing browsers that do support HSTS (but which don't support preloading) to the HSTS policy for cdnjs.cloudflare.com. I'm not sure how big that population is. So given the threat model here, I think this is a justifiable call. But I wouldn't, as a general matter, say that people on older browsers should get faster insecure things over slower secure things. As CloudFlare made clear in their end-of-2015 SHA-1 blog post, many people with older browsers are in more hostile regions of the world, where network attacks could well be more common and, when successful, more devastating. |
|
@konklone That's a very good point towards the other side when it comes to the redirect. I think it's very useful to have a discussion about what we should do here. I think we're all in agreement with moving forward on the HSTS side of things. Please correct me if I'm wrong.
The good news is that all it takes is one HTTPS request from any site to get cdnjs.cloudflare.com in the browser's local HSTS cache. Once we roll out the HSTS header, we might want to review the access logs and see how much HTTP traffic we continue to get. Knowing this information may help us shape the next steps with respect to HTTPS redirects. |
👍 I'll also note for anyone watching this thread that @thomasdavis successfully motivated me to start a comparison table tracking asset CDN behavior regarding HTTPS and HSTS. |
|
@thomasdavis anybody who is using <IE11 is already impaired by the fact Microsoft are no longer supporting them. For me this is one of those progressive enhancement type things - as long as it works in older browsers it doesn't have to be the best experience. |
|
The introduction of HSTS causes issues with hosting ZeroClipboard on CDNJS as its Flash SWF must be served via the same protocol as the page hosting it: zeroclipboard/zeroclipboard#632 👎 |
|
I published an article about HSTS usage on CDNs and was pointed to this issue on Twitter. It will be interesting to keep track of what happens. Here is the article if you're interested: https://scotthel.me/cdn |
|
@ScottHelme I saw your post last week, thanks for doing the research. As you can see here, it's been on our minds for a while. I think we'll make an action here soon. |
|
Thanks @terinjokes, that's great to hear. If there are concerns of the performance impact of a redirect, you could look at simply issuing the HSTS header and/or preloading to start with. This ensures that only HSTS capable clients would be moved over to HTTPS initially and there are multiple opportunities for a particular client to pick this up. The 301 redirect could come at a later stage but I imagine HSTS would catch a large portion of HTTP traffic to start with. |
|
@ScottHelme per above, that's what we're planning on doing. Short HSTS headers for a bit to find out what we broke, and still have time to address the issues, then if all goes well, add |
|
@JamesMGreene I understand the concern, it is part of the reason we haven't yet implemented this. Can you implement ZeroClipboard leveraging other browser technologies? All modern browsers (the ones that would follow HSTS headers or preload lists) support |
|
@terinjokes: Generally speaking, yes, I just never have any free time anymore to get around to updating ZeroClipboard to utilize the HTML5 Clipboard. I feel like an absentee parent or something. 😭 |
|
@terinjokes any movement on this one yet? |
|
@drewfreyling since no any other CDN is doing this (force HTTPS) yet, so I'm a little bit afraid that there may be some concerns like old devices may have problem with it. I have no problem with HSTS however. |
@PeterDaveHello That's not quite true - as of April 2016 there are a few (smaller) CDNs: konklone/cdns-to-https#10 (comment) But the consensus on thread is to deploy HSTS and not to perform HTTP->HTTPS redirects. The one expressed concern relates to ZeroClipboard having issues due to its dependency on Flash even in modern browsers. |
|
@konklone, sorry, no offense, I know the info you provided, in the last comment, actually I mean the larger and older CDN services, the new services usually will not have tons of concerns, but for older and larger ones, there are so many, I think we may still need some time to discuss, confirm the detail, and then we can do the redirection, thank you very much for your comment! |
|
Hey all. We've been operating CDNJS with a short cache time (currently 5 minutes) for a bit now, without hearing about any issues. Unless that changes, our current plan is to increase HSTS to 6 months next week. |
|
Chromium HSTS preloading recently started requiring a max-age of at least 1 year (https://hstspreload.org/#submission-requirements). |
|
@thestinger We'll cross that boat afterwards. |
|
Resolved? :-) |
|
The relevant domain here is
|
|
FWIW, Safari (desktop) users might be experiencing issues as a result of forcing the redirect to HTTPS. To replicate, using Safari 11.1, load HTTP site with various This successfully loads the HTTPS resource: These fail to load the HTTPS resource: Error Message: |
|
@PeterDaveHello Is there anything here that still needs to be followed up with Cf? |
|
@terinjokes @simon-says Thoughts on this? |
|
No further progress, closing. |
This is a sequel issue to #4112, where cdnjs started recommending HTTPS URLs over HTTP.
I believe cdnjs should feel comfortable turning on a 301 redirect from HTTP to HTTPS, and adding the
Strict-Transport-Securityheader to its web server, so that even sites that leave theirhttp://links in place will start fetching resources overhttps://and protecting their users.I've done my best to comprehensively evaluate the effects of forcing a redirect, on both
<script>tags and CORS requests, and my results are here:The short of it is that
<script>tags pointing tohttp://resources are completely unaffected by a 301 redirect, even as far back as IE6 on Windows XP. It's a safe move.For CORS requests, there are a couple of client incompatibilities: older Android, and Safari (on iOS and desktop). I don't know what cdnjs' CORS usage is like. If that's not auditable already, then the first step would be to enable some kind of analytics for that.
Even if CORS has some support -- to me, the benefits here seem to outweigh the costs. Strict Transport Security, which works in every browser except for IE (and the next IE will support it), means that CDNs have the ability to tighten up security for visitors to third-party websites using their assets, without the third-party websites having to do anything.
With Strict Transport Security in place, it then becomes trivial to add that domain to the HSTS Preload list managed by Chrome, and used by Firefox and Safari and the next version of IE, so that users won't even have to make one insecure redirect to start making secure cdnjs requests. Though they try to limit subdomains, I'm positive the Chrome team would happily add
cdnjs.cloudflare.comto their list, given cdnjs' reach.Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: