SSL Vulnerability Debriefing

Note that Ron Rivest reported MD4, MD5 and SHA-1 were “clearly broken,” and recommended migration from MD2 in 1996 [pdf]. See also Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD by Xiaoyun Wang et al. This leaves SHA-256, SHA-384 or SHA-512 and AES.

Fake certificates

See Creating a rogue CA certificate by Alexander Sotirov (December 2008). It is possible to create an MD5 hash collision; with that technique one can create a certificate that appears to have been issued by a trusted certificate authority but which specifies a URL of your choosing. As long as certificate authorities issue certificates signed with an MD5 hash code and client software (typically a web browser) accepts MD5 as a hashing algorithm, “the certificate was confirmed” cannot be sufficient reason to trust the other party.

Null characters

Black Hat USA 2009 presentation [pdf] by Moxie Marlinspike: Certificates can contain null characters that client software does not treat as a terminator. A person can see a expected text and be deceived into accepting an untrustworthy certificate.

Black Hat USA 2009 presentation by Dan Kaminsky, Len Sassaman et al: Also reported null character vulnerability. Reminded attendees that MD2 is not to be trusted (see, for example, Frédéric Muller, The MD2 Hash Function is Not One-Way, ASIACRYPT 2004, pp214–229). We can soon expect MD2 to be “broken;” that is, an attacker with sufficient resources could create a collision. The attacks upon MD2 are not yet practical, but should be soon. Many web sites still use certificates that use MD2. Browsers will soon report such certificates as untrustworthy.

July 29, 2009: Busy day at Black Hat is Tim Callan (Vice President of Product Marketing at VeriSign) response to Moxie Marlinspike’s and Dan Kaminsky’s presentations at Black Hat. Denies that Verisign certificates can contain null characters and agrees that the problem is with the certificate interpreters (the client software) not the (non-Verisign) certificates. Suggests EV SSL or code signing as mitigation measures.

… sites have the power to defend themselves against null character attacks and in fact all attacks using sslstrip.

SSL Strip refers to an earlier Moxie Marlinspike utility that intercepts the browser’s switch from http to https. See HTTPS Web Hijacking Goes From Theory to Practice by George Ou. See Verisign’s whitepaper “Spoofing Server-Server Communication: How You Can Prevent It” by Larry Seltzer [pdf].

August 1, 2009: Versions 3.0.13 and 3.5 of Firefox contain fixes for null characters in certificates.

August 27, 2009: Version 2.0.172.43 of Google Chrome will no longer connect to HTTPS (SSL) sites whose certificates are signed using MD2 or MD4 hashing algorithms.

September 29, 2009: Jacob Appelbaum releases a trick certificate with a null character as the leading character.  In effect, this can be used (in an unpatched browser) to match any domain.

September 30, 2009: Research in Motion releases updated software to clearly indicate the mismatch in names when the Blackberry browser encounters a null character in certificates. Misreported as SMS attacks against BlackBerry certificate flaw possible in SearchSecurity.

Implementation

The least expensive SSL certificates, domain-authenticated certificates, don’t authenticate an organization. They authenticate an internet domain. Users cannot discover with whom they are doing business.

Fault-Based Attack of RSA Authentication [pdf]

March 5, 2010: Power faults can be used to discover a server’s RSA private key. A patch for OpenSSL is forthcoming.

Bottom line

The success of eCommerce relies upon SSL which relies upon customer diligence. That is not a reasonable expectation. This expectation is further jeopardized when vendors establish an SSL connection, then use it only when encrypting form data. Form data is all that must be encrypted and encrypting everything would be slow. However, selective encryption removes the possibility that the customer can be diligent and you are relying upon the customer’s diligence.

If you have been attending to SSL, these announcements should not alter your plans. If you have been neglecting your SSL implementation, then these announcements are reminders that SSL needs periodic review.

It is more likely that your web site will be compromised through a poor implementation of SSL, than through an exotic compromise. See “A study of what really breaks SSL” by Ivan Ristić. See Qualys SSL Labs Threat Model.

An EV SSL appears as a green bar in the browser’s URL window. As a consumer, you want to watch for the green bar; as a merchant, you want to offer the green bar. While this guideline is not a guarantee (there can be EV SSL man-in-the-middle attacks), not observing this guideline is a more dangerous practice.

There are certificates that are not trustworthy. You want to be off MD5 and MD2 hashing as soon as possible. A check of my certificates reveals they are signed with SHA-1, not with MD5 or MD2. MD5 and MD2 are deprecated (that is, to be avoided by using alternatives).

Possible reasons you were relying upon SSL:

1. You provide an eCommerce service. You use SSL to give consumers confidence that you are legitimate.
2. You consume eCommerce services. You use SSL to gain confidence that the web site you connect to is legitimate.
3. You connect two applications (such as IIS and SQL Server) and want to assure that no third application spoofs one or the other; that is, as a defense against man-in-the-middle attacks.

SSL should be implemented as part of a Public Key Infrastructure (PKI) service. There are ways to do this poorly. There are ways that may have appeared trustworthy, but did not foresee problems (such as enhancements in cryptography that found weaknesses in MD2). MD2 was optimized for 8-bit machines. Certificates that used MD2 were highly compatible with older technologies. We should feel comfortable sacrificing 8-bit machine support and feel uncomfortable relying upon MD2.

Extended Validation SSL (EV SSL) provides additional assurance that the web site you are communicating with is legitimate. Generating a certificate with extended validation requires the certificate authority (CA) to collude with the requester when creating a malformed certificate. Offer EV SSL and watch for EV SSL when doing disclosing personally identifiable information (including eCommerce).
See also:

SSL Observatory presentation at Defcon 18 (July 2010, Las Vegas) by Peter Eckersley, Jesse Burns [pdf].

Internet SSL Survey 2010 (Black Hat USA 2010) by Ivan Ristić [pdf].

Practical steps to improve your corporate security posture by Calum MacLeod, Venafi. Managing encryption keys and certificate, with explicit recommendations.

SSLyze (from iSEC Research Labs) is a Python tool that can analyze the SSL configuration of a server by connecting to it.

Venafi Assessor is a downloadable, easy-to-install, free software solution that scans an organization ’s network to locate and analyze deployed digital certificates and the associated encryption keys.

How well do you know SSL? Qualys SSL Labs is a collection of documents, tools and thoughts related to SSL. It is an attempt to better understand how SSL is deployed, and an attempt to make it better. See their SSL/TLS Deployment Best Practices [pdf].