search

rgrove / rawgit

Served files from raw.githubusercontent.com, but with the correct content types. No longer actively developed.
https://rawgit.com
MIT License
2.39k stars 488 forks source link

Enforce HTTPS & use HSTS #114

Closed emilstahl closed 8 years ago

emilstahl commented 8 years ago

Why not enforce HTTPS and use HSTS (possibly preloaded)?

neoascetic commented 8 years ago

Why enforce?

rgrove commented 8 years ago

Thanks for the reminder, @emilstahl! I've been meaning to do this for a while, but hadn't gotten around to it.

RawGit now enforces HTTPS. I haven't enabled HSTS yet, but I'll do that once we've run HTTPS-only for a while and I'm sure there are no problems.

Multiply commented 8 years ago

Why enforce it? Simple websites that have non-HTTPS CORS requests will not work, due to "mixed-content".

Can I somehow 'opt out' of HTTPS using a get parameter or a header?

rgrove commented 8 years ago

Why enforce it?

Because optional HTTPS doesn't provide sufficient security against content injection or man-in-the-middle attacks.

Simple websites that have non-HTTPS CORS requests will not work, due to "mixed-content".

A website served over HTTP should be able to make CORS requests to both HTTPS and HTTP origins without a mixed content error. At least, this is the case in latest Chrome stable. Is this a problem you're actually seeing? If so, what requests are you making, and what browser is giving you trouble?

Multiply commented 8 years ago

I am visiting a page hosted on github, through rawgit.com (previously over HTTP, but now forced to HTTPS), which would then take one or more URLs (form input + JS), that will then fetch from said URLs, not hosted using HTTPS.

I got a solution here, but it hasn't been confirmed if it's permanent or not: https://github.com/rgrove/rawgit/issues/117#issuecomment-222523535

bchavez commented 8 years ago

Some embedded device scripts that don't have native SSL support were hosed by this change.

rgrove commented 8 years ago

Okay folks, I've reverted this change. Thanks for your feedback.

At some point in the future, RawGit will go HTTPS-only, but it's clear that there needs to be advance warning so that people with HTTPS-incompatible use cases can migrate off of RawGit.

Multiply commented 8 years ago

@rgrove Could there bet set up a separate sub-domain without HTTPS in the future? I am all for forcing HTTPS for sure, but having an alternative would be nice.

rgrove commented 8 years ago

Could there bet set up a separate sub-domain without HTTPS in the future? I am all for forcing HTTPS for sure, but having an alternative would be nice.

No. If RawGit is available via both HTTP and HTTPS, regardless of whether it's opt-in via a subdomain or a URL flag or any other mechanism, then HTTP requests to RawGit can be intercepted and altered with no indication to the victim.

The point of requiring HTTPS with HSTS is to avoid ever having an HTTP connection between a client and RawGit, so that there's never an opportunity for an attacker (often an ISP or a government) to redirect or alter the traffic. It can't be opt-in, because in many cases an attacker can simply "opt" the client out without the client knowing.

bardiharborow commented 7 years ago

@rgrove Is anything currently blocking HTTPS and HSTS preload deployment? If there is concern about breaking clients with no TLS support, can you implement everything except the 301 redirect, and then ping the preload list mainatiner to get an manual exemption from that preload requirement (they have been very accommodating in the past). I haven't looked into CORS issues, but that sort of thing seems fairly easy to resolve.

rgrove commented 7 years ago

I've just announced on the RawGit homepage (and will also announce on Twitter) that RawGit will become HTTPS-only on February 17, 2018.

This should give people plenty of time to find alternatives if they can't use HTTPS.