redirect http requests to https to satisfy Chrome

[mbutterick]

To be clear: this is Chrome idiocy. But as with much Chrome idiocy, it is often imputed back to the webmaster. https seems active on all Racket websites. But typing in racket-lang.org to a Chrome URL box still selects the http version by default, and produces the naughty-looking “not secure” warning. The fix is to redirect all http requests to https.

[samth]

@mflatt and I were discussing this yesterday. For most everything (everything that's fronted by Cloudflare) we can just press a button and it ought to work, but we should perhaps decide when a good time to hit the button is.

[jackfirth]

Out of curiosity, does this button enable a plain redirect or does it turn on HSTS?

[samth]

The former.

…

On Fri, Feb 8, 2019, 9:44 AM Jack Firth ***@***.*** wrote: Out of curiosity, does this button enable a plain redirect or does it turn on HSTS? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#88 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAO78xheZ2Ggdenbj8t7efY_p2RQzJMBks5vLbdzgaJpZM4av9xI> .

[jackfirth]

Is the latter a feasible option? The former is (relatively) insecure.

[samth]

The redirect is now implemented. There's still a http:// resource on school.racket-lang.org/2019 which is no longer the active page, but people may still be linked to it. Otherwise, Firefox shows everything working well on all the pages I've checked.

After checking that everything is working and that it won't take on too much risk, I'm going to enable HSTS as well.

[mbutterick]

Is it possible this change had an unintended consequence with the catalog server? I’m now getting Travis build failures for Racket 6.0 that look like this:

Resolving "txexpr" via http://download.racket-lang.org/releases/6.0/catalog/
ssl-connect: connect failed (error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert 
handshake failure)

I wonder if the http link is becoming https, and then Racket 6.0 doesn’t know how to handle it?

But recently, the package-server infrastructure has been generally flaky, so this is only a guess.

[mbutterick]

@mflatt wrote

We’ve turned off HTTP->HTTPS for now. Part of the idea is to check whether that fixes the package server, as you have suggested.

My quick check suggests that yes, this does fix the package server (inasmuch as Travis CI builds against 6.0 now work normally)

Do you need v6.0 support, or would supporting/testing only v6.2 and later be ok?

If Racket Command decides that this is the path forward, it doesn’t bother me to drop support for pre-6.2. I’m merely trying to be a good citizen by not obsoleting older versions that I don’t have to. The CI builds are the only way I know whether the software still works on those older versions.

(I’m aware that I seem to be arguing both sides of the HTTPS issue. I didn’t know about this interplay.)

[samth]

@jeapostrophe fixed pkgs.racket-lang.org today, so we've turned the redirect back on.

@mbutterick this will still break the ability of pre-6.2 Racket to contact download.racket-lang.org, which is the failure you saw. If people are concerned about this, we can consider trying to make this still work.

[abmclin]

This may be the reason why raco pkg installation on my TrueOS FreeBSD system is now broken. I don't recall having this problem before. Whenever I try to install a package from the main catalog in Racket 7.2, the error says ssl-make-client-context: requested protocol not supported; SSL not available; check ssl-load-fail-reason

Analyzing the error by evaluating (require openssl) ssl-load-fail-reason I get ffi-lib: couldn't open "libcrypto.so" (Shared object "libcrypto.so" not found, required by "racket")

Checking my system, I see there's libcrypto.so.111 under /lib. I tried creating a symbolic link libcrypto.so pointing to the previously mentioned file but no luck. I'm not sure but possibly the error is arising from a difference between how dynamic libraries are searched for between Linux and BSD variants and this is only being exposed because of the switch to forced use of https.

[samth]

Probably you need to add a new entry to this list: https://github.com/racket/racket/blob/master/racket/collects/openssl/libcrypto.rkt#L35

[greghendershott]

Can the package server force a redirect to https -- or not -- based on the value of the User-Agent header?

I'm guessing that raco supplies one with "Racket" in the value, or (perhaps in older Rackets) no User-Agent header at all.

[greghendershott]

By the way, I have some packages where I am still trying to support Racket versions older than 6.2.

Why? Because I've had no reason to drop support. Travis CI helps me identify blatant problems like using procedures provided only in newer versions of Racket. If CI can no longer help with that (because older versions of raco can no longer install anything), I will need to drop < 6.2 support.

I wanted to point out that it's a consequence. I don't know if it's a particularly bad one.

[samth]

Currently we're doing this at the Cloudflare CDN level, rather than on download.racket-lang.org. That doesn't make this easy, but it could be possible (although it would almost certainly cost some money). Alternatively we could do the redirect somewhere else, at the cost of some more work.

For pre-6.2 Racket, it would no longer be possible to install any packages via the package catalog with this change, so you'd have to drop support regardless.

If anyone actually wants to support pre-6.2 Racket, or even more significantly wants to use pre-6.2 Racket, then saying that would be helpful.