New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Apache SSLProtocol Best Practice?
So what is the current best practice for eliminating bad SSL protocols in Apache? I'm currently using:
SSLProtocol All -SSLv2 -SSLv3
on my server. But a test against https://www.ssllabs.com/ssltest/index.html still shows it as a grade capped to a 'B'.
"This server accepts RC4 cipher, but only with older protocol versions. Grade capped to B."
What are people using on their Apache servers that takes care of all these current vulnerabilities?
Comments
See:
https://cipherli.st/
https://mozilla.github.io/server-side-tls/ssl-config-generator/
https://observatory.mozilla.org/
(edited to improve formatting)
Add these two lines:
Best Regards,
Pavin.
Thanks for these! Bookmarking them.
Boom! With these two new lines, I jumped up from a 'B' to an 'A'! Thanks!
It's often more complicated.
You see, the xSSL people don't keep weaker algorithms and older protocol versions in their library for the fun of it or because they are stupid. They keep them because there is surprisingly (and sadly) much need for it.
If your goal is simply to get an 'A' in some SSL test then you are OK with the above (except maybe that you might want to exclude TLS 1.0 too).
But there are still many rather old machines and systems out there, many of which can't be upgraded because, for instance, some critical software only runs on that old OS version. Keeping your SSL parameters too tight you would exclude many of those.
Plus there are other factors to consider, too. Keep in mind that an open SSL port is basically an invitation for a DOS attack! The reason is the way ssl and later tls have been designed. Any attempt to connect triggers rather expensive processing on your server while the other attacker just needs to keep it open and to finally hang up after a second. All that is needed to bring down many servers, especially one running on a VPS is a couple of hundred or thousand connection attempts (which is ridiculously few in terms of (D)DOS).
The underlaying problem is also often the reason why, looking closer, you'll find that servers do support expensive algorithms but actually have a cheaper (but still reasonable) one as their preferred one.
Plus that whole crypto zoo and particularly ssl/tls is a big and complicated mess in practical terms. Hence I usually advise people to either go with the - hopefully reasonable - default settings or to copy the settings from a security centric site with a good reputation.
The 'A' at least tells me I'm heading in the right direction. But obviously there is a trade off between usability and security as you further mention.
I ended up finding this site: https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility which seems to have a whole bunch of suggested cypher configs depending on your target audience (modern, intermediate, and old compatibility). It sure would have been nice if they had just given the Apache configs rather than all the text....
Edit: looks like they have given us a config generator: https://mozilla.github.io/server-side-tls/ssl-config-generator/
Thanks for the comments!
This is only part of the hardening options you should consider. Perhaps most important after that option with recent versions of Apache would be the SSLCipherSuite. I bet if you set that to HIGH:!aNULL your grade will improve for instance. See the remarks and references by others for additional detail.
Maybe even more important/sensitive: OpenSSH. Many don't know much about those settings and actually some OSs or distros do not even have the algorithms in sshd_config (but go with the default).
To tighten the admin access to your box you would definitely want to make sure there are the following entries:
As this isn't about Joe and Jane everybody you have the advantage that you need not be too careful about not excluding people with very old systems.
Another point there are frequent questions about is rsa or ecc, which should I take?
Short answer for people who aren't interested in the details and background: ECC.
Short explanation: Theoretically both are about equally secure. Mathematically the problem behind the algorithms are related/similar. In particular, a quantum computer (not the show off machines today but real ones with enough qubits and capable to run e.g. Shore) could crack both equally simply.
Practically though ECC is clearly better (and more practical, e.g. regarding keysize) because rsa lives or dies with good prime modules - and that's where the rat is buried because actually almost never real primes are used. What actually is used is "probable primes". The reason being that finding primes is already a quite hard (read: expensive) computational problem. Hence typically some kind of somewhat filtered random numbers are generated and then checked for a high probability of primeness. In other words: this is a scenario in which the one with considerably more computing power has a clear and major advantage. Think "nsa" or the like.
ECC on the other hand is another kind of mathematical problem that has a higher algorithmic complexity and is much less depending on "perfect numbers" (like real primes of good quality).
If you chose ecc you should note that not all curves are equally good and some could even be considered/suspected tainted, namely the nist curves. Better alternatives are the brain and the djb curves.
In case you want to find out more or some practical guides and examples "ciphers and keying" plus "openssh" would be a good search string.