Date
1 - 15 of 15
Proposal: For sites_https, allow GitHub pages + custom domain + CloudFlare to implement HTTPS for project site
|
All: *Many* projects use GitHub pages with custom domains, but GitHub does not natively support HTTPS if you’re using GitHub pages with custom domains.
I think we should make it clear that using a CDN like CloudFlare as a workaround is acceptable if you’re using GitHub pages with custom domains. This is a common solution. GitHub *does* support HTTPS if you’re not using custom domains (that was a change made earlier this year). Some background: https://help.github.com/articles/securing-your-github-pages-site-with-https/ https://konklone.com/post/github-pages-now-sorta-supports-https-so-use-it https://github.com/isaacs/github/issues/156 Create an explicit exception for users of Github Pages who implement a Cloudfare proxy according to <https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/>; and set the non-HTTPS pages to redirect to HTTPS. The current sites_https criterion says: “The project sites (website, repository, and download URLs) MUST support HTTPS using TLS. You can get free certificates from [Let's Encrypt](https://letsencrypt.org/)” Proposed addition: If you are using GitHub pages with custom domains, you MAY use a content delivery network (CDN) such as CloudFlare as a proxy to support HTTPS; see <a href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/”>Secure and fast GitHub Pages with CloudFlare</a>. Thoughts? --- David A. Wheeler
|
|
|
|
Wheeler, David A said on Wednesday, December 21, 2016 4:22 PM:
I think we should make it clear that using a CDN like CloudFlare as aI haven't heard *any* objections, never mind a groundswell of opposition. So here's a proposed pull request that adds the proposed clarification to criteria.yml: https://github.com/linuxfoundation/cii-best-practices-badge/pull/548 I'll obviously have to make the equivalent changes to doc/criteria.md if this is acceptable. While there are pros and cons, I think this is a perfectly reasonable interpretation... and since it's not clear, we need to make it clear. If you have issues with the general idea, or with this specific pull request, please speak up ASAP! I intend to merge this tomorrow (Friday December 23) unless I hear something soon. This issue is important to some projects, and there doesn't seem to be a lot of pushback against the idea. --- David A. Wheeler
|
|
|
|
Kevin W. Wall
Quick question: Are there any CDNs that the security community should
toggle quoted messageShow quoted text
NOT accept as okay, e.g., ones that have poor reputation wrt security? If so, we should list them or criteria of what makes them bad. (I can understand not wanting to name names and invite lawsuits for defamation though.) -kevin
On Thu, Dec 22, 2016 at 6:58 PM, Wheeler, David A <dwheeler@ida.org> wrote:
Wheeler, David A said on Wednesday, December 21, 2016 4:22 PM:I think we should make it clear that using a CDN like CloudFlare as aI haven't heard *any* objections, never mind a groundswell of opposition. So here's a proposed pull request that adds the proposed clarification to criteria.yml: --
Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall NSA: All your crypto bit are belong to us.
|
|
|
|
Mark Rader
David For your explicit exception Create an explicit exception for users of Github Pages who implement a Cloudfare proxy according to <https://blog.cloudflare.com/ Does that mean that you have to implement a proxy only out of Cloudfare or could you use any other equivalent service if some other service exists. Mark
On Wed, Dec 21, 2016 at 3:22 PM, Wheeler, David A <dwheeler@...> wrote: All: *Many* projects use GitHub pages with custom domains, but GitHub does not natively support HTTPS if you’re using GitHub pages with custom domains.
|
|
|
Quick question: Are there any CDNs that the security community should NOTWe could list criteria-for-criteria, but that would get really complex, I don't think that's a problem (and thus it's not worth trying to counter). CDNs have financial incentives to do a better job, and in practice there aren't many of them. Besides, the same could be said of HTTPS hosting sites. We can't require everything - we need people to be able to read & apply the criteria. Does that mean that you have to implement a proxy only out of Cloudfare or could you use any other equivalent service if some other service exists.Any equivalent. I think it's very important to *not* mandate a specific vendor or technology. Here's the proposed text, straight from https://github.com/linuxfoundation/cii-best-practices-badge/pull/548/files + If you are using GitHub pages without a custom domain, you can simply + <a href="https://help.github.com/articles/securing-your-github-pages-site-with-https/";>change its settings to enforce HTTPS</a>. + If you are using GitHub pages with a custom + domain, you MAY use a content delivery network + (CDN) such as CloudFlare as a proxy to support HTTPS; see <a + href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/”>Secure + and fast GitHub Pages with CloudFlare</a>. + A project MAY also support HTTP, though we + encourage users to use HTTPS instead. --- David A. Wheeler
|
|
|
|
I would change the end to be: we encourage projects to redirect http traffic to https. Counting on users to do the right thing seems hopeless.
On Fri, Dec 23, 2016 at 09:01 Wheeler, David A <dwheeler@...> wrote: > Quick question: Are there any CDNs that the security community should NOT
|
|
|
|
Ok. Here's what I think that means...
change: A project MAY also support HTTP, though we encourage users to use HTTPS instead.to: A project MAY also support HTTP, though we encourage projects to redirect HTTP traffic to HTTPS.--- David A. Wheeler
|
|
|
|
Daniel Stenberg
On Fri, 23 Dec 2016, Wheeler, David A wrote:
I actually think that in 2017, that is about to start after all, there is *no* and I really mean zero, reasons to not offer all relevant info and services over HTTPS. I don't think there's any room left for a "MAY" do HTTP.A project MAY also support HTTP, though we encourage projects to redirect HTTP traffic to HTTPS. Sure, there are server and hosting offerings that don't give the users HTTPS. That's a perfect reason to NOT use them and NOT host your open source on those services. I think a 100% best-practices project in 2017 shouldn't have anything significant on HTTP. -- / daniel.haxx.se
|
|
|
|
Mark Rader
David
toggle quoted messageShow quoted text
Or maybe make that a criteria for moving from level 1 to level n. Migration from http to https. Mark
On Dec 23, 2016, at 9:55 AM, Daniel Stenberg <daniel@haxx.se> wrote:
|
|
|
|
toggle quoted messageShow quoted text
-----Original Message-----And that's what this criterion already requires. BTW, this is currently one of the most common criteria that projects *fail* at. For example, any project on Savannah (such as GNU make, binutils including cp, etc.) cannot currently meet this requirement, because Savannah doesn't support HTTPS for repos (!). Even so, I think we should retain this criterion as-is. After some pleading by myself and others, the Savannah maintainers have agreed to add HTTPS for repos... it's just not there yet. I don't think there's any room left for a "MAY" do HTTP.That's different. The criterion currently requires HTTPS support, but it intentionally does not forbid HTTP support. Since HTTP support isn't forbidden, it is *already* permitted. Explicitly *forbidding* HTTP support would be a big change to the "passing" criteria, and I think that's too harsh for "passing" at this time. We generally only have "passing" criteria if a lot of projects meet it already, and currently a *lot* of sites also support HTTP for a variety of reasons. Heck, we're having trouble getting projects to support HTTPS at all, never mind also dropping HTTP. In addition, users can *easily* see on their web browser if they're using HTTP or HTTPS, so the risks of *unknowingly* using HTTP are much smaller. I agree with your point that supporting HTTPS-only would be better. However, because so many are *not* in that situation, let's add it to "passing+1" first . It'll be easier to have it trickle down later, and I expect it'll be a lot easier to forbid HTTP after a little more time. Something like this: * The project sites (website, repository, and download URLs) MUST NOT support HTTP other than optionally upgrading HTTP requests to HTTPS requests. --- David A. Wheeler
|
|
|
|
Kevin W. Wall
That's fine, but I think that it should be worded so that it doesn't come across as an endorsement for CloudFlare. E.g., such as CloudFlare, Akamai, Rackspace, MaxCDN, <insert-your-favorite-CDN-provider-here>, etc. At least then it won't be seen as an endorsement for any specific one. Otherwise, I'm fine with the proposed wording. -kevin -- Blog: http://off-the-wall-security. NSA: All your crypto bit are belong to us.
On Dec 23, 2016 09:01, "Wheeler, David A" <dwheeler@...> wrote:
|
|
|
|
We currently say: The project sites (website, repository, and download URLs) MUST support HTTPS using TLS. You can get free certificates from [Let's Encrypt](https://letsencrypt.org/). If you are using GitHub pages with custom domains, you MAY use a content delivery network (CDN) as a proxy to support HTTPS, such as described in this <a href=”https://blog.cloudflare.
On Fri, Dec 23, 2016 at 1:17 PM, Kevin W. Wall <kevin.w.wall@...> wrote:
--
Executive Director, Cloud Native Computing Foundation <https://cncf.io/> tel:+1-415-233-1000
|
|
|
|
From: Dan Kohn [mailto:dan@linuxfoundation.org]
If you are using GitHub pages with custom domains, you MAY use a content delivery network (CDN) as a proxy to support HTTPS, such as described in this <a href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/”>blog post</a>, to satisfy this requirement. If you use a CDN in this manner, you SHOULD redirect HTTP traffic to use HTTPS.I like this, mainly because "list all CDNs" is a problem itself :-). Technically the last part is an additional requirement, and it's not good to mix SHOULD and MUST in the same sentence... maybe we can get away with it in this case?! --- David A. Wheeler
|
|
|
|
All:
I think we're getting closer to the "detail text" for criterion sites_https, one that makes it clear that CDN proxies are okay. I really appreciate the feedback. Here's a new version that hopefully merges everyone's comments as well as recent information that's become available. Just to recall, for criterion "sites_http" the current requirement text (which will be unchanged) is: The project sites (website, repository, and download URLs) MUST support HTTPS using TLS.The current detail is: You can get free certificates from <a href="https://letsencrypt.org/";>Let's Encrypt</a>.Dan Kohn posted an updated addition to the detail based on earlier comments, and it nicely avoided trying to "list all CDNs" by adding this: If you are using GitHub pages with custom domains, you MAY use a contentThat's a nice start, but I think there are some tweaks we should do: * It includes a "SHOULD", but we've learned that trying to combine SHOULD and MUST in a single criterion is a problem. The problem is that both MUST and SHOULD are keywords with different specific defined meanings, and the actual criterion text uses MUST. Let's avoid using SHOULD, and just use some other phrase like "urge" (or perhaps "encourage" or even "strongly encourage"). We could define that term earlier. * As written it seems to suggest that you should always support HTTP. I think *only* supporting HTTPS is just fine, and in fact, many people are moving that way. Let's not encourage people to re-add HTTP if they only support HTTPS! So instead, let's say something like "If you support HTTP, we urge you to redirect to HTTPS". If we just use "urge" instead of a keyword like "SHOULD" then I think we can simply say that in all cases (we're not specifically requiring it). I think this might be plausible as a new criterion, but let's make it a separate criterion - it's not something we've required up to this point, so changing the requirement might lead to people silently failing to meet it. * We now have several repos that directly support HTTPS, but you typically have to do something to make it work. I think we should add a few links for them too. Last I checked, sites_https is one of the most-missed criterion, so giving people some specific help and pointers might make this easier to implement. So, here's the proposed updated detail: You can get free certificates from <a href="https://letsencrypt.org/";>Let's Encrypt</a>. Projects MAY implement this criterion using (for example) <a href="https://help.github.com/articles/securing-your-github-pages-site-with-https/";>GitHub pages</a>, <a href="https://about.gitlab.com/2016/12/24/were-bringing-gitlab-pages-to-community-edition/";>GitLab pages</a>, or <a href="https://sourceforge.net/blog/introducing-https-for-project-websites/";>SourceForge project pages</a>. If you are using GitHub pages with custom domains, you MAY use a content delivery network (CDN) as a proxy to support HTTPS, such as described in this <a href=”https://blog.cloudflare.com/secure-and-fast-github-pages-with-cloudflare/”>blog post</a>, to satisfy this criterion. If you support HTTP, we urge you to redirect the HTTP traffic to HTTPS. Thoughts? --- David A. Wheeler
|
|
|
|
+1
On Wed, Dec 28, 2016 at 8:26 AM, Wheeler, David A <dwheeler@...> wrote: All: --
Executive Director, Cloud Native Computing Foundation <https://cncf.io/> tel:+1-415-233-1000
|
|
|