In June, Ivan Ristic of Qualys SSL Labs made a presentation at the OWASP AppSec Research 2010 conference called Breaking SSL: Why leave to others what you can do yourself? Ivan contends that “SSL is a rare application security area where we can make things virtually 100% secure, with relatively small effort.” However, he also points out that deployment mistakes are found on many websites and reduce the security of SSL implementations. Here are Ivan’s top 10 SSL deployment mistake and what can be done to get it right.
- Inconsistent DNS Configuration
Your www.example.com address points to one Web server, while example.com points to another or doesn’t resolve at all. Consider configuring your DNS to point both addresses to the same Web server.
- Different Sites on Ports 80 and 443
A user types and expects to see the same site as on . Consider configuring your secure and non-secure websites with the same content.
- Self-signed Certificates
Self-signed certificates condition your users to accept trust dialogue boxes. When a real trust issue appears, it is ignored. Replace self-signed certificates with certificates issued by a reputable public CA.
- Not using EV Certificates
EV certificates give the user visual feedback that they are at the right place. Consider replacing non-EV with EV SSL certificates.
- Poorly Configured SSL Servers
Many deployments rely on the Web server default settings. Unfortunately, these defaults may be wrong or insecure. Use the SSL Labs online assessment tool to identify these problems, and then tune your server as appropriate.
- Using Incomplete Certificates
You type and expect to see the same site as on , but you get a certificate error. This can be fixed by using a multi-domain SSL certificate that supports both example.com and www.example.com in the Subject Alternative Name (SAN) field.
- Mixing SSL and Plain-Text on a Site
Mixed content can lead to man-in-the-middle attacks. Don’t mix SSL and plain-text on a site.
- Using SSL for “Important” Bits
Sites that use SSL only for authentication are vulnerable to session hijacking. Use SSL for authentication and then for the rest of the session.
- Not using Secure Cookies
Non-secure cookies are subject to man-in-the-middle attack. You should always use secure cookies.
- Mixed Page Content
A single plain-text link is enough to compromise the entire “secure” SSL site. Don’t mix secure and unsecure content on a page.