Secure SSL Primer

8/9/2019 Secure SSL Primer

1/88


2/88

Introduction

i

Introduction to Realtimepublishers

by Don Jones, Series Editor

For several years, now, Realtime has produced dozens and dozens of high-quality books that justhappen to be delivered in electronic formatat no cost to you, the reader. Weve made thisunique publishing model work through the generous support and cooperation of our sponsors,who agree to bear each books production expenses for the benefit of our readers.

Although weve always offered our publications to you for free, dont think for a moment thatquality is anything less than our top priority. My job is to make sure that our books are as goodasand in most cases better thanany printed book that would cost you $40 or more. Ourelectronic publishing model offers several advantages over printed books: You receive chaptersliterally as fast as our authors produce them (hence the realtime aspect of our model), and wecan update chapters to reflect the latest changes in technology.

I want to point out that our books are by no means paid advertisements or white papers. Were an

independent publishing company, and an important aspect of my job is to make sure that ourauthors are free to voice their expertise and opinions without reservation or restriction. Wemaintain complete editorial control of our publications, and Im proud that weve produced somany quality books over the past years.

I want to extend an invitation to visit us at http://nexus.realtimepublishers.com , especially if youve received this publication from a friend or colleague. We have a wide variety of additionalbooks on a range of topics, and youre sure to find something thats of interest to youand itwont cost you a thing. We hope youll continue to come to Realtime for your educational needsfar into the future.

Until then, enjoy.

Don Jones
http://nexus.realtimepublishers.com/http://nexus.realtimepublishers.com/


3/88

Table of Contents

ii

Introduction to Realtimepublishers.................................................................................................. i

Chapter 1: Security Challenges and the Business Case for EV SSL Certificates............................1

Web Security Challenges.................................................................................................................2

Evolution of Attacks ............................................................................................................3

Phishing Attacks ..................................................................................................................4

Establishing Trust ....................................................................................................5

Convincing Users to Take Action............................................................................7

Collecting Confidential Information........................................................................7

Man-in-the-Middle Attacks .................................................................................................7

Double Vulnerability: Lack of Encryption and Poor Password Practices ...............8

Phishing by Proxy....................................................................................................9

Replay Attacks.......................................................................................................10

Loss of Privacy and Confidentiality ..................................................................................11

Implications of Security Threats for Business...............................................................................12

Reduced Potential for Online Business Due to Lack of Trust...........................................12

Fraud and Identity Theft ....................................................................................................12

Damage to Brand and Reputation......................................................................................13

Requirements for a Business-Grade Web......................................................................................13

Authenticated Identities .....................................................................................................15

Confidential Transmission.................................................................................................15Integrity of Transactions....................................................................................................16

The Role of EV SSL Certificates...................................................................................................16

Summary........................................................................................................................................17

Chapter 2: Overview of SSL and EV-SSL Certificates.................................................................18

Overview of SSL Certificates ........................................................................................................18

Proving Identity .................................................................................................................18

Acquiring Certificates........................................................................................................19

Installing an SSL Certificate..............................................................................................20SSL Encryption Technology..........................................................................................................21

Symmetric Key Cryptography ...........................................................................................22

Cracking Codes......................................................................................................22

Keeping Keys Secret..............................................................................................23

Public Key Cryptography ..................................................................................................24


4/88

Table of Contents

iii

Message Authentication Codes and Message Integrity .....................................................26

Hash Functions.......................................................................................................26

Protecting Message Integrity .................................................................................26

Example SSL Session ........................................................................................................27

Issues Successfully Addressed by SSL..............................................................................29

Limitations of SSL: Lack of Standards..........................................................................................30

Lack of Authentication Standards......................................................................................30

Varying Levels of Certification .............................................................................30

Problems with Varying Levels of Certification.....................................................32

EV SSL Certificates.......................................................................................................................32

Summary........................................................................................................................................33

Chapter 3: Authentication and Verification...................................................................................34

Standards-Based Verification Process ...........................................................................................35

Structure of the CA/Browser Forum..................................................................................35

EV Policies Governing CAs ..............................................................................................36

Compliance Policies...............................................................................................36

Insurance Requirements.........................................................................................37

Audit Requirements ...............................................................................................37

Obtaining an EV SSL Certificate...................................................................................................38

Subject Verification Requirements....................................................................................38Business Verification Requirements......................................................................38

Government Verification Requirements................................................................39

Private Organizations.............................................................................................39

Documentation Requirements............................................................................................40

Role Requirements.............................................................................................................40

Verification Requirements.............................................................................................................41

Verifying Legal Existence .................................................................................................41

Entity Legal Existence ...........................................................................................41Principal Legal Existence ......................................................................................42

Physical Existence .............................................................................................................42

Operational Existence ........................................................................................................42

Domain Name Rights.........................................................................................................42

Authority to Request an EV SSL Certificate.....................................................................44


5/88

Table of Contents

iv

Utilizing Existing Trust Models.........................................................................................44

Maintaining Certification Status....................................................................................................45

Additional Requirements of CAs...................................................................................................46

Employee Regulations .......................................................................................................47

RAs ....................................................................................................................................47

Document Management .....................................................................................................47

Data Security......................................................................................................................47

Summary........................................................................................................................................48

Chapter 4: User Experience ...........................................................................................................49

User Experience with Traditional SSL Certificates.......................................................................49

Examples of SSL Visual Cues...........................................................................................50

Limitations of Typical SSL Browser Displays..................................................................52

User Awareness .....................................................................................................53

Phishing Techniques ..............................................................................................53

User Experience with Web Browsers ............................................................................................55

Internet Explorer 7 on Vista...............................................................................................55

Internet Explorer 7 on Windows XP......................................................................57

Mozilla Firefox ..................................................................................................................58

Benefits of EV SSL Certificates ....................................................................................................59

Benefits to Browser Users .................................................................................................59Benefits to Businesses........................................................................................................60

Brand Protection ....................................................................................................60

Reduced transaction abandonment and increased customer trust..........................61

Summary........................................................................................................................................62

Chapter 5: Future of EV SSL Certificates .....................................................................................63

Historical Patterns and the Development of Information Security................................................63

Evolution of Malware ........................................................................................................65

Early Viruses and Worms ......................................................................................65Encrypted Malware................................................................................................65

Polymorphic Malware............................................................................................66

Changing Phishing Techniques..........................................................................................66

Spear Phishing .......................................................................................................67

E-Commerce Phishing ...........................................................................................67


6/88

Table of Contents

v

Social Networking Phishing ..................................................................................67

Resilient Botnets ....................................................................................................68

Common Patterns in the Development of Security Threats...............................................70

Near-Term Emerging Requirements..............................................................................................70

Non-Phishing Threats and Attacks ....................................................................................71

Privacy Protections ............................................................................................................72

Certified Security Measures...............................................................................................73

Other Integrity Certifications.............................................................................................75

Possible Improvements to Browser Interface ................................................................................75

Search Result Filtering with EV SSL Certificates.............................................................76

Advertisement Filtering with EV SSL Certificates ...........................................................76

Possible Additional Uses for EV SSL Certificates........................................................................77

Certifying Enterprise Web Applications............................................................................78

Certifying Standards Compliance......................................................................................78

Certifying Online Services.................................................................................................79

Summary........................................................................................................................................80

Download Additional eBooks from Realtime Nexus!...................................................................81


7/88

Copyright Statement

vi

Copyright Statement 2007 Realtimepublishers.com, Inc. All rights reserved. This site contains materials thathave been created, developed, or commissioned by, and published with the permissionof, Realtimepublishers.com, Inc. (the Materials) and this site and any such Materials areprotected by international copyright and trademark laws.

THE MATERIALS ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY KIND,EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,TITLE AND NON-INFRINGEMENT. The Materials are subject to change without noticeand do not represent a commitment on the part of Realtimepublishers.com, Inc or its website sponsors. In no event shall Realtimepublishers.com, Inc. or its web site sponsors beheld liable for technical or editorial errors or omissions contained in the Materials,including without limitation, for any direct, indirect, incidental, special, exemplary orconsequential damages whatsoever resulting from the use of any information containedin the Materials.

The Materials (including but not limited to the text, images, audio, and/or video) may notbe copied, reproduced, republished, uploaded, posted, transmitted, or distributed in anyway, in whole or in part, except that one copy may be downloaded for your personal, non-commercial use on a single computer. In connection with such use, you may not modifyor obscure any copyright or other proprietary notice.

The Materials may contain trademarks, services marks and logos that are the property ofthird parties. You are not permitted to use these trademarks, services marks or logoswithout prior written consent of such third parties.

Realtimepublishers.com and the Realtimepublishers logo are registered in the US Patent& Trademark Office. All other product or service names are the property of theirrespective owners.

If you have any questions about these terms, or if you would like information aboutlicensing materials from Realtimepublishers.com, please contact us via e-mail [email protected] .
mailto:[email protected]:[email protected]


8/88

Chapter 1

1

[Editor's Note: This eBook was downloaded from Realtime NexusThe Digital Library. Allleading technology guides from Realtimepublishers can be found athttp://nexus.realtimepublishers.com .]

Chapter 1: Security Challenges and the Business Case for EVSSL CertificatesThe Internet has rapidly become an integral part of day-to-day business and is now, along withshipping, manufacturing, and financial accounting, a critical component to business operations.The Internet, however, poses unique security challenges that threaten to undermine its ability tosupport business-grade services. The risks of unchecked security weaknesses can range fromfraud and identity theft which may ultimately damage a companys brand and reputation.Mitigating these risks requires a wide array of measures.

Broadly speaking, security measures are designed to protect three fundamental aspects of information:

Confidentiality of information Integrity of information Availability of information resource

Confidentiality and integrity are especially important to establishing and maintaining trustamong businesses and customers. Customers must be comfortable sharing information withbusinesses and be confident that it will not fall into the hands of hackers and thieves. When acustomer makes a purchase in a store, the customer can see exactly what he is buying, he handshis credit card to a human who hands it right back, and the customer knows that if there is aproblem a manager is probably nearby. Aspects of in-person commerce such as this help

establish trust between customers and businesses.Similar levels of trust can exist when online transactions are used as well, but the processes aredifferent. You dont see employees who provide services; youve likely never met managers of an online service in person. Instead, you depend upon factors such as brand recognition and losslimits on credit cards to provide some level of confidence that your financial transactions aresecure and your risks are limited.

Peter Steiners 1993 New Yorker cartoon depicting two dogs in front of a computer with thecaption On the Internet, nobody knows youre a dog captured the double-edged sword of online business. On the one hand, the Internet enabled small businesses to offer similar servicesand products as large corporations. However, this same development made it more difficult forcustomers to know which sites are actually created by reputable firms. You need online-specificmethods for creating and establishing trust between customers and businesses.
http://nexus.realtimepublishers.com/http://nexus.realtimepublishers.com/


9/88

Chapter 1

2

This guide addresses one method for establishing trust: the use of Extended Validation SecureSockets Layer SSL (EV SSL) certificates. The guide consists of five chapters:

Chapter 1 examines the security challenges to business on the Internet and the role of EVSSL certificates in establishing a more trusted business environment on the Internet.

Chapter 2 describes, in detail, how SSL certificates work and identifies weaknesses thatstill exist with the use of those certificates. The chapter concludes with a discussion of how EV SSL certificates correct for those weaknesses.

Chapter 3 examines the authentication and verification process used when issuing an EVSSL certificate.

Chapter 4 describes the user experience when conducting business with an EV SSLcertified organization. It also examines differences in browser implementations of the EVSSL.

Chapter 5 concludes the guide by looking into the future of EV SSL with particularattention to the development of the EV SSL standard and the potential for improved userexperience.

This chapter examines four related topics: Web security challenges Implications of these security challenges to business Requirements for a business-grade Web Role of EV SSL certificates

Lets begin with security threats that are especially problematic for maintaining a trustedenvironment for conducting business on the Web.

Web Security ChallengesThe Internets utility stems in part from the wide variety of services available from Webbrowsing and email to custom catalog, order processing, and customer support systems. Theapplications underlying these services are sometimes vulnerable to attacks. Although the specificdetails of particular attacks are not important here. While each instance may be different, thereare common patterns among attacks. These include:

Phishing Eavesdropping and tampering, known as man-in-the-middle attacks Attacks resulting in loss of confidentiality and integrity

Technically, phishing is a type of man-in-the-middle attack. For the purposes of this guide, weuse the term man-in-the-middle-attack to refer to eavesdropping and tampering attacks. Each of these will be described in detail, but first lets examine a recurring pattern in the history of information security.


10/88

Chapter 1

3

Evolution of Attacks Security practices and tools have evolved in large part as a response to attacks by hackers andcybercriminals. Attackers, in turn, respond by creating new techniques that circumvent emergingcountermeasures. This is an important pattern in the history of information security for tworeasons. First, it occurs repeatedly and across different areas of information security. Second,

because of it, the tools and techniques that may have worked at one time may no longer besufficient to protect us today.

Take, for example, the changes in computer viruses over time. The following list highlightsmajor developments in the history of this kind of malicious software, known as malware:

After computer viruses emerged, security researchers developed techniques foridentifying viruses based on unique signatures or fingerprints of viruses.

In the next stage, virus developers countered by encrypting their viruses so that theviruses were not so easily detected.

Of course, antivirus researchers developed new detection techniques, actually targeting

the part of the virus responsible for encrypting the viral code. In the next stage of development, virus writers created methods for changing the actual

code of the virus without changing its function. These mutating viruses, as they areknown, prompted the development of new detection techniques, called behavioralanalysis.

Today, viruses and other forms of malware can still inflict damage; however, the focus of themost damaging attacks has shifted from vandalism to financial gain. Rather than just deletingfiles or spreading malicious code to other devices, malware is used to gain sufficient control of PCs to use them to distribute spam and for phishing attacks. Large networks of compromisedcomputers, known as botnets, are responsible for much of the spam and phishing attacks spread

on the Internet.It is not just viruses that have changed to avoid detection or to become more virulent. Phishing,for example, is an all-too-common type of attack that takes advantage of peoples trust inbusinesses and other well-known organizations.


11/88

Chapter 1

4

Phishing Attacks Phishing is an attack that uses email or Web site content to trick victims into doing things thatthey would not normally do. Phishers succeed by establishing a sense of trust with the victim.The general class of such attacks is known as social engineering attacks. Examples of social

engineering attacks include: Calling an employee posing as a service desk technician and asking for the employees

password to troubleshoot a problem with network logins. Sending a legitimate-looking email claiming your account with a well-known online

retailer has been compromised and requesting you click an embedded link to go to a formthat will allow you to update your password.

Requesting that users take a brief survey about customer services in return for a cashpayment. The link provided in the email links to a phishing site that downloads malicioussoftware, such as a keylogger that captures usernames and passwords for banking andother financial services businesses.

As these examples demonstrate, the typical phishing attack includes a multi-step process:

1. Establish the victims trust using a lure, typically an email that appears legitimate.

2. Convince the user to take an action that will enable the capture of confidentialinformation.

3. When the action in step 2 is taken, collect the confidential information and terminate thesession.

Phishers have developed multiple techniques for each of these steps.


12/88

Chapter 1

5

Figure 1.1: A typical phishing scam lures victims to a bogus Web site where confidential information is collected.

Establishing Trust

One of the quickest ways to establish trust is to use visual cues. Company logos, tag lines, andeven entire Web pages are easily collected from legitimate sites. These can help to convincereaders that the message is legitimate but it is rarely enough. The text within the message mustbe written in standard business English with no obvious grammatical errors. Links have to look like the domain of the target institution. In some cases, as Figure 1.2 shows, phishers even go sofar as to advise users about anti-phishing practices.


13/88

Chapter 1

6

Figure 1.2: A typical phishing lure can establish trust by including logos from legitimate businesses or, in this case, by recommending typing URLs instead of clicking on embedded links.

Some companies have responded to phishing attacks against their brands by implementingadditional security measures, such as Bank of Americas SiteKey. Customers choose anindividual image that is displayed on a banks site when a user logs in. Unless a phisher hasaccess to information about customers choice of images, the phisher cannot duplicate thefunctionality of the banks site.


14/88

Chapter 1

7

Convincing Users to Take Action

Like a good advertising campaign, a phishing attack includes a call to action. Getting a user toactually take the time to respond is a challenge even for legitimate advertisers, so phishers oftenuse the well-known tactic: appealing to fear, uncertainty and doubt (FUD). Consider the subject

line from some phishing lures archived at MillersMiles.co.uk, an anti-phishing service: Security Alert: Secure Your Online Banking Information. Wachovia Alerts: Unauthorized Access Into Your Wachovia Account eBay Bid Cancellation Notice - Item 300120654262 Alert: A Thirdparty Access Into Your Online Banking Account. Your Account Is Blocked(Update Now)

Details about these and other phishing lures are available at http://www.millersmiles.co.uk/archives/ .

If a phisher can craft a well-written message with sufficient visual cues and no apparent tell-talesigns of a phishing scam, all that is left is to collect information once the reader has fallen for thelure.

Collecting Confidential Information

Once a phisher has drawn a victim to a website they control, it is a simple matter to displayforms that look legitimate and collect basic information, such as usernames and passwords.Attacks may be more sophisticated and include the use of keyloggers, which are programs usedto intercept and copy each keystroke as it is typed on a keyboard. The malicious program canthen transfer the data in its entirety to the attacker or scan for patterns in the text that indicate the

name of a bank or other financial service. When a target institution is found, the keystrokes nearit are sent to the attacker with the assumption that users log in to their accounts shortly afteraccessing the institutions Web site. Phishing attacks typically require some action on the part of the victim but other attacks can occur without any participation of the victims.

Man-in-the-Middle Attacks Man-in-the-middle attacks include a broad array of attacks that interfere with or observe theinteractions between two parties. There are several forms of this attack:

Simple eavesdropping Phishing by proxy Replay attacks

As with phishing attacks, there are a variety of practices that can reduce the risk of such attacks.
http://www.millersmiles.co.uk/archives/http://www.millersmiles.co.uk/archives/


15/88

Chapter 1

8

Double Vulnerability: Lack of Encryption and Poor Password Practices

Eavesdropping on wireless network communications is not difficult and in the rightcircumstances can easily yield confidential information. Lets consider a simple example. Aperson waiting for a plane has a few moments before boarding, so she decides to take care of a

few online tasks. A coffee shop in the airport offers a free but unsecured wireless network, so shedecides to use that. First, she checks her corporate email account, and then checks balances onher bank accounts, followed by browsing some online business journals.

A vulnerability of wireless communications is that anyone with reasonably inexpensiveequipment can monitor network traffic. If someone were nearby with wireless equipment thatallowed them to monitor all wireless traffic, they could pick communications of other users.Email and bank Web sites typically encrypt information but an eavesdropper could still pick upenough to know what email system or which banks are being used. Less security-conscious Websites might pass usernames and passwords as plain text.

Unfortunately for this user, her business journal is one of those sites that do not bother to encrypt

usernames and passwords. To make matters worse, this person has the habit of using the samepassword for multiple sites. In just a matter of minutes, an attacker could have collected enoughinformation to begin to compromise the users accounts, probably by exploiting othervulnerabilities as well.

The risk of this kind of attack can be mitigated by using only encrypted wireless networks.Furthermore, a well-known but too-often-overlooked best practice is to use different passwordsfor multiple sites.

Until there is a secure, widely accepted standard for managing identities and credentials, we will bemanaging passwords for multiple sites and applications. Keeping track of all these usernames andpasswords is so difficult that many users are prone to insecure practices, like writing down passwords

or storing them in emails and other online repositories. A better option is to use tools such asPassword Safe, available for free from http://passwordsafe.sourceforge.net/ , that keep a securedatabase of all your account and password information.

As noted earlier, phishing is technically a man-in-the-middle attack, but I have distinguishedmost kinds of phishing from eavesdropping and tampering attacks. The next section will examinea technique known as phishing by proxy that combines elements both kinds of attacks.
http://passwordsafe.sourceforge.net/http://passwordsafe.sourceforge.net/


16/88

Chapter 1

9

Phishing by Proxy

In a phishing by proxy attack, a program intercepts communication between a user and alegitimate site. This kind of attack has the advantage (to the phisher) of displaying actual contentfrom the real site while still collecting private information from a user. Here is how it works: A

user responds to a phishing lure, for example, a purported email from the persons bank askingthe user to verify information. When the user clicks the link, the browser loads content from aproxy server. The proxy server, in turn, gets legitimate content from the real business site anddisplays it for the user. There are no clues, such as poorly worded phrases or strange-lookingURLs to visually indicate a phishing scam.

The user then continues to enter a username and password as well as respond to any securityquestions. All this information is passed to the phishing proxy, which stores the information andthen passes it on to the legitimate site. The proxy has logged in on behalf of the user, so theproxy can return the same content the user would see from the legitimate site.

Figure 1.3: In a phishing by proxy attack, legitimate sites are used to generate responses on behalf of the phishing site.


17/88

Chapter 1

10

This type of attack even works against newer two-factor authentication schemes. Even if a userhas to enter an extra authentication codefor example, a number generated by a security tokenthat changes every minutethe proxy server will have as long as 60 seconds to initiate anothersession with the legitimate site and execute a transaction. This reuse of a time-based code is alsoa type of replay attack.

Replay Attacks

In a replay attack, the attacker captures authentication information and uses it to establishanother transaction. Replay attacks differ from man-in-the-middle attacks by collectinginformation and re-using it for a separate transaction rather than interfering with the originaltransaction. Several methods are available to prevent this type of attack, including the use of

One-time passwords Session tokens Message authentication codes Time-stamping

Each of these techniques incorporates information that changes over time or with each session.

Figure 1.4: The use of varying information in transactions can thwart replay attacks.

The threat from man-in-the-middle attacks can be reduced in several ways, including the use of strong encryption and strong mutual authentication. In addition to these specific kinds of attackson information, businesses must contend with the general problem of loss of privacy andconfidentiality.


18/88

Chapter 1

11

Loss of Privacy and Confidentiality When Sun Microsystems CEO Scott McNealy said in 1999 that we have no privacy, get overit, he was saying more about how much information could be collected and harvested bybusiness than about customers, patients, and the public in generals demand for privacy. In

addition to concerns about the ability of businesses and governments to analyze volumes of datafrom disparate sources, there is fear of unauthorized, malicious use of personal information.Consider some of the ways privacy and confidentiality can be compromised:

Data mining across databases with information about banking, shopping, and Internetsurfing

Data breaches resulting in the large-scale theft of financial and personal information Inadvertent release of confidential information in violation of privacy protection

directives, such as the private medical regulation known as the Health InsurancePortability and Accountability Act (HIPAA)

Loss or theft of laptops and other mobile devices containing unencrypted privateinformation Theft of customer credit card information by trusted database administrators for sale to

the highest bidder

There is little these examples have in common except they are all ways in which privateinformation can be mismanaged and disclosed. Collectively, these vulnerabilities can undermineconsumer confidence and willingness to share information that in turn can hinder a businessability to fully utilize the benefits of information technology.

To effectively leverage the Web, organizations must cope with a wide array of securitychallenges:

Fully develop, focused attacks on consumers, such as phishing, that seek immediatefinancial gain

Information gathering attacks, such as man-in-the-middle attacks, that may be used inconjunction with other kinds of attacks to realize a larger goal

The potential for a generalized fear of loss of privacy and confidentiality wheninformation is shared online

These types of challenges can have a direct impact on business operations as the next section willexplore.


19/88


20/88

Chapter 1

13

Damage to Brand and Reputation When phishers displays a logo of a well-known bank or online auction site, they are leveragingthat companys brand recognition and they are putting that brand at risk. Even if recipients arenot lured into revealing information, there is still the potential for the reader to make associationsbetween the malicious message and the brand.

The value of a brand is difficult to measure, so the damage done by cybercriminals playing on acompanys reputation is equally unquantifiable. Nonetheless, anything that can leave a customerwith unfounded, and even erroneous, concerns such as how well is Company X protecting myinformation if they cant even prevent these malicious emails? can damage ones brand.

Web security risks can adversely impact operations and revenues. Businesses can, however,mitigate these risks and the potential for lost trust and confidence on the part of their customersand partners.

Requirements for a Business-Grade Web

A successful environment for conducting business is built on trust between parties andconfidence in the integrity of the business environment. The most basic protocols of the Web,and the Internet in general, implicitly trust the parties involved in a transaction. If an emailmessage arrives claiming to be from [email protected], the Simple Mail TransportProtocol (SMTP) believes it. If a low-level transmission control protocol (TCP) packet arrivesat a router asserting that it is the third packet sent by the sender in a particular session, the routeracts as if this is truly the case. Unfortunately, these kinds of transmissions are not always whatthey appear .

In the case of email, spammers often use other peoples email addresses as the sender to helphide their identities. Low-level network packet transmissions can be spoofed; that is, informationabout the sender and other data about the transmission can be changed by an attacker. Thefundamental problem is that the most basic Internet protocols use a layered abstraction (seeFigure 1.5a) but business-grade services require a layered abstraction more like that shown inFigure 1.5b.


21/88

Chapter 1

14

Figure 1.5: Two simplified network models (a) implicitly trusts parties in communication while (b) does not.

The verification element encompasses three components required for secure and trustworthycommunication:

Authenticated identities Confidential transmission Integrity of transactions

If any one of these is missing, communications may be compromised.


22/88

Chapter 1

15

Authenticated Identities Secure communications require that you know with whom you are communicating. Often werely on usernames to identify a user and a password to authenticate or verify the person is who heor she claims to be.

As the earlier examples in phishing and man-in-the-middle attacks show, such attacks cancircumvent simple log in schemes. Other approaches such as multi-factor authentication improveon passwords by using a combination of techniques, typically by requiring something the userknows and something the user has. A bank, for example, may require a customer to provide apassword, then enter a randomly generated code provided by a security token synchronized withthe banks systems.

Although there are limitations to these techniques, they can reduce the risk of password-onlyauthentication. A drawback of this approach is that it works well for the business trying to verifythe identity of someone accessing their systems, but it is not a practical solution for customerswho want to verify the identity of the online business they are visiting. Customers need another

way to verify they are dealing with legitimate sites and not a phishing site. EV SSL certificatesfill this need. Once the parties to a communication are confident they know who they are dealingwith, the next step is to ensure that no one can eavesdrop on their session.

Confidential Transmission Protecting information in motion is a challenge with a long history. Julius Caesar purportedlyused a simple shift cipher, now known as a Caesar cipher, to communicate with his generals. Thebasic idea is that each letter in a message is changed to another letter a fixed distance in thealphabet. For example, if we use a distance of 2, an A would be changed to a C, a B to aD, and so on. Needless to say, these codes are easy to crack. The art and science of cryptography has come a long way since the days of the Roman Empire, but some basic

characteristics remain unchanged.Today, we still use algorithmic methods for changing messages, called plaintext, into ascrambled form, the cipher text. We still consider the strength of an encryption algorithm interms of the time and effort required to decrypt a message when the key is unknown. Othercharacteristics, however, have changed:

We have ways to conveniently and securely exchange keys over the same channel thatwill be used for the encrypted message

Brute force, trial-and-error approaches to searching for keys are not practical with state-of-the-art algorithms and sufficiently long keys

We now have the option to use both strong but computationally intensive algorithms andweaker but more efficiently computed algorithms, depending on the requirements of anapplication

Data encryption and key exchanges are fundamental to the use of both SSL and EV SSLcertificates.

Chapter 2 discusses the technical details of encryption as it relates to these certificates.


23/88

Chapter 1

16

Integrity of Transactions Secure communications are tamper-proof and non-reputable. If a customer submits a transactionordering $1000 worth of goods, it should not arrive at the server as an order for $10,000.Similarly, a customer who does place an order should not claim the order was never placed. Atrusted business environment on the Web must provide this kind of integrity of transactions.

Algorithms, known as hash functions, are ideal for this task. They take a message as input andproduce a fixed-length string as output. Sounds simple, except for the unique characteristics of hash functions. First, any change to the original message will yield a different output string. Evena minor change (for example, switching a comma for a period), will change the output string.The second useful feature of these functions is that it is extremely rare to have two differentinputs that produce the same output. The chances of tampering with a message and somehowgetting the same message digest are astronomically small. When you combine the ability toauthenticate parties to a transaction, ensure that their communications are kept confidential, andprovide assurances that that their transactions are not tampered with and cannot be repudiated,then you have a business-grade service.

The Role of EV SSL CertificatesEV SSL certificates have been created to further enhance the level of trust and confidence inWeb-based business. Threats such as phishing schemes are now so commonplace that additionalmeasures are required to ensure current and potential customers that legitimate businesses arewho they appear to be and EV certificates are one of those measures.

EV certificates are based on strong verification of a business or organization identity. The daysof no one knows youre a dog are over. Legitimate businesses now have the means todistinguish themselves online by using a standardized verification mechanism provided by atrusted third party.

Chapter 3 describes in detail the steps an organization must go through before receiving an EV SSLcertificate as well as the standards with which issuers must comply.

In addition, these certificates use strong encryption methods to protect the confidentiality of communications and integrity of transactions. Just as threats to information security haveevolved to continue to be effective, so have the countermeasures that mitigate the risk from thosethreats.


24/88

Chapter 1

17

SummaryThe Internet has proven its importance to business, but security challenges threaten to hamper itsfull potential. Threats range from various forms of phishing scams and man-in-the middle attacks

to the loss of confidential information and fraud. In spite of these challenges, a businessenvironment can exist on the Web as long as three key attributes are ensured: Authenticated identities Confidentiality of information exchange Integrity of transactions

The Internet, however, was not designed to distrust other parts of the network or users of thesystem. Later additions to the family of Internet protocols, such as the SSL protocol, were addedto improve security. In that same trend of identifying particular security needs and providing ameans to address those needs, EV SSL certificates have been created to maintain a sufficientlysecure business environment on the Web.


25/88

Chapter 2

18

Chapter 2: Overview of SSL and EV-SSL Certificates

SSL certificates are widely used in secure Web communications but because they functionbehind the scenes, most users give little attention to how they work. This chapter will take acloser look at SSL certificates to answer several key questions:

How are SSL certificates used? How are they implemented? What are their limitations? How are Extended Validation (EV) SSL certificates different?

In answering these questions, we will delve into both the technical and organizational issues thatare involved with the use of SSL certificates.

Overview of SSL CertificatesSSL certificates are like identification cards for a device. They associate an identity, such as aWeb site or a person, with a resource, such as a particular server or a client device. One of theirpurposes is to answer the question: how do I know that a server, which claims to host a particularWeb site, is actually the authentic company server? Another purpose is to ensure confidentialcommunications by encrypting traffic between a client and a server.

Proving Identity Servers with certificates can essentially present those certificates in much the same way we usedrivers licenses to prove our identity. SSL certificates are like drivers licenses in a couple of key ways. First, they are standardized. We expect a drivers license to have photo of the driver, aname, an address, a birth date, and an indication of the state that issued the license. Similarly, anSSL certificate will have a name of a server, the name of a trusted third party that issued thecertificate as well as some additional cryptographic information that makes any tampering easyto detect.

The second similarity is that trusted third parties issue both drivers licenses and certificates.States issues drivers licenses; companies, known as Certification Authorities (CAs), issuecertificates. Both types of third parties have procedures they use to verify the identity of theperson, business, or organization requesting a licenses or SSL certificate. We trust these thirdparties to sufficiently verify identities, so we can trust that people, or servers, are who they claimthey are when they posses one of these forms of identification.


26/88

Chapter 2

19

Figure 2.1: Parties that have not established mutual trust directly can establish trust indirectly through a mutually trusted third party.

Acquiring Certificates CAs might have different procedures for issuing authenticated SSL certificates but some stepsare common to all. First, the person or organization applying for the certificate will have toprovide the CA basic information, which is validated by the CA as true and accurate, including:

The name of the server or domain that will use the certificate; for examplewww.mybusinesssite.com or mybusinesssite.com

The organization or business name requesting the certificate The type of server platform Contact information

A certificate signing request (CSR)These are all self-explanatory except for the last item, the CSR.

Different standards for issuing SSL certificates can lead to uncertainty on the part of users whodepend on these certificates to verify the identity of businesses and organizations. EV SSLcertificates address this issue.


27/88

Chapter 2

20

The CSR is a cryptographic message that is created using the name of the domain or server thatwill use the SSL certificate along with a key, known only to the applicant. To create a CSR, theapplicant first generates a private key/public key pair using software generally provided withWeb servers. This key pair is used to encrypt and decrypt messages; one key essentially locks amessage while the other unlocks it.

The details of this kind of public key encryption are described later in this chapter.

A program provided with Web and application servers is then used to generate the CSR. Theserver or domain name and the private key are used as inputs. CSRs are bound to both thedomain name and the private key used to generate them so the certificate that is issued can onlybe installed on a server hosting that domain and by an administrator with the private key used togenerate the CSR.

It is possible to use a single certificate to secure the same domain on multiple servers as long as theprivate key has been installed on all servers.

Installing an SSL Certificate After your CA has created a certificate for a site, a file with a digitally encoded certificate is sentto the requestor. A certificate is delimited with a Begin Certificate and End Certificate taginstead of the BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST usedin CSRs.

The installation process will vary by server type but the essential steps are: Copy the CAs certificate to the server. This certificate contains information, such as the

CAs public key, needed to verify certificates from that CA.

Copy the servers certificate to the server. Update the server configuration to register the new certificate. For example, a systems

administrator would edit the http daemon configuration file to include the location of theservers certificate, the private key used to generate the CSR, and the location of theCAs certificate.

Once these steps are done, the server can then authenticate itself to clients and establishencrypted communication between the server and a clients browser.

Before delving into an example of how SSL certificates are used to secure a session between theserver and a client, we will first examine some of the details that underlie the SSL protocol.


28/88

Chapter 2

21

Figure 2.2: A typical server certificate contains details about the domain as well as the encryption algorithms and parameters.

SSL is actually an older protocol that has been supplanted by the newer Transport Layer Protocol(TSL), however they are quite similar and TSL is often referred to by the older name of SSL. Forconvenience, this book uses the more commonly used designation SSL and will use TSL only whendescribing a feature found in TSL but not SSL.

SSL Encryption TechnologyThe ability to secure confidential information and verify the identity of parties on the Internet, orany public network for that matter, depends on cryptography. The SSL protocol supports a

number of different encryption algorithms; users are able to select algorithms that best balancerequirements for security and speed. Although the details of the various encryption algorithms isbeyond the scope of this guide, we will examine two categories of algorithms, known assymmetric or private key cryptography and asymmetric or public key cryptography. Both areused in the SSL protocol.


29/88

Chapter 2

22

Symmetric Key Cryptography To encrypt a message, one needs an encryption algorithm and a key. The key is a sequence of bits that is input to the algorithm along a message (known as a clear text) to produce theencrypted message (known as the cipher text).

The cipher text cannot be decrypted unless one has the key or can discover the key bycryptanalytic technique (cracking the code). When using symmetric key cryptography, thesame key is used for both encoding and decoding a message, so we have two problems: keepingthe key from being cracked and, most problematic of all, keeping it secret.

Figure 2.3: In symmetric key cryptography, the same key is used to encrypt and decrypt a message.

Cracking Codes

In theory, all keys can be cracked if only by brute-force trial and error; however, the longer thekey, the more time that is required to crack the key. There was a time when keys tens of bits inlength were sufficient to protect messages. In fact, the U.S. government established the DataEncryption Standard (DES) standard in 1977 and specified the use of 56-bit keys. By the late1990s, DES-encrypted messages were being cracked on specialized hardware designed to searchall possible keys. DES is no longer considered secure, primarily because of its short key length.DES has been replaced by the Advanced Encryption Standard (AES) that uses 128- to 256-bitlength keys.

For more about DES, see the standard specification at http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf ; for more information about the AES standard, seehttp://csrc.nist.gov/CryptoToolkit/aes/rijndael/ .
http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdfhttp://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdfhttp://csrc.nist.gov/CryptoToolkit/aes/rijndael/http://csrc.nist.gov/CryptoToolkit/aes/rijndael/http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdfhttp://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf


30/88

Chapter 2

23

In addition to brute-force techniques to find keys, encryption can be compromised usingcryptanalytic techniques such as:

A cipher-text only attack in which the cryptanalyst only has a piece of encoded text. Thisgenerally requires a large quantity of cipher text.

A known plain-text attack in which both the plain text and cipher text of a message areavailable. A chosen plain-text attack in which the attacker is somehow able to get a piece of

selected text encrypted An adaptive chosen plain-text attack is possible when the attacker can continue having

pieces of selected text encrypted and decides what text to encrypt based on what waslearned from previous encryptions of selected text

These kinds of attacks can provide information that can help narrow the search for the key. Inpractice, cryptanalysis is exceedingly difficult and, practically speaking, not a significant threatto SSL.

The same cannot be said for all encryption algorithms. For example, the once popular WirelessEncryption Protocol (WEP) is easily cracked and should not be used. Only rigorously analyzedencryption algorithms, such as those commonly used in the SSL protocol, should be consideredsecure.

Cracking codes is and always will be a potential problem for symmetric key cryptography.However, the work effort required to crack algorithms used in SSL is so high, attackers are likelyto search for an easier route to decrypting messages.

Keeping Keys Secret

When using symmetric key cryptography, we need a secure method for exchanging keys. This issomething of a bootstrapping problem. We need to exchange keys in order to have securecommunication over the Internet, but we cant exchange keys over the Internet because the lowerlevel protocols, such as TCP and UDP, are not secure.

One option is to use some other means of exchanging keys. This out of channelcommunication, as it is known has its drawbacks. It is not practical to have out of channelcommunication for high volume, short-lived transactions. For example, consider buying a book from an online retailer. The customer chooses a book and proceeds to checkout. Before enteringher shipping and credit card information she needs to make or receive a phone call with a specialcode. Once she has the code, she enters it into her browser and establishes a secure session with

the retailer. She then goes on to provide her name, address, and credit card number. Othermethods of exchanging keysfor example, using email rather than the browser sessionare stillsubject to man-in-the-middle attacks and other eavesdropping attacks.


31/88

Chapter 2

24

Out of channel communications do have their place when additional levels of verification arerequired with relatively infrequent but important transactions. For example, when a bank customer signs up for online banking, the bank calls the customer at the home phone number onrecord to provide a verification code that must be entered into the online form.

Fortunately, practical methods have been developed for exchanging keys using the other broadgroup of encryption algorithms, known as public key cryptography. Before moving onto publickey cryptography, it is worth noting that in spite of the difficulties in exchanging keys,symmetric key cryptography holds an important advantage over public key algorithms:implementations of symmetric key algorithms are much faster than public key methods. Bycombining symmetric key and public key cryptography, we can have the best of both worlds.

Figure 2.4: Out of channel communications increase the complexity of and time required to complete a transaction and is practical only for low volume, high security transactions.

Public Key Cryptography Public key cryptography, also known as asymmetric cryptography, uses two keys instead of one.One key is used to encrypt a message and the other is used to decrypt it. Its like having one keyto lock a door and another to unlock it. We wouldnt worry if someone had a key to lock thefront door of our house as long as no one else had the key to unlock it. The same goes for public

key cryptography.


32/88

Chapter 2

25

Figure 2.5: Public key algorithms use two keys; one is kept secret and the other is publicly available,eliminating the requirement for exchanging a shared key.

An important characteristic of the public and private keys is that there is no practical way todetermine one of them given the other. Someone can safely assume that their public key can beshared widely and not have to worry that somehow an attacker will figure out their private key.This feature stems from the way key pairs are created.

Key generation for public key cryptography uses mathematical problems that are relatively easyto perform but the reverse, or inverse, operation is much harder. Take a simple example. Adding5 + 3 is just as easy as subtracting (additions inverse operation) 8 3. Now consider multiplying

two large prime numbers (these can be divided without a remainder only themselves and 1). Thatis easy, but given the product of those two large primes it is quite difficult, practicallyimpossible, factor that number back into the two prime numbers you started with. There are othermathematical problems that have similar characteristics. They are collectively known astrapdoor functions because it is easy to go through one way and much harder to go through theother way.

Trapdoor functions are useful when solving the problem of secretly exchanging keys. Supposetwo people want to exchange confidential messages. They can each share their public key withthe other. In the case of a large organization, they may store their key in a directory so thatanyone can use it to send encrypted messages that only the person holding the correspondingprivate key can decrypt. Each person generates a random number, encrypts it with the recipientspublic key, and sends it. Only the recipient will be able to recover the random number becausethe private key is needed to decrypt the message. Now each party has a pair of random numbersknown to each. This pair is used to generate a session key that both can use to communicate withless computationally intensive private key cryptography.

We have now established how keys can be securely exchanged allowing for efficiently encryptedcommunications. This meets the confidentiality requirement of secure communication. Therestill remains the need to ensure messages are not tampered with in transit. This is done withmessage authentication codes.


33/88

Chapter 2

26

Message Authentication Codes and Message Integrity Even though an attacker may not be able to read an encrypted message, using a man in themiddle attack, someone could intercept the message, scramble the order of bytes or substitutetheir own data. The attacker could at the very least disrupt the communications. To avoid thisproblem, SSL uses another cryptographic method known as hash functions.

Hash Functions

Hash functions are calculations that take a variable-length string of data as input and produce afixed-length string as output. This would be quite unremarkable if it were not for two facts. First,even a slight change in the original input will result in a change in the output; and second, it ishighly unlikely that two different input strings will produce the same output string. Thesefeatures of hash make them quite useful for detecting tampering.

Consider an example. A commonly used hash function is called MD5. When MD5 is applied tothe string

1 . The strategy meeting will be held Wednesday at 10:00 am

The following string is output2 . 0a7a94d707e95d0fe69b551dc0b9cdb8

If we change the input string slightly by adding a period to3 . The strategy meeting will be held Wednesday at 10:00 am.

The new output is:4 . b88b587881b945a5eadc8ca96bc5a0d3

By sending the value of a hash function along with a message, the recipient can tell if themessage has changed in transit. That is, of course, assuming the hash value has not changed

either. This brings us to the next step in calculating a message authentication code.

Protecting Message Integrity

To ensure that the hash value is protected, it is encrypted with the senders private key. It canthen be decrypted using the senders public key. To make sure no one other than the intendedrecipient can decrypt the hash value, the encrypted hash value is combined with the message textand encrypted using the recipients public key. Now, only someone with the recipients privatekey will be able to get the hash value.


34/88

Chapter 2

27

Figure 2.6: Doubly encrypting the hash value provides confidentiality as well as non-repudiation.

A further benefit is that if we can decrypt the hash value using the senders public key, we can besure the message was sent by someone in possession of the senders private key. This providessome level of assurance that the sender is actually who we believe it to be and thus providesanother important aspect of secure communicationsnon-repudiation.

To summarize, SSL-based communications use public key cryptography techniques to exchangea shared secret key, known as a session key, which is then used to encrypt communications usinga symmetric key algorithm.

Example SSL Session Several steps are required to set up a secure communication channel between a client and server:

1. The client sends a message to the server over an unsecuredchannel indicating its intent to start an SSL session. In themessage, the client includes details about the clientscapabilities, such as:

a. The version of SSL the client uses

b. Cipher algorithms supported

c. Session-specific data

2. The server responds by sending similar information about SSL version, cipheralgorithms, and session-specific data. In addition, the server sends its SSL certificate.


35/88

Chapter 2

28

3. The client uses the servers certificate to authenticate the server. This involves severalchecks, including:

a. Verifying that the current date is within the valid date range specified on thecertificate.

b.

Checking the clients list of trusted certification authorities stored in the clientsbrowser (see Figure 2.6). If the certificate is not issued by a trusted CA, then theserver is not authenticated.

c. The public key of the CA, provided along with other information about the trustedCA in the browsers list of trusted CAs, is used to verify the digital signature of the CA on the certificate. If the digital signature is not validated, the server is notauthenticated.

d. The client compares the domain name on the certificate and the domain name of the server. If they are different, then the server is not authenticated.

4. Once the servers certificate is validated, the client generates a piece of secret data. (The

details of how this is done will depend on which cipher was chosen by the client and theserver). The client then encrypts the secret data with the public key provided in theservers certificate and sends it to the server.

5. The server decrypts the message with the secret data using its private key. It thencalculates a master secret. (The exact steps depend on the protocol negotiated by theclient and server).

Figure 2.7: Browsers are preconfigured with lists of trusted CAs.


36/88

Chapter 2

29

6. The client uses the secret data it had sent to the server to calculate the master secret aswell.

7. The client and the server use the master secret to calculate a session key that is used forfurther encrypted communication.

8. The client and server exchange messages indicating they will use the shared session key

for future communication and that the setup process is complete.At this point, communications between the client and the server are encrypted until the session isterminated.

It should be noted, the example session described is the more common kind of SSL authentication. Asecond kind, known as mutual authentication, includes additional steps in which the client devicesends its SSL certificate to the server, which in turn verifies the certificate in the same way the clientverifies the servers certificate. The basic principles are the same in both kinds of authentication.

Issues Successfully Addressed by SSL

The SSL protocol has demonstrated by its continued widespread use that it is an effective meansof establishing and maintaining secure communications channels over untrusted networks, suchas the Internet. The important issues successfully addressed by SSL include:

The use of public key cryptography within SSL has solved the problem of securelysharing a private key (which must be kept secret) that can be used to both encrypt anddecrypt messages. SSL uses this more computationally intensive type of cryptography toexchange information needed to create a shared secret key; it is not used for encryptingthe contents of communication between the client and server.

Symmetric key cryptography is much more efficient than public key cryptography and isused for the bulk of the encryption work in an SSL session.

SSL must work with a wide range of clients and servers that may support differentversions of SSL and different kinds of ciphers, so SSL incorporates an initial exchange of information and a negotiation to find a mutually supported set of parameters.

SSLs support of a variety of encryption algorithms provides clients and servers a rangeof options for encryption, allowing for longer key lengths when requirements warrant it.The protocol also uses older as well as newer encryption algorithms, providing somedegree of backward compatibility to clients and servers that may not have upgraded toimproved ciphers.

Of course, a chain is only as strong as its weakest link. SSL strong links are built on the soundmathematical foundation of cryptography; the weaker links in the security chain stem from theconcerns with the initial authentication of an organization requesting a certificate from a CA.


37/88

Chapter 2

30

Limitations of SSL: Lack of StandardsThe SSL protocol is well designed with respect to preventing eavesdropping and avoidingsuccessful 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 thatwant to communicate over a secure channel can agree on an organization that will vouch for theidentity of holders of SSL certificates. The protocol does not address some key issues related toauthenticating 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 oftenmore 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 ones needs, for example,

to keep a toddler from getting into a cabinet filled with chemical cleaners. One could invest in astronger 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 theirpossessions. 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 securitymeasures to protect its assets.

Domain-Only Certificates

In the case of online transactions, different needs dictate different levels of security andauthentication. A Web master running a site for a local basketball league wants to allow coachesto use the site to post practice schedules and other team-related information. The Web masterdoes not want anyone else changing those schedules, so she implements a user login. Beingsecurity conscious, she also does not want clear text passwords sent over the Internet, so she usesthe 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, wouldlikely want nothing more than to be assured that the transaction is encrypted. In this case, simplyhaving a certificate that verifies the identity of the domain is sufficient.


38/88

Chapter 2

31

Domain-only certificates typically validate that the requestor of a certificate is authorized to usethat domain. These certificates are inexpensive, largely because the validation process can beautomated. Information about the owners of domain names is readily available from utilityprograms, such as whois. (See Figure 2.8 for example output of whois).

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 authenticatedcertificates to protect sensitive data. More extensive authentication procedures should be used formost business-oriented domains.

Full-Company Validation

When CAs use full validation procedures, they look for more rigorous proof of the identity of theperson, business, or organization requesting a certificate. They will still go through the samesteps 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 drivers license for a person or incorporation

papers for a companyWith full-company validation, one cannot simply register a domain name and acquire acertificate; the requestor must be able to demonstrate the company has some established legalidentity. Again, there are varying levels of certification involved depending on the issuing CA.


39/88

Chapter 2

32

Problems with Varying Levels of Certification

The biggest problem with varying levels of certification is that these variances are not apparentto users who are expected to trust these certificates. When a browser establishes an SSL sessionwith 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 bankssite.

The root of this problem was that there were no well-defined standards for authenticatingbusinesses. Two different CAs may have different procedures for full company certification. Onecompany may check government records to see if a business by a certain name has beenestablished while another will make more rigorous checks to see that the company is actuallystill actively in business. These variations in current practices, along with the rise of phishingscams, have undermined trust in online commerce and prompted the industry to respond with anew type of SSL certificate that does not suffer from these deficiencies.

EV SSL CertificatesEV SSL certificates use the same cryptography and network protocols as SSL certificates butthey improve the certification process to address the weakness outlined earlier. The standards forEV SSL certificates have been established by a governing body known as the CA/BrowserForum ( http://www.cabforum.org/ ). Before an EV SSL certificate is issued, the CA conducts athorough 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, aprofessional assurances organization, to demonstrate that proper policies, procedures, andtraining measures are in place to ensure quality control.

Details of the authentication and auditing process are described in Chapter 3.

In addition, most high-security browsers such as Microsoft IE7 now provide additional visualcues to users when a site uses EV SSL certificates. This eliminates the problem of how a user isto know the level of verification and authenticate behind a certificate.

Details about the how browsers make use of EV SSL certificates are described in Chapter 4.
http://www.cabforum.org/http://www.cabforum.org/


40/88

Chapter 2

33

SummarySSL certificates have long been used to support trust between parties using the Internet forcommerce and other transactions. Using sound cryptographic techniques, SSL has been able toprovide an efficient means for the confidential exchange of information and guarantees of message integrity in those exchanges. In spite of these advantages, weaknesses in howcertificates are issued and the level of information about certificates provided to users haveundermined the trust that had been built. In response to these issues, CAs and browserdevelopers have established EV SSL certificates and a set of standards governing theirprocessing and use that seek to re-establish levels of trust needed for an environment conduciveto online commerce and other transactions.


41/88

Chapter 3

34

Chapter 3: Authentication and Verification

In the first two chapters, we have seen a wide range of threats to Web security, includingphishing, loss of privacy and confidentiality. The implications for businesses include fraud,identity theft, damage to brand reputation, and ultimately the reduced potential for onlinebusiness due to a lack of trust. Clearly, business transactions are dependent on establishingauthenticated identities and maintaining the confidentiality and integrity of transactions. SSL hasmet many of these needs, but changes in phishing and other attacks are pushing the limits of SSL-based protections. Certification Authorities (CAs) and browser vendors have respondedwith the Extended Validation (EV) SSL certificate.

The EV SSL authentication and verification standard is more demanding on the part of CAs,parties seeking certificates, and has also required feature and functionality updates to webbrowsers in order to display the unique interface conventions associated with these certificates.This chapter will focus on the CAs and the parties seeking certificates. The use of EV SSLwithin browsers is the subject of Chapter 4.

The authentication and verification process is best explored by examining several aspects: Elements of the standards-based verification process Steps to obtaining an EV SSL certificate Verification requirements and processes Certificate revocation

Together these components provide for a better identification process, which in turn establishesthe foundation for greater trustthat is the objective of EV SSL certificates.

The focus of this chapter is the process and procedures used to authenticate and issue EV SSLCertificates. For details about the business case and cost justification for these enhanced measures,see Chapter 1.


42/88

Chapter 3

35

Standards-Based Verification ProcessThe additional trust that one places in EV SSL certificates is based largely on the comprehensiveverification process. To describe the verification process, it is useful to consider three elements:

Structure of the CA/Browser Forum Extended Validation policies Compliance issues

Structure of the CA/Browser Forum As we have seen with traditional SSL certificates, CAs often have different standards forverification. For this reason CAs, working with browser vendors, have established a governingbody known as the CA/Browser Forum to define a standards-based verification process.

See Limitations of SSL: Lack of Standards in Chapter 2 for a discussion of issues related to non-standardized certification processes.

The evolution of standards in the field of information security is similar to that of otherdisciplines. From the esoteric standards of the Institute of Electrical and Electronics Engineers(IEEE) to the well-known Underwriters Laboratory (UL), technical business disciplines havebenefited from objective third parties who are able to created standards that are adopted acrossan industry. The CA/Browser Forum has filled this role for the digital certification industry.

The CA/Browser Forum includes leading CAssuch as Thawte, VeriSign, and GeoTrustaswell as browser vendors and open source projects, including Microsoft, Opera Software, KDE,and The Mozilla Foundation. The widespread participation is crucial to ensuring that a single set

of standards is adopted to prevent confusion and defeat the purpose of EV. For example, if someleading CAs did not adopt this standard and instead proposed their own, there could be confusionin the market about the definition of EV SSLs and possibly concerns that one standard is awatered down version of the other.

The founders of the CA/Browser Forum recognized that the value is in being able to demonstratethis high level of authentication to the end user. To be most effective, end users would have to beable to identify sites secured by EV SSL certificates easily. Unlike CAs, browser vendors havemore flexibility with how they display EV SSL information. For example, all browsers maychange the background color of the URL address line when a site is certified by EV SSL butsome may use additional visual cues. IE7 was the first to develop the green barother browsermanufacturers will develop similar methodologies to signal the presence of an EV SSLcertificate.

For example, VeriSign provides a Firefox plug-in to turn the address bar green when an EV SSLcertificate is available and provides additional information when the user right-clicks the address bar.The add-on is available at https://addons.mozilla.org/en-US/firefox/addon/4828 .
https://addons.mozilla.org/en-US/firefox/addon/4828https://addons.mozilla.org/en-US/firefox/addon/4828


43/88

Chapter 3

36

EV Policies Governing CAs The CA/Browser Forum has issued a set of requirements for CAs to follow when processing EVSSL certificate requests. To be considered a legitimate provider of EV certificates, CAs mustfollow the requirements that address areas such as:

Compliance Insurance Disclosure Commitment to guidelines

Each of these areas provides a component of the foundation on which trust in EV SSLcertificates is built.

Compliance Policies

The compliance policies establish the minimum expectations for a CA. Users of EV SSL

certificates might even take for granted that the compliance policies are followed. Nonetheless,the CA/Browser Forum has spelled them out directly:

Implement and make public its own auditable processes for processing requests for EVSSL certificates

Make known the CAs and Root CAs certification hierarchy Incorporate the CA/Browser Forum guidelines in their EV certification process Comply with business laws of the jurisdiction in which the CA does business Implement the requirements of the WebTrust Program for CAs or the WebTrust EV

program

The WebTrust program is a set of principles and policies established by a professionalorganization from the public accounting field to further boost consumer confidence and trust ine-commerce and the use of PKI technology. Participating public accounting firms assess theservices provided by CAs to determine whether they meet the policies and criteria established bythe WebTrust Program. In addition to the basic principles established to verify identities,compliance requirements address insurance and auditing. For CAs to have their root included inbrowsers, they need to complete the WebTrust audit.

It is important to note that if a CA fails its annual WebTrust audit, its certificates will no longer causecompatible browsers to behave as if they were EV SSL certificates. The certificates will still supportencrypted communication, but the browser will not show the green bar when displaying a page from asite with an EV SSL certificate from such a CA.

For more information about the WebTrust Program for CAs seehttp://www.webtrust.org/CertAuth_fin.htm .
http://www.webtrust.org/CertAuth_fin.htmhttp://www.webtrust.org/CertAuth_fin.htm


44/88

Chapter 3

37

Insurance Requirements

Like many businesses providing professional services, CAs are expected to carry general liabilityand errors and omissions insurance. The general liability insurance must be at least $2 millionand the errors and omissions insurance must be at least $5 million. The guidelines stipulateadditional specifications for CAs that want to self-insure. As one might expect, there arestringent audit requirements imposed on CAs issuing EV certificates.

Audit Requirements

CAs are required to undergo these types of audits: Pre-issuance readiness audits Regular self-audits Annual independent audits

The pre-issuance readiness audit is conducted before a CA begins issuing EV SSL certificates.

This audit is based on the WebTru

Secure SSL Primer

Documents

Transcript of Secure SSL Primer