ThisPOODLEBites:ExploitingThe

SSL3.0Fallback
SecurityAdvisory
BodoMller,ThaiDuong,KrzysztofKotowicz
Google
September2014
{bmoeller,thaidn,koto}@google.com

Introduction
SSL3.0[RFC6101]isanobsoleteandinsecureprotocol.Whileformostpractical
purposesithasbeenreplacedbyitssuccessorsTLS1.0[RFC2246],TLS1.1[RFC4346],
andTLS1.2[RFC5246],manyTLSimplementationsremainbackwardscompatiblewith
SSL3.0tointeroperatewithlegacysystemsintheinterestofasmoothuserexperience.
Theprotocolhandshakeprovidesforauthenticatedversionnegotiation,sonormallythe
latestprotocolversioncommontotheclientandtheserverwillbeused.
However,evenifaclientandserverbothsupportaversionofTLS,thesecuritylevel
offeredbySSL3.0isstillrelevantsincemanyclientsimplementaprotocoldowngrade
dancetoworkaroundserversideinteroperabilitybugs.InthisSecurityAdvisory,we
discusshowattackerscanexploitthedowngradedanceandbreakthecryptographic
securityofSSL3.0.OurPOODLEattack(PaddingOracleOnDowngradedLegacy
Encryption)willallowthem,forexample,tostealsecureHTTPcookies(orotherbearer
tokenssuchasHTTPAuthorizationheadercontents).
Wethengiverecommendationsforbothclientsandserversonhowtocountertheattack:
ifdisablingSSL3.0entirelyisnotacceptableoutofinteroperabilityconcerns,TLS
implementationsshouldmakeuseofTLS_FALLBACK_SCSV.
CVE20143566hasbeenallocatedforthisprotocolvulnerability.

ThePOODLEAttack
Toworkwithlegacyservers,manyTLSclientsimplementadowngradedance:inafirst
handshakeattempt,offerthehighestprotocolversionsupportedbytheclientifthis
handshakefails,retry(possiblyrepeatedly)withearlierprotocolversions.Unlikeproper
protocolversionnegotiation(iftheclientoffersTLS1.2,theservermayrespondwith,say,
TLS1.0),thisdowngradecanalsobetriggeredbynetworkglitches,orbyactiveattackers.
Soifanattackerthatcontrolsthenetworkbetweentheclientandtheserverinterfereswith
anyattemptedhandshakeofferingTLS1.0orlater,suchclientswillreadilyconfine

themselvestoSSL3.0.
EncryptioninSSL3.0useseithertheRC4streamcipher,orablockcipherinCBCmode.
RC4iswellknowntohavebiases[RC4biases],meaningthatifthesamesecret(suchas
apasswordorHTTPcookie)issentovermanyconnectionsandthusencryptedwithmany
RC4streams,moreandmoreinformationaboutitwillleak.Weshowherehowtoput
togetheraneffectiveattackagainstCBCencryptionasusedbySSL3.0,againassuming
thattheattackercanmodifynetworktransmissionsbetweentheclientandtheserver.
UnlikewiththeBEAST[BEAST]andLucky13[Lucky13]attacks,thereisnoreasonable
workaround.ThisleavesuswithnosecureSSL3.0ciphersuitesatall:toachievesecure
encryption,SSL3.0mustbeavoidedentirely.
ThemostsevereproblemofCBCencryptioninSSL3.0isthatitsblockcipherpaddingis
notdeterministic,andnotcoveredbytheMAC(MessageAuthenticationCode):thus,the
integrityofpaddingcannotbefullyverifiedwhendecrypting.Paddingby1toLbytes
(whereListheblocksizeinbytes)isusedtoobtainanintegralnumberofblocksbefore
performingblockwiseCBC(cipherblockchaining)encryption.Theweaknessistheeasiest
toexploitiftheresanentireblockofpadding,which(beforeencryption)consistsofL1
arbitrarybytesfollowedbyasinglebyteofvalueL1.Toprocessanincomingciphertext
recordC1...CnalsogivenaninitializationvectorC0(whereeachCiisoneblock),the
recipientfirstdeterminesP1...PnasPi=DK(Ci)Ci1(whereDKdenotesblockcipher
decryptionusingperconnectionkeyK),thenchecksandremovesthepaddingattheend,
andfinallychecksandremovesaMAC.Nowobservethatiftheresafullblockofpadding
andanattackerreplacesCnbyanyearlierciphertextblockCifromthesameencrypted
stream,theciphertextwillstillbeacceptedifDK(Ci)Cn1happenstohaveL1asitsfinal
byte,butwillinalllikelihoodberejectedotherwise,givingrisetoapaddingoracleattack
[tlscbc].
Inthewebsetting,thisSSL3.0weaknesscanbeexploitedbyamaninthemiddle
attackertodecryptsecureHTTPcookies,usingtechniquesfromtheBEASTattack
[BEAST].TolaunchthePOODLEattack(PaddingOracleOnDowngradedLegacy
Encryption),runaJavaScriptagentonevil.com(oronhttp://example.com)togetthe
victimsbrowsertosendcookiebearingHTTPSrequeststohttps://example.com,and
interceptandmodifytheSSLrecordssentbythebrowserinsuchawaythattheresa
nonnegligiblechancethatexample.comwillacceptthemodifiedrecord.Ifthemodified
recordisaccepted,theattackercandecryptonebyteofthecookies.
AssumethateachblockChas16bytes,C[0]...C[15].(Eightbyteblockscanbehandled
similarly.)Alsoassume,fornow,thatthesizeofthecookiesisknown.(Laterwewillshow
howtostarttheattackifitisnt.)TheMACsizeinSSL3.0CBCciphersuitesistypically20
bytes,sobelowtheCBClayer,anencryptedPOSTrequestwilllookasfollows:
POST/pathCookie:name=value...\r\n\r\nbody20byteMACpadding
Theattackercontrolsboththerequestpathandtherequestbody,andthuscaninduce
requestssuchthatthefollowingtwoconditionshold:
Thepaddingfillsanentireblock(encryptedintoCn).
Thecookiesfirstasofyetunknownbyteappearsasthefinalbyteinanearlier
block(encryptedintoCi).
TheattackerthenreplacesCnbyCiandforwardsthismodifiedSSLrecordtotheserver.

Usually,theserverwillrejectthisrecord,andtheattackerwillsimplytryagainwithanew
request.Occasionally(onaverage,oncein256requests),theserverwillacceptthe
modifiedrecord,andtheattackerwillconcludethatDK(Ci)[15]Cn1[15]=15,andthus
thatPi[15]=15Cn1[15]Ci1[15].Thisrevealsthecookiesfirstpreviouslyunknown
byte.Theattackerproceedstothenextbytebychangingthesizesofrequestpathand
bodysimultaneouslysuchthattherequestsizestaysthesamebutthepositionofthe
headersisshifted1,continuinguntilithasdecryptedasmuchofthecookiesasdesired.
Theexpectedoveralleffortis256SSL3.0requestsperbyte.
Asthepaddinghidestheexactsizeofthepayload,thecookiessizeisnotimmediately
apparent,butinducingrequestsGET/,GET/A,GET/AA,...allowstheattackerto
observeatwhichpointtheblockboundarygetscrossed:afteratmost16suchrequests,
thiswillrevealthepaddingsize,andthusthesizeofthecookies.

Recommendations
TheattackdescribedaboverequiresanSSL3.0connectiontobeestablished,so
disablingtheSSL3.0protocolintheclientorintheserver(orboth)willcompletelyavoidit.
IfeithersidesupportsonlySSL3.0,thenallhopeisgone,andaseriousupdaterequired
toavoidinsecureencryption.IfSSL3.0isneitherdisablednortheonlypossibleprotocol
version,thentheattackispossibleiftheclientusesadowngradedancefor
interoperability.
DisablingSSL3.0entirelyrightawaymaynotbepracticalifitisneededoccasionallyto
workwithlegacysystems.Also,similarprotocolversiondowngradesarestillaconcern
withnewerprotocolversions(althoughnotnearlyassevereaswithSSL3.0).The
TLS_FALLBACK_SCSVmechanismfrom[draftietftlsdowngradescsv00]addressesthe
broaderissueacrossprotocolversionsversions,andweconsideritcrucialespeciallyfor
systemsthatmaintainSSL3.0compatibility.Thefollowingrecommendationssummarize
howTLS_FALLBACK_SCSVworks.
TLSclientsthatuseadowngradedancetoimproveinteroperabilityshouldincludethe
value0x56,0x00(TLS_FALLBACK_SCSV)inClientHello.cipher_suitesinanyfallback
handshakes.Thisvalueservesasasignalallowingupdatedserverstorejectthe
connectionincaseofadowngradeattack.Clientsshouldalwaysfallbacktothenext
lowerversion(ifstartingatTLS1.2,tryTLS1.1next,thenTLS1.0,thenSSL3.0)because
skippingaprotocolversionforgoesitsbettersecurity.(WithTLS_FALLBACK_SCSV,
skippingaversionalsocouldentirelypreventasuccessfulhandshakeifithappenstobe
theversionthatshouldbeusedwiththeserverinquestion.)
InTLSservers,wheneveranincomingconnectionincludes0x56,0x00
(TLS_FALLBACK_SCSV)inClientHello.cipher_suites,compareClientHello.client_version
tothehighestprotocolversionsupportedbytheserver.Iftheserversupportsaversion
higherthantheoneindicatedbytheclient,rejecttheconnectionwithafatalalert
(preferably,inappropriate_fallback(86)from[draftietftlsdowngradescsv00]).

ExperimentingwithaproofofconceptforthePOODLEattack,wefoundthatsomebrowserssend
requestheaderandrequestbodyinseparateSSLrecords.Inthiscase,onlythepathsizeneedstobe
changedwhenproceedingtothenexttargetbyte.

ThisuseofTLS_FALLBACK_SCSVwillensurethatSSL3.0isusedonlywhenalegacy
implementationisinvolved:attackerscannolongerforceaprotocoldowngrade.(Attacks
remainpossibleifbothpartiesallowSSL3.0butoneofthemisnotupdatedtosupport
TLS_FALLBACK_SCSV,providedthattheclientimplementsadowngradedancedownto
SSL3.0.)

References
[BEAST]T.Duong,J.Rizzo:HereComeTheNinjas,2011.
[draftietftlsdowngradescsv00]B.Mller,A.Langley:TLSFallbackSignalingCipher
SuiteValue(SCSV)forPreventingProtocolDowngradeAttacks,InternetDraft
draftietftlsdowngradescsv00,2014.
[Lucky13]N.J.AlFardan,K.G.Paterson:LuckyThirteen:BreakingtheTLSandDTLS
RecordProtocols,IEEESymposiumonSecurityandPrivacy,2013.
[RC4biases]N.J.AlFardan,D.J.Bernstein,K.G.Paterson,B.Poettering,J.C.N.Schuldt:
OntheSecurityofRC4inTLSandWPA,USENIXSecuritySymposium,2013.
[RFC2246]T.Dierks,C.Allen:TheTLSProtocolVersion1.0,RFC2246,1998.
[RFC4346]T.Dierks,E.Rescorla:TheTransportLayerSecurity(TLS)ProtocolVersion
1.1,RFC4346,2006.
[RFC5246]T.Dierks,E.Rescorla:TheTransportLayerSecurity(TLS)ProtocolVersion
1.2,RFC5246,2008.
[RFC6101]A.Freier,P.Karlton,P.Kocher:TheSecureSocketsLayer(SSL)Protocol
Version3.0,RFC6101,1996(publishedasHistoricRFCin2011).
[tlscbc]B.Mller:SecurityofCBCCiphersuitesinSSL/TLS:Problemsand
Countermeasures,http://www.openssl.org/~bodo/tlscbc.txt,2004.