The SSL protocol is well designed with respect to preventing eavesdropping and avoiding successful man in the middle attacks. It is less concerned with the processes and procedures that a person or organization must go through to acquire a certificate.
Lack of Authentication Standards
The SSL protocol depends on the existence of a trusted third party. It is assumed that parties that want to communicate over a secure channel can agree on an organization that will vouch for the identity of holders of SSL certificates. The protocol does not address some key issues related to authenticating a person or organization before issuing a certificate:
- What constitutes sufficient proof of identity?
- Are there varying levels of proof?
- If so, how will certificates represent the varying levels of proof?
- How can one be sure different CAs follow the same standards for identifying a party?
These issues all move us from the realm of cryptography and network protocols into the often more complex organizational and procedural issues that surround CAs.
Varying Levels of Certification
Rarely in business or government operations is there a situation in which one size fits all. Security requirements are especially variable. Consider a simple analogy with locks on doors.
Sometimes a relatively inexpensive and weak lock is sufficient to meet one's needs, for example, to keep a toddler from getting into a cabinet filled with chemical cleaners. One could invest in a stronger lock, but it would not add any advantages to the existing solution. An entire house, however, is likely to have stronger locks that will better protect its inhabitants and their possessions. The additional cost and effort required to use the better locks is well justified. Finally, a bank, an obvious target for thieves, will use specialized locks and additional security measures to protect its assets.
In the case of online transactions, different needs dictate different levels of security and authentication. A Web master running a site for a local basketball league wants to allow coaches to use the site to post practice schedules and other team-related information. The Web master does not want anyone else changing those schedules, so she implements a user login. Being security conscious, she also does not want clear text passwords sent over the Internet, so she uses the SSL protocol to establish a secure channel between clients and her Web server.
This is a relatively low-security environment. There are no financial transactions, no exchange of confidential personal information, and no potential for significant loss of intellectual property. Coaches, if they are concerned at all about submitting their usernames and passwords, would likely want nothing more than to be assured that the transaction is encrypted. In this case, simply having a certificate that verifies the identity of the domain is sufficient.
Domain-only certificates typically validate that the requestor of a certificate is authorized to use that domain. These certificates are inexpensive, largely because the validation process can be automated. Information about the owners of domain names is readily available from utility programs, such as whois. (See Figure 2.8 for example output of whois).
Whois Server Version 2.0
Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net for detailed information.
Domain Name: THAWTE.COM Registrar: NETWORK SOLUTIONS, LLC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com Name Server: CARIQUENEZ.VERISIGN.NET Name Server: GOLDENGATE-W2-INF6.VERISIGN.NET Name Server: NS1.CRSNIC.NET Status: clientTransferProhibited Updated Date: 01-may-2007 Creation Date: 10-feb-1996 Expiration Date: 11-feb-2008
Figure 2.8: Information about domain owners is publicly and programmatically available on the Internet. This easy-to-access information is used for domain-only validations.
Domain-only certificates have lowered the cost of using SSL, which has been a benefit to many. Unfortunately, they have also lowered the cost of starting phishing sites that look legitimate. They have also led some companies to use lower-grade certificates rather than authenticated certificates to protect sensitive data. More extensive authentication procedures should be used for most business-oriented domains.
When CAs use full validation procedures, they look for more rigorous proof of the identity of the person, business, or organization requesting a certificate. They will still go through the same steps as the domain-only validation, but in addition they will do things such as:
- Verify the existence of a physical address of the person, company, or organization
- Check government records to verify a business is legally established
- Require copies of documentation, such as a driver's license for a person or incorporation papers for a company
With full-company validation, one cannot simply register a domain name and acquire a certificate; the requestor must be able to demonstrate the company has some established legal identity. Again, there are varying levels of certification involved depending on the issuing CA.
Problems with Varying Levels of Certification
The biggest problem with varying levels of certification is that these variances are not apparent to users who are expected to trust these certificates. When a browser establishes an SSL session with a server, the same lock icon will appear on the browser whether the server certificate is domain-only or full-company validation. A phishing site can look as legitimate as a real bank's site.
The root of this problem was that there were no well-defined standards for authenticating businesses. Two different CAs may have different procedures for full company certification. One company may check government records to see if a business by a certain name has been established while another will make more rigorous checks to see that the company is actually still actively in business. These variations in current practices, along with the rise of phishing scams, have undermined trust in online commerce and prompted the industry to respond with a new type of SSL certificate that does not suffer from these deficiencies.
EV SSL Certificates
EV SSL certificates use the same cryptography and network protocols as SSL certificates but they improve the certification process to address the weakness outlined earlier. The standards for EV SSL certificates have been established by a governing body known as the CA/Browser Forum (http://www.cabforum.org/). Before an EV SSL certificate is issued, the CA conducts a thorough and standardized process to verify the identity of the requestor. The steps include:
- Verifying the entity physically exists
- The entity is legally recognized
- The entity is actively conducting business or other operations
- The identity of the entity matches the identity on legal records
- The entity has legitimate use of the domain
- The individual requesting the certificate is an authorized representative of the company in question
CAs that issue EV SSL certificates are also subject to audits, performed by WebTrust, a professional assurances organization, to demonstrate that proper policies, procedures, and training measures are in place to ensure quality control.
In addition, most high-security browsers such as Microsoft IE7 now provide additional visual cues to users when a site uses EV SSL certificates. This eliminates the problem of how a user is to know the level of verification and authenticate behind a certificate.
Read the rest of Chapter 2: Overview of SSL and EV-SSL Certificates (.pdf).