cdns-to-https
cdns-to-https copied to clipboard
Comparison Table
Hey Eric,
love all the hard work here. Do you have a table that compares the current CDN's to see how far along they have progressed with enforcing https?
@thomasdavis I don't, but that would be an interesting table to make. Can you think of some CDNs worth comparing? Off the top of my head, I can think of:
| Name | Asset Domain | Recommends HTTPS | Redirects to HTTPS | HSTS |
|---|---|---|---|---|
| cdnjs | cdnjs.cloudflare.com | Yes | No | No |
| jQuery CDN | code.jquery.com | No | No | No |
| Google Hosted Libraries | ajax.googleapis.com | Yes | No | No |
| browserify-cdn | wzrd.in | Yes | Yes | Preloaded |
| jsdelivr | cdn.jsdelivr.net | Yes | No | No |
| npmcdn | npmcdn.com | Yes | Yes | Preloaded |
| Microsoft Ajax CDN | ajax.aspnetcdn.com | No | No | Yes |
| BootstrapCDN | maxcdn.bootstrapcdn.com | Yes | No | No |
| RawGit | cdn.rawgit.com | Yes | No | No |
Definitions:
- Recommends HTTPS: The documentation gives developers
https://URLs to copy and paste. - Redirects to HTTPS: The server redirects requests for asset files over
http://tohttps://versions. - HSTS: Requests for asset files over
https://have an HSTS policy (good), and may be preloaded (best).
(Note that HTTPS and HSTS behavior should be measured by checking behavior on a specific served asset, rather than the root of the domain.)
Last updated: April 21, 2016
npmcdn and jsdelivr
@thomasdavis Thanks -- I added those above, and I made a table with what I could find about them.
Microsoft Ajax CDN - https://www.asp.net/ajax/cdn
Name - Microsoft Ajax CDN Domain - ajax.aspnetcdn.com Recommends HTTPS - No Redirects to HTTPS - Yes HSTS - Yes
BootstrapCDN - https://www.bootstrapcdn.com/
@anand-bhat Thank you! Though Microsoft actually doesn't redirect to HTTPS server-side, they just use HSTS (which was causing your browser to redirect, most likely).
@blagoeres Thank you!
Updated the table above with both entries.
https://rawgit.com
Shouldn't we be pushing HPKP too?
@indolering IMO, HPKP isn't safe or easy enough for general use. But CDNs aren't general use -- there's an argument that CDNs should hold themselves to a higher standard, given the role they play in the security posture of thousands or millions of websites, but it's also going to be the case that an outage caused by a broken or misconfigured pin would be proportionately more devastating. Given how unforgiving pinning failure can be (if the key is lost or compromised, there's no way to fix it until the max-age expires).
Most of the work in this repository is there to demonstrate that, barring special circumstances, CDNs should be able to update without disruption. HPKP significantly increases the chances of mass disruption, so the argument for it is going to have to be very persuasive.
(I should also note that I've since heard from one major CDN that HTTP requests coming right from Flash objects can be negatively affected in some way by switching on HSTS, and that that's been holding up their transition. I wouldn't have expected that to be a significant fraction of traffic, and didn't test or measure it, but it's another indicator of how seriously CDNs take the possibility of disruption of service.)
IMO, HPKP isn't safe or easy enough for general use.
@konklone if they can't manage to keep 3 copies of their key-signing-key in distributed locations ... then maybe they shouldn't be running a CDN? : )
Furthermore, as long as the intermediate key has a shelf-life longer than that of the pin then wouldn't they be able to switch to a new KSK without downtime?
At any rate, cdnjs will be rolling this out soon so you might as well start tracking it.
Also, we need to add subresouce integrity protection. cdnjs, Bootstrap, and jQuery already support it. Edit: jsdeliver also offers this.
It seems that https://code.jquery.com/ now recommends HTTPS.
@ScottHelme Unfortunately, I think it just recommends whatever protocol you visit the page itself on.
The HTTP URL -- http://code.jquery.com -- works and doesn't redirect to HTTPS. CDN links on that page are also to the HTTP URLs for JS files, such as http://code.jquery.com/jquery-3.1.1.min.js.
@konklone ahh, apologies. That's a bit disappointing given they clearly support HTTPS :(