Introducing SSL The Secure Sockets Layer Protocol · 2015-07-28 · Introducing SSL - The Secure...

Introducing SSL

The Secure Sockets Layer Protocol

MSc Seminar in Telecommunications

Michael [email protected]

supervised byProf. Dr. Ulrich Ultes-Nitsche

Department of InformaticsUniversity of Freiburg i. Ue., Switzerland

June 16, 2003

Introducing SSL - The Secure Sockets Layer Protocol 1

Contents

1 Abstract 2

2 Introduction 22.1 SSL Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 SSL and the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 The History of SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Security Concepts 43.1 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Message Digests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.3 Message Authentication Codes . . . . . . . . . . . . . . . . . . . . . . . . 63.4 The Key Management Problem . . . . . . . . . . . . . . . . . . . . . . . . 63.5 Public Key Cryptography and Digital Signatures . . . . . . . . . . . . . . 63.6 Certificates and Certification Authorities . . . . . . . . . . . . . . . . . . . 73.7 The Missing Part in the Puzzle . . . . . . . . . . . . . . . . . . . . . . . . 8

4 The Basic Design of SSL 94.1 The SSL Handshake Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1.1 Handshake Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 104.2 The SSL ChangeCipherSpec Protocol . . . . . . . . . . . . . . . . . . . . 134.3 The SSL Alert Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4 The SSL Record Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.5 SSL Connection Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Conclusion 165.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.2 Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17


1 Abstract

Network Security has grown to a major issue in the world of modern communication.Whether sharing financial, business or personal information, people want to know withwhom they are communicating (authentication), they want to ensure that what is sentis what is received (integrity), and they want to prevent others from intercepting whatthey are communicating (privacy). The Secure Sockets Layer protocol (SSL) [1] providesone means for achieving these goals and is the subject of this paper.Since SSL requires a basic knowledge of communications security and cryptography, thereader will first be introduced to some widely deployed security concepts in order tounderstand the security mechanisms used by SSL to provide secured communicationover TCP/IP [2, 3] (Transmission Control Protocol/ Internet Protocol) networks.

2 Introduction

2.1 SSL Overview

Communicating data over a network always implies a possible loss of confidentiality,message integrity or endpoint authentication. These are the three major aspects one hasto consider when speaking of data security:

• Confidentiality : We want to be sure that our data is kept secret from unintendedlisteners.

• Message Integrity : We want to be sure that any message we receive is exactly theone the sender sent.

• Endpoint Authentication: We want to be sure that our communicating partner isthe one we intend.

SSL is a security protocol, that provides the necessary mechanisms to achieve thesesecurity goals through the use of cryptography, certificates and digital signatures. Itprovides a secure channel between two machines, namely a client (usually a browser)and a server (usually a webserver). An SSL secured channel offers transparency, meaningthat, though encrypted, the data is being passed through unchanged; what is written bysome enpoint A is exactly what endpoint B will read upon reception. SSL can be usedwith several higher layer protocols including the Hyper Text Transfer Protocol (HTTP)[4], the File Transfer Protocol (FTP) [5] and the Net News Transfer Protocol (NNTP)[6] with only minimal modification, which is very convenient.

SSL is not a single protocol, but consists of four sub-protocols which operate ontop of TCP/IP (SSL Record Protocol) on the network layer and on the application layer(SSL Handshake Protocol, SSL ChangeCipherSpec Protocol and the SSL Alert Protocol),where we find other higher layer protocols, such as HTTP (Fig. 1). These subprotocolswill be discussed further in this paper. In theory, SSL may be thought of as a securedTCP connection, since an SSL connection is intended to act like two sockets connected


by a TCP connection. SSL depends on a reliable packet delivery mechanism, thus anyother transport protocol could be used below SSL. But practice shows that nearly everySSL connection runs on top of TCP. SSL isn’t able to run over UDP (User DatagramProtocol) [7] or directly over IP.

Figure 1: SSL runs above TCP/IP and below high-level application protocols

2.2 SSL and the Web

The primary use of Secure Sockets Layer is to enable protected web traffic over HTTP.This is the main reason we will discuss HTTP over SSL throughout this paper. HTTPuses the same way of communication with SSL as it does with TCP. So TCP can handleany SSL request like it does for any other protocol requesting its services. The processremains quite simple:

With HTTP, a TCP connection is started and the client sends a request. The serverresponds by sending a document. As soon as SSL comes into operation, the client againsets up a standard TCP connection, establishes an SSL channel on top of it and sendsthe same HTTP request to the server, this time using the secured SSL channel. Theserver responds the usual way but also uses the SSL channel to send its response to theclient. So far so good but there is still a problem with this approach. An ordinary HTTPserver does not understand an SSL request and interprets this data as some garbage.What we need is our client to have an additional feature in order for the process to workcorrectly, since we want to know whether the server even supports SSL connections. Thesolution comes with the use of a Uniform Resource Locator (URL) beginning with httpsrather than http to indicate that a client wants to use SSL, for example:

https://mysecureserver.com

Consequently, HTTP over SSL is often referred to as HTTPS. By default, HTTP andHTTPS use the separate ports 80 and 443 respectively.

2.3 The History of SSL

SSL was originally developed by Netscape Communications, intending to allow securecommunication between a browser and a webserver. Due to some major drawbacks,


mainly missing support for credit card transactions over the Internet, the first version ofSSL was never released. SSLv2 [8], being the earliest variant of SSL publicly released inNovember 1994, finally offered confidential credit card transactions and server authen-tication with the use of digital certificates and encryption. It was deployed in NetscapeNavigator 1.1 only a few months later in March of 1995.

But SSLv2 soon turned out to be highly insecure. Wagner and Goldberg [9] showedhow an SSL secured connection could be broken in less than an hour from Navigator 1.1.To address these problems, some firms developed a number of independent variants of theprotocol. The most important one was Microsoft’s Private Communications Technology(PCT) [10], released in October 1995.

After an abortive draft of SSLv2.1, which was supposed to be a modification ofSSLv2, Netscape eventually started all over and hired a well known security consultantto join the team and develop a completely new version of SSL. This project came to anend in late 1995 with the release of SSLv3 providing strengthened cryptographic algo-rithms and an important number of solutions to previous security problems.

In May 1996 the Internet Egineering Task Force (IETF) started a try to standardize anSSL-like protocol by chartering the Transport Layer Security (TLS) [11] working group.It was widely understood that this was an attempt to bring some harmony between theapproaches of both Microsoft and Netscape. In the same year Microsoft came up withanother submission, namely the Secure Transport Layer Protocol (STLP) [12], whichwas a modification to SSLv3, providing additional features which Microsoft consideredto be critical, like support for datagrams (e.g. UDP) and client authentication usingshared secrets. After several extraordinary meetings, the TLS working group decided toname their new standard Transport Layer Security Protocol (TLS), thus avoiding eitherparty to consider itself as the winner of the battle by naming the new standard neitherSSL nor PCT. It is clear that both Netscape and Microsoft were equally unhappy withthis decision. But whatever the name, the new protocol wouldn’t be more than a minorcleanup of SSLv3.

The TLS working group finished its work in January 1999 and finally published TLSas RFC 2246 [11] over two years late, because of backward compatibility problems withSSLv3 and several disagreements with the Internet Engineering Steering Group (IESG),which must approve any document before its being allowed to be published as a RequestFor Comment (RFC). As of this writing, both Internet Explorer and Netscape/Mozillabrowsers support TLS and SSL.

3 Security Concepts

SSL assures secure data transmission through the use of several security concepts, whichwill be briefly discussed in this section. These concepts each consist of one or morecryptographic 1 algorithms, used to provide security.

1Cryptology is the theory of designing various algorithms to provide security.Cryptography is the study of using these algorithms to secure systems and protocols.


3.1 Encryption

The most simple concept of a security algorithm is encryption. It is built on the ideaof taking some plaintext data and converting it to so-called ciphertext (encrypted data),using a specific key, usually a short random string of 8-24 bytes in length. Fig. 2 showsthe relationship between these elements. The resulting ciphertext looks nothing morethan random data with no useful information in it. The only thing one could gatherout of it without knowing the appropriate key, might be the approximate length of theinitial plaintext.

Figure 2: Encryption and Decryption

However, it is quite difficult to detect, whether the ciphertext has been tamperedwith. Possible effects on the plaintext of tampering with the ciphertext depend on thecipher (encryption algorithm) being used for encryption. An encryption algorithm isconsidered to be efficient when it responds to the following criteria:

• The cipher’s security is totally determined by the number of possible keys; thefastest attack should require exhaustive work.

• The cipher’s security depends solely on the secrecy of the key, whereas the algo-rithm itself should not have to be secret to be secure.

The scheme of using the same key for encyrption and decryption is often referred to asSecret Key Cryptography (SKC). Some of the most popular ciphers on the market arethe Data Encryption Standard (DES) [13], Triple-DES (DES repeated three times) [14],RC2 [15] and RC4 (no official specification published), see [16] for a description.

3.2 Message Digests

A message digest is a function that takes a message of arbitrary length as an inputand generates a string of fix length as an output. This string is simply a characteristicrepresentation of the initial message’s content. Message digests have two importantproperties:

1. Irreversibility : Computing a message given its digest should be extremely difficult.

2. Collision-Resistance: It should be nearly impossible to produce two messages withthe same digest.

The main purpose of message digests is the computation of Digital Signatures and Mes-sage Authentication Codes (MACs), both of which will be discussed later in this section.Message digests generally allow to prove possession of a secret without actually revealingit. Currently, Message Digest 5 (MD5) [17] and Secure Hash Algorithm (SHA-1) [18]are the most widely used message digest algorithms.


3.3 Message Authentication Codes

Assume Alice and Bob want to communicate with each other. They share a same key.Alice would like to send a message to Bob. She uses her key to encrypt her message,since it is meant to be secure during transmission. But how can Bob know that theincoming message really is from Alice; how will he know that the encrypted messagehasn’t been tampered with on its way to him? What is needed here is a new tool.

A Message Authentication Code is sort of a digest algorithm with the differencethat beside the message, a key is incorporated to the computation as well. Thus aMAC always depends on both the message being treated as well as the key being usedfor encryption. MACs are usually constructed using digest algorithms. SSLv3 uses avariant of HMAC [19], while TLS uses HMAC itself. HMAC is a description of how tocreate MACs with provable security properties based on digest algorithms.

3.4 The Key Management Problem

Now that Alice and Bob make use of MACs to communicate, everything seems to befine: Alice encrypts her message, adds a MAC to it and sends it to Bob. Now she canbe sure that Bob is the only person able to read the message since he’s the only one whohas the shared key to decrypt the message. Bob on the other side knows that Alice isthe only person who has the necessary key needed to create the MAC. This implies thatBob can be sure that the message hasn’t been tampered with.

However, there’s still a problem remaining. Communicating with n persons securelyover a network implies having n keys to share. How do this? Because this actuallymeans that you would have to meet everyone with whom you want to communicate inorder to exchange keys. This problem is commonly referred to as The Key ManagementProblem.

3.5 Public Key Cryptography and Digital Signatures

Public Key Cryptography (PKC) is known to be the most popular solution to the KeyManagement Problem. As opposed to Secret Key Cryptography, PKC uses differentkeys for encryption and decryption respectively. The encryption key (public key) is madepublicly available, whereas the decryption key (private key) is kept secret by its owner 2.This way, anyone can send secret messages without ever meeting the intended recipient.Consequently, PKC offers confidentiality while solving the problem of preshared keys.

PKC also provides a solution to the authentication aspect in the way that a privatekey can also be used to create something called a Digital Signature. The relationshipbetween a digital signature and a MAC is the same as the one between PKC and SKC;you can use your private key to sign a message and the receiver can use your public keyto verify your signature. As opposed to a MAC, a digital signature has one importantproperty in addition: nonrepudation. Both sender and receiver can generate a MAC

2Public Key Cryptography is often referred to as asymmetric cryptography and Secret Key Crypto-graphy as symmetric cryptography.


but only the signer of a message can generate a signature. Thus, a recipient can alwaysprove that the sender signed a message, a fact that can’t be denied by the sender.

3.6 Certificates and Certification Authorities

The Key Management Problem is not yet completely solved. There’s still a questionwhich needs to be answered: how do communicating parties get each other’s publickeys? The obvious answer might be to publish them electronically or simply exchangethem between the two communicating parties. But these approaches wouldn’t be thatclever since an attacker could intercept the keys during transit and instead send his ownkey to each party, a case referred to as Man-in-the-Middle Attack.

The solution comes with the introduction of a trusted third party, called a Certifi-cation Authority (CA). A CA uses its private key to sign individual documents, whichcontain the name of the key owner as well as his public key. These documents are widelyknown as Certificates. The CA’s public key, which is needed to verify the CA’s signa-ture, is usually compiled directly into the software that needs it. The details of publiccertificates will not be discussed any further in this paper, but notice the basic structure:

• Issuer Name: Name of the signer of the certificate (usually a CA, e.g. VeriSign).

• Subject Name: Name of the certificate/key holder (e.g. www.ikea.com).

• Subject Public Key : The public key itself, containing information such as expirydate, serial number and the signature over the whole document.

We now have a complete solution to the Key Management Problem, including a secureway to avoid a possible Man-in-the-Middle attack; a CA does not have access to anyone’sprivate keys, which implies that it cannot read any of the messages. Moreover, sincethe same certificate can be used to prove one’s public key to anyone, a CA doesn’t haveto be online in order to allow secure communication between two parties. This is veryconvenient.

The security concepts described above (encryption, message digests, PKC and digitalsignatures) are often referred to as security primitives. These primitives can be combinedto build some more complex security mechanisms. Probably the most common exampleis, once again, to be found in PKC:

PKC can be up to a thousand times slower than SKC. So we can simply combine bothconcepts, using PKC to exchange secret keys and SKC to communicate over a securechannel using the same key for encryption and decryption. Similarly, digital signaturesare quite slow and can only be used efficiently with small messages. The solution to thisproblem is to combine digital signatures with message digests. You first calculate thedigest to a message of arbitrary length and then sign the digest with your private key.We now have an efficient way to sign large messages. Combining message digests withdigital signatures offers a convenient way of message integrity and sender authenticationwithout shared keys.


3.7 The Missing Part in the Puzzle

Setting up a secure system using these concepts works fine as long as you just sendsingle messages around (e.g. e-mail). Such a system is shown in Fig. 3 and 4. But assoon as one wants to have a permanent communication channel, this simple messagingsystem wouldn’t cover our needs, since we would have to run through the whole process(authentication, key exchange etc.) for each and every message. The idea is to establisha unique, secured channel over which we establish a set of secret keys once to last duringthe whole communication, thus as long as the channel is needed.

Figure 3: Message sending process

These requirements lead us to a point where a protocol is needed to handle differentprocesses within different phases. A basic design of such a protocol could look like this:

• Handshake phase: Exchange of certificates and secret keys in order to authenticateand exchange a shared secret

• Key Exchange phase: Using the shared secret to derive a set of cryptographic keysto protect the traffic

• Data Transfer phase: Splitting data into a sequence of records, each of them pro-tected. This way, data is sent as soon as it is ready and processed as soon as arecord reaches its destination

• Closure phase: Securely closing the established connection through the use ofprotected control messages

And this is the point where SSL finally comes into play, providing a security protocolsuite to answer these needs.


Figure 4: Message receiving process

4 The Basic Design of SSL

An SSL connection generally implies two distinct phases, namely the handshake and thedata transfer phases. Before any data can be sent over an existing SSL connection, thehandshake process must be completed successfully. The data stream being transmittedcan then be framed and sent as a sequence of secure records in the data transfer phase.All these elements will be discussed in the following.

4.1 The SSL Handshake Protocol

The initialization of an SSL connection always comes from the client, normally a web-browser looking up an URL like

https://someserver.com

The SSL Handshake has three purposes:

1. Client and server have to agree on a set of ciphers for data protection

2. Client and server have to exchange a set of keys for use with these ciphers

3. The client may optionally have to authenticate itself to the server

What happens next, can be best described by enumerating each step of the overallprocess:


1. The client sends the list of algorithms it supports to the server, along with arandom number used as input for the upcoming key generation process.

2. The server then chooses an algorithm out of the client’s list and sends it backalong with a certificate containing the server’s public key as well as its identity forauthentication purposes. Finally, the server also sends a random number, neededfor the client’s key generation process.

3. The client now verifies the server’s certificate and eventually extracts the server’spublic key. Subsequently, the client generates the so-called pre-master secret, (arandom, secret string), encrypts it using the server’s public key and sends thepre-master secret to the server.

4. Both client and server compute their respective encryption and MAC keys fromthe pre-master secret and the client and server’s random values.

5. The client computes a MAC over all the handshake messages and sends it to theserver.

6. The server computes a MAC over all the handshake messages and sends it to theclient.

To make this a little more clear; Steps 1 and 2 accomplish the first goal, namely agreeingon a cipher suite to be used for data protection. Thereafter, the client uses the server’spublic key to encrypt a shared key, which the server can decrypt using its private key.As for the remaining steps of the handshake, their purpose is to secure this exchange andto protect the handshake itself from tampering. Figure 5 shows the handshake overallprocess.

4.1.1 Handshake Messages

Every single step described above corresponds to one or more Handshake Messages,through which all necessary tasks can be accomplished (see Fig. 6):

• Step 1 consists of one message, ClientHello.

• Step 2 consists of several messages, the first being ServerHello; coming from theserver, containing its preferred cipher suite. Then the server sends a Certificatemessage and signals its temporary end of transmission with a ServerHelloDonemessage. When receiving this message, the client knows it can proceed with itsnext task of the handshake.

• Step 3 consists of a single message, ClientKeyExchange.

• Steps 5 and 6 both consist of the Finished message, being the first message en-crypted with the recently negociated algorithms. The content of this message is a


Figure 5: SLL handshake overview

MAC of all the previous handshake messages to protect the handshake from be-ing tampered with. Furthermore, the Finished message itself is MACed with thenewly negociated MAC keys.

These messages map to the steps of the handshake scheme described above. However,there is one message missing; ChangeCipherSpec, which is needed in a more particularsituation. Before going any further with a short description of the handshake messages’main characteristics, the next paragraph will briefly discuss the basic structure of hand-shake messages.

Each handshake message has a 4-byte header, consisting of a 1-byte type field and 3length bytes. The header is followed by a body, which depends on the message typebeing transmitted. The length field is not mandatory since the end of a message canbe determined from its components. But the existence of an explicit length field easesthe implementation of the protocol. Note that there is no fixed mapping of handshakemessages to SSL records. A single record might include multiple handshake messages.In theory, a single handshake message might even span more than one SSL record, butit appears that it never occurs in practice.

Brief Overview of SSL Handshake Messages

ClientHello: This is the first message sent by a client at the beginning of each SSLhandshake. Its main purpose is to communicate the client’s connection preferences tothe server. There are three negotiable parameters, namely the SSL version being used,


Figure 6: SLL handshake messages

the ciphers and the compression algorithms.

ServerHello: With this message, the server makes its choice out of the options of-fered by the client. Its parameters are the SSL version, cipher suite and compressionalgorithms that will be used for this connection. There is no obligation for a server tochoose the client’s preferred ciphers, even if supported on the server side.

Certificate: This message simply consists of a sequence of X.509 certificates, pre-sented in order, with the first one being the certificate that belongs to the server itself.The next certificate (if available) contains the key to certify the server’s certificate, etc.This step is mandatory for the server during the handshake phase; it has to send itscertificate in order to authenticate itself to the client.

ServerHelloDone: This message is empty and tells the client that the server has sentits last message in this phase. The message is required, because there are cases whereoptional messages can appear after the Certificate message.

ClientKeyExchange: This message contains the pre-master secret, generated by theclient and encrypted with the server’s public key. The pre-master secret is 48 bytes inlength, two bytes containing the client’s offered version number followed by 46 randomlygenerated bytes.

ChangeCipherSpec: This message consists of a single type byte and can be consid-ered as a placeholder since it can only take a single value of 1. ChangeCipherSpecindicates that the sender has switched to the lately negociated keys and algorithms,


thus signalising that all future messages will be encrypted with these algorithms. TheChangeCipherSpec message is unique in its kind and is not really part of the handshakesince it has its own content type. The SSL specification [1] considers ChangeCipherSpecto be a performance improvement feature of the protocol.

Netscape uses this message to ensure that it is not transmitted together with theFinished message. Because the ChangeCipherSpec message must not be encryptedwhereas the Finished message has to be encrypted. This way, it becomes impossiblefor both messages to find themselves within the same record, thus causing possible se-curity problems. But using this feature only makes sense while trying to send multiplehandshake messages within the same record. There is no public proposal for any otheruse of ChangeCipherSpec.

Finished: This is the first message encrypted with the new cryptographic parameters.Its main purpose lies in that it allows to verify, whether a message has been tamperedwith during the handshake. The concept consists of each side sending a message digestof the negociated master secret along with the concatenated handshake messages to theother party. Each side compares this digest to the same result computed locally. If theymatch, the handshake was secure and has completed successfully.

4.2 The SSL ChangeCipherSpec Protocol

As already mentioned in the former subsection, ChangeCipherSpec uses a single bytewith value 1 to indicate a transition in the cipher methods used for communication. Thisis the most simple of the SSL sub-protocols. The functionality of this protocol is usedin the finish phase of the handshake (after completion of the negotiation of the sessionparameters) to indicate that the following messages will be encrypted with the newlyestablished security parameters.

4.3 The SSL Alert Protocol

The Alert Protocol provides exception handling for SSL secured connections. Alertmessages consist of two bytes, the first byte indicates the severity of an alert, the secondbyte contains the alert code. The value of the first byte is either 1 or 2, where 1 meansthat the message is a warning and a value of 2, that it is a fatal alert. Alert messages arealways encrypted and optionally compressed. This protocol will not be discussed anyfurther, since its purpose within the SSL concept is quite clear. When receiving an alertof level fatal, the connection must be immediately terminated and the current sessioncan not be resumed. A complete list of possible alerts can be found in [20].

4.4 The SSL Record Protocol

Now that the server has been authenticated and the necessary cryptographic materialhas been exchanged between the server and the client, the secure SSL channel is finallyset up and allows protected data to be transmitted. In SSL, data transmission is done


through the use of the SSL Record Protocol, which fragments the data stream into aseries of individually protected records and sends them independently over the channel.This brings the advantage of sending data as soon as it is ready and process it on theother side, as soon as it is received.

Basically, there are two important concepts in the SSL context, SSL sessions andSSL connections. An SSL session is a set of security parameters that define the opera-ting environment of the Record Protocol (e.g. the cipher methods in use for encryption,the master secret and other parameters). This operating environment is defined duringthe SSL Handshake. In an SSL session, multiple SSL connections sharing the securityparameters defined in the SSL session can be established between the two peers. In gene-ral only one session is created and multiple connections associated with that session areused for the secure communication via SSL. This concept is used to avoid the repeatingnegotiation of security parameters for each new connection.

Each data fragment is protected through the use of a MAC, computed over the data toprovide data integrity. The MAC is then appended to the data fragment and this newlyconcatenated packet is encrypted to form the encrypted payload. The MAC will be veri-fied by the receiving party upon decryption of the payload. Eventually, a simple headeris added to the payload to form what is referred to as a record. Data fragmentation andprotection is shown in Fig. 7.

Figure 7: SSL data fragmentation and protection

The Record Header

The header of an SSL record contains the necessary information for the receiver tointerpret the record correctly. There are three relevant parameters, namely the contenttype, the length and the SSL version. The receiving implementation uses the lengthfield to determine how many more bytes it has to read off the wire before being able toprocess the message. As for the version field, it is only used as a redundant check toverify whether both parties agree on the same SSL version.


The content type field primarily identifies the nature of a message, which can eitherbe standard application data or control information, such as connection termination orerror messages. SSL offers this possibility of sending different kinds of traffic over thesame protected channel, which is very convenient.

The following describes the different content types supported by SSL:

• Application Data: All data transmitted between applications using SSL (e.g. Mozilla).

The other content types are used for traffic management:

• Alert : Various error messages, such as handshake errors, decryption or recordauthentication errors or simply to signal that the existing connection is about tobe terminated.

• Handshake: Transmits handshake messages including the initial handshake mes-sages that form the connection and are not yet encrypted since no keys have beennegociated at this point.

• Change Cipher Spec: Indicates a change of encryption and authentication of SSLrecords once a handshake has established a new set of keys.

The pieces discussed in this section form the basic SSL protocol structure (see Fig. 8).We have seen that SSL is a layered protocol. This protocol consists of a record layerthat inludes multiple message types running on top of the record layer. The record layeritself runs on top of a reliable transport protocol, mostly TCP.

Figure 8: The SSL protocol structure

4.5 SSL Connection Types

With SSL different connection types can be established. These different possibilitiesresult from the fact that the authentication of two peers (using certificates) during the


handshake is optional. In an anonymous connection, none of the two peers is authenti-cated, in this case only the encryption mechanism of SSL is used. The peers are protectedagainst passive Man-in-the-Middle attacks (eavesdropping), but no protection from ac-tive Man-in-the-Middle attacks, where messages are intercepted and fake messages aresent to the receiver, is provided. Hence, this type of connection is (or should be) avoidedwhenever possible.

A second connection type is described as Authenticated Server, Anonymous Client.In this case only the server is authenticated but no certificate from the client is requestedby the server. This is the default connection method used in general. Compared to ananonymous connection, it additionally provides protection against active Man-in-the-Middle attacks.

The third possibility to establish an SSL connection can be described as Authenti-cation of both peers. This means that the server requests a certificate from the client aswell as it checks whether the client really is who it claims to be. Although this is thepossibility that provides most security, it is not the commonly used method (as men-tioned above, in general only the server is authenticated).

Even though SSL provides a high level of security, this level solely depends on how theprotocol is used in specific cases. At this point it must be emphasized that certificatesrepresent an integral part of the security SSL provides.

5 Conclusion

5.1 Summary

SSL is vital to Web security. It provides a strong sense of confidentiality, message in-tegrity, and server authentication to users. The business of e-commerce is tied closelyto consumer confidence in the operation of SSL across the net [21].

People who develop SSL applications have two options to get an SSL implementationtoolkit:

• The easiest way is to download OpenSSL, a high-quality, free, source implementa-tion of SSLv2, SSLv3 and TLS, worldwide available for download at:http://www.openssl.org/ and free for commercial and non-commercial use.

• The alternative is to buy a commercial toolkit from one of several vendors, such asCerticom, Netscape Communications, RSA Security or SPYRUS/Terisa Systems.

• JAVA implementations are available as well at the following vendors: Baltimore,Certicom, Phaos Technology Corp. and Sun, whose Java SSL Toolkit is royalty-freefor non-commercial use (in binary form only): http://www.javasoft.com/.


Both Netscape/Mozilla and Internet Explorer implement SSL as well as Netscape’s Web-servers and Microsoft’s IIS (Internet Information Server). Multiple free source imple-mentations, based on OpenSSL, are available for the free Apache HTTP server:

• http://www.apachessl.com/

• http://www.modssl.org/.

5.2 Outlook

In the future, SSL termination devices will be able to handle more transactions at afaster rate. The encryption of key lengths and the cipher suites used will also continueto evolve in order to ensure the security of sensitive information over the Web. This way,e-commerce will be able to continue to grow in popularity as users grow more confidentin online shopping and banking, and embracing new online applications [21].

References

[1] A. O. Freier P. Karlton and P. C. Kocher. The SSL Protocol, Version 3.0. NetscapeCommunications, 1996, http://wp.netscape.com/eng/ssl3/draft302.txt (2003).

[2] J. Postel. RFC793, Transmission Control Protocol. Information Sciences Institute,University of Southern California, 1981, ftp://ftp.rfc-editor.org/in-notes/rfc793.txt(2003).

[3] J. Postel. RFC791, Internet Protocol. Information Sciences Institute, University ofSouthern California, 1981, ftp://ftp.rfc-editor.org/in-notes/rfc791.txt (2003).

[4] R. Fielding J. Gettys J. Mogul H. Frystyk L. Masinter P. Leach and T. Berners-Lee. RFC2616, Hyper Text Transfer Protocol, HTTP 1.1. Network Working Group,1999, ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt (2003).

[5] J. Postel and J. Reynolds. RFC959, File Transfer Protocol. Network WorkingGroup, 1985, ftp://ftp.rfc-editor.org/in-notes/rfc959.txt (2003).

[6] B. Kantor and P. Lapsley. RFC977, Network News Transfer Protocol. NetworkWorking Group, 1986, ftp://ftp.rfc-editor.org/in-notes/rfc979.txt (2003).

[7] J. Postel. RFC768, User Datagram Protocol. Information Sciences Institute, Univer-sity of Southern California, 1980, ftp://ftp.rfc-editor.org/in-notes/rfc768.txt (2003).

[8] Kipp E. B. Hickman. The SSL Protocol, Version 2.0. Netscape Communications,1995, http://wp.netscape.com/eng/security/SSL2.html (2003).

[9] I. Goldberg and D. Wagner. Randomness and the Netscape Browser. Dr. Dobb’sJournal, January 1996.


[10] J. Benaloh B. Lampson D. Simon T. Spies and B. Yee. Private Com-munication Technology Protocol. draft-microsoft-PCT-01.txt, September 1995,http://www.graphcomp.com/info/specs/ms/pct.htm (2003).

[11] T. Dierks and C. Allen. RFC2246, The TLS Protocol, Version 1.0. Network WorkingGroup, 1999, ftp://ftp.rfc-editor.org/in-notes/rfc2246.txt (2003).

[12] Strawman. Secure Transport Layer Protocol, Discussion Draft 1.0. Microsoft, 1996,http://www.cs.ucsd.edu/users/bsy/stlp.ps (2003).

[13] National Institute of Standards and Technologies. Data Encryption Standard. U.S.Dpt. of Commerce, December 1993.

[14] ANSI. American National Standard for Financial Institution Key Management(wholesale). ANSI, 1985.

[15] R. Rivest. A Description of the RC2(r) Encryption Algorithm, RFC 2268. NetworkWorking Group, 1998, ftp://ftp.rfc-editor.org/in-notes/rfc2268.txt (2003).

[16] B. Schneier. Applied Cryptography, 2ed. John Wiley and Sons, 1996.

[17] R. Rivest. The MD-5 Message-Digest Algorithm, RFC 1321. John Wiley and Sons,1996, ftp://ftp.rfc-editor.org/in-notes/rfc1321.txt (2003).

[18] National Institute of Standards and Technologies. National Institute of Standardsand Technologies, and Secure Hash Standard. U.S. Dpt. of Commerce, 1994.

[19] H. Krawczyk M. Bellare and R. Canetti. HMAC: Keyed-Hashing for Message Au-thentication, RFC 2104. Network Working Group, 1997, ftp://ftp.rfc-editor.org/in-notes/rfc2104.txt (2003).

[20] Eric Rescorla. SSL and TLS, Designing and Building Secure Systems. AddisonWesley, 2001, 3rd printing.

[21] Cisco Systems. Introduction to Secure Sockets Layer, White Paper. Cisco Systems,2002.

Introducing SSL The Secure Sockets Layer Protocol · 2015-07-28 · Introducing SSL - The Secure...

Documents

Transcript of Introducing SSL The Secure Sockets Layer Protocol · 2015-07-28 · Introducing SSL - The Secure...