Is there any reason we’re not using HTTPS/TLS for lucee.org at present?
…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.
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
@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.
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
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
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.
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
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.
@JoyMiller - If this isn’t yet ticketed for the site relaunch, can you please jot it down? Thanks!
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!
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.