An attack on a Brazilian bank caused them to lose control of their DNS for nearly five hours. Once attackers gained control of the bank’s DNS, they were able to also show control over the domain enabling them to get a DV SSL/TLS certificate. The attacker could create a secured phishing site that could capture user names and passwords. That data could be used to login to the real bank site using customer credentials and embezzle funds from customer bank accounts presenting a high risk to bank customers.
The ongoing discussion has been, how do we protect the bank’s customers? How can customers tell when a site secured with SSL/TLS was not been secured by the domain owners?
Financial Services Favor EV Certificates
Most financial service institutions worldwide secure their websites with OV or EV certificates. EV certificates display the site owner’s name in the browser status bar. This assures website visitors that the website is authentic and that they are on the intended site. This unique status bar is only displayed for brand’s protected with an EV certificate. They are designed specifically to mitigate attacks by letting users know the website can be trusted.
EV certificates have the highest level of validation that can be provided by a certification authority (CA). The CA must validate:
- Applicant identity from the original registration authority
- Business type, registration number, and registration jurisdiction location
- Place of business
- Contract signer and certificate approver identity and authorization
The intensity of the validation process means most attackers will not even apply for an EV certificate. If an attacker does apply for one, it is highly likely for them to fail validation or just give up in the process. As a result of this rigorous validation process, EV certificates are not issued to attackers. Thereby providing another reason to trust EV certificates.
According to experts, EV provides the same encryption as DV – Melih recently blogged about the two use cases for encryption: “To Avoid” and “Encrypt For.” In his blog, Melih shows that DV provides the same encryption for the “To Avoid” use case, but does not support “Encrypt For.” The “Encrypt For” use case would greatly benefit users if they knew when a site is supposed to have an EV certificate. Or better yet, warn users when an EV certificate is missing – a clear indication for users who might otherwise trust an unauthorized certificate.
So, How Can We Warn Browser Users When an EV-only Certificate is Missing?
One suggestion is to use HTTPS public key pinning (HPKP). With HPKP, the web server provides a header to the browser with a list of keys where one should be found when validating the certificate trust path. The browser will cache the header for days or months for reuse in the future. When the browser goes back to the site it will provide an error if the site does not have one of the cached keys. If the CA has EV-only issuing CAs, then the header could have a list of EV-only public keys.
Some experts do not recommend HPKP. A search on “HPKP brick site” reveals a surprising number of responses. This is due to an issue that arises with HPKP if the public key changes and there are no longer matching keys in the browser cache — the connection will fail. The site will be “bricked” for some users until the cache expires. Adam Caudill writes, “It’s a very powerful tool, though one I rarely recommend because like many things that offer such power, it is easy to get wrong, and can take a site down for an extended period of time with little ability to recover.”
An alternative would be to get a lot of CAs to get together and create a list of public keys for EV-only CAs. Then website owners could list many EV-only public keys in their HPKP header. It is interesting, but not very scalable. How do you convince a certificate subscriber to trust CAs which they do not trust? How do you get them to update their list as the public keys change?
One way for a CA to remain independent while allowing the site to assert EV policy is with an EV-only header. The browsers would still be able to manage CAs. Creating a mechanism for website owners to declare their site as EV-only would prevent an attack like the one made against the Brazilian bank. A site that is indicated for EV-only, would fail if the same or a similar attack were repeated. In addition, customers could not be fooled by misleading UI indicators because the site would fail if an attacker gained DNS control and declared a domain as their own.
Having an EV-only header would help browsers protect their users from phishing sites. This could be done through a new standard or added to a current standard such as HTTPS Strict Transport Security (HSTS). More thought should be considered on how browsers should use identity to support trust for browser users.