FORMAL VERIFICATION OF THE SECURE
SOCKETS LAYER PROTOCOL
∗
Llanos Tobarra, Diego Cazorla, J. Jos´e Pardo and Fernando Cuartero
Escuela Polit´ecnica Superior de Albacete, Universidad de Castilla-La Mancha, 02071, Albacete, Spain
Keywords:
Security protocols, model checking, Casper/FDR2.
Abstract:
Secure Sockets Layer (SSL)has become one of the most popular security protocols in the Internet. In this paper
we present a formal verification of this protocol using the Casper/FDR2 toolbox. In the analysis of SSL v3.0
Handshake we have used a methodology that considers incremental versions of the protocol. We have started
with the most basic protocol, and then we have included other features such as server and client authentication,
digital signatures, etc. We have also verified SSL v2.0 because of the so called version rollback attack. Each
version has been modelled and verified, and the results have been interpreted. Using this methodology it is
easy to understand why some messages are needed in order to ensure confidential communication between a
client and a server.
1 INTRODUCTION
Security has become one of the most important topics
in the Internet in recent years. The quick development
of e-commerce, that needs the exchange of sensitive
information (credit card numbers, account numbers,
...), has given great importance to the study of com-
munication protocols that allow the exchange of se-
cret data between two or more agents in a non trusted
environment. In the last years, the most popular se-
curity protocol used in e-commerce has been Secure
Sockets Layer (SSL), developed by Netscape Com-
munications.
Two versions of SSL have been used in recent
years: SSL v2.0 (Hickman, 1995), released in 1995,
and SSL v3.0 (Freier et al., 1996) released in 1996
in order to solve some problems in v2.0. In 1999,
the Internet Engineering Task Force (IETF), the “pro-
tocol engineering and development arm of the Inter-
net”, presented the Transport Layer Security protocol
(TLS) (Dierks and Allen, 1999), an Internet standard
based on SSL v3.0 that, in fact, can be called the next
version of SSL.
In parallel to the development of communication
and security protocols, some analysis techniques have
also been developed in order to verify that these pro-
tocols work as they are supposed to, and they do not
∗
This work has been supported by the spanish government with the project “Appli-
cation of Formal Methods to Web Services”, with reference TIN2006-15578-C02-02, and
the JCCM regional project “Application of formal methods to the design and analysis of
Web Services and e-commerce ” (PAC06-0008-6995 )
have bugs that allow intruders to hear or alter the in-
formation. One of the most promising techniques in
this line is
model checking . Model checking (Clarke
et al., 1999) is a formal methods based technique
for verifying finite state concurrent systems, such as
sequential circuit designs and communication proto-
cols, that has been implemented in several tools. One
of the main advantages of this technique is that model
checking is automatic and allows us to know whether
a system works properly or not. In case the system
does not work as expected, the model checking tool
gives us a trace that leads to the source of error.
Some general purpose model checking tools have
been developed by different research groups: Spin,
UPPAAL, Murφ, Isabelle. These tools allowus to ver-
ify not only the functional properties of a system (e.g.
Spin), but also the performance of a real-time system
(e.g. UPPAAL).
Although we can use these general purpose tools
in order to verify security protocols, we consider that
it is preferable (and more intuitive) to use a tool de-
voted to the verification of security protocols. Among
these tools we can find Casper/FDR2 toolbox (Lowe,
1998), ProVerif (Blanchet et al., 2005), LySA(Bodei
et al., 2003) and AVISPA (Armando et al., 2005).
In this paper we present a formal verification of
the SSL protocol using the Casper/FDR2 toolbox.
Casper/FDR2 has been used successfully to verify
several security protocols, and we consider it is also
appropriate for the verification of SSL.
In the analysis of SSL v3.0, especially in the hand-
246
Tobarra L., Cazorla D., José Pardo J. and Cuartero F. (2008).
FORMAL VERIFICATION OF THE SECURE SOCKETS LAYER PROTOCOL.
In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 246-252
DOI: 10.5220/0001695202460252
Copyright
c
 SciTePress

shake subprotocol, we have used a methodology that
considers incremental versions of the protocol. We
have started with the most basic protocol, and then we
have included other features We have also considered
compatibility between SSL v3.0 and SSL v2.0 that al-
lows the so called version rollback attack, so we have
also needed to verify SSL v2.0.
In literature we may find several papers that deal
with the analysis of the SSL protocol. The most inter-
esting one is (Mitchell et al., 1998) where SSL Hand-
shake is analysed using a general purpose finite-state
enumeration tool called Murφ. The tool Murφ (Dill,
1996) was designed for hardware verification and re-
lated analysis, but has also been used to analyse some
security protocols (Mitchell et al., 1997). Although
the paper presents very interesting results, the main
problem, from our point of view, is that Murφ needs
a long code in order to specify the protocol and the
properties we want to analyse. A simple security pro-
tocol like the 3 messages version of the Needham-
Schroeder protocol may be specified in about 20 lines
using Casper; using Murφ more than 400 are needed
(Mitchell et al., 1997). Our approach, using Casper,
minimizes this problem.
In (Wagner and Schneier, 1996) an informal anal-
ysis of SSL Handshake and SSL Record is presented.
This analysis explores several possible attacks on the
SSL protocol and also gives several ways in which the
robustness of the SSL protocols can be improved.
The paper is organised as follows. In Section 2 the
SSL Handshake v3.0 subprotocol is verified using the
same methodology that was used in (Mitchell et al.,
1998), i.e., we start from a simple version of the sub-
protocol and then we include in subsequent versions
other features such as server and client authentication,
digital signatures, verification messages, etc. In this
section, the SSL Handshake v2.0 is also verified in or-
der to consider the so called version rollback attack.
Finally in Section 3 we give our conclusions and some
lines of future work.
2 VERIFICATION OF SSL
HANDSHAKE v3.0
SSL protocol is a layer, between TCP/IP and applica-
tion layers, that allows us to encrypt (in a transparent
way) the application data exchanged between a client
and a server in a network.
SSL is a security protocol based on sessions and
connections. Each session can be a set of SSL con-
nections and an agent can establish several SSL ses-
sions. Each session and each connection has a set of
(different) parameters associated to it.
SSL v3.0 protocol consists of four subprotocols:
SSL Record, SSL Handshake, SSL Alert and SSL
ChangeCipherSpec. Each subprotocol has a clear
function: SSL Handshake allows entities to establish
sessions and connections, SSL Record exchanges ap-
plication data between entities, SSL Alert reports on
error during SSL execution, and SSL ChangeCipher-
Spec sets the active configuration, that uses the just
negotiated parameters. SSL Alert and SSL ChangeCi-
pherSpec consist of only one message that is usually
exchanged during the handshake phase.
More detailed information about SSL v3.0 can be
obtained from the Netscape specification (Freier et al.,
1996).
Our analysis is mainly focused on SSL Handshake
subprotocol. If the peers succeed in establishing a ses-
sion, the exchange of application data will be secure.
In order to analyse the protocol we have to de-
scribe the environment that we consider Each agent
can take one of three possible roles: client, server or
intruder. There are several honest clients that try to
establish a session with a server but they can be dis-
turbed by an intruder.
When a client and a server establish a successful
SSL connection, SSL guarantees them the following
security properties:
A. The connection is private. Each message is en-
crypted with secure session keys.
B. Each peer is authenticated with both public and
private keys.
C. The connection is reliable. Each message includes
a message authentication code (MAC) which is
computed from application data and some shared
secret. This code checks the messages integrity.
Our analysis will find out whether SSL fulfils
these security properties or not. In order to check
these properties, we need to introduce a new agent
in the system model: the intruder. The intruder can
perform the following actions:
• Overhear and intercept all the messages over the
network.
• Modify the messages, add bytes, delete bytes or
change the value of several bytes.
• Generate new messages using its initial knowl-
edge or parts of the overheard messages.
• Send a new or captured message to another entity
of the system.
In addition, we assume that:
• The intruder cannot perform any cryptanalysis.
• The data types are atomic, i.e., an intruder cannot
guess part of the value of a variable.
FORMAL VERIFICATION OF THE SECURE SOCKETS LAYER PROTOCOL
247

• There are trusted Certificate Authorities. They
generate certificates that the intruder cannot mod-
ify.
• All the entities use secure functions and algo-
rithms.
2.1 Basic Protocol
We begin the incremental analysis with a basic pro-
tocol (see Fig. 1(a)). Through this initial protocol a
client and a server agree on which CipherSuite and
compression method they use, and some secret data.
This basic protocol shows how SSL Handshake works
although it does not include any security techniques.
ClientHello. C → S : C,SuiteC,LCompression
ServerHello. S → C : SuiteS,MCompression
Certificate . S → C : PKServer
ClientKeyExchange C → S : {preMasterSecret}
PKServer
(a) Basic Protocol Narration
ClientHello. C → I
S
: C,SuiteC,LCompression
ServerHello. I
S
→ C : SI,MComI
Certificate . I
S
→ C : PKIntruder
ClientKeyExchange C → I
S
: {preMasterSecret}
PKIntruder
(b) Attack on basic protocol version
Figure 1: Narration of the basic protocol and the associated
attack.
First, a client sends its identifier to the server (C).
The client knows the IP address of the server but the
server ignores that of the client. Besides, it includes a
list of CipherSuites (SuiteC) and a list of compression
methods (LCompression). A CipherSuite is a con-
stant that allows both agents to negotiate a cipher al-
gorithm, a hash function and the size of the pre-master
key, among other session parameters.
The server selects a CipherSuite (SuiteS) and a
compression method (MCompression) from the list
and sends them back to the client. It also sends an-
other message to the client that contains the server
public key (PKServer). Thus, the client can encrypt
some secret data (using the server public key), and
send them to the server. Only the server, who knows
its own private key, can decrypt them.
We verify that the basic protocol satisfies two se-
curity properties:
A. preMasterSecret is a secret shared between the
client and the server. The intruder cannot find out
its value.
B. The client finishes a run of the protocol with the
server and both know the same value for several
session parameters.
We have found several attacks on the basic proto-
col, and we can conclude that it does not satisfy any
of the two properties. In Fig. 1(b) we can see how
the intruder takes the place of the server and sends its
public key to the client. The client generates some se-
cret data, it encrypts them with the intruder public key
and sends it back to the intruder. In this case, the in-
truder knows the value of MasterSecret and the client
does not run the protocol with the server.
Another attack takes place when the intruder de-
ceives the server and sends the client identifier and
a list of weak CipherSuites to the server. When it
knows the server public key, it generates some false
secret data and encrypts them with it. In this case,
the intruder can supplant the client and can establish
a session as an honest client.
2.2 Server and Client Authentication
If we want to prevent the previous described attacks
on the basic protocol, we must be sure that the client
ciphers the secret data with the server public key and
the message is sent to the server. In other words, the
server has to authenticate itself using a certificate.
We represent certificates as a list with a certifi-
cate owner identifier and its public key (see Fig. 2(a)).
They are encrypted with a Certificate Authority sym-
metric key. This key is known by all the entities so
we must guarantee that the certificate has not been
modified. In addition, we define a verification func-
tion called ValidCertificate which will allow a client
to finish a run (with error) if the certificate has been
modified.
The client should be also authenticated. In this
case, the server will send a request certificate mes-
sage to the client (see Fig. 2(a)). This message in-
cludes a list of trusted CA (Certificate Authority) and
a list of acceptable types of certificates. Each en-
tity sends its certificate in a Certificate message, and
when the other entity receives it, it verifies the cer-
tificate integrity with the ValidCertificate() function.
The selected CipherSuite at ServerHello message de-
termines whether an agent has to be authenticated or
not.
A client must be able to prove that it is the cer-
tificate owner. Thus, it sends a digital signature in a
message called CertificateVerify (see Fig. 2(a)). In or-
der to generate its signature, the client applies a hash
function to several session parameters and then it en-
crypts the result with the client private key. Only the
real owner of one certificate knows the private key
corresponding to the public key and only the owner
can cipher some data with it.
At this point, the intruder can supplant neither the
ICEIS 2008 - International Conference on Enterprise Information Systems
248

ClientHello. C → S : C,SuiteC,LCompression
[C!=S]
ServerHello. S → C : SuiteS,MCompression
CertificateS. S → C : {S,PKServer}
CASign
[ValidCertificate(S,PKServer)]
CertificateRequest. S → C : tCert
CertificateC. C → S : {C,PKClient}
CASign
[ValidCertificate(C,PKClient)]
ClientKeyExchange. C → S : {preMasterSecret}
PKServer
CertificateVerify. C → S : {MD5(preMasterSecret)}
SKClient
(a) Basic Protocol Narration
ClientHello. I
C
→ S : C,SI,LComI
ServerHello. S → I
C
: SuiteS,MCompression
CertificateS. S → I
C
: {S,PKServer}
CASign
CertificateRequest. S → I
C
: tCert
ClientHello. C → I
S
: C,SuiteC,LCompression
ServerHello. I
S
→ C : SI,MCompI
CertificateS. I
S
→ C : {S,PKServer}
CASign
CertificateRequest. I
S
→ C : tCert
CertificateC. C → I
S
: {C,PKClient}
CASign
ClientKeyExchange. C → I
S
: {preMasterSecret}
PKServer
CertificateVerify. C → I
S
: {MD5(preMasterSecret)}
SKClient
CertificateC. I
C
→ S : {C,PKClient}
CASign
ClientKeyExchange. I
C
→ S : {preMasterSecret}
PKServer
CertificateVerify. I
C
→ S : {MD5(preMasterSecret)}
SKClient
(b) Attack on basic protocol version
Figure 2: Narration of the protocol with client and server
authentication and the associated attack.
client nor the server. But it can perform active at-
tacks on the messages. In particular, it may try to al-
ter non-encrypted parameters in messages, as the list
of CipherSuite and the list of compression methods
(see Fig. 2(b)). These attacks can desynchronise both
agents or can reduce the security, as we have seen in
previous cases.
2.3 Verification Messages
SSL v3.0 includes messages for avoiding attacks on
plain text (text that is not cipher). These verification
messages, called Finished (see Fig. 3), are computed
from all the headings of the previous messages ex-
changed between the server and the client.
When an entity receives one of these messages, it
must check all the included variables, but it does not
need to send an acknowledge message. The Finished
message means that the sender has finished its part of
SSL Handshake and it is ready to start SSL Record.
We have simplified the Finished message because
the complete message leads to a state explosion in the
verification tool. We only include in this message the
session variables that have not been checked in other
messages.
The verification messages are the first ones to be
encrypted with the session key. Each agent has two
ClientHello. C → S : C,SuiteC,LCompression
[C!=S]
ServerHello. S → C : SuiteS,MCompression
CertificateS. S → C : {S,PKServer}
CASign
[ValidCertificate(S,PKServer)]
CertificateRequest. S → C : tCert
CertificateC. C → S : {C,PKClient}
CASign
[ValidCertificate(C,PKClient)]
ClientKeyExchange. C → S : {preMasterSecret}
PKServer
CertificateVerify. C → S : {MD5(preMasterSecret)}
SKClient
FinishedC. C → S : {MD5(SuiteC,LCompression,SuiteS,
MCompression)}
CWS(preMasterSecret)
FinishedC. S → C : {MD5(SuiteC,LCompression,SuiteS,
MCompression)}
SWS(preMasterSecret)
Figure 3: Narration of the protocol with verification mes-
sages.
symmetric session keys: a write session key and a
read session key. In fact, they only generate two keys,
but they need to know both keys. One is used to en-
crypt the sent messages and the other one is used to
decrypt the received messages. We represent the pro-
cess of generating these keys with two symbolic func-
tions. We suppose that the secret data are exchanged
successfully, so these session keys are secret and se-
cure.
We add a third property to verify in addition to the
two previous ones:
C. The server finishes a run of the protocol with the
client and both know the same value for several
session parameters.
This new property is analogous to the B property.
It checks if the intruder is able to supplant the client
and can establish an SSL session as an honest client.
We could not add this property before because Casper
considered that we did not authenticate the client cor-
rectly.
In this protocol version we avoid the attack on
plaint text but then we find a “replay” attack. Maybe
the intruder cannot guest the application data but it
establishes a new session and the client ignores it.
2.4 Establishing a Session
We must distinguish among runs of the protocol in or-
der to avoid “replay” attacks. So, when an agent starts
a new run of the protocol, it generates some random
data, called nonces, which are sent in its Hello mes-
sage. Each pair of nonces is associated to a connec-
tion and it is used to generate the session keys. It
gives more security because each pair of session keys
is unique so, if an intruder was able to guess a pair, the
rest would continue being secure keys. Nonces are
verified by Finished messages (Fig. 4). In the com-
plete SSL specification we need to add two new fields:
FORMAL VERIFICATION OF THE SECURE SOCKETS LAYER PROTOCOL
249

SSL agent version and session identifier.
We also add three new messages: a ServerHel-
loDone message and two ChangeCipherSpec mes-
sages. These messages mark the state of the run. They
only include a non-encrypted constant. The Server-
HelloDone is used by the server to indicate that it has
finished the Hello part of SSL Handshake.
ChangeCipherSpec is, in fact, one of the four sub-
protocols of SSL v3.0, but may be studied as a mes-
sage in the Handshake. It consists of a single mes-
sage. An agent sends this message when it wants
to notify the other agent that it will begin to use the
just negotiated configuration. The ChangeCipher-
Spec messages are not verified by any message.
ClientHello. C → S : C,verC,NonceC,SuiteC, LCompression
[C!=S]
ServerHello. S → C : verS,NonceS,idSes,SuiteS, MCompres-
sion
CertificateS. S → C : {S,PKServer}
CASign
[ValidCertificate(S,PKServer)]
CertificateRequest. S → C : tCert
ServerHelloDone. S → C : HelloDone
CertificateC. C → S : {C,PKClient}
CASign
[ValidCertificate(C,PKClient)]
ClientKeyExchange.C → S : {preMasterSecret}
PKServer
ChangeCipherSpecC.C → S : CCS
CertificateVerify. C → S : {MD5(preMasterSecret,NonceC,
NonceS)}
SKClient
FinishedC1. C → S : {MD5(SuiteC,
verC)}
CWS(preMasterSecret,NonceC,NonceS,idSes)
FinishedC2. C → S : {MD5(SuiteS,verS,
idSes)}
CWS(preMasterSecret,NonceC,NonceS,idSes)
ChangeCipherSpecS.S → C : CCS
FinishedS1. S → C : {MD5(SuiteC,
verC)}
SWS(preMasterSecret, NonceC,NonceS,idSes)
FinishedS2. S → C : {MD5(SuiteS,verS,
idSes)}
SWS(preMasterSecret, NonceC,NonceS,idSes)
Figure 4: Narration of the verification system and the com-
plete SSL Handshake protocol.
We check the same three security properties and
we verify that this is a secure protocol.
2.5 Restarting a Session and
Establishing a New Connection
If a client has executed SSL Handshake and has estab-
lished a SSL session with a server, when this client
wants to resume a SSL connection with the same
server, it executes a brief version of SSL Handshake
(see Fig. 5). It is not necessary to negotiate a new
configuration or exchange secret data in order to gen-
erate new session keys. They only exchange Hello
and Finished messages. No agent is authenticated in
this short SSL Handshake.
ClientHello. C → S : C,verC,NonceC,SuiteC, LCompression
[C!=S]
ServerHello. S → C : verS,NonceS,idSes,SuiteS, MCompres-
sion
CertificateVerify. C → S : {MD5(preMasterSecret,NonceC,
NonceS)}
SKClient
ChangeCipherSpecC.C → S : CCS
FinishedC1. C → S : {MD5(SuiteC, verC, LCompression,
NonceC)}
CWS(preMasterSecret,NonceC,NonceS,idSes)
FinishedC2. C → S : {MD5(SuiteS,verS,NonceS,
MCompression,
idSes)}
CWS(preMasterSecret, NonceC,NonceS,idSes)
ChangeCipherSpecS.S → C : CCS
FinishedS1. S → C : {MD5(SuiteC, verC, LCompression,
NonceC)}
SWS(preMasterSecret,NonceC,NonceS,idSes)
FinishedS2. S → C : {MD5(SuiteS,verS,NonceS,MCompression,
idSes)}
SWS(preMasterSecret, NonceC,NonceS,idSes)
Figure 5: Description of the verification system and the re-
sume protocol.
In this case, we can only verify the properties B
and C because the server and the client do not ex-
change secret data. It is a secure protocol because
they do not negotiate any session parameter or ex-
change any secret. They only resume the previous
session.
2.6 The Version Rollback Attack:
Verifying SSL Handshake v2.0
The compatibility between SSL v3.0 and SSL v2.0
allows a client and a server to negotiate which ver-
sion of the protocol they are going to use. Usually,
the client may permit or not using SSL v2.0 (this is
a configuration parameter in most internet browsers)
but the server must be prepared to accept both kinds
of connections. It is very likely that the client (the
end user) is not aware of the differences between v2.0
and v3.0, so, usually, both options are marked. At this
point, an intruder may force both peers (the client and
the server) to use the weakest version of the proto-
col which, as we will show soon, has several security
problems.
Therefore, it is necessary to verify not only SSL
Handshake v3.0 but also v2.0. In order to verify the
SSL Handshake v2.0 subprotocol (Hickman, 1995),
we will distinguish four cases to analyse:
1. A client wants to establish a new session with a
server and both entities must be authenticated.
2. A client wants to establish a new session with a
server, and only the server must be authenticated.
3. A client and a server have established a session
before and now the client wants to resume it. Both
entities must be authenticated.
ICEIS 2008 - International Conference on Enterprise Information Systems
250

ClientHello. C → S : C,SuiteC,challenge
ServerHello. S → C : SuiteS, idCon, {P, PKServer}
CASign
[TrustedCertificate(S,PKServer)]
ClientMasterKey.C → S : {MasterSecret }
PKServer
ClientFinished. C → S : {idCon%con}
WSC(MasterSecret,challenge,idCon)
[idCon == con]
ServerVerify. S → C : {challenge%temp}
WSS(MasterSecret,challenge,idCon)
[challenge == temp]
RequestCertificate.S → C : {ChCertificate}
WSS(MasterSecret,challenge,idCon)
ClientCertificate.C → S : {{C,PKClient}
CASign
,{f(f(MasterSecret,
challenge,idCon),ChCertificate,
{S,PKServer}
CASign
)}
SKClient
}
WSC(MasterSecret,challenge,idcon)
[TrustedCertificate(C,PKClient)]
ServerFinished. S → C : {idSes}
WSS(MasterSecret,challenge,idCon)
Figure 6: Casper specification of SSL Handshake v2.0.
Case 1.
ClientHello. C → S : C, SuiteC, challenge
ServerHello. S → C : SuiteS, idCon, {P, PKServer}
CASign
[TrustedCertificate(S,PKServer)]
ClientMasterKey.C → S : {MasterSecret}
PKServer
ClientFinished. C → S : {idCon%con}
WSC(MasterSecret,challenge,idCon)
[idCon == con]
ServerVerify. S → C : {challenge%temp}
WSS(MasterSecret,challenge,idCon)
[challenge == temp]
ServerFinished. S → C : {idSes}
WSS(MasterSecret,challenge,idCon)
Figure 7: Casper specification of SSL Handshake v2.0.
Case 2.
4. A client and a server have established a session
before and now the client wants to resume it. Only
the server must be authenticated.
In cases 1 and 2, a client wants to start an SSL
session with a server (see figures 6 and 7). In SSL
Handshake v2.0 we have two parts: negotiation pa-
rameters phase and authentication phase. In the nego-
tiation parameters phase, both entities exchange Hello
messages.
In SSL v2.0, each entity of a connection uses a
pair of symmetric session keys. One of the keys, the
read key, is used to encrypt all the messages that are
sent. The other one, the write key, is used to decrypt
every message that is received. The client write key
is the same as the server read key and the server write
key is the same as the client read key.
Cases 1 and 2 may suffer an attack on their plain
(non encrypted) text. Each variable which is sent in
plain text must be verified by a Finished or ServerVer-
ify message. But the list of CipherSuites and the se-
lected CipherSuite are not verified by any message.
So, an intruder can intercept the Hello message and
modify these values. This leads to two main conse-
quences: on one hand, both entities will use a weak
configuration mode; on the other hand, the server uses
one configuration mode and the client uses a different
ClientHello. C → S : C, SuiteC, challenge, idSes%ses
[(C!=S)and(idSes == ses)]
ServerHello. S → C : SuiteS, idCon, idEncontrado(C)%ses
[idSes == ses]
ClientFinished. C → S : {idCon%con}
WSC(MasterSecret,challenge,idCon)
[idCon == con]
ServerVerify. S → C : {challenge%temp}
WSS(MasterSecret,challenge,idCon)
[challenge == temp]
ServerFinished. S → C : {idSes}
WSS(MasterSecret,challenge,idCon)
[idSes == ses]
Figure 8: Casper specification of SSL Handshake v2.0.
Case 3.
ClientHello. C → S : C, SuiteC, challenge, idSes%ses
[(C!=S)and(idSes == ses)]
ServerHello. S → C : SuiteS,idCon, idEncontrado(C)%ses
[idSes == ses]
ClientFinished. C → S : {idCon%con}
WSC(MasterSecret,challenge,idCon)
[idCon == con]
ServerVerify. S → C : {challenge%temp}
WSS(MasterSecret,challenge,idCon)
[challenge == temp]
RequestCertificate.S → C : {ChCertificate}
WSS(MasterSecret,challenge,idCon)
ClientCertificate. C → S : {{C,PKClient}
CASign
,{f(f(MasterSecret,
challenge,idCon),ChCertificate,
{S,PKServer}
CASign
)}
SKClient
}
WSC(MasterSecret,challenge,idcon)
[TrustedCertificate(C,PKClient)]
ServerFinished. S → C : {idSes}
WSS(MasterSecret,challenge,idCon)
[idSes == ses]
Figure 9: Casper specification of SSL Handshake v2.0.
Case 4.
one. This way, they cannot exchange data.
Cases 3 and 4 consider a different situation. A
client has successfully executed SSL Handshake with
a server. They have a previous session identifier and
the client wants to establish a new connection. They
do not need to exchange secret data or negotiate ses-
sion parameters in either case (see figures 8 and 9).
There are no attacks on these cases because they
do not exchange secret data or negotiate any session
parameter. They only confirm the new connection.
As a conclusion, we have seen in the previous
cases that there is an important attack on this version
of the protocol, and this was the main reason for de-
veloping a new version.
3 CONCLUSIONS AND FUTURE
WORK
Our analysis has shown that SSL v3.0 is a secure pro-
tocol if all the features of the protocol are used. It
allows a client and a server to exchange some secret
data in a secure way. Thus, agents can generate se-
cure session keys that guarantee that all data applica-
FORMAL VERIFICATION OF THE SECURE SOCKETS LAYER PROTOCOL
251

tion encrypted with them is secret, and the connection
is private.
But there are some attacks that we cannot con-
sider in Casper/FDR2. For instance, there are several
messages, such as ServerHelloDone and ChangeCi-
pherSpec, that are sent as clear text. A cryptanalyst
could easily detect these messages and, from that mo-
ment on, it could identify each encrypted message in
an SSL execution. We assume that an intruder can
not perform cryptanalysis so we do not include these
kinds of attacks in our analysis. This problem is de-
scribed in detail in (Wagner and Schneier, 1996).
Nevertheless, SSL v3.0 is compatible with SSL
v2.0, and, as we have seen above, this means that a
version rollback attack is possible, i.e., the intruder
may force both peers to use a weak security protocol,
and take advantage of the security “holes” we have
detected in SSL v2.0.
At this point, it is worth noting that we have fo-
cused on the verification of the SSL specification as
published in (Hickman, 1995; Freier et al., 1996).
In literature we may find several documented attacks
over SSL v3.0, but these attacks are performed over
real implementations of the protocol, not over the
SSL specification (Brumley and Boneh, 2003; Can-
vel et al., 2003).
Our future work is concerned with extending our
analysis of the SSL protocol to other security proto-
cols and e-commerce protocols. With respect to e-
commerce protocols, we are planning to deal with the
verification of the SET protocol.
REFERENCES
Armando, A., Basin, D., Boichut, Y., Chevalier, Y., Com-
pagna, L., Cuellar, J., Hankes Drielsma, P., He´am,
P.-C., Mantovani, J., M¨odersheim, S., von Oheimb,
D., Rusinowitch, M., Santiago, J., Turuani, M., Vi-
gan`o, L., and Vigneron, L. (2005). The AVISPA Tool
for the Automated Validation of Internet Security Pro-
tocols and Applications. In Etessami, K. and Raja-
mani, S. K., editors, Proceedings of the 17th Inter-
national Conference on Computer Aided Verification
(CAV’05), volume 3576 of LNCS. Springer.
Blanchet, B., Abadi, M., and Fournet, C. (2005). Auto-
mated Verification of Selected Equivalences for Se-
curity Protocols. In 20th IEEE Symposium on Logic
in Computer Science (LICS 2005), pages 331–340,
Chicago, IL. IEEE Computer Society.
Bodei, C., Buchholtz, M., Degano, P., Nielson, F., and Niel-
son, H. R. (2003). Automatic validation of protocol
narration. In Proceedings of the 16th Computer Secu-
rity Foundations Workshop (CSFW 03)., pages 126–
140. IEEE Computer Society Press.
Brumley, D. and Boneh, D. (2003). Remote Timing Attacks
Are Practical. In Proc. of 12th USENIX Security Sym-
posium, pages 1–14. USENIX Press.
Canvel, B., Hiltgen, A., Vaudenay, S., and Vuagnoux, M.
(2003). Password Interception in a SSL/TLS Chan-
nel. In Proc. of Advances in Cryptology (CRYPT’03),
LNCS 2729, pages 583–599. Springer.
Clarke, E. M., Grumberg, O., and Peled, D. A. (1999).
Model Checking. The MIT Press.
Dierks, T. and Allen, C. (1999). The TLS Protocol Version
1.0. Internet Standards, RFC 2246.
http://www.ietf.org/rfc/rfc2222.txt .
Dill, D. L. (1996). The Murφ Verification System. In Proc.
of 8th International Conference on Computer Aided
Verification (CAV’96), LNCS 1102, pages 390–393.
Springer.
Freier, O. A., Karlton, P., and Kocher, P. C. (1996). The SSL
Protocol Version 3.0. Netscape Communications.
http://wp.netscape.com/eng/ssl3/
ssl-toc.html .
Hickman, K. E. B. (1995). SSL 2.0 Protocol Specification.
Netscape Communications.
http://wp.netscape.com/eng/security/
SSL_2.htm .
Lowe, G. (1998). Casper: A Compiler for the Analysis
of Security Protocols. Journal of Computer Security,
6:53–84.
Mitchell, J. C., Mitchell, M., and Stern, U. (1997). Au-
tomated analysis of cryptographic protocols using
Murφ. In Proc. of IEEE Symposium on Security
and Privacy, pages 141–151. IEEE Computer Society
Press.
Mitchell, J. C., Shmatikov, V., and Stern, U. (1998). Finite-
State Analysis of SSL 3.0. In Proc. of 7th USENIX
Security Symposium, pages 201–216. USENIX Press.
Wagner, D. and Schneier, B. (1996). Analysis of the SSL
3.0 Protocol. In Proc. of 2nd USENIX Workshop on
Electronic Commerce, pages 29–40. USENIX Press.
ICEIS 2008 - International Conference on Enterprise Information Systems
252