TLS server uses insecure cipers / settings
Brought to you by:
mguessan
Menu
▾
▴
#289 TLS server uses insecure cipers / settings
The TLS server module of DavMail uses insecure cipers and other settings.
There is no docuemented way to configure TLS ciphers used or other TLS parameters.
Tested with for example https://www.htbridge.com/ssl/ . Results include:
- The Diffie-Hellman parameter's size is only 1024 bits . A longer one must be generated to prevent Logjam vulnerability.
- The server supports elliptic curves but not the EC_POINT_FORMAT TLS extension.
- The server does not prefer cipher suites. We advise to enable this feature in order to enforce usage of the best cipher suites selected.
- TLS_FALLBACK_SCSV extension prevents protocol downgrade attacks. We advise to update your TLS engine to support it.
- The server supports a client-initiated secure renegotiation that may be unsafe and allow Denial of Service attacks.
Final Grade: F
Overall, the TLS settings seem to not comply to current standards, making it unsafe to use as a server.
DavMail is a java application so you basically have to adjust Java settings, I obtained an A- score at https://www.ssllabs.com/ssltest by just changing jvm settings.
Edit jre/lib/security/java.security and change the following line:
Add the following option in davmail.sh to force Diffie Hellman key size:
-Djdk.tls.ephemeralDHKeySize=2048Note that with those settings DavMail may no longer work with your Exchange server:
=> I got an error message:
=> You have to adjust those settings to match your Exchange server configuration.
Mickael,
thank you for your answer. Changing jdk.tls.disabledAlgorithms in the java.security does indeed help. It is this kind of information I was searching for in the DavMail documentation and FAQ but there is no mention of java security settings at all, not even that such a thing exists.
The instruction to disable TLSv1 and TLCv1.1 is not very helpful though, it would exclude too many clients and might break the connection to the backend exchange server (as you noted).
After the changes the test at ssllabs.com still notes some issues. The main problem is, that DavMail does not provide the cerification path: Our certificate is not directly signed by an entry in the trust store, but by an intermediate certificate authority two steps down. The certificate we use provides the whole certificate chain in a pkcs12 file. Unfortunately, DavMail only uses the server cert, it does not send the rest of the certificate chain, breaking communication with certain client.
How to configure DavMail / Java to provide the certificate chain?
Marku
Additional notes: I removed the sun.security.ssl.allowUnsafeRenegotiation=true added a few years ago for Apple iCal compatibility => this should no longer be required... and may be the main cause of the F grade. Thus you may reenable TLSv1 and TLSv1.1
If you need more options for TLS you should probably check bouncycastle as an alternative to standard JCE implementation.
About your certificate issue: first step is to launch DavMail with -Djavax.net.debug=ssl vm option to check loaded private key and certificates. If you indeed have the full chain in your PKCS12 file you should see all certificates after:
found key for : mykey
Currently we don't do anything specific at this level, we just give the key store to SSL socket factory.
Thank you for your tipps, I managed to create a viable configuration (Qualsys ssllabs.com gives the server an "A-" rating). Unfortunately, the file java.security is overwritten with every update of java. Therefore I placed the option into a separate file and included it. Also, the latest java update included a new default option in java.security (see below):
Steps to harden TLS implementation of DavMail on Windows:
Create file "java.security" in davmail directory, contents:
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5, DH keySize < 768, EC keySize < 224, DESede, RSA keySize < 2048Modify the davmail service entry to include three commandline options (change the path to the exe and to java.security for your installation:
sc config DavMail binPath="\"C:\DavMail\davmailservice64.exe\" -Djdk.tls.ephemeralDHKeySize=2048 -Djdk.tls.rejectClientInitiatedRenegotiation=true -Djava.security.properties=C:\DavMail\java.security"These changes are preserved after a java update. They will have to be re-applied when the service entry is re-created for any reason.
Suggestion: Make these settings easily configurable, for example via entries in the davmailservice64.ini file,
P.S.: The problem with the missing certificate chain problem was on our side: The pkcs12 file did indeed not contain the chain.
Update: jdk.tls.rejectClientInitiatedRenegotiation=true and jdk.tls.ephemeralDHKeySize=2048 are now directly enforced in DavMail code.
I will leave the java.security adjustments to most security concerned users. I assume the official JDK release is supposed to include the latest recommandations.
Current value in JDK 1.8.0_111 is:
Mickael, thank you for your assistance in this matter, this will significantly harden default DavMail installations and reduce complexity of complying with best security practices. When will the new release of DavMail with these new defaults be available?
As for Java seurity settings: As I posted already, the new Java version does include one more disabled Alghorithm (EC keySize < 224):
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, EC keySize < 224
But we cannot rely on Java defaults alone, these settings are always balanced betweenf security and useability for many different applications. The last years have shown clearly that complying with current best security practices requires additional hardening of TLS, above and beyond the defaults set by the software itself. It would therefore be very helpful if DavMail provided an easy way to apply additional TLS settings/restrictions, preferably via a setting in davmail.properties .
Thanks for your feedback, added additional documentation for security conscious users.