What You Really Need To Know About EV Certificates

SSL certificates are used for two purposes, encryption and validation. The encryption portion ensures the traffic is not readable by anyone other than the correct sender and receiver. The validation portion ensures that the server is actually who it says it is.

Validation was not the primary consideration when developed by Netscape in the early 1990s.

In the wake of the Superfish (affecting Lenovo), Komodia and PrivDog vulnerabilities, it is a good idea to look at what the problem was, and how you can protect yourself and your end users or customers.

Unintentional Trust

Your browser will happily accept an SSL certificate that was signed by a trusted Certificate Authority (CA). These are typically public Certificate Authorities such as Verisign. The way the system knows if the Certificate Authority is trusted is by checking the operating system’s local trusted Root Authority Store.

This process is great, other than the fact that anyone, or any piece of authorised software, can insert themselves as a trusted root Certificate Authority on the operating system.

This is how the Komodia component in Superfish worked. It made itself a trusted root CA by installing a certificate to the trusted root certificate authority store.

How SSL Inspection Works

This process is in fact exactly the same way proxy SSL inspection works. The difference is that installing the certificate it is intentional and legitimate with the signing certificate typically distributed via group policy in a corporate domain.

What happens in these cases is the browser attempts to connect to the HTTPS web site. The proxy intercepts this request, it establishes the trusted tunnel from itself to the website, and the on the way back it signs the HTTPS traffic with its own certificate effectively impersonating the original website to the browser. If the proxy’s certificate is trusted you would not know anything was going on unless you checked the certificate issuer and discovered it was issued by the proxy and not by one of the public certificate authorities.

Here is an example of where Sophos UTM has been configured for SSL inspection. When you look at the certificate, that you notice the certificate was issued by the company's own UTM and not by a trusted public CA. There is no warning since the certificate authority is present in the Windows Trusted Root Certificate Authority store.

So basically, using standard SSL certificates for site SSL validation can’t truly be trusted any more, as they can be falsified by corporate web gateways, and unintentionally installed trusted root certificates.

EV Certificates to the Rescue!

This problem was identified back in 2005 and the solution was conceptualised and implemented around 2007 by the Certificate Authority Browser Forum (CAB). As its name suggests, the CAB is a collaboration between the CAs and the browser manufacturers (note that the operating system manufactures are not included) and they came up with a better way of performing the validation role of certificates, this time making it a priority. They do this by implementing:

• Much stricter guidelines to the parties being issued certificates
• Much stricter guidelines to the member CAs that would be trusted
• Browser validation being used and system validation being ignored

According to section 2.1.1.1 of the Guidelines for the Issuance and Management of Extended Validation Certificates the primary function of an EV certificate is:

Identify the legal entity that controls a Web site: Provide a reasonable assurance to the user of an Internet browser that the Web site the user is accessing is controlled by a specific legal entity identified in the EV Certificate by name, address of Place of Business, Jurisdiction of Incorporation or Registration and Registration Number or other disambiguating information

This means that much more actual validation is performed by the CA. This includes confirmed established communications with the legal representatives of the company such as the CEO. There are legal documents that need to be completed signed and returned. The process is, by definition, extensive.

The CA members that can issue EV certificates are also controlled. Only a few CAs are able to issue the EV certificates and they themselves are held to much higher standards. They also run the risk of being evicted from the CAB should they violate any of the set standards. There are currently only 29 CAs able to issue EV certificates compared to the 250 + Trusted Root Authorities on an iOS device.

The last additional validation point is where it gets really interesting from a technical perspective.

Browser Certificate Validation

Browsers, generally speaking, are nice enough to show you when you are looking at a site that is secure and trusted. The different browsers show this in different ways, and they also tend to change this behavior periodically.

Invalid/Untrusted Certificate Browser Behavior

It is important to note that even if a certificate fails validation, it does not mean traffic is not encrypted. It is encrypted, just not by a trusted source.

When a certificate fails all validation, the browsers typically display a "Nag Screen" where you confirm whether or not you want to proceed before allowing you through to the site.

This is what an invalid or untrusted certificate looks like in Opera, Chrome, Firefox and Internet Explorer.

• Only Chrome and IE continue to show that the certificate is not valid.
• Opera and Firefox allows you to easily accept and trust the certificate (even if you shouldn't)

Standard Certificate Browser Behavior

If a standard certificate passes the validation test, then no nag screen is presented. This is what a standard valid certificate looks like in the same four browsers.

• Opera does not show a padlock icon at all
• Chrome show a green padlock and green https
• Firefox show the padlock in grey at the start of the address bar
• IE also show a grey padlock at the end of the address bar (typically at the other end of the screen)

EV Certificate Browser Behavior

The browsers who are CAB members (Chrome, Firefox, Opera, Internet Explorer, Safari and others) do not look at the operating system when trusting EV certificates. The browser knows it is an EV certificate because the OID (object identifier) used by a CA for EV signing is different to the OID used for standard certificates. Other than that, EV certificates and standard certificates are identical.

When an EV certificate is encountered, it completely skips the system's PKI store. Instead a browser looks at its own internal CAB CA store and only accepts EV certificates from those CAs.

The main point of difference between a standard certificate and an EV certificate is that the company name is displayed when an EV certificate is validated. Three of the four major browsers appear to at least be following a standard(ish) guideline.

Pros of using EV Certificates

This method of browser PKI validation breaks that weak dependency of the legacy system PKI validation process.

The method further means that there is nothing you can do to the system to influence the validation of EV certificates. Effectively it makes EV certificates spoof proof. If you see the EV indication in the browser, it means the site has been correctly identified as belonging to the indicated entity and is thus verified. You are not trusting the operating system, you are trusting the browser.

The take from this is two fold:

• You as a user now know that EV certificates means more than just a green address bar.
• As an administrator you also know that using EV certificates protect you, your company and the end user from spoofed certificates and 'man in the middle' (MIM) attacks.

Cons of using EV Certificates

The penalties for using EV certificates are:

• They are more expensive
• They are generally valid for shorter durations
• The hassle of going through the validation process.

You may therefore choose not to use EV certificates for every single site you publish to the Internet, especially if you have many of them, but you should definitely consider using them for important sites such as your online retail or banking site.

Informing Website Visitors

You can further enhance security and limit potential liability by using the site itself to inform users to check for the green EV status, as ultimately it is only the end user who can choose to use a site regardless of the certificate status.

By using EV certificates and informing end users, you are doing the maximum you can to identify and verify yourself to them, and this speaks to due care and diligence on your side to help protect the users. Below is a mock up image I used in a presentation to illustrate this concept.

EV Certificates in Firefox

The article so far has described the general behavior of EV certificates, but there is some variance between operating system and browser configurations. The most notable is that Firefox never looks at the system's certificate store. It maintains its own trusted CA store, which you need to amend manually through the browser itself if you want to add your own CA. There is also the secondary EV CA store that is not editable.

EV Certificates in Internet Explorer

Internet Explorer enables you to add your own internal PKI as an EV CA for use in your company. This is done by first configuring your internal PKI to support EV certificates, and then the internal CA needs to be distributed through group policy. And yes, it kind of defeats the purpose of having EV if you can mess around with it.

Conclusion

This was a very lightweight introduction to EV certificates. I hope that you have found it informative and that the knowledge you gained here helps to keep you safer during your Internet browsing and web site publishing endeavours.

The EV concept is great and fixes a number of issues, but it is still not perfect. If this has sparked your interest, check the references below for more detailed information.

• RFC 6125: Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX). Certificates in the Context of Transport Layer Security (TLS)
• CAB - CA/Browser Forum
• Guidelines For The Issuance And Management Of Extended Validation Certificates - Published by the CAB.
• Extended Validation Certifications (wikipedia) (Handy tables here!)
• Breaking the Myths of Extended Validation SSL Certificates - Blackhat Briefings 2009.
• How HTTPS / SSL Inspection Affects Logging and Reporting in Sophos UTM