EV SSL allows software to authenticate strongly in ways which defeat the SSLStrip attack. We saw that with conventional certificates, especially domain-validated certificates, there is no reliable information to back up the authentication of the domain name. To address this critical problem, certificate authorities and software companies joined to form the CA/Browser Forum4 and promulgate a new standard called EV SSL for Extended Validation SSL.
EV SSL defines rules for who can qualify for such a certificate and the procedures a CA must follow in order to validate the information. For instance, they must validate that the organization exists as a legal entity, that any organization names are legal names for that organization, and that the applicant is authorized to apply for the certificate.
EV SSL allows software to authenticate strongly in ways which defeat the SSL Strip attack.; see Figure for an illustration The fields in the certificate generally ignored by conventional SSL implementations, such as organization name, are required in EV SSL and can be checked every time. This second-level of authentication ensures that the parties know exactly with whom they are communicating. Since certificates contain organization names that have been verified, users and applications that rely on EV SSL Certificate can verify the actual owner of the certificate with confidence
EV SSL enables software to authenticate strongly in ways which defeat the SSLStrip attack. In addition to the domain name, the fields generally ignored by conventional SSL implementations, such as organization name, are required in EV SSL and can be checked reliably every time. This second-level of authentication ensures that the parties know exactly with whom they are communicating.
The specification is also clear about the information that must be provided by the applicant. Other rules are more restrictive than with conventional SSL. For instance, wildcard certificates, the type that make null character attacks even more dangerous, are not allowed in EV SSL.
EV certificates are also limited in lifetime relative to conventional certificates: the maximum validity period is 27 months. This ensures “freshness” of the information in the certificate.
In addition to collecting a proper EV Certificate request, containing much organization information including the jurisdiction of incorporation, and a signed subscriber agreement, the CA is required to verify that the organization exists and operates at the locations specified in the request. They may go to government sources for this. They have to verify that the entity exists at the physical address they specify. For business organizations a face-to-face verification of the principal individual in the entity is required.
The requirements go on and on for 93 pages. It would be very hard to get a fake EV certificate.
EV certificates enable strong authentication
Standards also specify what software needs to do in order to authenticate a party based on a certificate. Unlike the loose conventions which developed around conventional SSL, these rules must be followed for EV.
When encountering an EV certificate, a program must confirm first that the CSP (Certificate Service Provider), meaning the certificate authority who issued the EV certificate, is authorized to issue such certificates. Each CSP has a unique EV policy identifier associated with it which must be compared to the identifier in the end-entity certificate.
Applications that use EV certificates properly need to embed CSP root certificates in order to confirm that certificates they encounter are issued by trusted roots. Required procedures for CSPs to work with application developers, including providing test facilities, are defined by the CA/Browser Forum.
“Relying applications [clients authenticating certificates] must provide adequate protection against malign threats to the integrity of the application code and the CSP root.” This is the sort of requirement that needs some history to fully-define itself, but basically it puts the onus on application developers to take care to write secure code.
The rules state that applications must be able to handle key strength of symmetric algorithms of at least 128 bits.
Applications are required to check for revocation of the certificate before accepting it. The application should support both CRL and OCSP, although OCSP is clearly the wave of the future and the only scalable approach. (In his presentation Marlinspike suggests a method for bypassing OCSP by returning a “Try again later” code, in which case the application typically gives up and authenticates. The EV rules state: “If the application cannot obtain a response using one service, then it should try all available alternative services.” This precludes the lazy behavior described by Marlinspike.)
Once all of these requirements have been met and the fields in the certificate match those expected by the application, then it may proceed.
Implementation considerations
Adopting EV SSL is not simply a matter of buying and using an EV SSL certificate. Client software has to know to look for an EV SSL certificate and to follow the rules for implementing EV SSL authentication .
Fortunately, it’s not difficult programming, but it needs to be done potentially with in-house as well as with 3rd party client software code. But the work is the same in all places. If you are well-organized about your certificates then it will be straightforward work. And many products, including current Windows versions, support EV SSL out of the box.
SSLStrip attack could be used against server-server communications with the potential for mass-compromise of confidential data
Advances in attacks on network security over the last few years have led to many high-profile compromises of enterprise networks and breaches of data security. A new attack is threatening to expand the potential for attackers to compromise enterprise servers and the critical data on them. Solutions are available, and they will require action by company officers and administrators.
“SSLStrip” and related attacks1 were among the highlights of the July 2009 Black Hat show in Las Vegas2. Researcher Moxie Marlinspike3 combined a number of discrete problems, not all related to SSL, to create a credible scenario in which users attempting to work with secure web sites were instead sent to malicious fake sites. One of the core problems described by Marlinspike is the ability to embed null characters in the common name field of a certificate, designating a domain name. This can be used to trick software, web browsers for example, into recognizing a domain name different from the complete field name. The result is that software, and users, are misled as to the actual domain with which they are communicating.
SSLStrip has not lacked for press coverage, but the analysis has focused on the consumer or end user with a browser. The use of SSL in embedded applications, including server-server communications, presents an even more ominous scenario. This is because SSLStrip attack could be used against server-server communications with the potential for mass-compromise of confidential data.
This spoofing problem is solved by proper use of Extended Validation SSL certificates for authentication. Moving certificate-based enterprise authentication to EV SSL would therefore protect an organization against this form of attack.
SSL authentication is most famous for providing secure web access to sites with sensitive information, such as banks, but it has many applications. It is commonly used, for example, as a means for parties in a machine-to-machine, typically serverserver conversation to verify each other’s identity; see Figure A for an illustration.
The recent revelation of a new attack against SSL threatens these server-server communications. An attacker who gains access to the network could use the attack to spoof the identity of a critical server and thereby gain unauthorized access to critical data.
Since EV SSL Certificates contain only authenticated organization information, businesses can employ EV SSL and require the organization information to match the expected values before allowing access to mission critical applications. In this scenario the intruder using the new attacks will fail to gain access because it will lack the presence of the EV certificate, the correct organization information, or both.
It is possible to trick the client into seeing the name it expects, when the actual domain name in the certificate is that of a malicious site
The main weakness with conventional SSL certificates is that there are no standards for their issuance, nor any rules for what the fields in them are supposed to mean and which are required for authentication.One implication is that client applications, called relying parties, cannot have confidence that the organization listed as the owner of the certificate is in fact that owner. This follows all the way up the chain until the relying party reaches a trusted root.
In fact, the least expensive SSL Certificate, domain-authenticated certificates, don’t even authenticate an organization, merely an internet domain. Users can tell precious little from them about those with whom they are doing business.
Marlinspike’s SSLStrip attack demonstrated the combination of several attack techniques to exploit the above weaknesses and fool users / client applications into thinking they were using a trusted site / server, when in fact they were using a fake version of that site / server. He combined a number of techniques, including “man-in-the-middle,” fake leaf node certificates and the null character attack.
Null characters in a domain name
The key threat Marlinspike discloses is the use of null (zero value, often designated ‘\0’) characters embedded in a domain name.
Online purchase of inexpensive “domain-validated” SSL Certificate is so automated that it’s often possible to buy one with an embedded null character. For example - \0thoughtcrime.org. In the attack, the domain name of the certificate is combined to the right of the domain name to be spoofed, for example, “www.verisign.com\0thoughtcrime.org”. (Thoughtcrime.org is a domain owned by Marlinspike and used by him in his examples.)
Most software treats the null character as a string terminator. So when SSL client software reads the certificate domain name in the example it will stop at the null and treat the certificate as valid for www.verisign.com as issued by the certificate authority.
Null-stripping
Two SSL implementations, the Opera and Safari browsers, defeat this specific attack by stripping null characters from the Common Name. Thus, in the example above, the comparison will be to www.verisign.com.thoughtcrime.org and it will fail. But Marlinspike claims that some certificate authorities can be tricked with the same vulnerability in a way that makes null-stripping itself a vulnerability. In his example, he buys a certificate for sitekey.ba\0nkofamerica.com. Presumably he owns nkofamerica.com. When this name is presented to Opera or Safari it will display his attack site as sitekey.bankofamerica.com, the login page for that bank.
Man-in-the-middle
If you’re on the same local network as the server you are compromising, Marlinspike’s techniques make it very possible to perform the man-in-the-middle attack; see Figure B for an illustration. A number of popular techniques exist for this: A rogue wireless access point is one, or DNS or AARP cache poisoning.If you’re not on the same network then you need to get there, which you can do most likely by installing malware on a relatively less-secured system on the same network. The attacks which make this possible are legion.
Damage potential in server-server environments
The damage potential of this attack in a server-server communication scenario, such as database servers synchronizing across a WAN, is substantial.
Such servers commonly use SSL to authenticate each other. A malicious user on the network could spoof that authentication using the techniques described above. One that authenticated as a database mirror could capture the entire database including, if it’s stored on the server, privileged information and confidential customer data.
Posts
