A CHALLENGING BUT FEASIBLE BLOCKWISE-ADAPTIVE

CHOSEN-PLAINTEXT ATTACK ON SSL

Gregory V. Bard

University of Maryland, Department of Mathematics

College Park, MD, 20914, USA

Keywords:

Blockwise Adaptive, Chosen Plaintext Attack (CPA), Secure Sockets Layer (SSL), Transport Layer Security

(TLS), Cryptanalysis, HTTP-proxy, Initialization Vectors (IV), Cipher Block Chaining (CBC).

Abstract:

This paper introduces a chosen-plaintext vulnerability in the Secure Sockets Layer (SSL) and Trasport Layer

Security (TLS) protocols which enables recovery of low entropy strings such as can be guessed from a likely

set of 2–1000 options. SSL and TLS are widely used for securing communication over the Internet. When

utilizing block ciphers for encryption, the SSL and TLS standards mandate the use of the cipher block chaining

(CBC) mode of encryption which requires an initialization vector (IV) in order to encrypt. Although the

ﬁrst IV used by SSL is a (pseudo)random string which is generated and shared during the initial handshake

phase, subsequent IVs used by SSL are chosen in a deterministic, predictable pattern; in particular, the IV

of a message is taken to be the ﬁnal ciphertext block of the immediately-preceding message, and is therefore

known to the adversary.

The one-channel nature of web proxies, anonymizers or Virtual Private Networks (VPNs), results in all Internet

trafﬁc from one machine traveling over the same SSL channel. We show this provides a feasible “point of

entry” for this attack. Moreover, we show that the location of target data among block boundaries can have a

profound impact on the number of guesses required to recover that data, especially in the low-entropy case.

The attack in this paper is an application of the blockwise-adaptive chosen-plaintext attack paradigm, and is

the only feasible attack to use this paradigm with a reasonable probability of success. The attack will work for

all versions of SSL, and TLS version 1.0. This vulnerability and others are closed in TLS 1.1 (which is still

in draft status) and OpenSSL after 0.9.6d. It is hoped this paper will encourage the deprecation of SSL and

speed the adoption of OpenSSL or TLS 1.1/1.2 when they are ﬁnially released.

1 INTRODUCTION

This paper outlines a vulnerability of all ver-

sions of SSL and also TLS 1.0 by means of a

feasible blockwise-adaptive chosen-plaintext attack

(BACPA). The attack proceeds as follows. After valu-

able low-entropy data has been transmitted by the tar-

get (e.g. a stock from a list of 2–1000 companies) the

adversary inserts plaintext into the communications

stream by inducing the target machine to transmit data

designed to contain particular byte sequences. Based

on the ciphertext values of these known plaintexts,

the low-entropy data can be guessed. The probabil-

ity of success depends on the type of data being tar-

geted, with examples given below. Furthermore, it

is shown that the position of this target data within

block-boundaries directly and signiﬁcantly impacts

the number of guesses required to recover that datum.

The vulnerability described here was closed in TLS

1.1 and OpenSSL after 0.9.6d. Probably all other

SSL implementations

are vulnerable. Since TLS 1.1

had only just exited draft status in late April 2006,

most TLS deployments (at the time of the submis-

sion of this article) use version 1.0, which is vulner-

able to this attack. Nonetheless, the main purpose

of this paper is not to claim the existence of a ma-

jor threat to computer security, but rather to disprove

the myth that blockwise-adaptive chosen-plaintext at-

tacks are totally infeasible and thus of theoretical in-

terest only. Furthermore, we prove that it is easier

to guess the values of low-entropy data when it is di-

vided across block boundaries.

It is hoped this paper

will highlight some of the disadvantages of Cipher

Block Chaining, emphasize the importance of using

There would be exceptions if others copy OpenSSL.

We believe this has not previously been published.

V. Bard G. (2006).

A CHALLENGING BUT FEASIBLE BLOCKWISE-ADAPTIVE CHOSEN-PLAINTEXT ATTACK ON SSL.

In Proceedings of the International Conference on Security and Cryptography, pages 99-109

DOI: 10.5220/0002104100990109

 SciTePress

distinct keys for each source-destination pair, and il-

lustrate the importance of using random numbers as

initialization vectors.

The Attack Modern users are becoming aware that

installing software of unknown origin is unsafe. For

this reason, and many others, the concept of an “un-

trusted applet” running in a “sandbox” within the Java

Virtual Machine was created (Gosling et al., 2005).

These applets have highly restricted security privi-

leges, but are commonly available on individual and

commercial web-sites as utilities and games. If an at-

tacker can manage to get a user to install a Java appli-

cation (or application in any other language) the at-

tacker can read the user’s keystrokes and broadcast

them—there is no need for cryptanalysis in this case.

However, an untrusted applet does not have this priv-

ilege (Loefﬂer, 1997) (Gosling et al., 2005). It only

receives notice (“events”) from keystrokes pressed

while the applet is on screen and “has the mouse fo-

cus.” Therefore reading the user’s keystrokes while

he/she enters valuable data into other applications is

impossible. However, one privilege of the untrusted

applet is to open a TCP connection to the web server

from whence it came (Loefﬂer, 1997). Imagine a

user visiting a secure web-site for banking, and later

playing a Java applet game. Naturally the socket for

the secure transaction and the socket that the applet

opens back to its server are unrelated. However, in

the special case of a web-anonymizer, HTTP-proxy

or virtual private network, all network trafﬁc leav-

ing the user’s machine will travel over the same SSL

socket

. Since they travel over the SSL link and in the

same direction, the data in each case will be encrypted

with the same secret key. This results in the targeted

data, as well as data of the adversary’s choosing (the

chosen-plaintext), becoming available for use in veri-

fying guesses of the targeted plaintext via Blockwise-

Adaptive Chosen-Plaintext attack.

Blockwise-Adaptive Chosen-Plaintext BACPA

was simultaneously discovered in 2001 by Bellare,

Kohno, and Namprempre (Bellare et al., 2002) and

by Joux, Martinet, and Valette (Joux et al., 2002).

The BACPA differs from classical chosen plaintext

attack (now termed “message-wise” or MCPA) in

essentially one detail. In MCPA, the attacker can

generate arbitrary messages for the target to encrypt,

as part of a sequence of messages. In BACPA, the

attacker can generate arbitrary blocks for the target

to encrypt, inserted as part of an existing message

(i.e., a sequence of blocks). However, four years

We have recently learned that an e-mail posted to the

Certicom TLS mailing list in March of 2002 had also men-

tioned this possibility, though with fewer details (Rescorla,

2002).

after its discovery, BACPA has received very little

notice outside the cryptographic community, despite

several additional papers within it. Bellare, Kohno,

and Namprempre (Bellare et al., 2002), in addition to

outlining a theoretical model of potential adversary

capabilities that is expanded upon in later papers

(Fouque et al., 2004) (Boldyreva and Taesombut,

2004) (Fouque et al., 2003), loosely describe a gen-

eral attack on the Secure Shell (SSH) ﬁrst found by

(Dai, 2002). That attack had a success probability

of 2

−12.5

or 6.9 × 10

−4

. This paper outlines an

attack with a success probability that can approach

100%. We are aware of no other feasible attack under

the BACPA model against an existing or proposed

protocol, except for our previous paper (Bard, 2004).

The Versions of the SSL Protocol The Secure

Socket Layer (SSL) (Freier et al., 1996) is currently

one of the most widely-used methods for securing

communication over the Internet

. There are two re-

cent versions, SSL 2.0 (1995) and SSL 3.0 (1996).

The successor protocol is Transport Layer Security

(TLS), which includes version 1.0 (1999) (Dierks and

Allen, 1999), and version 1.1 (Dierks and Rescorla,

2005) (2006). Also, a version 1.2 has been proposed

(Dierks and Rescorla, 2006). Almost all secure web

transactions (i.e. HTTPS) use either TLS 1.0 or SSL

3.0. For simplicity, we refer to all versions of SSL,

as well as TLS 1.0, by saying “SSL.” OpenSSL is

an open source implementation of SSL. Versions of

OpenSSL since 0.9.6d (Various, ) have closed this

vulnerability, as has TLS 1.1 (Dierks and Rescorla,

2005). All SSL deployments other than OpenSSL,

including TLS 1.0, are believed to be currently vul-

nerable to this attack

, though possibly other imple-

mentations have copied solutions used by OpenSSL.

See Section 6.

Initialization Vectors Our attack relies on the fact

that SSL currently mandates the use of a weak variant

of the cipher block chaining (CBC) mode of encryp-

tion (Kaufman et al., 2002, Chap. 4). CBC mode re-

quires a one-block initialization vector (IV) for each

message that is encrypted. In “standard” crypto-

graphic usage of CBC, a fresh, random IV is chosen

for each message. In SSL, however, only the initial IV

is chosen in a (pseudo)random manner; IVs for subse-

quent messages are simply taken to be the ﬁnal block

The success probability is stated to be equivalent to

waiting for a collision on approximately 25 bits. See the

last sentence of Section 3 of (Bellare et al., 2002).

See (Kaufman et al., 2002, Chap. 19) for an excellent

overview of SSL.

Personal E-mails with E. Rescorla, co-author of the

TLS 1.0, 1.1, and 1.2 RFCs

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

100

of the ciphertext corresponding to the immediately-

preceding message. (This process is called “chaining

the IVs.”) In particular, an attacker may know in ad-

vance the IV that is going to be used to encrypt the

next message. We show that this enables an attacker

mounting a chosen-plaintext attack to validate a guess

as to the value of a particular plaintext block.

Consequences Since the adversary can validate a

guess as to the value of a particular plaintext block,

this attack violates the theoretical standard of Left-Or-

Right Indistinguishability, whereby no polynomial

time adversary may be able to distinguish between

the encryption of two messages of his/her own choice,

given the ciphertext, (with non-negligible advantage)

(Goldwasser and Micali, 1984) (Bellare et al., 1997).

On the more practical side, it possibly allows an at-

tacker to determine a low-entropy string by repeat-

edly guessing all possible values for this string until

the correct one is identiﬁed. Examples of such low-

entropy information (2–1000 choices) include names

of stocks, cities, users, or even PINs that have been

previously encrypted (or, for example, knowing if a

stock order is buy, sell, or stop-loss could be valuable

information by itself). Given the use of SSL for trans-

mitting exactly this sort of data, we believe this rep-

resents a potentially serious (but challenging) attack

which should be addressed by any security group se-

lecting an SSL implementation.

1.1 Related Work

Essentially this method has been used previously to

attack SSH (Bellare et al., 2002) (Dai, 2002). In fact,

the ﬂaw attacked there is identical to the ﬂaw attacked

here (namely, setting IVs in a predictable way). Little

discussion of feasibility or point-of-entry was given,

and the probability of success was very low as already

stated. On the other hand, that discovery gave birth to

the blockwise-adaptive chosen-plaintext world.

Due to the similar structure of SSL and SSH, the

related vulnerability in SSL was discovered soon af-

ter, independently by Moeller (Moeller, ) and the au-

thor of this paper, in late 2002—8 months after the

publications of the two original blockwise papers.

Moeller’s work identiﬁes the attack but does not show

how it could be exploited. Moreover, our paper elab-

orates upon the attack by showing how low-entropy

data, in particular, is easy to recover, and provides

mechanisms by which to execute the attack. The au-

thor of this paper, in 2004, wrote of a similar BACPA

attack against SSL but via a much more difﬁcult and

complex point-of-entry (Bard, 2004).

The changes to TLS between versions 1.0 and 1.1

were made partially in response to this class of vul-

nerability

, as well as that of Vaudenay

(Dierks and

Rescorla, 2005).

2 HIGH-LEVEL OUTLINE

We begin by brieﬂy highlighting the minimal aspects

of SSL needed to understand our attack at a high level.

A more detailed treatment of the attack (and hence of

SSL) is given in Section 3. A good survey of the SSL

protocol is given in (Kaufman et al., 2002, Chap. 19).

The SSL protocol begins with a handshaking stage

during which the parties agree on a protocol version,

select cryptographic and (optionally) compression al-

gorithms, perform optional authentication steps, and

use public-key mechanisms to share secrets. The

shared secrets, which include distinct symmetric keys

and IVs for each direction of communication, can

then be used for symmetric-key encryption and mes-

sage authentication. While messages may optionally

be compressed before encryption, few SSL imple-

mentations do so (Kaufman et al., 2002, Chap. 19),

(Freier et al., 1996).

The SSL standard allows for symmetric-key en-

cryption using either block ciphers or stream ciphers.

Most implementations utilize block ciphers, and the

vulnerability in this paper applies only when block

ciphers are used. A block cipher is a keyed, invertible

function (or keyed permutation) over strings of some

ﬁxed length called blocks; DES, for example, operates

on 64-bit blocks. We write F

(X) to represent the

application of a block cipher using key sk to block X.

To encrypt messages longer than one block in length,

a mode of encryption must be used. SSL mandates the

cipher block chaining (CBC) mode, which encrypts a

message P = P

, . . . , P

ℓ

(where the length of each

is the block-length of the cipher) as follows: given

some IV denoted C

, compute C

, . . . , C

ℓ

sequen-

tially via:

= F

⊕ C

i−1

In the general case of CBC, the resulting ciphertext is

usually taken to be C

, . . . , C

ℓ

although if the receiver

already knows C

then it need not be transmitted. To

decrypt, the receiver computes P

for i = 1 to ℓ via:

= F

−1

) ⊕ C

i−1

We note that it is considered “standard” security prac-

tice to choose a new, random IV for every message

Attack denoted CBCATT in some TLS documentation

(Moeller, ), see also Section 6.2.3.2 of (Dierks and Allen,

1999) (Dierks and Rescorla, 2005).

Another interesting attack on the use of CBC in SSL,

discovered by Vaudenay, relates to the padding of messages,

and is unrelated to the vulnerability in this paper (Vaudenay,

2001).

A CHALLENGING BUT FEASIBLE BLOCKWISE-ADAPTIVE CHOSEN-PLAINTEXT ATTACK ON SSL

101

that is encrypted. However, the above deﬁnition of

CBC does not force this to be the case. As we have

mentioned already, SSL chooses all but the initial IV

by setting it equal to the ﬁnal ciphertext block of the

preceding encrypted message; this is referred to as

“chaining IVs across messages”. (Thus, continuing

the above example, the IV used for the next message

would simply be C

ℓ

.) SSL chooses the initial IV in a

pseudorandom fashion which is not important for the

purposes of the present attack.

The attack. Suppose an adversary who can mount

a chosen-plaintext attack wants to verify a guess

as to whether some plaintext block has a particular

value. Speciﬁcally (continuing the above example),

suppose an adversary who has observed the cipher-

text C

, . . . , C

ℓ

wants to determine whether plain-

text block P

is equal to P

∗

. Note that the adver-

sary knows the IV (i.e., C

ℓ

) that will be used when

encrypting the next message. Consider now what

happens if the adversary causes the sender to en-

crypt a message P

′

whose initial block P

′

is equal

to C

j−1

⊕ C

ℓ

⊕ P

∗

. The ﬁrst ciphertext block C

′

then:

′

= F

′

⊕ C

ℓ

)

= F

((C

j−1

⊕ C

ℓ

⊕ P

∗

) ⊕ C

ℓ

)

= F

j−1

⊕ (C

ℓ

⊕ C

ℓ

) ⊕ P

∗

)

= F

j−1

⊕ P

∗

However, we also know that C

= F

⊕ C

j−1

This implies that C

′

= C

if and only if P

= P

∗

since F

is a permutation. In this way, an adversary

can verify a guess P

∗

for the value of any plaintext

block P

. In particular, if the adversary knows that

is one of two possible values then the adversary

can determine the actual value by executing the above

attack a single time. Similarly, if the attacker knows

that P

is one of N possible values then by repeat-

ing the above attack N/2 times (on average) the ad-

versary can determine the actual value of P

. This

already violates the standard notions of security for

encryption (in terms of Left-Or-Right Indistinguisha-

bility, as mentioned in the Introduction (Goldwasser

and Micali, 1984) (Bellare et al., 1997)). Moreover,

this implies that an attack of this form can be used to

determine the value of a low-entropy string in its en-

tirety. (Note that, in practice, the block of plaintext

containing the user’s data also likely contains addi-

tional information such as headers, etc. However, it

is also likely that this additional information is known

to the attacker; for example, if the information is ﬁxed

padding, then an adversary can learn the format of this

data from the web-page source code. We discuss this

further in Section 4.)

Attack requirements. Focusing speciﬁcally on the

case of an adversary trying to recover a user’s tar-

geted low-entropy data, we brieﬂy highlight the re-

quirements needed for the above-described attack to

succeed; in Section 4 we discuss in more detail how

these requirements are typically met in practice. First,

the attacker must know which plaintext block j con-

tains the desired information. All this means is that

the adversary knows the format of the HTTPS trans-

mission being targeted. Second, the adversary must

know C

j−1

. However, since the ciphertext travels

over the Internet (in the clear!), this is not expected

to be difﬁcult. (In fact, if it is assumed difﬁcult to

obtain this information then there is little reason to

use encryption in the ﬁrst place.) Third, the adver-

sary must know the value of the IV that is going to be

used for the next message. However, we have noted

already that because of the way SSL computes IVs, an

attacker would actually obtain this information from

the last ciphertext block of the previous message. Fi-

nally, the adversary must be able to insert a plaintext

block of its choice into the ﬁrst block of the next mes-

sage to be transmitted. This is the most challenging

part of the above attack.

The scenario. The mechanism by which the adver-

sary executes the attack is summarized as follows.

First, we assume that the user is connected to an

HTTP-proxy, web anonymizing service, or virtual

private network. This guarantees that all outbound In-

ternet trafﬁc will be routed over one SSL tunnel with

a single secret key. Second, we assume the attacker

can setup a site under his/her control, and create an

applet for the user to open. In particular, applets have

features, which will be described below in Section 4,

that make them desirable for use. Third, a “reﬂector”

or mechanism for observing the target’s ciphertexts is

set up. This is needed in all forms of cryptanalysis, so

we presume it is available. Fourth, we assume that the

user can be induced into opening the applet. This can

be in the form of an email which persuades the user to

go to the site, or perhaps an email that simply causes

the applet to be opened upon viewing, via HTML en-

coded requests for the applet in the email body, using

the <APPLET> tag. We fully acknowledge that these

assumptions are non-trivial but they demonstrate that

a chosen-plaintext attack is feasible.

Note that untrusted Java applets have very few priv-

ileges (Gosling et al., 2005), but one of those priv-

ileges is to open a TCP socket to the server from

whence it came (Loefﬂer, 1997). They cannot, for ex-

ample, simply read all of the user’s keystrokes and ex-

port them to the adversary, as explained before. Since

all outgoing trafﬁc, in the case of a web anonymizer,

HTTP-proxy, or virtual private network, travels over

the same SSL link, this permits the applet to send and

receive arbitrary data—which will become the chosen

plaintexts of the attack.

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

102

3 ATTACKING SSL

Here, we simply note that there is nothing in the struc-

ture of SSL (such as extraneous headers or formatting

information) which prevents the attack of the previous

section from succeeding.

SSL sits between the Application and Transport

layers, and so acts like a Session Layer in the OSI

model. As such, SSL receives plaintext from the Ap-

plication Layer as raw data. This plaintext is frag-

mented into blocks of length less than or equal to 2

bytes. These blocks are optionally (but rarely) com-

pressed

and are then processed and sent as follows:

• Unencrypted Portion:

– message type (8 bits);

– major/minor version number (16

bits);

– length counter (16 bits);

• Encrypted Portion:

– plaintext fragment (≤ 2

bits);

– message authentication code

(typically 160 bits);

– padding (0--56 bits; ensures

plaintext length is a multiple of

block length);

– padding length (8 bits);

We stress that the ﬁrst block of the plaintext is the ﬁrst

block to be encrypted. In particular, the header infor-

mation that is prepended to the eventual transmission

(i.e., the message type, major/minor version number,

etc...). is not encrypted. Thus, as long as the adver-

sary can set the ﬁrst block of the plaintext fragment to

some desired value (as discussed in the previous sec-

tion), that block will be encrypted ﬁrst and the attack

will succeed.

We note that in SSH, some header data is

prepended to the plaintext before encryption. This

makes an attack such as the one outlined here more

difﬁcult in the context of SSH (Bellare et al., 2002)

(Dai, 2002), since the adversary no longer has con-

trol over the ﬁrst block of the plaintext that is eventu-

ally encrypted. Although it may be possible to work

around these constraints (see (Bellare et al., 2002)),

the attack is more difﬁcult against SSH than it is

against SSL (demonstrated by a success rate of 2

−12.5

as compared to rates as high as 100% under certain

circumstances).

4 FEASIBILITY

Several challenges must be surmounted before an ad-

versary can successfully perform the attack that has

Our attacks do not apply when compression is used;

however, we note that it is rarely used.

been outlined here. The necessary steps to meet these

challenges are listed below.

Using one common key. First and foremost, the data

to be learned and the test cases must be encrypted

with the same key. Furthermore, since the key for the

block cipher is chosen at random each time an SSL

socket is created, the data to be learned and the test

cases must be transmitted through the same tunnel,

and in the same direction. Luckily enough, when a

web-tunneling service like an HTTP-proxy, or a VPN

is used, all the out-going data travels over one SSL

link, regardless of destination, and thus is encrypted

with the same secret key.

Learning the plaintext format. Despite the length

of a plaintext message, there are times when only a

very small sequence of bytes is of critical importance.

For example, a stock choice, a destination city for a

geospatial inquiry, a user name, or data where only

2–1000 choices are considered likely, and known in

advance (i.e., a “low-entropy string” in our terminol-

ogy).

We have mentioned earlier that the adversary must

somehow know which block of the plaintext contains

the data of interest. Note, however, this is easily done

by reading the source ﬁles for the pages that are used

in sending the data. Discerning the format merely re-

quires knowledge of HTTP, HTML, and CGI, and per-

haps Javascript. Commonly available browsers have

a “show page source” command, which displays the

page’s HTML source code. Both the “form elements”

which compile the user’s data, as well as the optional

Javascript code which would verify its format, would

thus be available to an attacker. While Javascript can

alter HTML code, for example, to add hidden form el-

ements, these would be visible in the Javascript code.

The attacker need only read this code and the format

is trivially derived.

Ensuring that the adversary’s chosen plaintext

block is encrypted ﬁrst. It is essential that the chosen

plaintext, namely P

= P

∗

⊕ C

ℓ

⊕ C

j−1

, be the ﬁrst

encrypted block of the SSL datagram inside which it

is found. However, this is easy, as we argue now.

Data is submitted to the SSL layer in the form of

application-level messages, which are ﬁrst aggregated

into blocks of (at most) 2

bytes in length. SSL does

not respect message boundaries. If more than 2

bytes are submitted, additional blocks are created; if

several application level messages are submitted, they

are concatenated in the buffer. However, in the ab-

sence of these two conditions, the data is encrypted

and transmitted to the TCP layer immediately. There-

fore, short intermittent messages would be encrypted

and transmitted immediately. The structure of SSL

packets guarantees, in the absence of concatenation,

that the ﬁrst block of the application message will be

the ﬁrst encrypted block of the SSL datagram.

A CHALLENGING BUT FEASIBLE BLOCKWISE-ADAPTIVE CHOSEN-PLAINTEXT ATTACK ON SSL

103

Concatenation only occurs when two messages ar-

rive at the SSL layer simultaneously. However, since

the packet source (the applet or game) is under the

control of the adversary, the timing could be adjusted

to guarantee that two packets never arrive during the

required interval. Of course, packets could arrive

from some other user activity or application. These

timing failures can be avoided probabilistically by re-

peating each guess several times. Finally it should be

noted that in the event concatenation does occur, if

the game packet is the ﬁrst packet, with other packets

appended, no disadvantage is caused for the attack.

Nonetheless, we acknowledge the timing difﬁculties.

Encrypting Chosen Plaintext. The attacker must

force the encryption of particular data in any chosen

plaintext attack, in this case based upon the previous

ciphertext block, the guess of the targeted plaintext,

and the ciphertext previous to the data to be guessed.

Once this block is calculated, it must be inserted into

the “plaintext stream.”

Since our scenario of a user connecting via an

HTTP-proxy or a VPN involves all network trafﬁc

ﬂowing to/from the target machine being encrypted

by the same SSL connection, with a distinct key for

each direction, the attacker need only cause the cho-

sen plaintext data to appear in an application-level

datagram, traveling in the same direction as the tar-

geted plaintext. However, there are other considera-

tions.

• The data must start the datagram. Once the

immediately previous ciphertext block is known,

the very next plaintext block must contain the at-

tacker’s plaintext. There must be no blocks in be-

tween, otherwise our previous formulas fail. There-

fore, it is essential that the test block (ﬁrst block of

new plaintext) be the ﬁrst block of the datagram.

• The data must be tolerated. The data must not re-

sult in a crashed application, a dropped connection

or error messages that would alert the user. Send-

ing arbitrary bytes to an application via a datagram

would almost surely violate that application pro-

tocol’s datagram formatting rules. The data must

“blend in” to the data that would have been other-

wise sent.

For example, if the application has a

header for each datagram, then its unlikely that the

cryptanalysis blocks, being the ﬁrst blocks of the

datagram, will conform to that header’s deﬁnition.

• The application must anticipate many data-

grams. Since only one guess can be validated per

packet, the application must anticipate a moderate

number of packets (on the order of 1–500 for a

guess among a set of 2–1000 choices).

Special thanks to (a referee from a previous confer-

ence) for pointing out several challenges in this regard.

• Background Trafﬁc The attack will also be less

likely detected if there is background trafﬁc to/from

the applet when the attack is not running.

Given these four requirements, it seems desirable to

write one’s own application for the attack, rather than

ﬁnd an application that can tolerate the above. In par-

ticular, if the applet is programmed to search for a

128-bit “magic number” in each datagram, then it can

discard all the data before and including that number.

This way the cryptanalysis blocks can be safely ig-

nored. The chances of the magic number occurring

accidentally are almost inﬁnitesimal.

Providing feedback to the Applet. Note that the ad-

versary needs feedback from the reﬂector to the applet

site (in particular, to inform it of the ciphertext blocks

j−1

, C

ℓ

) in order to perform the attack. It is not

expected to be difﬁcult for an adversary’s reﬂector to

obtain these ciphertexts (after all, they are traveling

on the Internet), but the information must somehow

be communicated to the applet site.

There are two principal avenues through which this

communication could occur. First, if the attack is

being performed in a wireless environment, setting

a wireless device to promiscuous mode is attractive.

However, many systems use WEP (Wired Equivalent

Privacy) though certainly not all (including, for exam-

ple, the University of Maryland and American Uni-

versity campus networks, which are unencrypted).

Alternatively, if the adversary has access to the

same Ethernet network on his/her own machine that

the user is connected to, then the following can be

executed. Perhaps a subordinate employee will use

his/her private laptop with tcpdump and a special

feedback script acting as a reﬂector, to capture his/her

employer’s SSL trafﬁc. The game applet’s server

would only need to know where the feedback dae-

mon is, receive the ciphertexts, and use it to compute

new plaintexts. The search for the daemon could be

through the use of a throw-away DNS address, or by

hard-coding the IP address.

On the one hand this could be detected by an In-

trusion Detection System as unauthorized trafﬁc, but

on the other, steganography could be used to embed

the data in legitimate communications. Alternatively,

since few Intrusion Detection Systems would be this

sensitive, the reﬂector could simply pass the packets

back in the clear.

Synchronization. The demands of synchronization

are important since there can be no transmitted data

between the “last ciphertext block” and the encrypted

attacking plaintext. There may be many ways to

achieve this, but the game/applet server could signal

that it is ready by sending a special packet. The re-

ﬂector responds with the most recently transmitted ci-

phertext, which hopefully travels with minimal delay

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

104

to the applet. Upon receipt of this, the applet trans-

mits a packet, with or without game data. The ﬁrst 8

or 16 bytes of the packets (one encrypted word) is not

game data, but the chosen-plaintext. If no data (from

any application) was transmitted on the tunnel in this

time, then this stage of the attack succeeds and one

guess can be checked. If data was transmitted on the

tunnel in this time, then the plaintext loses its meaning

in this context, but no harm is done and the attack can

be attempted again. Since the Poisson Distribution

is known to be a good model of user packet gener-

ation during web-browsing and other non-streaming

Internet tasks, large gaps between packets will be ex-

pected. This is especially true if the game is interest-

ing and the user is not surﬁng other sites while playing

it.

If the user will play for as little as 15 minutes, many

packets can make the round trip in this time. Since the

“go signal”, the reﬂector’s “last seen ciphertext”, and

the “guess” must all be exchanged, naturally with ac-

knowledgments (since we are using TCP), six round-

trip times are required. Rarely is a round-trip more

than 250 ms, so each “guess” takes 1.5 seconds, or

40 guesses can be made per minute. This comes to

600 guesses per short 15 minute game. Some of these

guesses will be clobbered by trafﬁc from other sock-

ets, but others should succeed. Even if only one-third

of the packets get through (which is very pessimistic),

a choice from a list of 200 options will be found with

absolute certainty, and a choice from a list of 10,000

options (e.g. a four digit PIN number) will be found

with a probability of 2%.

Summary The requirements listed in this section

are non-trivial. The timing and other network packet

structure considerations will result in some guesses

failing to serve their purpose. But we believe that we

have demonstrated the potential feasibility of this sort

of attack. This further demonstrates that BACPA is of

more than purely theoretical interest.

5 RECOVERING PIN’S

Here we show how even a moderately small entropy

string (≤10,000 choices) can be easy to recover due to

segmentation that occurs when the target data falls on

a block boundary. (We assume throughout this sec-

tion that the data surrounding the target information

is known; see above). Since it is now demonstrated

that the adversary has the ability to verify guesses of

plaintext blocks, one can imagine that an adversary

can attempt to guess the value of a valuable target

low-entropy string either by exhaustive search (in the

case of Personal Identiﬁcation Numbers or PINs) or

by more efﬁcient context-speciﬁc schemes (using dic-

tionary based attacks versus passwords, for example).

If we assume for simplicity that the data is cho-

sen uniformly from a space of size S, then the ex-

pected number of guesses needed before determining

the string is S/2. (Note that in the case of passwords

chosen by a user, the entropy is likely to be much

lower than would be indicated by the length of the

password alone. In particular, an 8-character pass-

word model typically has entropy much lower than

64 bits). For example, a 4-digit PIN can be deter-

mined with (on average) 5,000 guesses. If only 100

guesses can be made, the probability of success is

1%, which is low, but certainly represents a feasible

attack—we shall see momentarily that this can be im-

proved greatly.

Block Cipher Choices: Recall that AES was not

in existence when SSL 3.0 was originally speciﬁed

(1996), nor was it ﬁnalized when TLS 1.0 was re-

leased (1999). Both SSL 3.0 and TLS 1.0, the stan-

dardized versions now available, do not include AES

in their speciﬁcation (Freier et al., 1996) (Dierks and

Allen, 1999). Likewise, TLS 1.1 does not have AES

as a built-in option, but it is available via some ex-

tension documents (e.g., (Modadugu and Rescorla,

2006)). Finally TLS 1.2 will have AES built in, as

this was one of two principle changes between 1.1 and

1.2, the other relating to the choice of hash functions

(Dierks and Rescorla, 2006). Therefore, essentially

all SSL/TLS transactions at this time use DES or 3-

DES, both with a 64-bit plaintext and ciphertext block

length (though with an effective key size of 56 or 112

bits).

Split Target Data: However, assume 3-DES is be-

ing used as the block-cipher in the SSL transaction.

Then the plaintext blocks are 64 bits or 8 bytes. There

is a 12.5% probability that the four bytes of pin-

data will be divided exactly in the middle of a block

boundary.

Since each block can be guessed inde-

pendently, 50 guesses are required for the 100 options

on the left, and 50 guesses are required for the 100 op-

tions on the right. This use of 100 guesses results in

a 25% chance of success, since both halves must be

correct—rather than a mere 2% above. Alternatively,

fewer guesses can be made if a lower probability of

success is tolerated. Even a 3-1 or 1-3 split results in

a major distortion of the number of required guesses.

And there is a 37.5% chance that such a split (1-3, 2-2

or 3-1) will occur. See the Appendix for a discussion

of applying this technique to passwords.

One must assume that enough trafﬁc has gone by that

the “indentation” or “offset” within the stream of the valu-

able data is unpredictable, and therefore can be treated as a

uniformly distributed random variable.

A CHALLENGING BUT FEASIBLE BLOCKWISE-ADAPTIVE CHOSEN-PLAINTEXT ATTACK ON SSL

105

One should be careful to distinguish forms where

passwords are entered all at once, and then submitted

via SSL, from the normal SSH method where pass-

words are entered one keystroke at a time. In the lat-

ter case, this trick of breaking up the password would

not work—a single byte is never broken up

6 SOLUTIONS

It has been noted that TLS 1.1 and OpenSSL (after

0.9.6d) are not vulnerable to this attack, for reasons

detailed below.

TLS 1.1 and Explicit IVs The TLS 1.1 protocol

(Dierks and Rescorla, 2005) ﬁxes this vulnerability

by using explicit IVs. That is to say, each message

has one more ciphertext block than plaintext blocks.

This ﬁrst ciphertext block is the IV, determined as a

(pseudo)random number. As we have stated several

times already, this is the accepted way to encrypt us-

ing CBC. Since the attacker does not know this value

in advance, this attack cannot be executed. Using the

formula for CBC, it is easy to see that having an Ex-

plicit IV is identical to adding an additional plaintext

block of all zeroes to the start of each message, which

the receiver knows to discard, and chaining the IVs

from message to message (Moeller, ).

If generating truly random bits is a concern (say, for

reasons of efﬁciency), it is easy to generate a pseudo-

random IV in any of a number of ways. For example,

instead of simply using C

ℓ

(i.e., the last block of the

preceding ciphertext) as the IV, the protocol could use

H(C

ℓ

|sk) where sk is the shared secret key used for

encryption and H is a cryptographic hash function.

Single Block Nonces This solution is mentioned

because it can be used in other applications that use

CBC, to protect them from BACPA, and helps to ex-

plain the solution used by the OpenSSL community.

As was noted previously, the adversary’s guess must

be the ﬁrst block of each message. Introducing a one

block nonce—which would always be discarded be-

fore reading the message—would make this impos-

sible. The nonce does not even need to be random.

Suppose the nonce was always the all-zero string, and

the previous message ended on block C

. Then the ad-

versary will submit a block P

i+2

based on a guess G

for block g. This will be output in block i + 2, where

i + 1 is the nonce. Therefore the submitted plaintext,

from the attack formula given previously would be

Personal E-mails with E. Rescorla, co-author of the

TLS 1.0, 1.1, and 1.2 RFCs (Dierks and Allen, 1999)

(Dierks and Rescorla, 2005) (Dierks and Rescorla, 2006)

i+2

= C

i+1

⊕ C

g−1

⊕ G

But C

i+1

has not been transmitted yet. It equals

i+1

= F

⊕ 0000 · · · 0)

Therefore, C

i+1

can only be determined if F

)

has been calculated before, or the adversary guesses

the F

). Since F

(·) is a function family be-

lieved to be pseudorandom, this guess will be correct

with negligible probability. Likewise, since the space

of all possible ciphertexts is 2

or 2

128

, the proba-

bility of a repetition is low. As mentioned earlier, in

the case of the all zero plaintext, this is identical to

explicit IVs. The TLS speciﬁcation for version 1.1 al-

lows for this solution, in addition to Explicit IVs, but

recommends that the nonce be pseudorandom, gen-

erated for each message independently (Dierks and

Rescorla, 2005).

OpenSSL and the Empty Message A slight vari-

ation of the above is used by OpenSSL after version

0.9.6d (Various, ). An empty message, which con-

sists of no plaintext, but only padding and a hash, is

prepended to each set of messages before encryption.

The “extra parts”, namely the padding and hash, are

encrypted, and so form the throw-away blocks sim-

ilar to the nonce above. Since the adversary’s cho-

sen blocks are no longer the ﬁrst to be encrypted,

this attack becomes impossible. What is interesting

about this solution is that it does not require any ma-

jor changes at all to the SSL standard, and fulﬁlls

the present deﬁnition of SSL as written. The only

point to mention is that some SSL clients will declare

an error if an empty message is received. This error

message need only be suppressed, which is a minor

change.

Compression Note that an immediate way to pre-

vent the attack suggested here is to turn compres-

sion on (as we have noted, an attack of the sort sug-

gested here is much more difﬁcult — if not impos-

sible — if compression is used). However, this re-

quires that peers only communicate with others who

also use compression (or else an adversary connecting

to the honest party could mount a “chosen-protocol

attack” in which they claim to be unable to use com-

pression). On the other hand, blocking users not con-

ﬁgured for compression would limit inter-operability

with deployed versions of SSL.

7 CONCLUSIONS

The attack presented here is not so easy that it can

be done on the spur of the moment by the typical

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

106

hacker. However, while the attack is challenging to

carry out, the success probability and relatively low

numbers of datagrams required should be sufﬁcient to

motivate the SSL community to migrate away from

TLS 1.0 and SSL, to OpenSSL after 0.9.6d, or TLS

1.1/1.2 when they are ﬁnally released. Moreover, by

demonstrating the existence of this attack on a real-

world protocol, which corresponds to the theoretical

deﬁnition of blockwise-adaptive chosen-plaintext at-

tack, we prove that the BACPA model is not sterile,

but is useful for modeling adversarial capabilities.

Moreover it is hoped that this work will take a step

toward opening the dialog between protocol designers

and theoretical cryptographers, and stimulate discus-

sion between these two camps which are otherwise in-

dependent. Finally, there are other uses of CBC sim-

ilar to that of SSL, and this attack shows that those

applications should also use explicit IVs or another

solution listed here (e.g. Datagram Transport Layer

Security or DTLS (Modadugu and Rescorla, 2004)).

ACKNOWLEDGEMENTS

Thanks to Prof. Jonathan Katz for suggesting the

problem, for helpful discussions, and for substantial

help editing this document. Thanks also to Rug-

gero Morselli, Patrick Studdard, Radostina Koleva,

Zhongchao Yu, Susan Schmoyer and Prof. Lawrence

Washington (all of the University of Maryland), for

reading and commenting extensively on early ver-

sions of this paper. Valuable feedback was received

from Daniel Brown of CertiCom, Eran Tromer of

the Weizmann Institute, Prof. Bodo Moeller of UC

Berkeley, and Jack Lloyd of randombit.net, about an

earlier paper outlining a different attack on this same

SSL vulnerability (Bard, 2004). Most importantly

we would like to thank Eric Rescorla, co-author of

the TLS RFCs (Dierks and Allen, 1999) (Dierks and

Rescorla, 2005), (Dierks and Rescorla, 2006), for his

extended correspondences via email that helped this

work immensely.

REFERENCES

Bard, G. (2004). The vulnerability of ssl to chosen-plaintext

attack. Cryptology ePrint Archive, Report 2004/111.

http://eprint.iacr.org/.

Bellare, M., Boldyreva, A., Knudsen, L., and Namprempre,

C. (2001). On-line ciphers and the hash-cbc construc-

tion. In Lecture Notes in Computer Science. Advances

in Cryptology— CRYPTO’01, Springer-Verlag.

Bellare, M., Desai, A., Jokipii, E., and Rogaway, P. (1997).

A concrete security treatment of symmetric encryp-

tion: Analysis of the des modes of operation. In

Symposium on the Foundations of Computer Science

(FOCS’97). IEEE.

Bellare, M., Kohno, T., and Namprempre, C. (2002). Prov-

ably ﬁxing the ssh binary packet protocol. In Con-

ference on Computer and Communications Security

(CCS’02). ACM.

Bellare, M. and Namprempre, C. (2000). Authenticated en-

cryption: Relations among notions and analysis of the

generic composition paradigm. In Lecture Notes in

Computer Science. Advances in Cryptology— ASI-

ACRYPT’00, Springer-Verlag.

Boldyreva, A. and Taesombut, N. (2004). On-line encryp-

tion schemes: New security notions and constructions.

In Cryptographer’s Track. RSA Conference.

Dai, W. (2002). An attack against ssh2 protocol. Email to

the ietf-ssh@netbsd.org email list.

Dierks, T. and Allen, C. (1999). The tls protocol, version

1.0. Technical Report RFC 2246, Internet Engineering

Task Force.

Dierks, T. and Rescorla, E. (2005). The tls protocol, ver-

sion 1.1. Technical Report RFC 2246-bis-11, Internet

Engineering Task Force.

Dierks, T. and Rescorla, E. (2006). The tls protocol, ver-

sion 1.2. Technical Report RFC 4346-bis-00, Internet

Engineering Task Force.

Dworkin, M. (2001). Recommendation for block cipher

modes of operation: Methods and techniques. Tech-

nical Report NIST Special Publication 800-38A, Na-

tional Institute of Science and Technology.

Dworkin, M. (2002). Recommendation for block cipher

modes of operation: The rmac authentication mode,

methods and techniques. Technical Report NIST Spe-

cial Publication 800-38B, National Institute of Sci-

ence and Technology.

Fouque, P., Joux, A., and Poupard, G. (2004). Blockwise

adversarial model for on-line ciphers and symmet-

ric encryption schemes. In Lecture Notes in Com-

puter Science. Advances in Cryptology— SAC’04,

Springer-Verlag.

Fouque, P., Martinet, G., and Poupard, G. (2003). Practi-

cal symmetric on-line encryption. In Lecture Notes

in Computer Science. Advances in Cryptology—

FSE’03, Springer-Verlag.

Freier, A., Karlton, P., and Kocher, P. (1996). The ssl pro-

tocol, version 3.0. Technical report, Transport Layer

Security Working Group Internet Draft.

Gligor, V. and Donescu, P. (2001). Fast encryption and au-

thentication: Xcbc encryption and xecb authentication

modes. In 2nd NIST Workshop on AES Modes of Op-

eration. National Institute of Science and Technology.

Goldwasser, S. and Micali, S. (1984). Probabilistic encryp-

tion. Journal of Computer and System Sciences.

Gosling, J., Joy, B., Steele, G., and Bracha, G. (2005). The

Java(TM) Language Speciﬁcation. Addison-Wesley

Professional, third edition.

A CHALLENGING BUT FEASIBLE BLOCKWISE-ADAPTIVE CHOSEN-PLAINTEXT ATTACK ON SSL

107

Joux, A., Martinet, G., and Valette, F. (2002). Blockwise-

adaptive attackers: Revisiting the (in)security of some

provably secure encryption models: Cbc, gem, iacbc.

In Lecture Notes in Computer Science. Advances in

Cryptology— CRYPTO’02, Springer-Verlag.

Kaufman, C., Perlman, R., and Speciner, M. (2002). Net-

work Security: Private Communication in a Public

World. Prentice Hall, second edition.

Knudsen, L. (2000). Block chaining modes of operation.

In Symmetric Key Block Cipher Modes of Operation

Workshop. National Institute of Science and Technol-

ogy.

Krawczyk, H. (2001). The order of encryption and authen-

tication for protecting communications (or: How se-

cure is ssl?). In Lecture Notes in Computer Science.

Advances in Cryptology— CRYPTO’01, Springer-

Verlag.

Lipmaa, H., Rogaway, P., and Wagner, D. (2000). Com-

ments to nist concerning aes modes of operation: Ctr-

mode encryption. In Symmetric Key Block Cipher

Modes of Operation Workshop. National Institute of

Science and Technology.

Loefﬂer, S. (1997). Using ﬂows for analysis and mea-

surement of internet trafﬁc. Master’s thesis, Institute

of Communication Networks and Computer En-

gineering of the University of Stuttgart. http:

//www.mathematik.uni-stuttgart.de/

∼

floeff/diplom/report/node62.html.

Modadugu, N. and Rescorla, E. (2004). The design and im-

plementation of datagram tls. In Network Distributed

System Security Conference.

Modadugu, N. and Rescorla, E. (2006). Aes counter mode

cipher suites for tls and dtls. Technical report, Internet

Engineering Task Force.

Moeller, B. Security of cbc ciphersuites in ssl (tls prob-

lems and counter-measures. Posting on the Open SSL

Project’s website. http://www.openssl.org/

∼

bodo/tls-cbc.txt.

Rescorla, E. (2002). [ietf-tls] re: Rfc 2246-bis open

issues. Email to the ietf-tls@lists.certicom.com

email list. http://www.imc.org/ietf-tls/

mail-archive/msg03341.html.

Various. Various documents at the Open SSL web-site.

http://www.openssl.org/.

Vaudenay, S. (2001). Security ﬂaw induced by cbc padding

applications to ssl, ipsec, wtls, .... In Lecture Notes

in Computer Science. Advances in Cryptology— EU-

ROCRYPT’02, Springer-Verlag.

A GENERAL PROBLEMS WITH

CBC

The Cipher Block Chaining (CBC) mode of encryption was

ﬁrst proposed as a mode for DES, the Data Encryption Stan-

dard (Bellare et al., 1997). However, in the three decades

that have passed since that time, much research has taken

place in both adversarial modeling and modes of encryp-

tion (Bellare et al., 2001) (Dworkin, 2001) (Dworkin, 2002)

(Fouque et al., 2003) (Gligor and Donescu, 2001) (Knud-

sen, 2000) (Lipmaa et al., 2000).

A mode of encryption is an algorithm for deﬁning how

the block cipher will be used to produce ciphertexts when

the plaintext is of length longer than one block. For exam-

ple, CBC has the formula C

= F

i−1

⊕ P

) where C

is an initialization vector, and Counter Mode (CTR) has the

formula C

= F

(i + i

)⊕ P

, where i

is an initialization

vector (Knudsen, 2000) (Lipmaa et al., 2000).

We note the following disadvantages of CBC.

• CBC is vulnerable to blockwise-adaptive chosen-

plaintext attack, while CTR is not.

• An error in one block of CBC renders unreadable the re-

mainder of the message, while an error in one block of

CTR only renders that block unreadable.

• CBC cannot be parallelized, as can CTR. In CBC each

block depends on the encryption of the block before it.

In CTR, each block is encrypted independently.

• CBC is subject to the padding attack of Vaudenay (Vau-

denay, 2001), but this is avoidable if one pads according

to the algorithm given in that paper. In CTR, one can

pad arbitrarily and have the padding length as an extra

plaintext block at the end.

• CBC offers no protection versus Chosen Ciphertext At-

tack (CCA), as would HPCBC, XCBC, or OCB (Bel-

lare et al., 2001) (Gligor and Donescu, 2001). However,

Counter Mode also offers no CCA protection.

• An initialization vector need only be calculated once in

CTR mode, not per message as in CBC. The counter i

can be statefully maintained, and so will not repeat until

or 2

128

blocks.

• While this does not necessarily apply to SSL, the F

(i+

) can be pre-computed, leaving only XOR operations

with the plaintext to compute the ciphertext. If data needs

to be transmitted only occasionally, but urgently when

ready, this can be an advantage.

Since SSL uses Message Authentication Code (MAC)

algorithms for the datagrams, the malleability attacks and

other CCA attacks that plague CTR mode are of no interest.

Therefore it is clear that CTR and not CBC would be a bet-

ter choice for future versions of TLS and SSL, as CTR has

advantages and no disadvantages over CBC (Lipmaa et al.,

2000).

Other Problems with SSL’s Encryption: We note

that the mode of encryption should probably be changed

to address other concerns as well. For example, it is well-

known that applying a message authentication code to the

ciphertext itself after encryption is preferable to applying

it to the message before encryption (Bellare and Namprem-

pre, 2000) (Krawczyk, 2001). Currently, SSL does the latter

rather than the former.

SECRYPT 2006 - INTERNATIONAL CONFERENCE ON SECURITY AND CRYPTOGRAPHY

108

B THE APPLICATION OF

SPLITTING BLOCKS TO

GUESSING PASSWORDS

While the attack presented in this paper really can only pro-

vide for up to about 1000 guesses at best (a long game with

little background trafﬁc), under ideal conditions, other cho-

sen plaintext attacks might allow for several more. There-

fore it is interesting to point out the effect of splitting

upon passwords. If the printable ASCII character set of 95

choices is used, and the passwords are 8 bytes long, and

nearly randomly chosen (very generous assumptions), then

there are 95

= 6.6 × 10

= 2

52.6

possible passwords,

and 2

51.6

≈ 3.4 × 10

guesses would be required in ex-

pectation.

However, the probability of the password not being bro-

ken in two is 12.5%. Even with AES and 16-byte blocks,

= 43.8% will be broken into pieces. If divided down the

center, (regardless of 64-bit or 128-bit blocks) the number

of guesses expected would be

52.6

+ 2

52.6

= 2

26.3

= 8.26 × 10

Since 3.4×10

guesses are expected in the unsplit case,

and 8.3×10

in the split case, the attack becomes 4.1×10

times faster when the password is split. While our present

attack scenario is not suited for anywhere near this num-

ber of guesses, there may be similar scenarios which can

tolerate a few tens of thousands guesses, and if a few thou-

sand users are targeted, then at least one password recovery

would be expected, if not more.

A CHALLENGING BUT FEASIBLE BLOCKWISE-ADAPTIVE CHOSEN-PLAINTEXT ATTACK ON SSL

109