The following paper was originally published in the
`Proceedings of the Second USENIX Workshop on Electronic Commerce
`Oakland, California, November 1996
`
`Analysis of the SSL 3.0 Protocol
`
`David Wagner, University of California, Berkeley
`Bruce Schneier, Counterpane Systems
`
`For more information about USENIX Association contact:
`1. Phone:
`510 528-8649
`2. FAX:
`510 548-5738
`3. Email:
`office@usenix.org
`4. WWW URL: http://www.usenix.org
`
`Ex. 1007
`Apple v. MPH Techs. Oy
`IPR2019-00823
`
`0001
`
`

`

`Analysis of the SSL . protocol
`
`David Wagner
`University of California, Berkeley
`daw@cs.berkeley.edu
`
`Bruce Schneier
`Counterpane Systems
`schneier@counterpane.com
`
`Abstract
`
`The SSL protocol is intended to provide a prac-
`tical, application-layer, widely applicable connection-
`oriented mechanism for Internet client/server com-
`munications security. This note gives a detailed tech-
`nical analysis of the cryptographic strength of the
`SSL . protocol. A number of minor (cid:13)aws in the
`protocol and several new active attacks on SSL are
`presented; however, these can be easily corrected
`without overhauling the basic structure of the pro-
`tocol. We conclude that, while there are still a few
`technical wrinkles to iron out, on the whole SSL .
`is a valuable contribution towards practical commu-
`nications security.
`
` Introduction
`
`The recent explosive growth of the Internet and the
`World Wide Web has brought with it a need to se-
`curely protect sensitive communications sent over
`this open network. The SSL . protocol has be-
`come a de facto standard for cryptographic protec-
`tion of Web http tra(cid:14)c. But SSL . has several
`limitations|both in cryptographic security and in
`functionality|so the protocol has been upgraded,
`with signi(cid:12)cant enhancements, to SSL .. This new
`version of SSL will soon see widespread deployment.
`The IETF Transport Layer Security working group
`is also using SSL . as a base for their standards
`e(cid:11)orts. In short, SSL . aims to provide Internet
`client/server applications with a practical, widely-
`applicable connection-oriented communications se-
`curity mechanism.
`
`the SSL . speci(cid:12)cation
`This note analyzes
`[FKK ], with a strong focus on its cryptographic
`security. We assume familiarity with the SSL .
`speci(cid:12)cation. Explanations of some of the crypto-
`graphic concepts can be found in [Sch ].
`
`The paper is organized as follows. Section  brie(cid:13)y
`
`gives some background on SSL . and its prede-
`cessor SSL .. Sections and  explore several
`possible attacks on the SSL protocol and o(cid:11)er some
`technical discussion on the cryptographic protection
`a(cid:11)orded by SSL .; this material is divided into
`two parts, with the SSL record layer analyzed in Sec-
`tion and the SSL key-exchange protocol considered
`in Section . Finally, Section  concludes with a
`high-level view of the SSL protocol’s strengths and
`weaknesses.
`
` Background
`
`SSL is divided into two layers, with each layer us-
`ing services provided by a lower layer and provid-
`ing functionality to higher layers. The SSL record
`layer provides con(cid:12)dentiality, authenticity, and re-
`play protection over a connection-oriented reliable
`transport protocol such as TCP. Layered above the
`record layer is the SSL handshake protocol, a key-
`exchange protocol which initializes and synchronizes
`cryptographic state at the two endpoints. After the
`key-exchange protocol completes, sensitive applica-
`tion data can be sent via the SSL record layer.
`
`SSL . had many security weaknesses which SSL
` . aims to (cid:12)x. We brie(cid:13)y describe a short list of the
`(cid:13)aws in SSL . which we have noticed. In export-
`weakened modes, SSL . unnecessarily weakens the
`authentication keys to  bits. SSL . uses a weak
`MAC construction, although post-encryption seems
`to stop attacks. SSL . feeds padding bytes into the
`MAC in block cipher modes, but leaves the padding-
`length (cid:12)eld unauthenticated, which may potentially
`allow active attackers to delete bytes from the end
`of messages. There is a ciphersuite rollback attack,
`where an active attacker edits the list of ciphersuite
`preferences in the hello messages to invisibly force
`both endpoints to use a weaker form of encryption
`than they otherwise would choose; this serious (cid:13)aw
`limits SSL .’s strength to \least common denomin-
`ator" security when active attacks are a threat. Oth-
`
`0002
`
`

`

`ers have also discovered some of these weaknesses:
`Dan Simon independently pointed out the ciphersuite
`rollback attack, Paul Kocher has addressed these
`concerns [Koc ], and the PCT . protocol [PCT ]
`discussed and countered some (though not all) of
`these (cid:13)aws.
`
` The record layer
`
`This section considers the cryptographic strength of
`the record layer protocol, and assumes that the key-
`exchange protocol has securely set up session state,
`keys, and security parameters. Of course, a secure
`key-exchange protocol is vital to the security of ap-
`plication data, but an examination of attacks on the
`SSL key-exchange protocol is postponed until the
`next section.
`
`The SSL record layer addresses fairly standard prob-
`lems that have received much attention in the crypto-
`graphic and security literature [KV ], so it is reas-
`onable to hope that SSL . provides fairly solid pro-
`tection in this respect. As we shall see, this is not
`far from the truth. We consider con(cid:12)dentiality and
`integrity protection in turn.
`
` . Con(cid:12)dentiality: eavesdropping
`
`The SSL protocol encrypts all application-layer data
`with a cipher and short-term session key negotiated
`by the handshake protocol. A wide variety of strong
`algorithms used in standard modes is available to
`suit local preferences; reasonable applications should
`be able to (cid:12)nd an encryption algorithm meeting the
`required level of security, US export laws permit-
`ting. Key-management is handled well: short-term
`session keys are generated by hashing random per-
`connection salts and a strong shared secret.
`Inde-
`pendent keys are used for each direction of a connec-
`tion as well as for each di(cid:11)erent instance of a connec-
`tion. SSL will provide a lot of known plaintext to the
`eavesdropper, but there seems to be no better altern-
`ative; since the encryption algorithm is required to
`be strong against known-plaintext attacks anyway,
`this should not be problematic.
`
` . Con(cid:12)dentiality: tra(cid:14)c analysis
`
`sidering. Tra(cid:14)c analysis aims to recover con(cid:12)dential
`information about protection sessions by examining
`unencrypted packet (cid:12)elds and unprotected packet
`attributes. For example, by examining the unen-
`crypted IP source and destination addresses (and
`even TCP ports), or examining the volume of net-
`work tra(cid:14)c (cid:13)ow, a tra(cid:14)c analyst can determine what
`parties are interacting, what type of services are in
`use, and even sometimes recover information about
`business or personal relationships. In practice, users
`typically consider the threat of this kind of coarse-
`grained tracking to be relatively harmless, so SSL
`does not attempt to stop this kind of tra(cid:14)c analysis.
`Ignoring coarse-grained tra(cid:14)c analysis seems like a
`reasonable design decision.
`
`However, there are some more subtle threats posed
`by tra(cid:14)c analysis in the SSL architecture. Bennet
`Yee has noted that examination of ciphertext lengths
`can reveal information about URL requests in SSL-
`or SSL-encrypted Web tra(cid:14)c [Yee ]. When a Web
`browser connects to a Web server via an encrypted
`transport such as SSL, the GET request containing
`the URL is transmitted in encrypted form. Exactly
`which Web page was downloaded by the browser
`is clearly considered con(cid:12)dential information|and
`for good reason, as knowledge of the URL is of-
`ten enough for an adversary to obtain the entire
`Web page downloaded|yet tra(cid:14)c analysis can re-
`cover the identity of the Web server, the length of
`the URL requested, and the length of the html data
`returned by the Web server. This leak could often al-
`low an eavesdropper to discover what Web page was
`accessed. (Note that Web search engine technology
`is certainly advanced enough to catalogue the data
`openly available on a Web server and (cid:12)nd all URLs
`of a given length on a given server which return a
`given amount of html data.)
`
`This vulnerability is present because the ciphertext
`length reveals the plaintext length. SSL includes
`support for random padding for the block cipher
`modes, but not for the stream cipher modes. We
`believe that SSL should at the minimum support the
`usage of random-length padding for all cipher modes,
`and should also strongly consider requiring it for cer-
`tain applications.
`
`When the standard attacks fail, a cryptanalyst will
`turn to more obscure ones. Though often maligned,
`tra(cid:14)c analysis is another passive attack worth con-
`
` This is strictly speaking only true of stream ciphers, but
`they are currently the common case. With block ciphers,
`plaintexts are padded out to the next -byte boundary, so
`one can only recover a close estimate of the plaintext length.
`
`0003
`
`

`

` . Con(cid:12)dentiality: active attacks
`
`It is important that SSL securely protect con(cid:12)den-
`tial data even against active attacks. Of course, the
`underlying encryption algorithm should be secure
`against adaptive chosen-plaintext/chosen-ciphertext
`attacks, but this is not enough on its own. Recent
`research motivated by the IETF ipsec (IP security)
`working group has revealed that sophisticated active
`attacks on a record layer can breach a system’s con-
`(cid:12)dentiality even when the underlying cipher is strong
`[Bel ]. It appears that the SSL . record layer res-
`ists these powerful attacks; it is worth discussing in
`some depth why they are foiled.
`
`One important active attack on ipsec is Bellovin’s
`cut-and-paste attack [Bel ]. Recall that, to achieve
`con(cid:12)dentiality, link encryption is not enough|the
`receiving endpoint must also guard the sensitive data
`from inadvertent disclosure. The cut-and-paste at-
`tack exploits the principle that most endpoint applic-
`ations will treat inbound encrypted data di(cid:11)erently
`depending on the context, protecting it more assidu-
`ously when it appears in some forms than in others.
`The cut-and-paste attack also takes advantage of a
`basic property of the cipher-block chaining mode: it
`recovers from errors within one block, so transplant-
`ing a few consecutive ciphertext blocks between loc-
`ations within a ciphertext stream results in a cor-
`responding transfer of plaintext blocks, except for
`a one-block error at the beginning of the splice. In
`more detail, Bellovin’s cut-and-paste attack cuts an
`encrypted ciphertext from some packet containing
`sensitive data, and splices it into the ciphertext of
`another packet which is carefully chosen so that the
`receiving endpoint will be likely to inadvertently leak
`its plaintext after decryption. For example, if cut-
`and-paste attacks on the SSL record layer were feas-
`ible, they could be used to compromise site security:
`a cut-and-paste attack on a SSL server-to-client Web
`page transfer could splice ciphertext from a sensit-
`ive part of that html transfer into the hostname por-
`tion of a URL included elsewhere in the transferred
`Web page, so that when a user clicks on the booby-
`trapped URL link his browser would interpret the
`decryption of the spliced sensitive ciphertext as a
`hostname and send a DNS domain name lookup for
`
`In the ipsec world, encrypted data to TCP user ports is
`not protected by the operating system nearly as strongly as
`encrypted data to the system TCP login or telnet port. For a
`SSL-protected Web connection, the client browser will guard
`the path portion of a URL more carefully than the hostname
`portion, as the hostname portion may subsequently appear
`unencrypted in DNS queries and IP source addresses, whereas
`the path portion of a URL is encrypted via SSL.
`
`it in the clear, ready for capture by the eavesdropping
`attacker. Cut-and-paste attacks, in short, enlist the
`unsuspecting receiver to decrypt and inadvertently
`leak sensitive data for them.
`
`SSL . stops cut-and-paste attacks. One partial
`defense against cut-and-paste attacks is to use in-
`dependent session keys for each di(cid:11)erent context.
`This prevents cutting and pasting between di(cid:11)erent
`connections, di(cid:11)erent directions of a connection, etc.
`SSL already uses independent keys for each direc-
`tion of each incarnation of each connection. Still,
`cutting and pasting within one direction of a trans-
`fer is not prevented by this mechanism. The most
`comprehensive defense against cut-and-paste attacks
`is to use strong authentication on all encrypted pack-
`ets to prevent enemy modi(cid:12)cation of the ciphertext
`data. The SSL record layer does employ this defense,
`so cut-and-paste attacks are completely foiled. For a
`more complete exposition on cut-and-paste attacks,
`see Bellovin’s paper [Bel ].
`
`The short-block attack is another active attack
`against ipsec which can be found in Bellovin’s paper
`[Bel ]. The short-block attack was originally ap-
`plied against DES-CBC ipsec-protected TCP data
`when the (cid:12)nal message block contains a short one-
`byte plaintext and the remainder of it is (cid:12)lled by
`random padding. One guesses at the unknown plain-
`text byte by replacing the (cid:12)nal ciphertext block
`with another ciphertext block from a known plain-
`text/ciphertext pair. Correct guesses can be recog-
`nized by the validity of the TCP checksum: an in-
`correct guess will cause the packet to be silently
`dropped by the receiver’s TCP stack, but the cor-
`rect guess will cause a recognizable ACK to be re-
`turned. Knowledge of the corresponding plaintext
`for a correctly guessed replacement ciphertext block
`enables the enemy to recover the unknown plaintext
`byte. Because the receiving ipsec stack ignores the
`padding bytes, the short-block attack requires about
` known plaintexts and  active online trials to re-
`cover such an unknown trailing byte. Many distract-
`ing technicalities have been signi(cid:12)cantly simpli(cid:12)ed;
`see Bellovin’s paper [Bel ] for more details.
`
`There are no obvious short-block attacks on SSL.
`The SSL record layer format is rather similar to
`the old vulnerable ipsec layout, so it is admit-
`tedly conceivable that a modi(cid:12)ed version of the at-
`tack might work against SSL. In any case, stand-
`ard SSL-encrypting Web servers probably would not
`be threatened by a short-block type of attack, since
`they do not typically encrypt short blocks. (Note,
`however, that a SSL-encrypting telnet client should
`
`0004
`
`

`

`demand particularly robust protection against short-
`block attacks, as each keystroke is typically sent in
`its own one-byte-long packet.)
`
`In summary, our analysis did not uncover any active
`attacks on the con(cid:12)dentiality protection of the SSL
` . record layer.
`
` . Message authentication
`
`In addition to protecting the con(cid:12)dentiality of ap-
`plication data, SSL cryptographically authenticates
`sensitive communications. On the Internet, active
`attacks are getting easier to launch every day. We
`are aware of at least two commercially available soft-
`ware packages to implement active attacks such as IP
`spoo(cid:12)ng and TCP session hijacking, and they even
`sport a user-friendly graphical interface. Moreover,
`the (cid:12)nancial incentive for exploiting communications
`security vulnerabilities is growing rapidly. This calls
`for strong message authentication.
`
`SSL protects the integrity of application data by us-
`ing a cryptographic MAC. The SSL designers have
`chosen to use HMAC, a simple, fast hash-based con-
`struction with some strong theoretical evidence for
`its security [BCK ]. In an area where several ini-
`tial ad-hoc proposals for MACs have been cryptana-
`lyzed, these provable security results are very at-
`tractive. HMAC is rapidly becoming the gold stand-
`ard of message authentication, and it is an excellent
`choice for SSL. Barring major unexpected cryptana-
`lytic advances, it seems unlikely that HMAC will be
`broken in the near future.
`
`We point out that SSL . uses an older obsolete ver-
`sion of the HMAC construction. SSL should move to
`the updated current HMAC format when convenient,
`for maximal security.
`
`On the whole, SSL . looks very secure against
`straightforward exhaustive or cryptanalytic attacks
`on the MAC. SSL . had a serious design
`(cid:13)aw in that it used an insecure MAC|though
`post-encryption saved this from being a direct
`vulnerability|but SSL . has (cid:12)xed this mistake.
`The SSL MAC keys contain at least  bits of en-
`tropy, even in export-weakened modes, which should
`provide excellent security for both export-weakened
`and domestic-grade implementations.
`Independent
`keys are used for each direction of each connection
`and for each new incarnation of an connection. The
`choice of HMAC should stop cryptanalytic attacks.
`SSL does not provide non-repudiation services, and
`it seems reasonable to deliberately leave that to spe-
`
`cial higher-level application-layer protocols.
`
` . Replay attacks
`
`The naive use of a MAC does not necessarily stop
`an adversary from replaying stale packets. Replay
`attacks are a legitimate concern, and as they are
`so easy to protect against, it would be irrespons-
`ible to fail to address these threats. SSL protects
`against replay attacks by including an implicit se-
`quence number in the MACed data. This mechanism
`also protects against delayed, re-ordered, or deleted
`data. Sequence numbers are  bits long, so wrap-
`ping should not be a problem. Sequence numbers
`are maintained separately for each direction of each
`connection, and are refreshed upon each new key-
`exchange, so there are no obvious vulnerabilities.
`
` . The Horton principle
`
`Let’s recall the ultimate goal of message authentic-
`ation. SSL provides message integrity protection
`just when the data passed up from the receiver’s
`SSL record layer to the protected application exactly
`matches the data uttered by the sender’s protected
`application to the sender’s SSL record layer. This
`means, approximately, that it is not enough to apply
`a secure MAC to just application data as it is trans-
`mitted over the wire|one must also authenticate any
`context that the SSL mechanism depends upon to
`interpret inbound network data. For lack of a bet-
`ter word, let’s call this \the Horton principle" (with
`apologies to Dr. Seuss) of semantic authentication:
`roughly speaking we want SSL to
`
`\authenticate what was meant, not what
`was said."
`
`To phrase it another way,
`
`Eschew unauthenticated security-critical
`context.
`
`SSL . su(cid:11)ered from at least one (cid:13)aw along these
`lines:
`it included padding data but not the length
`of the padding in the MAC input, so an active at-
`tacker could manipulate the cleartext padding length
`(cid:12)eld to compromise message integrity. An analysis
`checking SSL .’s compliance with the Horton prin-
`ciple would have uncovered this (cid:13)aw; therefore, we
`undertake an informal analysis of SSL . following
`the guidelines of the Horton principle.
`
`0005
`
`

`

`Figure : Analysis of security-critical context
`
`encrypted fragment(cid:3)(cid:3)
`#
`[read key(cid:3), read IV ( )]
`padded compressed fragment
`#
`[cipher type(cid:3) ()]
`SSLCompressed.fragment
`[CompressionMethod(cid:3)]
`#
`SSLPlaintext.fragment
`[ContentType(cid:3)(cid:3) ( ),
`#
`#
`ProtocolVersion,
`#
`SSLPlaintext.length(cid:3)(cid:3)]
`\meaning"
`
`Notes:
`
`(cid:3) session state synchronized by the key-exchange
`protocol.
`
`(cid:3)(cid:3) protected by the MAC.
`
`( ) read IV is initially taken from the session state,
`then taken from the last ciphertext block of the
`previous encrypted fragment.
`
`() for block ciphers, padding is removed from the
`end of the padded fragment.
`
`The SSL record layer depends on a lot of context
`to interpret, decrypt, decompress, de-multiplex, and
`dispatch data from the wire.
`It is instructive to
`follow the chain of this processing of inbound net-
`work data, catalogue all the security-critical context
`which this processing depends on, and check to en-
`sure that the critical context has been authenticated.
`This ensures that we have applied the MAC prop-
`erly to all security-relevant items and ful(cid:12)lled the
`Horton principle. Because the encrypted fragment
`(cid:12)eld is authenticated by the MAC, we will assume
`that that (cid:12)eld is trustworthy, and follow its trans-
`formation into application data (\meaning"). The
`right-justi(cid:12)ed bracketed items in Figure identify
`security-critical context used in each step of pro-
`cessing.
`
`Figure indicates that SSL . follows the Hor-
`ton principle fairly closely. One minor exception
`is that the integrity of the ProtocolVersion (cid:12)eld
`is not protected.
`(We refer speci(cid:12)cally to the
`SSLCiphertext.ProtocolVersion (cid:12)eld in the re-
`cord layer, not the ClientHello.client version
`(cid:12)eld from the handshake protocol;
`the latter
`is protected, but the former is not.)
`If the
`ProtocolVersion (cid:12)eld is ever used by SSL, it should
`
`be authenticated; if not, it should not be present in
`the packet format. Also, it is worth mentioning that
`the (cid:12)nal result of the inbound processing is a stream
`of bytes from the application data stream, and mes-
`sage boundaries are not preserved. Any application
`that relies on message boundaries|such as a UDP-
`based program|will have to impose a higher-layer
`message length protocol on top of SSL. On the whole,
`though, our \Horton principle"-inspired analysis re-
`vealed no major weaknesses, to SSL .’s credit.
`
` . Summary
`
`In summary, the protection of application data by
`the SSL record layer is, on the whole, quite good.
`The preceding section indicated a few small areas of
`concern, but they should be considered minor and
`the exception to the rule.
`
` The key-exchange protocol
`
`This section considers the security of the SSL hand-
`shake protocol as well as other SSL meta-data trans-
`port. The design of a secure key-exchange protocol
`is a thorny endeavor. There is a signi(cid:12)cant amount
`of complexity involved, so the discovery of a few
`weaknesses should not prove surprising. The fol-
`lowing analysis describes a number of shortcomings
`of the SSL meta-data protection mechanisms, mostly
`in areas that have seen recent changes. The SSL .
`key-exchange protocol appears to be a signi(cid:12)cant ad-
`vance over SSL ., but it still bears a few scars from
`growing pains.
`
`. Overview of the handshake (cid:13)ow
`
`The SSL . handshake-protocol message (cid:13)ow in-
`volves client and server negotiating a common
`ciphersuite acceptable to both parties, exchanging
`random nonces, and the client sending an encryp-
`ted master secret. Then each veri(cid:12)es that their
`protocol runs match by authenticating all messages
`with the master secret, and assuming that the
`check succeeds, both generate session keys from
`the master secret and proceed to send applica-
`tion data. The SSL protocol also includes a more
`lightweight session resumption protocol which al-
`lows two parties who have already exchanged a
`master secret to generate updated session keys and
`start a new connection with those parameters.
`
`0006
`
`

`

`. Ciphersuite rollback attacks
`
`The SSL . key-exchange protocol contained a seri-
`ous (cid:13)aw: an active attacker could silently force a do-
`mestic user to use export-weakened encryption, even
`if both endpoints supported and preferred stronger-
`grade algorithms. This is known as a ciphersuite
`rollback attack, and it can be performed by editing
`the cleartext list of supported ciphersuites sent in
`hello messages. SSL . (cid:12)xes this vulnerability by
`authenticating all the handshake protocol messages
`with the master secret, so such enemy tampering
`can be determined at the end of the handshake and
`the session terminated if necessary.
`
`We describe the SSL . mechanism for prevent-
`ing modi(cid:12)cation of handshake protocol messages in
`more detail. There are several generic vulnerabilit-
`ies in this part of the SSL handshake protocol, so
`some introduction is in order. All the initial hand-
`shake protocol messages are sent, unprotected, in
`the clear.
`Instead of modifying the parameters in
`use at the moment, the key-exchange protocol mod-
`i(cid:12)es a pending session state. After the negotiation is
`complete, each party sends a short change cipher
`spec message, which simply alerts the other to up-
`grade the status of the pending session state to cur-
`rent. The new session state is used starting with
`the next message, though the change cipher spec
`message is unprotected. Immediately following the
`change cipher spec comes the (cid:12)nished message,
`which contains a MAC on all the handshake pro-
`tocol messages keyed by the master secret. (For
`peculiar non-security reasons, the change cipher
`spec and alert messages are not authenticated in the
`(cid:12)nished message.) The -byte master secret is
`never disclosed; instead, session keys are generated
`from it. This ensures that even if the session keys
`are recovered, the master secret will remain secret,
`so the handshake protocol messages will be securely
`authenticated. The (cid:12)nished message is itself protec-
`ted with the newly established ciphersuite. Neither
`party is supposed to accept application data until it
`has received and veri(cid:12)ed a (cid:12)nished message from
`the other party.
`
` More precisely, it is protected with the old session state,
`which initially is set up to provide no protection. The dis-
`cussion ignores the complicating case of a handshake protocol
`execution which changes cryptographic parameters on a con-
`nection that already has some protection in e(cid:11)ect.
`
`. Dropping the change cipher spec
`message
`
`One quirk of the SSL key-exchange protocol is that
`the change cipher spec message is not protected by
`the message authentication in the (cid:12)nished message.
`This can potentially allow the cryptanalyst to get a
`foot in the door. We recall the normal SSL message
`(cid:13)ow:
`
`: : :
`[change cipher spec]
` : C ! S :
`[(cid:12)nished:] fagk
`: C ! S :
`[change cipher spec]
` : S ! C :
`[(cid:12)nished:] fagk
`: S ! C :
`: C ! S : fmgk
`: : :
`
`where f(cid:1)gk represents the keyed cryptographic trans-
`forms used by the record layer, m denotes a plaintext
`message sent after the key-exchange is (cid:12)nished, and
`a represents the (cid:12)nished message’s authentication
`code, which is obtained by computing a symmet-
`ric MAC on the previous handshake messages (ex-
`cluding the change cipher spec message). Note
`that before the receipt of a change cipher spec
`message, the current ciphersuite o(cid:11)ers no encryp-
`tion or authentication and the pending ciphersuite
`includes the negotiated ciphersuite; upon receiving a
`change cipher spec message, implementations are
`supposed to copy the pending ciphersuite to the cur-
`rent ciphersuite and enable cryptographic protection
`in the record layer.
`
`We describe an attack that takes advantage of the
`lack of protection for change cipher spec mes-
`sages. We assume the special case where the ne-
`gotiated ciphersuite includes only message authen-
`tication protection and no encryption. The active
`attacker intercepts and deletes the change cipher
`spec messages, so that the two endpoints never up-
`date their current ciphersuite; in particular, the two
`endpoints never enable message authentication or en-
`cryption in the record layer for incoming packets.
`Now the attacker allows the rest of the interaction
`to proceed, stripping o(cid:11) the record layer authentica-
`tion (cid:12)elds from (cid:12)nished messages and session data.
`At this point there is no authentication protection
`for session data in e(cid:11)ect, and the active attacker can
`modify the transmitted session data at will. The
`impact is that, when an authentication-only trans-
`form is negotiated, an active attacker can defeat the
`authentication protection on session data, transpar-
`ently causing both parties to accept incoming session
`data without any cryptographic integrity protection.
`
`0007
`
`

`

`We summarize the attack (cid:13)ow:
`
`: : :
`[change cipher spec]
` : C ! M :
`[(cid:12)nished:] fagk
`: C ! M :
`[(cid:12)nished:] a
`: M ! S :
`[change cipher spec]
` :
`S ! M :
`[(cid:12)nished:] fagk
`:
`S ! M :
`[(cid:12)nished:] a
`: M ! C :
`: C ! M : fmgk
`: M ! S : m
`: : :
`
`Remember, in this (cid:13)ow fmgk denotes the transmis-
`sion of a message m along with a message authen-
`tication (cid:12)eld keyed by k; given fmgk it is easy to
`strip o(cid:11) the MAC (cid:12)eld and recover fmg, since no
`encryption is in use here. Note that the attacker can
`easily replace the unprotected session data m in (cid:13)ow
` by forged data of his choice.
`
`It is worth pointing out what happens when the ne-
`gotiated ciphersuite includes encryption. Then the
`client’s (cid:12)nished message is sent encrypted, but the
`server expects to receive it unencrypted, so it does
`not su(cid:14)ce to strip o(cid:11) the MAC (cid:12)eld|instead, the
`attacker must recover the encryption key k and de-
`crypt fagk to obtain a. Therefore the attack will
`be foiled when the negotiated ciphersuite includes
`strong encryption.
`In the intermediate case where
`weak encryption (such as a -bit exportable mode)
`is used, the attacker may be able to carry out this
`attack if it possible to perform an online exhaustive
`keysearch to recover the short encryption key. In
`all fairness, real-time online exhaustive keysearch of
`a -bit cipher is currently out of reach for many ad-
`versaries, although advances in computation power
`may make it a more serious threat in the future.
`
`The simplest (cid:12)x is to require that a SSL implement-
`ation receive a change cipher spec message before
`accepting a (cid:12)nished message. Some readers might
`complain that this requirement ought to be obvious
`with a moment’s re(cid:13)ection, even if it is not explicitly
`
`A note about the amount of known plaintext available is
`in order. When a block cipher mode (such as -bit RC or
`-bit DES) is in use, there will be  bytes of known plaintext
`in the header of the (cid:12)nished message and another { bytes in
`the padding (cid:12)elds, so enough known text is available. For un-
`padded -bit stream cipher modes, there is only the  bytes
`of known plaintext in the (cid:12)nished message header; if the cli-
`ent immediately sends encrypted session data after sending
`the (cid:12)nished message (as is allowed in Section .. of the
`SSL . speci(cid:12)cation) then enough additional known plain-
`text will probably be available to uniquely recover the stream
`cipher key; otherwise, about  possible -bit keys will be
`suggested, and the attacker must settle for a (cid:0) chance of
`success.
`
`stated in the SSL speci(cid:12)cation. We cannot fault such
`clarity of vision. However, we settle for the obser-
`vation that at least one implementation has fallen
`for this pitfall. After performing the theoretical ana-
`lysis, we examined Netscape’s SSLRef .b refer-
`ence source code for SSL .. Indeed, the necessary
`check is not made there; though we have not actu-
`ally implemented the attack, it appears that SSLRef
` .b will fall to a change cipher spec dropping
`attack when an authentication-only ciphersuite is ne-
`gotiated.
`
`A more radical (cid:12)x would include the change cipher
`spec message in the the (cid:12)nished message’s mes-
`sage authentication calculation. This would require
`a change to the SSL speci(cid:12)cation; however, it also
`would have the advantage of being more robust in
`face of implementation (cid:13)aws.
`
`At the least, we recommend that future SSL docu-
`ments include a warning about this pitfall. Explicit-
`ness is a virtue.
`
`. Key-exchange algorithm rollback
`
`The SSL . handshake protocol also contains an-
`other design (cid:13)aw. A server can send short-lived
`public key parameters, signed under its long-term
`certi(cid:12)ed signing key, in the server key exchange
`message. Several key-exchange algorithms are sup-
`ported, including ephemeral RSA and Di(cid:14)e-Hellman
`public keys. Unfortunately, the signature on the
`short-lived parameters does not protect the (cid:12)eld
`which speci(cid:12)es which type of key-exchange algorithm
`is in use. Note that this violates the Horton principle:
`SSL should sign not just the public parameters but
`also all data needed to interpret those parameters.
`
`For convenience, we reprint the relevant SSL . data
`structures from the the server key exchange mes-
`sage here.
`
`enum { rsa, diffie_hellman, ... }
`KeyExchangeAlgorithm;
`
`struct {
`opaque rsa_modulus;
`opaque rsa_exponent;
`} ServerRSAParams;
`struct {
`opaque dh_p;
`opaque dh_g;
`opaque dh_Ys;
`} ServerDHParams;
`struct {
`select (KeyExchangeAlgorithm) {
`
`0008
`
`

`

`case d