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 <notifications@github.com 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 https://github.com/racket/racket-lang-org/issues/88#issuecomment-461885991, 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.

[greghendershott]

Do you have stats for URLs like http://download.racket-lang.org/releases/6.0/catalog/? It won't be zero if only because of CI scripts. :smile:. But it might be tiny enough.

[samth]

I don't immediately have the logs for that machine, but I'll see what I can find.

[abmclin]

After some experimenting and reading up on the expected conventions regarding shared libraries on *nix platforms. The convention is to have a libcrypto.so symbolic link to the latest version of libcrypto.so.xxx on the platform. It's not absolutely required since typically programs link to the specific version of shared library they want. It makes sense for racket to use versionless as first choice to ensure maximum portability.

In any event, I'm able to resolve the problem simply by adding the missing symbolic link by installing the development package version which will automatically configure the links.

I don't think any changes are necessary in libcrypto.rkt.

[samth]

Well, it shouldn't be necessary to install the development package for Racket to work. If you add "111" to that list, does that fix the problem?

[abmclin]

Adding 111 to the list does fix the problem, shall I open a pull request with the new list entry?

Aside, the resolution of the libcrypto.so problem exposed an entirely new problem that is not related to the previous one as far as I can tell. I will move discussion of the new problem elsewhere.

[samth]

Yes, a PR for that would be great. I wish that there was something that would just make this work in general, but we haven't found it yet.

[jarcane]

I was hoping to maintain support for 6.0.1 in Heresy, because I just got a retro iBook and 6.0.1 was the last version built for PowerPC. 😞

Unfortunately, we depend on rackjure so I guess that's a no go unless I can find a way to replace that dependency. I'll have to see what I'm using.

[samth]

@jarcane Is the issue just about pre-built binaries? Could you compile 6.2 yourself?

[jarcane]

I honestly don't know. I will have to try; might be a few days before I can get to it though.