The recent Superfish incident has raised more concerns that SSL/TLS connections of users can be intercepted, inspected, and re-encrypted using a private root certificate installed on the user system. In effect, this is a man-in-the-middle (MITM) attack carried out within the user's own system. We believe that site owners adopting extended validation (EV) certificates would help warn users about possible MITM attacks. Here’s how a MITM interception works:
Figure 1. Man-in-the-middle attackMITM attacks are justified by their creators as providing benefits to users, either by scanning for viruses and malware in encrypted material or by displaying relevant advertising. Whether or not these benefits are valid or not is a separate debate, but certificate authorities like Trend Micro agree that secret MITM interceptions are not appropriate. These can invade the privacy of the user without express notice or consent, and they may also open attack vectors that attackers can use to gain access to the user’s information. MITM interception is frequently carried out within corporate networks to check incoming encrypted content for malware, web threats, and other potential risks. This is a legitimate security technique. However, in a corporate network the users (employees) are presumably aware that their internet usage can be monitored by their employer, and so they have effectively given consent. More significantly, the rules governing browser trusted root programs bar CAs from issuing unconstrained sub-CA certificates to corporate customers that could then be used in MITM interceptions to “mimic” the real certificates of websites (as Superfish did). Use of such a sub-CA certificate from a commercial CA would mean the user could never know that their secure connections had been decrypted, viewed, and then re-encrypted. Corporate networks must provide their own self-signed certificates to perform MITM interception. Superfish and PrivDog were particularly troubling because they installed their own untrusted private root certificates in the client’s trusted root store, sometimes without the user’s explicit knowledge or informed consent. Once the certificate is in the trusted root store, future MITM interception will not generate any warnings about the certificate coming from an untrusted root, as the MITM certificate is now explicitly trusted. How can EV certificates help in this situation? Connections made with valid EV SSL certificates adds information about the identity of the site, which is then shown to the user in a distinct "green bar". Below is an example of how it is shown to the user in Mozilla Firefox (other browsers use similar displays):
Figure 2. Browser loading a SSL site using an EV certificateThe identity of the site owner is explicitly displayed here. In contrast, typical SSL connections show that the connection is encrypted but do not say anything about the site's identity:
Figure 3. Browser loading a SSL site without an EV certificateIn addition, EV certificates include safeguards not used in other certificates such as Domain Validation (DV) and Organization Validation (OV) certificates. These safeguards will likely cause warning messages to be shown to users affected by MITM interception. These safeguards include:
- An EV certificate will display some version of the “green bar” as well as the site's owner. This only occurs because the EV certificate includes a unique EV Object Identifier (OID) that is linked to the specific CA and trusted root that issued the EV certificates. This is hardcoded into the browser itself. A MITM interception can copy the EV OID from the real certificate and insert it into the fake certificate, but the EV OID won’t match the issuing CA identity of the untrusted certificate (the MITM interceptor). The fake EV certificate will not display the “green bar” to the user and may even display an issuer mismatch warning. If a user visiting his or her normal banking website notices that the "green bar" is gone, that serves as a warning that their "secure" connection may not be as secure as they'd think, putting their information at risk.
- The fake MITM certificates will not include required certificate revocation checking information, such as an OCSP or CRL pointer. (Including this information will likely result in a “no such certificate” warning being shown to users.) Some browsers no longer check for certification revocation on DV and OV ceritificates. However, all browsers check for revoked EV certificates by using the certificate’s OCSP and CRL pointer information. This check must return with a positive result (“found but not revoked”) before the "green bar" is shown to the user, verifying that an EV certificate is in use. This is another reason that a MITM attack will result in the absence of the EV information.
- Stringent regulations and audit requirements enforced on legitimate commercial CAs by browser vendors prevent CAs from issuing MITM-capable EV certificate to customers. A CA that would do so would face removal of its certificates from browser stores, which is essentially a death sentence for its business.