4 ms·

GitHub is now SSL only

51 points by abraham 16y ago

mrchess 16y ago
GG Firesheep
ElbertF 16y ago
Awesome, hopefully other big sites will follow suit. I wonder if the hype around Firesheep was part of the motivation to make this change.
- abraham 16y ago
  Yes it did: https://github.com/blog/737-sidejack-prevention https://github.com/blog/737-sidejack-prevention
itsnotvalid 16y ago
That is a good start. Although I am not a paying user (which would have TLS if I am one), that makes everyone protected from the benefits. I also hope that they would not suffer from performance issues, as I've see several loading problems since the change.
- kneath 16y ago
  We have always implemented SSL regardless to your paid or unpaid status. This is an unfortunate inaccuracy in Eric's Firesheep followup post that he refuses to correct. Previously, SSL was only implemented on private facing pages, such as (everyone's) dashboard, (everyone's) account pages, (everyone's) repository admin pages and all pages under private repositories. I know it's a small difference (private vs paid), but GitHub would never hold security hostage for money — the thought of that makes my skin crawl.
  - bostonvaulter2 16y ago
    Back when github first launched, SSL protection was only included on private repositories. http://web.archive.org/web/20080621111340/http://github.com/plans http://web.archive.org/web/20080621111340/http://github.com/... Although I may be misunderstanding something.
    - kneath 16y ago
      Well, first off... that's a really old archive (come on now). The problem there was that the wording was wrong (private repositories vs paid accounts).
      - itsnotvalid 16y ago
        Thanks for correcting me on this regard. Now it is nice that TLS is mandatory.
christefano 16y ago
That link shows me a 404. This worked instead: https://twitter.com/github/status/29534618326 https://twitter.com/github/status/29534618326
- abraham 16y ago
  Might be a hiccup in #newtwitter. It works fine for me.
jparise 16y ago
Bonus meta points for using HTTPS for this item's Twitter link.
- uxp 16y ago
  Yet, my Chromium is complaining that there is un-secure content. A quick resource inspection shows that the triangle image that links the content body div to the twitter logo (right under the W in twitter), is being transmitted over http, not https. I've always been a little paranoid on the internet. Firesheep has increased the paranoia, and a 21x11 pixel image coming from twimg.com just broke all the trust in Twitter I had.
  - abraham 16y ago
    Twitter is terrible about including non SSL assets and always has been.
stevejohnson 16y ago
Note that this may break any API libraries. For example, github2 broke. I have patched it: github.com/irskep/github2 Yes, I need github2 bad enough to patch it within two hours of it breaking. Otherwise the "Steve's last 10 Github commits" stream won't display on my site! The horror! Edit: Scratch that. Apparently I was cloning from the wrong repository and the up-to-date version works fine.
- alanh 16y ago
  Sometimes it isn’t so obvious what the canonical repo is, right? That could use improvement, generally, on GitHub. E.g. a low-friction way to say, “hey, this is just a fork I made to fix a bug — don’t clone me!” etc.
- technoweenie 16y ago
  The API should still allow HTTP requests. No cookies are involved, so they shouldn't be vulnerable. I would like to keep things all SSL for consistency, but I think that'll require a bit more notification to API developers.
erikano 16y ago
Wouldn't it also make sense to have HTTPS as default for the read-only clone URL? I for one always replace "http" with "https" before cloning.
- technoweenie 16y ago
  No HTTP cookies are involved, so no. For now, git will always ask for your password for https clone urls.
- pilif 16y ago
  I don't know. The code you are cloning is already public (exception: private repos), so it leaking to a third party is a non-issue. Additionally, a MITM changing the code on-the-fly to give you a troian horse is quite impossible to pull off as this would completely change revision IDs which you'd notice. The reason for public http cloning be there at all (as opposed to the git protocol) is restrictive firewalls (git's http support still isn't perfect), which are more likely to cooperate with http as opposed to https
  - uxp 16y ago
    Is the git protocol unencrypted as well for read-only public repos? I should probably know the answer to that already, but I'm coming up blank. I guess a solution (for a non-issue) of pulling public repositories would be to fork the repo over the secure GitHub interface and then pull your fork over ssh...

51 points by abraham 16y ago

GG Firesheep

Awesome, hopefully other big sites will follow suit. I wonder if the hype around Firesheep was part of the motivation to make this change.

abraham 16y ago
Yes it did: https://github.com/blog/737-sidejack-prevention https://github.com/blog/737-sidejack-prevention

itsnotvalid 16y ago

That is a good start. Although I am not a paying user (which would have TLS if I am one), that makes everyone protected from the benefits. I also hope that they would not suffer from performance issues, as I've see several loading problems since the change.

kneath 16y ago
We have always implemented SSL regardless to your paid or unpaid status. This is an unfortunate inaccuracy in Eric's Firesheep followup post that he refuses to correct. Previously, SSL was only implemented on private facing pages, such as (everyone's) dashboard, (everyone's) account pages, (everyone's) repository admin pages and all pages under private repositories. I know it's a small difference (private vs paid), but GitHub would never hold security hostage for money — the thought of that makes my skin crawl.
- bostonvaulter2 16y ago
  Back when github first launched, SSL protection was only included on private repositories. http://web.archive.org/web/20080621111340/http://github.com/plans http://web.archive.org/web/20080621111340/http://github.com/... Although I may be misunderstanding something.
  - kneath 16y ago
    Well, first off... that's a really old archive (come on now). The problem there was that the wording was wrong (private repositories vs paid accounts).
    - itsnotvalid 16y ago
      Thanks for correcting me on this regard. Now it is nice that TLS is mandatory.

christefano 16y ago

That link shows me a 404. This worked instead: https://twitter.com/github/status/29534618326 https://twitter.com/github/status/29534618326

abraham 16y ago
Might be a hiccup in #newtwitter. It works fine for me.

jparise 16y ago

Bonus meta points for using HTTPS for this item's Twitter link.

uxp 16y ago
Yet, my Chromium is complaining that there is un-secure content. A quick resource inspection shows that the triangle image that links the content body div to the twitter logo (right under the W in twitter), is being transmitted over http, not https. I've always been a little paranoid on the internet. Firesheep has increased the paranoia, and a 21x11 pixel image coming from twimg.com just broke all the trust in Twitter I had.
- abraham 16y ago
  Twitter is terrible about including non SSL assets and always has been.

stevejohnson 16y ago

Note that this may break any API libraries. For example, github2 broke. I have patched it: github.com/irskep/github2 Yes, I need github2 bad enough to patch it within two hours of it breaking. Otherwise the "Steve's last 10 Github commits" stream won't display on my site! The horror! Edit: Scratch that. Apparently I was cloning from the wrong repository and the up-to-date version works fine.

alanh 16y ago
Sometimes it isn’t so obvious what the canonical repo is, right? That could use improvement, generally, on GitHub. E.g. a low-friction way to say, “hey, this is just a fork I made to fix a bug — don’t clone me!” etc.
technoweenie 16y ago
The API should still allow HTTP requests. No cookies are involved, so they shouldn't be vulnerable. I would like to keep things all SSL for consistency, but I think that'll require a bit more notification to API developers.

erikano 16y ago

Wouldn't it also make sense to have HTTPS as default for the read-only clone URL? I for one always replace "http" with "https" before cloning.

technoweenie 16y ago
No HTTP cookies are involved, so no. For now, git will always ask for your password for https clone urls.
pilif 16y ago
I don't know. The code you are cloning is already public (exception: private repos), so it leaking to a third party is a non-issue. Additionally, a MITM changing the code on-the-fly to give you a troian horse is quite impossible to pull off as this would completely change revision IDs which you'd notice. The reason for public http cloning be there at all (as opposed to the git protocol) is restrictive firewalls (git's http support still isn't perfect), which are more likely to cooperate with http as opposed to https
- uxp 16y ago
  Is the git protocol unencrypted as well for read-only public repos? I should probably know the answer to that already, but I'm coming up blank. I guess a solution (for a non-issue) of pulling public repositories would be to fork the repo over the secure GitHub interface and then pull your fork over ssh...