Lucee.org and HTTPS/TLS

Afternoon all - happy Tuesday.

Is there any reason we’re not using HTTPS/TLS for lucee.org at present? :unlock:
…and if not, anything we/others can volunteer to do to help you get to that place?

Particularly concerned with JAR downloads from cdn.lucee.org. SHA checksums served from behind HTTPS would be a great addition for ensuring the validity of any JAR downloads.

Cheers. :beers:

1 Like

oh yeah! i’m guessing it might be a bit complicated for lucee due to the quirky need to import certificates via the admin? anyone know why this manual process is (still) needed, especially given the world has moved to https in the last few years

here’s the relevant bug
https://luceeserver.atlassian.net/browse/LDEV-1506

@Zackster - there is no need to import the certificates into the admin for Trusted TLS certificates, that is only for untrusted certificates like self signed ones… As long as the version of Java you are using is not outdated you should never need to import any certificates signed by a trusted certificate authority.

The cdn.lucee.org site is redirected to Amazon CloudFront: http://d8yjolse1mixx.cloudfront.net/ it is really easy to setup CloudFront to serve a HTTPS - you can even generate and manage the certificate for free all from within CloudFront as well. I do this for cfdocs.org which is served by cloud front using https. All you have to do is click edit on General Settings, then click the button to generate a certificate using ACM (Amazon Certificate Manager). Here’s a screenshot:

You can see there that the server will require a client capable of SNI, which should be fine on any Java 8+ server. Even if you decide not to default cdn.lucee.org to HTTPS - it should at least support https.

As a workaround you can change http://d8yjolse1mixx.cloudfront.net/ to https://d8yjolse1mixx.cloudfront.net/ but who is to say that d8yjolse1mixx.cloudfront.net is the correct hostname? – I got that from an unsecured request to cdn.lucee.org

2 Likes

:point_up: +1 .

(Thanks for the bug link)

Being able to compare checksum after download would be a very welcome feature - but of course completely useless unless we can verify the checksum itself hasn’t been tampered with.

Bonus points for enabling DNSSEC at the same time.

thanks Pete, it’s late night here down under and I had a brain fade :blush:

I just checked and according to the headers the lucee.org web server is also running what appears to be a four year old version of nginx/1.4.6 which was released way back in 04 Mar 2014 http://nginx.org/en/CHANGES-1.4

Updating the whole stack is on our TODO list.

An easy fix for this is to just use Cloudflare as CDN in front of what you have. That’s how I am handling a bunch of “gotta update the whole thing” resources.

Mark Drew

Cloudflare is great - but only if you run with “Full (Strict)” to the Origin, and thus ensure valid TLS for the whole journey. Unfortunately many people are setting it up in either “Flexible” or “Full” mode, neither of which is secure, whilst masking the issue from the end user.

  • Flexible creates a HTTP connection (non-SSL) between Cloudflare and your Origin. Whilst that mitigates the chances of a MITM between Consumer + Cloudflare, it does nothing to prevent MITM between Cloudflare + Origin (Lucee.org).

  • Full at least uses TLS between Cloudflare + Origin, but doesn’t verify the certificate is valid. As such this also doesn’t prevent a MITM attack between Cloudflare <=> Origin.

By implementing IP blocks, and authenticated origin pulls, for Lucee.org (where it’s mostly GET requests) you can mitigate this to some extent, however not for critical data travelling in both directions.

is this ever going to happen? ideally the next RC should be configured to update over https urls, otherwise this can will just keep on getting kicked down the road

Also chasing any update on this?

More than happy to volunteer time to point you in the right direction if it helps.

How can we make this happen @IamSigmund ?

Hey Zac. As part of the imminent site relaunch (main website at lucee.org), we’ll also be reviewing and updating some of the related parts, like HTTPS for the CDN, overall hosting setup, etc. Rumor has it we have some AWS experts in the house. :thinking:

@JoyMiller - If this isn’t yet ticketed for the site relaunch, can you please jot it down? Thanks!

1 Like

@IamSigmund I added this to our project tracking for the new website in Asana.

Thanks!

Thanks for your help on this @IamSigmund / @JoyMiller . Great to hear it’s in progress.

Any update on the new site launch? Anything we can do to help?

Have a great week!

Greetings. Joy can give the latest status update, but she’s out of the office until mid-week, so we likely won’t hear from her until end-of-week. More soon!

Adding @Dominic_Watson and @sanderbruinsma to this conversation. Dom is doing the majority of the building blocks for the website.

We have a call next week to get status of the website. My hope is that we are VERY close to having our first version out there.

Dom, I believe the https is planned for when we make the site public, correct?

Hi @JoyMiller, @Dominic_Watson,

Just wondering if there was ever any update on this? As ever, please do let us know if we can help.

Thanks

1 Like

We are planning to launch the new site this week! I need to get some things in place on this end and then Dom’s colleague, Jack will make the switch. Dom is on vacation currently.

Awesome news!