{"action":"created","issue":{"url":"https://api.github.com/repos/isaacs/github/issues/156","repository_url":"https://api.github.com/repos/isaacs/github","labels_url":"https://api.github.com/repos/isaacs/github/issues/156/labels{/name}","comments_url":"https://api.github.com/repos/isaacs/github/issues/156/comments","events_url":"https://api.github.com/repos/isaacs/github/issues/156/events","html_url":"https://github.com/isaacs/github/issues/156","id":29023915,"number":156,"title":"Add HTTPS support to Github Pages","user":{"login":"konklone","id":4592,"avatar_url":"https://avatars.githubusercontent.com/u/4592?v=3","gravatar_id":"","url":"https://api.github.com/users/konklone","html_url":"https://github.com/konklone","followers_url":"https://api.github.com/users/konklone/followers","following_url":"https://api.github.com/users/konklone/following{/other_user}","gists_url":"https://api.github.com/users/konklone/gists{/gist_id}","starred_url":"https://api.github.com/users/konklone/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/konklone/subscriptions","organizations_url":"https://api.github.com/users/konklone/orgs","repos_url":"https://api.github.com/users/konklone/repos","events_url":"https://api.github.com/users/konklone/events{/privacy}","received_events_url":"https://api.github.com/users/konklone/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":337,"created_at":"2014-03-08T15:44:36Z","updated_at":"2016-05-22T00:25:03Z","closed_at":null,"body":"**Note:** Even though `*.github.io` is technically reachable over HTTPS, but this is incomplete. It's not officially supported by GitHub, and GitHub support staff have indicated that the connection is unencrypted between Fastly (GitHub's CDN) and GitHub's origin.\r\n\r\n--------------------------\r\n\r\nGithub obviously takes HTTPS very seriously. It was early to switch to HTTPS everywhere in the site, and @dbussink has already made some [great](https://github.com/blog/1734-improving-our-ssl-setup) [strides](https://github.com/blog/1727-introducing-forward-secrecy-and-authenticated-encryption-ciphers) in shoring it up for Github. \r\n\r\nRecently, Github has given Pages a [proper home](http://pages.github.com/) and place in the Github suite of offerings. I was extremely happy to see that, because Github Pages is one of my favorite things on the Internet and has amazing potential. It's being used for more than simple project pages, and that's only going to continue as Github's reach and accessibility improves.\r\n\r\nGiven all that, **Github should figure out how to support HTTPS on Pages**. Encryption is becoming the standard for the entire web, for many obvious reasons -- to the point that [Chrome and Firefox will require HTTP 2.0 requests to be encrypted](http://www.mnot.net/blog/2014/01/04/strengthening_http_a_personal_view).\r\n\r\nThis is an issue I've brought up with @benbalter from Github before, on a few occasions. We talked about it a bit last month on Twitter, and [he raised the dual point](https://twitter.com/BenBalter/status/412735715706167296) that most people wouldn't turn on HTTPS, yet turning it on by default would wreck a lot of unsuspecting people's sites with mixed content warnings.\r\n\r\nThese are good points, but this can be addressed by:\r\n\r\n* making HTTPS the default for new Github Pages *going forward*\r\n* provide an option for existing Pages to opt-in to HTTPS\r\n* provide an option for future Pages to opt-out of HTTPS\r\n\r\nIn other words: a checkbox, defaulting to on for all future Github Pages.\r\n\r\nThis is the best of both worlds: no one gets surprised with mixed content warnings, and Github gets to proceed with a strong HTTPS policy that will bring a lot of content into the encrypted Internet (aka the future). People who really have to deal with non-HTTPS content can continue to use Pages by unchecking the box.\r\n\r\nSo how would this work? Covering *.github.io domains is comparatively straightforward - install a wildcard certificate.\r\n\r\nHowever, if custom domains weren't supported at the same time, this could pose its own problems: I'm unsure how that would impact automatic redirects to custom domains -- it's not considered best practice to redirect from an HTTPS URL to an HTTP one, and I've seen Chrome flag such a redirect *as a mixed content warning*. \r\n\r\nAdditionally, it would require potentially confusing language and settings to handle different cases, as people add and remove CNAME files. So, it's probably worth tackling both situations at once.\r\n\r\nWhile there are a few solutions, realistically, I believe this means building a dedicated settings pane for managing private keys and certificates. Certificates would need to be handled at the project level, but private keys could be managed at the user level.\r\n\r\nI believe the infrastructure of web hosting can and will rework itself to make encryption on every wire standard and easy for publishers and consumers alike. Github is in a position to really help move that needle, and get huge praise for doing so -- not to mention a competitive edge in site hosting.\r\n\r\nThis is a non-trivial feature request, but the challenge it poses is why I'm not aware of any major option right now for simple, free, secure web hosting -- and why Github meeting this challenge would be so important. Making it easier for people to do powerful things is what Github is all about."},"comment":{"url":"https://api.github.com/repos/isaacs/github/issues/comments/220807521","html_url":"https://github.com/isaacs/github/issues/156#issuecomment-220807521","issue_url":"https://api.github.com/repos/isaacs/github/issues/156","id":220807521,"user":{"login":"whmountains","id":8680147,"avatar_url":"https://avatars.githubusercontent.com/u/8680147?v=3","gravatar_id":"","url":"https://api.github.com/users/whmountains","html_url":"https://github.com/whmountains","followers_url":"https://api.github.com/users/whmountains/followers","following_url":"https://api.github.com/users/whmountains/following{/other_user}","gists_url":"https://api.github.com/users/whmountains/gists{/gist_id}","starred_url":"https://api.github.com/users/whmountains/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/whmountains/subscriptions","organizations_url":"https://api.github.com/users/whmountains/orgs","repos_url":"https://api.github.com/users/whmountains/repos","events_url":"https://api.github.com/users/whmountains/events{/privacy}","received_events_url":"https://api.github.com/users/whmountains/received_events","type":"User","site_admin":false},"created_at":"2016-05-22T00:25:03Z","updated_at":"2016-05-22T00:25:03Z","body":"Wow, that’s worrisome.  The TLDR of that article is that unless you \nhave strict SSL enabled (which requires the $200/mo enterprise plan) \nCloudflare will trust *any* backend cert making it no better than the \npseudo security that Github is trying to avoid.\n\nOn 21 May 2016, at 14:01, Bradford Cottel wrote:\n\n> The significant advantages to CloudFlare's CDN, site optimization, & \n> DNS analytics notwithstanding, don't all of the critiques in this post \n> still apply to CloudFlare:\n>\n> https://scotthelme.co.uk/tls-conundrum-and-leaving-cloudflare/\n>\n> ?\n>\n> If so, it would be great to use a GitLab solution with https \n> redirection from http, barring GitHub finally getting their act \n> together to do proper TLS/SSL from GitHub Pages.\n>\n> Is there a (simple) way to enable that redirect via GitLab that \n> doesn't involve (client-side, presumably) JS magic? If so, I think \n> we've found our low / no cost *and* fully transparent / secure (Pages) \n> solution, which is Let's Encrypt and GitLab.\n>\n> ~ Brad\n>\n> --\n> Mobile: +1 650-804-9555\n>\n>> On May 21, 2016, at 7:34 AM, Eclipse <notifications@github.com> \n>> wrote:\n>>\n>> You could use cloudflare for the https redirect. A bonus with the\n>> cloudflare solution is DNS level analytics and site optimisation, \n>> plus a\n>> CDN.\n>> On 21 May 2016 14:50, \"Sergey Lukin\" <notifications@github.com> \n>> wrote:\n>>\n>>> I've just generated Let's Encrypt SSl certificate and uploaded it to \n>>> my\n>>> newly setup Gitlab pages - works like a charm. Only drawback is that \n>>> there\n>>> is no HTTP redirect header from http:// to https:// but tiny JS \n>>> snippet\n>>> kind of fixes that although it's not perfect. Eager to see \n>>> certificate auto\n>>> renewal feautre.\n>>>\n>>> —\n>>> You are receiving this because you commented.\n>>> Reply to this email directly or view it on GitHub\n>>> <https://github.com/isaacs/github/issues/156#issuecomment-220778832>\n>>>\n>> —\n>> You are receiving this because you were mentioned.\n>> Reply to this email directly or view it on GitHub\n>>\n>\n>\n> ---\n> You are receiving this because you were mentioned.\n> Reply to this email directly or view it on GitHub:\n> https://github.com/isaacs/github/issues/156#issuecomment-220788827\n"}}
{"actor":{"display_login":"whmountains"}}