Modernizing Authentication — What It Takes to Transform Secure Access
If your SSL server have misconfigurations and known vulnerabilities that make it insecure, follow these ten tips to avoid common SSL security mistakes.
1. Disable support for SSL v2 - This version of the SSL protocol was shown to be insecure over 15 years ago, but many web servers still support it.
Disabling it takes no more than a couple of minutes. For example, in Apache v2 you would need to change one line of configuration from the default:https://o1.qnsr.com/log/p.gif?;n=203;c=204634421;s=15939;x=7936;f=201702151714490;u=j;z=TIMESTAMP;a=20304455;e=i
SSLProtocol all -SSLv2
2. Disable support for weak ciphers - Almost all web servers support strong (128 bit) or very strong (256 bit) encryption ciphers, but many also support weak encryption, which can be exploited by hackers to compromise your enterprise network security. There is no reason to support weak ciphers, and they can be disabled in a couple of minutes by configuring your server with a line like:
3. Make sure your server doesn't support insecure renegotiation - the SSL and TLS Authentication Gap vulnerability allows a man-in-the-middle to use renegotiation to inject arbitrary content into an encrypted data stream. Most major vendors have issued patches for this vulnerability, so if you have not already done so make it a priority to implement secure renegotiation or disable insecure renegotiation (making any necessary changes to your site) at the very least.
4. Ensure that all stages of authentication are performed over SSL - Protecting your user credentials is key, and that means sending users your login form over an SSL connection as well as protecting their credentials with SSL when they are submitted to you. Failure to do this makes it possible for hackers to intercept your form and replace it with an evil insecure one which forwards users' credentials to their own servers.
6. Use HTTP Strict Transport Security (HSTS) to protect your domains (including sub-domains) When your website is protected using HSTS, after the first visit all links to the website are converted from http to https automatically, and visitors cannot access the site again unless it is verified by a valid, non-self-signed certificate. That means that hackers will be unable to divert your users to a phishing site that they control over an insecure link (using SSL stripping ) or steal unsecured session cookies (using Firesheep .)
Strict-Transport-Security headers must be sent via HTTPS responses only and configuration can be as simple as a couple of lines. For Apache, this could be:
Header set Strict-Transport-Security "max-age=XXXXXX"
Header append Strict-Transport-Security includeSubDomains
7. Protect cookies using the HttpOnly and Secure flags - Cookies that are used for authentication for the duration of an SSL session can be used to compromise the session's SSL security. The HttpOnly flag makes the cookies you issue invisible to client side scripts, so they can't be stolen via cross-site scripting exploits, while the Secure flag means the cookie can only be transmitted over an encrypted SSL connection and therefore can't be intercepted.
Configuring your web server to issue cookies with both the HttpOnly and Secure attributes protects against both these types of attacks and this can be done by simply adding ; Secure ; HttpOnly to your Set Cookie Http response header:
Set-Cookie: =; =
; expires=; domain=
; secure; HttpOnly
8. Use Extended Validation (EV) certificates - Although this is not vital for the security of your site, EV certificates give a clear visual confirmation in most browser address bars that visitors have made a secure SSL connection to a site that is genuinely yours, and have not been diverted to a phishing site. EV certificates are only issued after a certificate authority has taken rigorous steps to confirm your identity and that you own or control the domain name for which the certificate is being issued.
9. Ensure your certificates include subdomains - To avoid site visitors getting certificate errors make sure that both https://www.yourdomain.com and https://yourdomain.com are covered by your SSL certificate.
You can do this using a multi-domain SSL certificate which will usually allow you to specify up to three Subject Alternative Names (SANs) such as yourdomain.com or www.yourdomain.com.
10. Run an online SSL Server test - You can check your overall SSL security posture, including SSL server configuration, certificate chain, and protocol and cipher suite support, as well as search for known weaknesses such as the renegotiation vulnerability, using the free Qualys SSL Labs SSL Server Test https://www.ssllabs.com/ssldb/index.html