Secure Sites do not pass security scanning software.

ISSUE MIGRATED FROM https://gitlab.com/aegir/hosting_https/issues/38 (see #2934484: Move back issue management to D.o)

I am setting up hosting_https for a client, successfully setup a LetsEncrypt cert, but a security scan by "IBM Security AppScan" still throws issues.

I'm attaching the full report, but the main issues appear to be the old cipher support (according to my client's security person, this is the main problem.)

Deprecated SSL Version is Supported 1
RC4 cipher suites were detected 1
SHA-1 cipher suites were detected 1
Weak SSL Cipher Suites are Supported 1

Colan Schwartz @colan commented 7 months ago

@memtkmcc I just checked the Nginx config templates, and we don't appear to set these anywhere so are just using the defaults. Do you have a good known set you're using already?

Adam Andrzej Jaworski @memtkmcc commented 7 months ago

This is expected, because Aegir by design has left these things for the server admin, and at some point we have made them BOA-specific in Provision (that mysterious $satellite_mode), to respect this "features not policy" Aegir policy.

We do automate this in BOA where we keep these things up to date, so all HTTPS sites hosted on BOA pass all checks with flying colors, and we usually recommend to test this with https://www.ssllabs.com/ssltest/

Example in BOA: https://github.com/omega8cc/boa/blob/master/aegir/tools/system/conf/ssl_...

Code in Provision:

if ($satellite_mode == 'boa'):
## SSL protocols, ciphers and settings
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA;
ssl_prefer_server_ciphers on;

## GeoIP support
geoip_country /usr/share/GeoIP/GeoIP.dat;
endif;

Colan Schwartz @colan commented 7 months ago

How should we handle this then?

Maybe make this configurable by adding it as an item to the Web -> Nginx HTTPS subform on the Server Edit form? The above can be the default.

Jon Pugh @jonpugh commented 7 months ago

So this is a web server configuration issue, not something about the certs themselves?

Thanks, I'll research this more.

Colan Schwartz @colan commented 7 months ago

So this is a web server configuration issue, not something about the certs themselves?

Yes, exactly, but we provide the templates for both Web servers in the module.

If we don't want to enforce policy, let's figure out a way to make this stuff configurable, and use something secure as the default. For example, older clients will require SSLv3, which should not be included by default as it's no longer considered secure. (Hence only TLSv1.1 TLSv1.2 are listed above.)

Jon Pugh @jonpugh commented 7 months ago

Thank you for tips, @memtkmcc. I've read up and learned what was needed:

Upgrade to Apache 2.4.25 (not absolutely necessary, I guess, but might as well: it doesn't support SSLv2 at all.
Remove support for SSLv2 and SSLv3.
Add the recommended SSLCipherSuite and other config: I used Mozilla's helpful tool: https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=a...

I also added a PR to the Aegir SSL documentation about this: https://github.com/aegir-project/documentation/pull/40

Thanks!
Jon Pugh @jonpugh

@colan looks like we wrote in parallel: This config resides in Apache/nginx itself. The majority of which is not messed with by Aegir at all.

So, I'd say adding to the docs is enough for now, but I agree, we should make it easy to be truly secure out of the box

Jon Pugh @jonpugh commented 7 months ago

So maybe this is a feature request, then?

If we don't include this in Aegir HTTPS, I worry we are giving people a false sense of security in the truest sense of the word!

Colan Schwartz @colan commented 7 months ago

That's exactly my point. Let's update the templates in the module to be more secure, but provide them with an easy way to override if necessary.

Colan Schwartz @colan commented 7 months ago

The server Edit form was my suggestion for configurability (see above).

Colan Schwartz @colan commented 7 months ago

See also:

https://mozilla.github.io/server-side-tls/ssl-config-generator/
https://github.com/coopsymbiotic/provision_symbiotic/blob/master/tpl/cus...

Edited 7 months ago by Colan Schwartz

mlutfy @mlutfy commented 7 months ago

^ I've been using this https configuration for some time, and haven't had many complaints recently. My clients are mostly non-profits, they often have really old software, but Windows XP seems finally out.

Adam Andrzej Jaworski @memtkmcc commented a month ago

Re:

Maybe make this configurable by adding it as an item to the Web -> Nginx HTTPS subform on the Server Edit form? The above can be the default.

You don't want to expose this configuration as an option in the web form. Too easy to break the web server configuration and even bring all sites down..

Instead, we could add switches/options to generate proper, but not arbitrary values for different types of expected browser compatibility, because both ssl_ciphers and ssl_protocols depend on the OpenSSL library version available in the system, so there must be a safety/compatibility check which can't be overridden by the user via the front-end.
Herman van Rink @helmo42

Colan Schwartz @colan commented 2 weeks ago

This is going to require more discussion, and isn't necessary for a release. Removing tag.
Colan Schwartz @colan

removed Release blocker label 2 weeks ago

Herman van Rink @helmo42 commented 2 weeks ago

I'm OK with adding such config as optional elements... but feel that it should be the responsibility of either the Distro or the sysadmin.