SSL Deployment Mistakes

Bruce Morton

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. Not using Secure Cookies
    Non-secure cookies are subject to man-in-the-middle attack.  You should always use secure cookies.
  10. 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.
Bruce Morton
Bruce Morton
Director, Certificate Technology & Standards

Bruce Morton has worked in the public key infrastructure and digital certificate industry for more than 15 years and has focused on SSL and other publicly trusted certificates since 2005. He has been an active member of the CA/Browser Forum that released guidelines for extended validation (EV) certificates and Baseline Requirements for SSL certificates. Bruce oversees the governance and compliance of Entrust’s publicly trusted PKI.

1 Comment

Add to the Conversation