Rubygems.org: Discuss: Require TLS on rubygems.org

[forced-request]

👋 folks!

I wanted to start a discussion on requiring the use of TLS on Rubygems.org. I was surprised this morning when I discovered that the site operated on HTTP by default. With the prevalence of consumer hacking tools that make Man-in-the-Middle (MitM) attacks trivial, users of the site are at an increased risk of having communication compromised.

An attack scenario that comes to mind would be intercepting and rewriting the rubygems.org page that a user has requested, to trick them into installing a gem that has malicious intent.

Is there some requirement to support plaintext HTTP? All modern browsers should handle TLS1.1 and TLS1.2 fine.

I know the Application Security team at GitHub would feel much more confident in knowing that our developers are not at risk when utilizing rubygems.org.

[rubyFeedback]

I think we need to first consider any trade offs related to the move to HTTPS as such. Old browsers, old ruby versions, old computers etc...

What also should be defined is whether HTTP will be removed; or just be a fall-back, if HTTP becomes the default.

In my opinion, once all the trade offs are on the table, making decisions is better, than e. g. quickly moving to HTTPS and in the process disrupt or disable something. As far as I know gem itself requires a working openssl version as-is; I know that because I tended to break that accidentally on my local linux system.

I am not even sure how important rubgems.org is at all; don't most people actually use the commandline way only, when installing any gem?

[forced-request]

Yes, it is very important to consider the trade offs. I suspect someone has access to analytics that could be used to see which percentage of browsers (if any) are unable to support TLS1.1. This is a helpful reference: https://caniuse.com/#feat=tls1-1

I am not even sure how important rubgems.org is at all; don't most people actually use the commandline way only, when installing any gem?

I suspect this is another area where analytics would help. I use it quite frequently for several reasons including searching for new gems and verifying that a current Gem is up-to-date. I.e., it's easier to discover and search via the web UI.

I took a look at the current SSL/TLS implementations, and it looks like we only support TLS1.2. This may be fine since it looks like TLS1.2 has identical browser support to TLS1.1. So with that in mind, I'd recommend forcing the use of TLS by enabling load balancers to redirect to https by default. Furthermore, review all on-site links to rubygems.org and ensure we are hardcoding the use of https:// instead of http://.

After some time (30 days, 6 months, etc) review the situation. If site access has not been problematic after the TLS enforcement, begin to establish a short-lived HSTS header, such as Strict-Transport-Security: max-age=86400; includeSubDomains. This header will ensure that modern browsers never attempt to connect over plaintextHTTP. It provides a short window wherein if any issues arrise the header can be modified/removed while causing a minimal window of interference to the end users.

I see that @dwradcliffe self-assigned himself. Is there anything else I can do to help? I'm happy to cut a PR for s/http/https/ if you'd like to get the ball rolling.

[dwradcliffe]

(I will respond in detail as soon as I have a chance to review some things and write a response. Sorry for the delay!)

[dwradcliffe]

Ok, finally had a chance to sit down and check on what was going on here and respond in more detail. There are really 2 scenarios here that we're trying to accommodate.

Legacy clients - we do have some really really old clients (not browsers) that don't have the option of https connections. For years now we've maintained http support for basic gem installation for these clients. I haven't looked recently at logs to see how much traffic we still have from these clients, but we probably should check again and make a decision if we want to continue supporting this.

Browsers and all modern clients - For several years now we _have_ been trying to push all browser users into https and modern TLS settings. As you noticed, however, at the time you checked the redirects were not actually working. I found that an unrelated change to our CDN config on 2019-08-13 broke our detection of the scheme and thus disabled the redirect behavior. This has been fixed as of a few minutes ago. You should be redirected properly now.

I seem to remember we checked nearly all the links on the site a few years ago and they too should be linking to the correct place (now that the redirects are working). If you find anything we missed feel free to submit a PR.

We started rolling out our HSTS config recently, and we'll extend that to a standard config in the coming weeks.

Hopefully that answers your questions and concerns. If not let me know.

[tobypinder]

Regarding legacy clients, one could imagine supporting them via a dedicated http://insecure.rubygems.org source, but deprecating/HSTSing http access via the main endpoint. This would force those in the minority to make a small configuration change to source in bundler etc that wouldn't require them to upgrade to TLS support, but would also protect the vast majority of users via HSTS.

[simi]

I see rubygems uses TLS by default now. Can we close this?