Red Hat strives to ship sane defaults that allow both security and availability. Depending on your clients a more stringent or lax configuration may be desirable. Red Hat Support provides both written documentation as well as a friendly person that can help make sense of it all. Inevitably, it is the responsibility of the system owner to secure the systems they host.
Good cryptographic protocols
Protocols are the basis for all cryptography and provide the instructions for implementing ciphers and using certificates. In the asymmetric, or public key, encryption world the protocols are all based off of the Secure Sockets Layer, or SSL, protocol. SSL has come along way since its initial release in 1995. Development has moved relatively quickly and the latest version, Transport Layer Security version 1.2 (TLS 1.2), is now the standard that all new software should be supporting.
Unfortunately some of the software found on the Internet still supports or even requires older versions of the SSL protocol. These older protocols are showing their age and are starting to fail. The most recent example is the POODLE vulnerability which showed how weak SSL 3.0 really is.
In response to the weakened protocol Red Hat has provided advice to disable SSL 3.0 from its products, and help its customers implement the best available cryptography. This is seen in products from Apache httpd to Mozilla Firefox. Because SSL 3.0 is quickly approaching its twentieth birthday it's probably best to move on to newer and better options.
Of course the protocol can't fix everything if you're using bad ciphers.
Good cryptographic ciphers
Cryptographic ciphers are just as important to protect your information. Weak ciphers, like RC4, are still used on the Internet today even though better and more efficient ciphers are available. Unfortunately the recommendations change frequently. What was suggested just a few months ago may no longer be good choices today. As more work goes into researching the available ciphers weaknesses are discovered.
Fortunately there are resources available to help you stay up to date. Mozilla provides recommended cipher choices that are updated regularly. Broken down into three categories, system owners can determine which configuration best meets their needs.
Of course the cipher can't fix everything if your certificate are not secure.
Certificates are what authenticate your server to your users. If an attacker can spoof your certificate they can intercept all traffic going between your server and users. It's important to protect your keys and certificates once they have been generated. Using a hardware security module (HSM) to store your certificates is a great idea. Using a reputable certificate authority is equally important.
Most clients that support SSL/TLS encryption automatically try to negotiate the latest version. We found with the POODLE attack that http clients, such as Firefox, could be downgraded to a weak protocol like SSL 3.0. Because of this many server owners went ahead and disabled SSL 3.0 to prevent the downgrade attack from affecting their users. Mozilla has, with their latest version of Firefox, disabled SSL 3.0 by default (although it can be re-enabled for legacy support). Now users are protected even though server owners may be lax in their security (although they are still at the mercy of the server's cipher and protocol choices).
Much of the work has already been done behind the scenes and in the development of the software that is used to serve up websites as well as consume the data that comes from these servers. The final step is for system owners to implement the technology that is available. While a healthy understanding of cryptography and public key infrastructure is good, it is not necessary to properly implement good cryptographic solutions. What is important is protecting your data and that of your users. Trust is built during every interaction and your website it usually a large part of that interaction.