See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/216485703

Transport Layer Security (TLS)--A Network Security Protocol for E-commerce

Article · January 2004

CITATIONS READS

4 2,993

2 authors, including:

Mahboob, A.
Khwaja Fareed University of Engineering & Information Technology, Rahim Yar Khan, Pakistan
56 PUBLICATIONS   119 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Cryptanalysis View project

Evaluation of OLSR protocol Implementations using Analytical Hierarchy Process (AHP) View project

All content following this page was uploaded by Mahboob, A. on 31 May 2014.

The user has requested enhancement of the downloaded file.

 Transport Layer Security (TLS) – A Network Security
Protocol for E-commerce

† ‡
Athar Mahboob & Dr. Nassar Ikram

†Under Ph. D. Programme ‡Dean Faculty of Electronics and Power Engineering

Pakistan Navy Engineering College, Karachi Pakistan Navy Engineering College, Karachi
National University of Sciences & Technology National University of Sciences & Technology
Rawalpindi, Pakistan Rawalpindi, Pakistan
athar@pnec.edu.pk nassar@pnec.edu.pk

Abstract. Transport Layer Security (TLS) protocol has been developed by the Internet
Engineering Task Force (IETF) as the standard protocol for providing security services
in the context of E-commerce over the Internet. Thus TLS enabled web servers form the
portals through which E-commerce client server interaction takes place. This paper
provides an overview of the design and workings of the TLS protocol and how it enables
network security for E-commerce. It would be of help to those wishing to get a concise
description and a clear understanding of the TLS protocol before implementing it for E-
commerce. Another important contribution of this paper is a comparison between the
IPSec security protocol and TLS in the context of E-commerce applications.

1. Introduction

E-commerce over the TCP/IP based global Internet requires the presence of security attributes
such as confidentiality, integrity, authenticity and non-repudiation within the TCP/IP protocol
framework. Despite the fact that TCP/IP protocol development was initiated under the
auspices of the US Department of Defense, the TCP/IP protocols contain major security flaws
[5] and are vulnerable to many security threats that make the protocols insecure for E-
commerce applications.
A long-term solution to the security problems in the TCP/IP protocols was undertaken by
the Internet Engineering Task Force (IETF) around 1995 in the form of the IPSec initiative
[2]. IPSec is a family of protocols providing the necessary security attributes to an IP
implementation at the network layer. Since IPSec is located adjacent to the IP layer it can
provide security on end-to-end basis and can be used for a variety of security needs including
secure E-commerce, Virtual Private Networks, Access Control, Private communication
between two hosts and many other security needs. However, due to the time delay associated
with the development of a comprehensive security protocol such as IPSec, and the associated
politics of making available strong cryptography universally, it was felt that the a security
protocol for E-commerce might have to be developed separately. Hence Netscape
Communications developed the Secure Sockets Layer (SSL) protocol and incorporated its
support in its browsers. Netscape also made the design of SSL public. The version 3 of the
SSL protocol was later standardized by the IETF as Transport Layer Security (TLS) protocol
version 1.0 [1]. It has to be clearly understood that the TLS protocol only deals with the
network security issues related to E-commerce and does not address various other important
security issues such as authentication of public keys and secure payments. These are
addressed by various Public Key Infrastructure (PKI) standards and Secure Electronic
Transaction (SET) suite of protocols.
An outline of this paper is now given. In §2 we describe the security requirements of an E-
commerce based information exchange and define the terminology precisely. To explain the
rationale for these requirements we take analogy from non-E-commerce transactions with
which we are all familiar in our daily lives. In §3 we describe the TLS Protocol Data Unit
(PDU) format and explain the existence of various fields in the TLS PDU. In §4 we describe
the TLS protocol operation with the help of client server interaction diagram. In §5 we
2 Athar Mahboob & Dr. Nassar Ikram

describe the known attacks on the TLS protocol and counter measures proposed, if any. In §6
we provide information about the performance impact of TLS on web servers. In §7 we
discuss the current state of the TLS standard and development tracks presently being
undertaken by IETF. In §8 we compare TLS with IPSec and justify why the TLS will
continue to be used in E-commerce applications for a long time rather than being replaced by
IPSec. Finally, we conclude in §9 by summarizing the important ideas presented in this paper.
We provide a comprehensive set of references at the end for those interested in further reading
on the subject.

2. Security Requirements of an E-commerce Information Exchange

An E-commerce exchange happens between a client desiring to purchase product(s) or access

service(s) from a server offering the product(s) or the service(s) under consideration. There
are several security requirements for such an interaction to be beneficial as intended rather
than being harmful to the parties involved.

2.1 Principal Authentication

From the point of view of the client the first required assurance is the authenticity of the
server. The client needs to be confident that the server at the other end does represent the
company whom the client thinks it represents. In analogy to a normal non E-commerce
transaction the buyer is certain of dealing with the correct seller because the transaction
generally takes place physically at the premises (store) of the seller. In an E-commerce
transaction the client cannot know the physical location and the ownership of the server as
there is no physical contact between them.
Using standard computer and network security terminology, as given in [6], Alice is the
client and Bob is the server. Alice needs to be sure that she is dealing with Bob and not
Mallory as shown in figure 1.

1. I
produ want to
cts an se
d pric e a list
es. of E-commerce Server for
somecompany.com.pk
E-commerce cts (Bob)
produ d
Client (Alice) list of e
ere is the t you ask
2. H th a
d prices
an
for.

? 3. Is this really the server for

www.somecompany.com.pk? E-commerce Server for
badcompany.com
(Mallory)

Fig. 1. An E-commerce client requires assurance that it is really dealing with a server for the correct
company

The same logic could be applied from the server’s perspective. The server needs assurance
of client’s identity. This is even more important in cases where the server will be providing
the client access to use of a service. Use of the service must be done by the authentic client
who has actually paid for the use of the service.
 Transport Layer Security (TLS) – A Network Security Protocol for E-commerce 3

2.2 Message Authentication

Even after the identity verification of the client and server to each other in the beginning of an
E-commerce exchange, each subsequent packet of information exchanged between them
needs authentication. This is required since electronic communication, especially in the
context of TCP/IP can be hi-jacked or taken over by malicious entities transparently [5]. The
client needs continuous assurance throughout the E-commerce information exchange that the
all messages being received as being from the server are truly coming from the server.
Similarly, the server needs assurance of authenticity about the packets allegedly being
received from the client.
Using the computer security terminology, if Bob is the server and Alice is the genuine
client then any packets injected by Mallory must be duly rejected by Bob.

1. I
w
100 u ant to pla
nits o c
f XYZ e order f
produ or
ct. E-commerce Server for
E-commerce Client somecompany.com.pk
(Alice) r (Bob)
rder fo
lace o uct.
wan t to p p rod
2. I C
of AB
units
1000 3(a) Has this message really come

? from Alice?
3(b) Which message has really come
from Alice?
Rouge Host (Mallory)

Fig. 2. Authenticity of messages being received is very important in E-commerce

2.3 Message Integrity

The client and server both also need assurance that contents of the packets being received are
original and have not been modified on their way. Plain IP does not provide any such
assurance. It is possible to incorporate message integrity in an electronic information
exchange by using the message authentication codes (MACs). MACs are cryptographic
constructions that make use of hash functions and either public key or symmetric encryption.
MACs can provide message integrity check as well as a proof of origin or authenticity. Some
of the well-known hash functions include MD-5 [17], SHA-1 [9] and RIPEMD-160.
Figure 3 shows the scenario with reference to message integrity in E-commerce.

1. I
E-commerce Client w
100 u ant to pla
(Alice) nits o
f XYZ ce order fo
produ r E-commerce Server for
1. I ct.
w somecompany.com.pk
1000 ant to pla
units
of AB ce order fo (Bob)
C pro r
duct.

Rouge Host (Mallory)

? 3. Has this message arrived as
originally transmitted by Alice?

Fig. 3. Integrity of messages being received is important in E-commerce

4 Athar Mahboob & Dr. Nassar Ikram

2.4 Message Confidentiality

In many cases it is also required that the contents of messages being exchanged should be kept
private because these contain sensitive information, disclosure of which could cause damage
to the parties. For example, if credit card numbers or bank account information is being
transmitted, it is essential that it be kept private by using encryption. In the course of normal
non-E-commerce transactions, wherever security is required, it is physically ensured by
limiting access to documents or keeping only authorized person in privy of the information
that has to be protected. In E-commerce transactions, the private information is in electronic
format and is traveling on communication links that are subject to eavesdropping. Strong
cryptography is therefore required in E-commerce to keep private information as such.
Figure 4 shows how Eve is able to snoop on valuable confidential information and could
possibly use it later to cause harm to Alice or Bob.

1. I
w
100 u ant to plac
n e
Here its of XY order for
E-commerce Client is m Z pro
numb
er. Bil y credit duct.
(Alice) l me. card
E-commerce Server for
somecompany.com.pk
(Bob)

Rouge Host (Eve)

2. Aha! So this is
Alice’s credit card
number and that is what
she is purchasing.

Fig. 4. Message confidentiality is critical for E-commerce transactions

Generally symmetric encryption algorithms are employed for attaining message secrecy.
They serve this purpose because they provide acceptable level of security as well as good time
performance. However, for the exchange and management of keys required for symmetric
encryption algorithms, public-key or asymmetric encryption algorithms are employed. Some
of the well-known symmetric encryption algorithms are DES, IDEA, RC4 and AES. Popular
public-key algorithms include RSA, Diffie-Hellman, El-Gamal and ECC.

2.5 Non-repudiation

Non-repudiation means that the originator of a message or a party to a transaction should not
be able to deny it later. Imagine the financial loss to a business if a client places the order for
1000 units of a product and later disclaims having done so. There must be a mechanism to
ensure that an impartial third party can, in case of a dispute, adjudicate and decide whether an
entity did participate in a transaction or sent a message. In the non-E-commerce transactions
this is accomplished through the use of hand-written signatures of lawfully authorized entities.
Similarly in E-commerce transactions digital signatures can be used to associate the identity of
participating entities with messages and transactions. Digital signatures are cryptographic
constructions which utilized a hash function to create a digest of the message to be signed and
then encrypt that digest with the private key of the entity. The signature can then be verified
by using the public-key of the entity that signed the message. In the context of E-commerce
this non-repudiation is not handled by TLS but rather by the SET standards [18, 19]. Also the
authenticity of public keys is handled by using digital certificates in the form of a PKI. More
information about PKI is available in [20].
 Transport Layer Security (TLS) – A Network Security Protocol for E-commerce 5

3. TLS Protocol Data Unit (PDU)

The TLS protocol actually consists of two groups of sub protocols:

1. The Record Protocol

2. The TLS Control Protocols

The Record Protocol provides a standard packaging for TLS messages where as the control
protocols of TLS consist of the following three protocols:

1. Handshake Protocol
2. Change Cipher Spec Protocol
3. Alert Protocol

Figure 5 shows how the Record Protocol encapsulates higher layer protocols.

Change
Handshake Alert
Cipher Spec HTTP
Protocol Protocol
Protocol

TLS Record Protocol

TCP

IP

Fig. 5. TLS Protocol Stack

TLS uses TCP as the underlying transport protocol because TCP provides a reliable
connection oriented service and there is no need to reinvent the wheel by repeating the same
functions at the TLS layer.

3.1 TLS Record Protocol

The TLS Record Protocol PDU format is given in figure 6. The fields in the PDU are
explained below. Further details are available in [1] and [4].
6

Content Major Minor Compressed

Type Version Version Length

Plaintext
(optionally
Encrypted

compressed)

MAC (0, 16, or 20 bytes)

Fig. 6. TLS Record Format

• Content Type (8 bits): This indicates the higher layer protocol that should be used to
process the enclosed fragment. Content types have been defined to indicate the various TLS
control protocols such as Handshake Protocol, Change Cipher Spec Protocol, Alert
Protocol and also an Application Data content type has been defined. The contents of
application data are opaque to TLS.
• Major Version (8 bits): This indicates the major version number of the TLS protocol used
for this PDU.
• Minor Version (8 bits): This indicates the minor version number of the TLS protocol used
for this PDU.
• Compressed Length (16 bits): This indicates the length in bytes of the plain-text fragment
contained in this PDU. The maximum value is 214 + 2048 because ultimately the IP Version
4 datagram is limited to 216 bytes.

3.2 Change Cipher Spec Protocol

The TLS Change Cipher Spec protocol PDU is shown in the figure 7(a). It is a simple, single
message protocol which indicates to the recipient to update the cipher suite to be used on this
connection.

3.3 Alert Protocol

The TLS Alert Protocol PDU is shown in the figure 7(b). The Alert protocol is used to
convey TLS-related alerts to the other party. The first byte contains a level value that can
signify the seriousness of the alert such as (1) warning or (2) fatal. If the level is fatal the
TLS-connection is immediately terminated. The second byte indicates the specific alert.
More details are available in [1] and [4].
 Transport Layer Security (TLS) – A Network Security Protocol for E-commerce 7

1 byte 1 byte 3 bytes 3 bytes

1 Type Length Content

(a) Change Cipher (c) Handshake Protocol

Spec Protocol

1 byte 1 byte Up to 214 + 2048 bytes

Level Alert Content

(b) Alert Protocol (d) Other Upper Layer Protocol as TLS Payload

Fig. 7. TLS Record Protocol Payloads

3.4 Handshake Protocol

The TLS Handshake Protocol PDU is shown in the figure 7(c). The Handshake Protocol
provides facilities for the client and server to mutually authenticate each other at the beginning
of a TLS session, before any application data is exchanged, and to negotiate the algorithms to
be used for message authentication and secrecy during the session.

3.5 Encryption and Message Authentication Algorithms Supported in TLS

TLS supports the following algorithms for encryption and message authentication:

Encryption: RC4, RC2, DES, 3DES, DES40,IDEA, Fortezza, AES

MAC: MD5, SHA-1

The exact algorithms used during a particular session are negotiated using the handshake
protocol.

4. TLS Protocol Operation

The TLS session is initiated by a client by sending a TLS message on port 443 on the TLS-
enabled web server. Since all TLS messages are encapsulated in the TLS Record Protocol
PDU it is worthwhile to look at the operation of the TLS Record Protocol.

4.1 Record Protocol Operation

The operation of the TLS Record is shown in figure 8.

8

Application Data

Fragment

Compress

Add MAC

Encrypt

Add TLS Record

Header

Handed-off to Handed-off to Handed-off to

TCP as Segment TCP as Segment TCP as Segment
Payload Payload Payload

Fig. 8. TLS Record Protocol Operation

Higher layer TLS control messages or application data are fragmented first by the record
protocol. The fragmented data are then compressed. At this time no compression algorithm
ha been specified so compression remains optional and unused for the most part. Then a
MAC is computed and appended to the compressed information. The resulting packet is then
encrypted using a symmetric encryption algorithm and a key negotiated during he handshake
phase. Then a TLS record protocol header is added and the resulting TLS PDU is passed on
to TCP for further processing and is treated as TCP segment payload.

4.2 TLS Session Initialization Sequence

The handshake protocol message exchange leading to a TLS Session establishment is shown
in figure 9 which has been adapted from [4]. There are four distinct phases of the TLS
handshake:

Phase 1: Establish Security Capabilities

Phase 2: Server Authentication and Key Exchange
Phase 3: Client Authentication and Key Exchange
Phase 4: Finish

Figure 9 also provides details of the four phases. For further details the reader is referred to
[1], [4] and [10].
 Transport Layer Security (TLS) – A Network Security Protocol for E-commerce 9

Client Server
Phase 1
client_he Establish security
llo
capabilities including
protocol version, session
ello ID,cipher suite,
server_h compression method,and
initial random numbers.

te
certifica Phase 2
ange Server may send
ey_exch
server_k certificate, key exchange,
and request certificate.
_request
certificate Server signals end of
e hello message phase.
ello_don
server_h

Phase 3
Time

certifica
te
Client sends certificate if
client_ke requested. Client sends
y_excha
nge key exchange. Client
certifica may send certificate
te_verify
verification.

change_
cipher_s
pec
finished Phase 4
Change cipher suite and
pec finish handshake
cipher_s
change_ protocol.

finished

Fig. 9. TLS Handshake Protocol Client Server Interaction

5. Known Attacks on the TLS Protocol

The TLS protocol is well designed. Formal security protocol verification has shown that
version 3 of SSL, on which TLS 1.0 is based, is a semantically secure protocol [11,12, 21]. A
security analysis in [12] concludes that TLS/SSL are highly secure against passive attacks
such as eavesdropping.
10

A Distributed Denial of Service (DDoS) attack is possible against TLS based web servers
where a rouge machine would send hundreds of TLS client_hello requests to an E-commerce
server. As shown in section 5, the server would perform RSA public key encryption in its
server_hello response for each of the client_hello’s. This could choke the server and make it
unavailable because RSA computations are extremely CPU intensive. A solution to this
attack, based on using client puzzles, has been proposed in [14].

Beyond the security of the TLS protocol itself, it is essential to ensure the security of other
aspects of the system also such as key management and storage. Reference [12] discusses
various ways to attack a TLS-based E-commerce server and also proposes some security
measures against those attacks.

6. Performance of TLS

The impact of TLS on web server performance has been extensively studied in the literature.
As an enabling technology for E-commerce, it is highly desirable that TLS signature should be
minimal on E-commerce servers. However, due to the nature of the cryptographic algorithms
that need to be executed in a TLS session, there is degradation in the TLS-enabled web
server’s performance.
Good studies of TLS Performance have been undertaken in [13] and [16]. A great deal of
performance improvement can be achieved using (1) caching of server certificate by the client
(2) optimizing the TLS handshake procedure as reported in [13].
In addition to that several commercial products have been developed to improve the
performance of TLS-based web servers. These include specialized hardware that plugs into a
slot on the regular server and offloads computation intensive cryptographic processing from
the server to specialized hardware designed for this purpose.

7. State of TLS Development

TLS is under active development at the IETF. However, the activity level in the TLS working
group is fairly low compared to some other active IETF working groups. Some of the recent
activity includes the following:

• Support for Kerberos – RFC 2712

• Support for OpenPGP keys for Authentication (currently in the draft stage)
• Support for AES – RFC 3268 [7]

The last of the TLS RFCs is dated June 2002 showing that TLS development is alive and well
incorporating latest cryptographic algorithms such as AES [8]. The TLS website at the IETF
can be accessed via http://www.ietf.org/html.charters/tls-charter.html.

8. Comparison of TLS and IPSec for E-commerce Applications

Even though both TLS and IPSec are network security protocols developed within the TCP/IP
framework, they have many differences. Many of the differences arise due to the relative
location of each of the protocols in the TCP/IP protocol stack as shown in figure 10. Whereas
IPSec is located at the network layer as a companion to IP it is in fact sandwiched between
 Transport Layer Security (TLS) – A Network Security Protocol for E-commerce
TCP and IP layers. TLS on the other hand is located above the transport layer between TCP
and the applications.
FTP SMTP TELNET HTTP
TCP
IP/IPSec
IPSec is located at the
Network Level
Fig. 10. Relative Location of the Security Facilities of IPSec and TLS
The table below compares and contrasts TLS with IPSec:
TLS
Collection of protocols (Record,
Handshake, Change Cipher Spec, Alert)
that work simultaneously to provide
security services.
Developed specifically for enabling
secure E-commerce.
The relationship between the two entities
in an TLS-based information exchange is
client server.
Can be used to secure end-to-end
sessions of information exchange.
Enabling TLS on a host simply requires
the installation of a TLS capable browser.
Automated key management is built into
the protocol.
Can support any application layer
protocol that can run over TCP.
Supports only point-to-point connections
and unicast IP addresses.
In the presence of an intermediate
network layer firewall TCP port 443 (in
the default mode) has to be opened to in
order to allow TLS traffic to flow.
Independent of the network layer
protocol version and not a mandatory
11
FTP SMTP TELNET HTTP
TLS
TCP
IP
TLS is located above the
Transport Level
IPSec
Collection of protocols (Encapsulating
Security payload – ESP and
Authentication Header – AH) that may be
used simultaneously or separately to
provide security services.
Developed to provide solutions to a large
number of network security problems.
The relationship between the two entities
in an IPSec-based information exchange
is peer to peer.
Can be used to secure end-to-end
sessions of information exchange in the
transport mode.
Enabling and using IPSec on a host
requires a fair amount of technical
expertise and configuration.
Automated key management is still under
development.
Can support any application layer
protocol whether running over TCP or
UDP. Also supports ICMP, OSPF or any
other protocol simply running on top of
IP.
Can support multicast IP addresses.
In the presence of an intermediate
network layer firewall IP Protocol
numbers 50 and 51 have to be allowed to
pass in order for IPSec traffic to flow.
Designed for both IP Version 4 and IP
Version 6. IP Version 4 implementations
12

protocol in the Internet. may implement IPSec as an

Can be used to build a TLS-enabled
proxy server as an application level
firewall to secure traffic to/from non-TLS
hosts.
extension/enhancement whereas IP
Version 6 implementations must
implement IPSec in order to be compliant
with the Internet.
Can be used in Tunnel mode to create
security gateways and network level
firewalls for securing traffic to/from non-
IPSec hosts.

Deployment of IPSec requires considerable planning and configuration whereas TLS can
be deployed in a plug-and-play fashion by just installing TLS-capable browsers. For a more
detail comparison between IPSec and TLS along with some other security protocols the reader
is referred to [3] and [15].

9. Conclusions

Due to its plug and play nature, its proven security and wide spread deployment TLS will
continue to remain the protocol of choice for network security over the Internet for
client/server based E-commerce transactions. It is essential to understand the workings of the
TLS protocol and its performance impact on the E-commerce website in order to ensure the
security and performance of the E-commerce implementation. Lastly, within the context of
E-commerce on the Internet TLS will play the dominant role as a security protocol of choice
for such applications and IPSec may be chosen for other security applications.
The E-commerce implementation technical team would be best served by understanding the
various issues highlighted in this paper and the references given at the end can serve to
provide more detailed information to the interested reader.

References

[1] Dierks, T., Allen, C.: “The TLS Protocol, Version 1.0”, RFC 2246, January 1999
[2] Kent, S., Atkinson, R.: “Security Architecture for the Internet Protocol”, RFC 2401,
November 1998
[3] Fumy, Walter: “Internet Security Protocols”, State of the Art in Applied
Cryptography, B. Preenel, V. Rijmen (Eds.) COSIC’97 Course, Springer LNCS
1528, pp. 186-208, 1998
[4] Stallings, William: “Cryptography and Network Security”, 2nd Edition, Prentice
Hall, 1998
[5] Bellovin S.M., “Security Problems in the TCP/IP Protocol Suite”, AT&T Bell
Laboratories, Murray Hill, New Jersey 07974,Vol. 19, No. 2, pp. 32-48, April 1989
[6] Schneier, Bruce, “Applied Cryptography”, Second Edition, John Wiley & Sons, Inc.,
New York, c. 1996
[7] Chown, P., “Advanced Encryption Standard (AES) Ciphersuites for Transport Layer,
Security (TLS)”, RFC 3268, June 2002
[8] National Institute of Standards and Technology, “Specification for the Advanced
Encryption Standard (AES)” FIPS 197. November 26, 2001
[9] FIPS PUB 180-1, “Secure Hash Standard,” National Institute of Standards and
Technology, U.S. Department of Commerce, April 17, 1995
[10] Smith, R. E., “Internet Cryptography”, Addison-Wesley, 1997
 Transport Layer Security (TLS) – A Network Security Protocol for E-commerce 13

[11] Childs, J.: “Evaluating The TLS Family of Protocols With Weakest Precondition
Reasoning”, The Florida State University, Tech Report TR-000703, July 2000
[12] D. Wagner and B. Schneier. Analysis of the SSL 3.0 protocol. In 2nd USENIX
Workshop on Electronic Commerce, 1996. Revised version of November 19, 1996
available from http://www.cs.berkeley.edu/~daw/papers/ssl3.0.ps.
[13] Apostolopoulos, G., Peris , V., Saha D.: “Transport Layer Security: How much does
it really cost?”, Proceedings of IEEE , 1999
[14] Dean Drew, Stubblefield, Adam: “Using Client Puzzles to Protect TLS”, 1999
[15] Morgan, J., Morris, H., Krishnan, V., Ivan, A.: “Secure Web Access in an
Environment of Mutual Distrust”, HPL-2001-60, HP Laboratories Palo Alto, March
22nd , 2001
[16] Coarfa, C., Druschel, P. and Wallach, D. S.: “Performance Analysis of TLS Web
Servers”,
[17] Rivest, R. L.: “The MD5 Message-Digest Algorithm”, RFC 1321, 1992
[18] SET Secure Electronic Transaction Specification, “Book 1: Business Description,
Version 1.0”, May 31, 1997, available at http://www.setco.org/download.html
[19] SET Secure Electronic Transaction Specification, “Book 3: Formal Protocol
Definition, Version 1.0”, May 31, 1997, available at
http://www.setco.org/download.html
[20] Branchaud, M.: “A Survey of Public key Infrastructures”, MS Thesis, McGill
University, Canada, 1997
[21] Mitchell J., Shmatikov V., and Stern U.: Finite-State Analysis of SSL 3.0, available
at http://verify.stanford.edu/uli/secur/usenix/usenix.html

View publication stats