Lucee.org and HTTPS/TLS


#1

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:


#2

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


#3

@Zac_Spitzer - 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


#4

: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.


#5

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


#6

Updating the whole stack is on our TODO list.


#7

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


#8

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.


#9

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


#10

Also chasing any update on this?

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