Settings for hardened TLS/SSL & A+ on SSLlabs (Apache ssl.conf file)

This is for Apache (& I’m running Ubuntu 14.04)

I had been previously running my OC setup on my Mac Mini and found this awesome post (LinkedIN walled) OR (Google cached version) outlining SSL security settings that worked quite well last year. Caveat that since this guys post came out Apple did update OSX Server to allow TLS v1.1 & 1.2 and I ran it perfectly then too for those OSX server users.

Now I’m on a new install of NextCloud with Ubuntu 14.04 as mentioned.

Long story short, for you folks running Apache feel free to look into these settings but they’re giving me a A+ on SSLLabs with a fresh install/new server of NextCloud 10’s already great Security & Hardening guidance & implementations of HSTS settings etc.


#Open
#/etc/apache2/mods-available/ssl.conf
to make changes


#Enable only secure ciphers:

SSLCipherSuite whatever

…mine had SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5

to

SSLCipherSuite 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


#Cipher Order for forced best supported TLS crypto

AND uncomment/delete default ‘#’ then change…

**#**SSLHonorCipherOrder on

to

SSLHonorCipherOrder On


#SSL Protocol

SSLProtocol all

to

SSLProtocol -ALL +TLSv1 +TLSv1.1 +TLSv1.2

*Note, +TLSv1 is required by the NC desktop client so forcing only 1.1 & 1.2 can’t be done.

Adding SSLEngine On as he instrusts to this file ssl.conf gives me an Apache failed error. I haven’t researched why but it is also on and default in the etc/apache2/sites-available/default-ssl.conf file so I don’t think it’s needed here. Test your settings incrementally with service apache2 restart

Btw, I’m running a cron certbot by LetsEncrypt w a RSA 4096 bit key strength.
On initial auto install per Lets Encrypt’s Ubuntu + Apache instructions add –rsa-key-size 4096
certbot-auto --rsa-key-size 4096

I look forward to hearing others TLS settings to keep our NextCloud server ahead of the game. :punch::cloud:

2 Likes

Just a few remarks:

2 Likes

It’s not exactly this!
The problem is not with Android System, but with Android App, than need poor or bad ciphers to communicate with server NC; ciphers based on SSLv3, results the fallback into this protocol even using TLSv1.2.
Do not using App Android if you want setting your server, correctly, with ciphers more secured, as ‘ECDH(E)’.
There are no problem to communicate with web browser, as Firefox, or inside Tor connections, with Orfox (ie, exemple).

@tflidd: thank you, for all those relevant informations :smiley:

@ll : for informations: SSLv3 (layer|protocol) will be deleted into future TLSv3 (in this time, it is a draft). SHA1 will be deprecated end of 2016.

1 Like

If you want a good configuration for your server, you just need to follow the mozilla ssl configuration generator: https://mozilla.github.io/server-side-tls/ssl-config-generator/
coma. :wink:

1 Like

@Guillaume: “Intermediate” mode run with app Androids … but it’s not safe and correct.
“Modern” mode prevents that those applications work - there are can not connect to the server.
And with mode “ultra”, only with ECDHE ciphers, bye-bye the app!

in fact, you are right …
can’t believe this !
all the client should use TLSv1.2 and ECDHE, we should not have to do this kind of tricks …

I tested and changed my original post. Was told +TLSv1.1 & TLSv1.2 aren’t supported by the nextcloud desktop client — only +TLSv1 and below atm. So I edited it to include +TLSv1.

These are great resources all and thank you for contributing to the discussion.

@Guillaume it might also be a problem to rely on Mozilla since they are propagating 256 cipher and TLS1.2 only has 128 as mandatory, so see discussion here https://forums.bitfire.at/topic/720/ssl-handshake-aborted-exception-while-adding-account/17 different Android versions/devices might simply not ship such ciphers being activated and as such it’ll just fail :frowning:

@Guillaume @HucSte @cloud as for Android there is also this: // http://developer.android.com/reference/javax/net/ssl/SSLSocket.html which defines which ciphers are available on which Android version (in general) and which are actually activated by default.

That’s the plan for the Nextcloud Box:

As can be seen on the compatibility list, support for Android <4.4 would be dropped. The plan is to make the config overridable so it shouldn’t be a problem for the <15% of users out there who may be affected, but we may in the end go for something looser which can be tightened by advanced users. I just prefer to have something a bit safer which we don’t need to change every 3 months.

Summary:

  • TLSv1.2 only
  • ECDH only
  • 384bits curve only
  • Drop support for HMAC-SHA1
  • SSL traffic logging
  • SSL compression off
  • Removes support for Android <4.4

Because of browser incompatibility, there is no plan to drop AES128 to achieve the perfect score and OCSP stapling is not enabled.

Anyway, I thought I’d mention this here to collect feedback as well as to give an example config which is quite secure.

2 Likes

Hello Olivier,

  • I think that the TLS configuration must be a collegiale decision on the Nextcloud project. The server side is quite easy to configure, but all the client must be up-to-date with this configuration ! As far as I know, Android client is not working with ECDH only, MacOS is working only with TLS v1 only, and I did not check the others…

  • From my point of view, browser incompatibility is not a probleme : main browser (chrome, firefox, ie/edge) are updating automaticaly, and personaly, I don’t wan’t any people connecting on my server with out of date software. I think it’s a security concern for themselve. They just need to update (lots of linux ditribution works fine on very old hardware) and if they don’t/can’t update then stay on older version of Owncloud/Nextcloud.

  • To conclude, I think that it would be great to have 2 supported versions of Nextcloud

    1. a legacy version (eg NC 10), with long-term support for the people with “old” configuration working with TLSv1 and deprecated cipher-suite
    2. a standard version (eg NC 11 and following) that will follow the latest evolution. Keep in mind that this problem is recurring (TLSv1.3 should come soon and by definition cipher suite are regularly deprecated) so if people don’t want to update their computer, the things will only get worst !

So you disable Nextcloud for about 20% of android users:

Not really:

  • it’s one stats provider
  • stats are 6 months old

And within those, maybe 15%, we have to assess how many devices are actually capable of using the Nextcloud app.

Also, bear in mind that all those devices can still access the web interface.

Yes, that’s the reason I’ve posted a PR, so that people can start testing. It will probably be posted after we make configurations writeable by users.

@Andy could confirm here, but the chart says Android can connect just fine, so it must be fixable in the app itself.

Do you mean the client? If yes, then that could be a problem.

I don’t know if it makes sense to follow the NC releases since the problem lies more with the clients, but this should definitely be coordinated.

Updated the issue with a default config and a recommended one.

@oparoz which chart? see https://github.com/nextcloud/android/issues/228 which describes issues with ciphers e.g. ECDH (!). This is something we have on the radar but is nothing of a top priority (like the Android N instant upload issue, which now hits >1000 users :frowning:)
There are 2 issue to be exact:

From my understanding activating ciphers should be possible (even though we need to test this heavily) TLS support is not possible at the moment since we would have to drop support for Android 14 and 15 to even have TLS 1.1/1.2 (while this is just the Android documentation so OEMs could change this…).

So yes with “Removes support for Android <4.4” this should be possible for the Android app (even though this needs some implementation to activate ciphers where it also is tricky since there are a lot of ciphers which we then potentially would have to active - needs testing if this can be done smoothly with regards to app performance). This would also lead to the decision if it is still possible to configure the server to weaker ciphers or if this should enforce the dropping of support for Android <4.4.

cc @tobiasKaminsky

This is what I’m doing: https://antipaucity.com/2017/07/07/ssl-configuration-for-apache-2-4-on-centos-7-with-lets-encrypt

####[/etc/httpd/conf.d/defaults.conf]

#SSL options for all sites
Listen 443
SSLPassPhraseDialog  builtin
SSLSessionCache         shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout  300
Mutex sysvsem default
SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/urandom  1024
# requires twuewand to be installed
SSLRandomSeed startup exec:/bin/twuewand 64
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/urandom 1024
SSLCryptoDevice builtin
# the SSLSessionTickets directive should work - but on Apache 2.4.6-45, it does not
#SSLSessionTickets       off
SSLCompression          off
SSLHonorCipherOrder	on
# there may be an unusual use case for enabling TLS v1.1 or 1 - but I don't know what that would be
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLOptions +StrictRequire
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache        shmcb:/var/run/ocsp(128000)

#all unknown requests get domain.tld (over http)
<VirtualHost *:80>
    DocumentRoot /var/html
    ServerName domain.tld
    ServerAlias domain.tld *.domain.tld
    ErrorLog logs/domain-error_log
    CustomLog logs/domain-access_log combined
    ServerAdmin user@domain.tld
    <Directory "/var/html">
         Options All +Indexes +FollowSymLinks
         AllowOverride All
         Order allow,deny
         Allow from all
    </Directory>
</VirtualHost>

SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/javascript text/css text/php

####[/etc/httpd/conf.d/z-[sub-]domain-tld.conf]

<Virtualhost *:80>
    ServerName domain.tld
# could use * instead of www if you don't use subdomains for anything special/separate
    ServerAlias domain.tld www.domain.tld
    Redirect permanent / https://domain.tld/
</VirtualHost>

<VirtualHost *:443>
    SSLCertificateFile /etc/letsencrypt/live/domain.tld/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain.tld/privkey.pem
# if you put "fullchain.pem" here, you will get an error from ssllabs
    SSLCertificateChainFile /etc/letsencrypt/live/domain.tld/chain.pem
    Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
    DocumentRoot /var/www/domain
    ServerName domain.tld
    ErrorLog logs/domain-error_log
    CustomLog logs/domain-access_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
    ServerAdmin user@domain.tld

# could put this in defaults.conf - I prefer it in each site config
    SSLEngine on

<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
</files>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>

SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

    <Directory "/var/www/domain">
         Options All +Indexes +FollowSymLinks
         AllowOverride All
         Order allow,deny
         Allow from all
    </Directory>

</VirtualHost>
1 Like

All you guys could do this automatically as well. We wrote a script that installs a real SSL cert from Let’s Encrypt with this script:

Works on Ubuntu 16.04.

2 Likes