Cryptoinpractice:WhathappenswhenyouconnecttoasecurewebserverNormalcommunicationbetweenawebbrowserandawebserveriscarriedoutthroughanexchangeofmessagesinHTTP(HypertextTransferProtocol).Thesemessagesaretranslatedintoandfromthenetworkpacketsusedbythelower-levelnetworkprotocols.TheSecureSocketsLayer(SSL),laterrenamedTransportLayerSecurity(TLS)isaprotocolthatsitsbetweenapplicationlayerprotocolslikeHTTPandthelowerlevels.ThefirstTLSmessagesexchangedcreatethesecurechannelbetweenclientandserver,andthesubsequentmessagesareencryptedversionsoftheapplicationlayermessages.Thisdemopresentsaverydetailedexampleofhowthisiscarriedout,usingTLSversion1.2,thelatestdescendantofSSL.Init,youwillseehowallthetechniqueswehavestudiedinclass:pseudo-randomnumbergeneration,publickeyencryption,symmetricencryption,hashfunctions,messageauthenticationcodes,anddigitalsignatures,areactuallydeployedinpractice.ThetextbookprovidesaverybriefaccountofhowanearlierTLSversionworks.TheinspirationforthisdemoisablogpostbyDougMoser,'Thefirstfewmillisecondsofanhttpsconnection'http://www.moserware.com/2009/06/first-few-milliseconds-of-https.html.Mosercarriesoutessentiallythesameprocedureshownhere,withanolderversionofTLSandadifferentcipherforsymmetricencryption.Howthedemowascreated.IsetanenvironmentvariablesothattheChromebrowserwouldlogthesecretkeymaterialitgenerates.(Forobviousreasons,thisissomethingyouDON'Twanttodoroutinely.)OnaMacintoshcomputer,yousetthisvariablefromthecommandlineintheTerminalutilitybytyping:launchctl setenv SSLKEYLOGFILE full-path wherefull-pathisthefullpathnameofatextfilethatwillbeusedtologthesecrets.IlaunchedWireshark,anetworkanalysistool,whichcapturedallthepacketssentfromandreceivedbytheWi-Ficonnectiononmycomputer.ThenIstartedtheChromebrowser,wenttotarget.com,andstartedtheprocess(nevercompleted)ofbuyingsomespeakers.WhenIwenttocheckout,Ifinallyreachedthesecurewebsitehttps://www-secure.target.com.(Interestingly,Targetdoesnotencryptthecommunicationuntilitistimetopay,soitdoesnottreatWHATIambuyingasconfidentialinformation.)

OnceIreachedthesecurewebsite,Ishutdownthebrowser,stoppedthenetworkcaptureonWiresharkandsavedtheresult.WhenyouopenthesavedfileinWireshark,youcanenter'SSL'asafilterandclickApply;thisshowsyoualltheTLSmessages.Itisalsopossibletofilterthemessagessothatyoujustseetheonesassociatedwithoneconversation.Thisiswhatisshowninthescreenshotsbelow.Wiresharkpresentstwodifferentviewsofeachmessage---oneinrawhex,andanotherthat'understands'theprotocol,andparsesthemessageintoitsvariousmeaningfulcomponents.Let'sgothroughthesemessagesonebyone:ClientHello.TheClientHellomessage(Figure1)sentfrommybrowsertotheserverincludes,amongotherthings,a4-bytetimestamp,a28-byterandomly-generatedvalueandalistoftwenty'ciphersuites',collectionsofcryptographicalgorithmsthatthebrowsersupports.Forinstance,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256meansEllipticCurveDiffieHellmanforestablishingthesymmetrickey,EllipticCurveDigitalSignatureAlgorithmforsignatures,AESwith128-bitkeysinGaloisCounterMode(that'sanewoneforme!)forsymmetricencryption,andSHA256forhashing.Wehaven'tyetestablishedthesecurechannel,sotheinformationinthismessageissentintheclear.YoucanseefromtheASCIItranslationofthehexdumpthatweareatwww-secure.target.com.The28-byterandomvaluewillbetakentogetherwiththe4-bytetimestampthatprecedesitaspartofthekeygenerationprocess,whichwe'lldescribelater.(IdonotknowwhythetimestampsaysthedateisMarch5,2022.IdidthisinNovember2014.)

Figure1:TheClientHellomessage,showingsomeofthesupportedciphersuites,the4-bytetimestamp,andthe28bytesofrandomdata

ServerHello.TheServerHellomessagecontainsa4-bytetimestamp(thistimewiththerightdate),anindependently-generatedrandom28-bytevalueandtheselectedciphersuite,whichisRSAforpublic-keyencryption,AES-256inCBCmodeforsymmetricencryption,andSHA-1forhashing.

Figure2:ServerHellomessage,showingthetimestamp,randomdata,andthechosenciphersuite.

Certificates.Thenextmessageconsistsofcertificatessentfromtheserver.Thethreecertificatesinthechainmatchtheonesreportedtousinthefriendlierviewfromthebrowser.(Figure4.)

Figure3:Thelistofcertificatessentbytheserver,asdisplayedinWireshark

Figure4:Asamelistofcertificates,viewedinthebrowser

ThepurposeofthecertificateistoshowthatthepublickeyinformationitcontainsreallydoesbelongtoTarget,andthuspreventaMan-in-the-MiddleattackinwhichwesendconfidentialinformationtoanattackerpretendingtobeTarget.Thisisaccomplishedbyhavingthecertificatebearthedigitalsignatureofatrustedauthority.Let'sdosomecryptographiccalculationsandindependentlyverifythelegitimacyofthecertificate.Thesitecertificate(theoneatthebottominthebrowserview,thefirstoneintheWiresharkview)containsthesignature.It'slabeledas'encrypted'inWireshark'sview,andas'Signature'inthebrowser'sview,whichiswhatweshowinFigure5.

Figure5:Thesignatureonthesitecertificate

Thepublickeyforverifyingthissignatureisonthenextcertificateinthechain,theonelabeled'ComodoExtendedValidationSecureServerCA2'.ThekeyconsistsofanRSAmodulusandexponent,whichhere,asiscustomary,is65537=216+1.To

Figure6:Thepublicverificationkeyofthesignerofthesitecertificate.Thiskeyisfoundonthesecondcertificateinthechain.

generatethePythoncodeshownbelow,Ijustcopiedthehexsignatureandmodulusfromthecertificates,removedtheblanks,convertedtolongintegers,andcalledPython'sbuilt-inpowfunctionformodularexponentiation.Youwouldn'tnoticeanythingspecialabouttheresultifyouprinteditindecimal,butwhenwelookatitinhex,weseethatitcontainsaboutagazillion(ok,about1700)1bitswithafewzerostackedoninfront,followedbytheinformationthe

signaturewasappliedto.Thisresultcouldnotpossiblyarisebychance,sowemusthavedonesomethingright!

Figure7:Verificationofthesignatureonthesitecertificate.ThesignatureisappliedtoanSHA1hashofthecertificate,withspecialcodeprependedtosaythatthisisanSHA-1hash,andthenpaddedoutwithalotof1's.

Evidently,thepayloadtobesignedispaddedoutwithallthose1sbeforetheRSAalgorithmisexecuted.Butwehavetodigdownabittofigureouthowtoreadthisandcompleteoursignatureverification.ThesignaturealgorithmisdescribedindetailintheInternetstandardsdocumentdefiningtheRSApublic-keysignaturestandard(forthecurious,it'sRFC3447,Section9.2).Thestepsforsigningare:

• Hashthemessagetobesigned,usingthehashalgorithmSHA1• prependthebytes30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14

• prependazerobyte• prepend218bytesFF(16721sinbinary)• prependaonebyte(01inhex,00000001inbinary)• prependazerobyte(00hex,00000000binary)• raisethistothepoweremodN,whereeisthepublicRSAexponentandNthemodulusof

thesigner'spublickey•

Sonowweknowthatthehashofthesigneddatashouldmatchthelast160bits(40hexdigits)oftheresultofourcalculation,namelyF418D08FB2D7EA2BA68F96157A405ED68704A554Butexactlywhichbytesofthecertificateisthehashappliedto?Obviously,itcan'tbetheentirecertificate,asthisincludesthesignatureitself.Fortunately,Wiresharkpointsthisouttousunder'signedcertificate'(Figure8).Thiscontainstheserialnumber,theexpirationdate,thenameandaddressoftheTargetcompany,andthepublickey,asitmust.Tofinishthesignatureverification,Iexportedtherawbytesofthesignedcertificateandusedthebuilt-inhashlibraryofPythontocomputetheSHA-1hash.Theresultmatchesthe160bitsweextractedearlier,sothesignatureisaccepted.

Figure8:Theportionofthecertificatethatishashedbeforethesignatureisapplied.TheSHA-1hashofthissequenceofbytesisequaltothe160-bitsstringwecomputedearlier,sothesignatureisverified.

That'senoughsignature-verifyingforthisdemo,butourbrowserisnotdoneverifying.Whyshouldweacceptthesignatureofthecertifyingauthority?Becauseitspublickey(onthesecondcertificateinthechain)issignedwiththepublickeyonthelastcertificate(therootcertificate).Therootcertificate,asitturnsout,is`self-signed':Youverifyitwiththepublickeyonthesamecertificate!Sowhyshouldwetrusttherootcertificate?TherootcertificateexactlymatchesoneofthecertificatesstoredinmyMac's'keychain'.Thisisasmalllistofcertifyingauthoritiesthatareconsideredtobetrustworthy.Shouldwebelievethat?Itseemstobeanaxiomincomputersecuritythatultimatelyyouhavetotrustsomebody.FinishingtheHandshake.Thenextprotocolmessage,sentfromtheclienttotheserverhasthreeparts,calledClientKeyExchange,ChangeCipherSpec,andEncryptedHandshake.Theclientgeneratesa48-bitstringcalledthepremastersecret.Thiswillbeusedbyboththeclientandservertogeneratethesymmetrickeysusedforthesecuredportionofthesession.TheClientKeyExchangesendstheservertheRSA-encryptedpremastersecret,a256-byte(2048-bit)value.Thisistheonlyplaceintheprocesswherepublic-keyencryptionisused.

Figure9:ClientKeyexchangemessage,showingRSA-encryptedpremastersecret.

Whatistheactualpremastersecret?Ofcourseitcannotbesentdirectlytotheserver;that'swhyit'sencrypted.ItdoesnotshowupintheseviewsinWireshark,andinfactisshouldnotbestored.ButChromeallowsyoutotakethepotentiallydangerousstep(presumablyfordebugging)ofloggingthesecretkeymaterial,sothiswhereweusethekeylogfile.DuringthesessionImonitored,alotofdifferentsecureconnectionsweremade,sothekeylogfilecontainsmorethan100entries.Butyoucanuseatoollikegreptosearchforanentryusingthefirstfewhexdigitsoftheencryptedsecret.Thisturnsupthefollowingentry:

Thefirstfieldgivesjustthefirst8bytesofthepre-mastersecret.Thesecondisthepremastersecretitself,a48-byte(96hexdigits)integergeneratedusingacryptographicallysecurerandomnumbergenerator.ItwouldbenicetodemonstratetheRSAencryptiontransformingthepremastersecretintotheencryptedversion.Wecangetthepublicencryptionkeyfromtheserver'scertificate,butrememberthatRSAplaintextsarealwayspaddedwithrandomdatapriortoencryption,andwecannotrecovertheserandombits.Ofcoursetheserver,whichhastheRSAprivatekey,candecryptthemessage,stripawaythepadding,andobtainthepremastersecret.(Intheblogpostcitedatthebeginningofthesenotes,thebloggerworkedwithadebugbuildoftheFirefoxbrowser:hewasabletoinsertdebugstatementsandcapturetherandompaddingdata,andthusindependentlyreproducetheRSAencryptionofthepremastersecret.)Thepremastersecretisusedtocomputesomethingcalledthemastersecret,a48-byteblockfromwhichthesymmetrickeyswillbederived.TheChangeCipherSpecmessageinformstheserverthat'everythingIsendyoufromnowonwillbeencrypted'.Finally,theclienthashesallofthehandshakemessagesthathavebeenexchangeduptothispoint,and'encrypts'this.Itisnotactualencryptionperse,butrathertheresultofapplyingthepseudo-randomfunction(seebelow)toaseedvaluederivedfromthemastersecretandthehashofthehandshakemessages.TheresultistheEncryptedHandshakeMessage.Theservershouldbeabletorepeatthiscomputationby(a)decryptingtheencryptedpremastersecret;(b)usingthistogeneratethemastersecret;(c)repeatingthecomputationoftheencryptedhandshakemessage.Thisservestoauthenticatethedatasentfromtheclientuptothispoint.Thenextmessagefromtheserveralsohas3parts,NewSessionTicket,ChangeCipherSpec,andEncryptedHandshakeMessage.Thefirstprovidesameansfortheclienttostartanewsessionwithoutafullhandshakeandkeyexchange,bypresentingthetickettotheserver.Wewillignorethis---noteveryTLSserverimplementsthisfeature.ChangeCipherSpecagaintells

RSA 1942f553cde7fda1 03037baa39916a8d8a15eff048ecf32c9b3b828bc288bea2383a2531328c4172428ebf1ddf1252a02bfb51b1ea728aa7

Figure10:Anentryfromthekeylogfile,showingthestartoftheRSA-encryptedpremastersecret,andthepremastersecretitself.

theclientthatallsubsequentmessageswillbeencrypted,andtheEncryptedHandshakeMessageusesthemastersecretandahashofalltheprecedinghandshakemessagestoderivearandomstring.ThisisdifferentfromtheEncryptedHandshakeMessagesentbytheclient,becausethehashincludesoneadditionalhandshakemessage.Onceagain,theclientcanverifythatthishasbeendonecorrectly.Theauthenticated,secureconnectionhasnowbeenestablished.Thehandshakeisover.Generatingthekeys,andencryptingapplicationdataThenextmessageweseefromWiresharkislabeledApplicationData,anditcontainsencryptedapplicationdatasentfromtheclienttotheserver(Figure11).BypointingWiresharktothekeylogfile,wecanseeitsdecryptedcontents(Figure12),anHTTPmessagebeginningwithGET /checkout_process?catalogId=10051&langId=-1....

Figure11:ThefirstmessagefromclienttoserverthatisencryptedwithAES---ciphertextview.

Figure12:..andplaintextview

Let'slookindetailatthestepstheserveratTargettakestodecrypttheencryptedapplicationdata.Wefirsthavetoknowhowthesymmetricencryptionkeyisgeneratedfromthepremastersecret.(ThedefinitivesourceforthisistheInternetStandardsdocumentRFC5246describingtheTLS1.2protocol.)Attheheartofthisprocessisthepseudo-randomfunction,whichisobtainedbyiteratingahash-basedmessageauthenticationcode(HMAC)basedontheSHA256hashfunction.TheuseofSHA256isaninnovationinTLS1.2---earlierversionsusedacombinationofMD5andSHA-1.ThePythoncodeinFigure13isanimplementationofthepseudo-randomfunction.TheHMACproducesdatain32-byteblocks.Byiteratingtheprocessenoughtimes,youcangetasmanypseudo-randombitsasyouwant.YoushouldbeawarethatthefirstthreeargumentstoPRFaresequencesofbytes,treatedasstrings.Thustheadditionoperatorthatappearsinthecodebelowisconcatenationofthesestrings,andnotadditionofnumbers.

Thepseudorandomfunctionisusedtogetherwiththe48-bytepremastersecretandtherandomdataexchangedinthehellomessagestogeneratethemastersecret.Thisisanother48-bytestring.Theclient_randomandserver_randomargumentsinthecodebeloware32byteslong:theyconsistofthe4-bytetimestampineachHellomessageconcatenatedwiththe28randombytes.Themastersecretisinturncombinedwiththe32-byterandomstringsfromtheHellomessagesusingthepseudo-randomfunctiontoproducethekeyblock.Thesizeandstructureofthekeyblockdependontheciphersuiteused.Inourexample,weareencryptingwithAES256inCBCmodeandusingtheSHA-1hashfunctionformessageauthentication.Thekeyblockinthiscaseconsistsoffourkeys:A20-bytekeyusedbytheclienttocomputeSHA-1-basedHMACauthenticationtags,followedbya20-bytekeyusedbytheserverforthesamepurpose,thena32-byte(256-bit)AESkeyusedbytheclientforencryptingdata(andtheserverfordecrypting),followedbyanother32-bitAESkeyusedbytheserverforencryptingandtheclientfordecrypting.(Notethatincontrasttothesetupwedescribedatthestartofthecourse,eachpartyusesonesymmetrickeyforencryptingandanotherfordecrypting.)ThecodeforcomputingthekeyblockisshowninFigure15.Inourexample,itisthethirdcomponentofthekeyblockthatisusedtoencryptdatafromtheclienttotheserver.Forwhatit'sworth,themastersecretisa7bb34756fd93a981a9e60469da3848cf409c0c9a65983bf8de61f5c3d2f4170a76fd77415a80bff20cf37eac6053d55andtheclientwritekeyis4d04afed676a500ca0f5088a7e887deb53fc69e54b88e5500dda732beda6c2fdThisconsistsof64hexdigits,thus32bytesor256bits.Finally,wesetthiskeyontheencryptedapplicationdataseeninFigure11,usingtheimplementationofAESinthepycryptopackage.Themessageis3920byteslong.SinceweareinCBCmode,thefirst16bytesistheinitializationvector,andtheremaining3904bytesconsistofciphertextforustodecrypt.Thedecryptedversion,also3904bytes,beginswiththeHTTPmessageshownaboveinFigure12.ThelastfewbytesofthedecryptedmessageareshowninFigure16(PythondisplaystheresultinASCII,withnon-printingcharactersarerenderedinhexprecededby`\x'.) Thesefinalbytesconsistofthebytevalue10(theASCIIencodingofthenewlinecharacter\n)repeated11times.Thisispaddingthatwasaddedtotheplaintexttomakeitconsistofawholenumberof16-byteblocks.Thetwentybytesprecedingthis,whicharemostlynonprintablecharacters,constitutetheMACtag.TheactualplaintextHTTPmessageendswiththecharacterspkyvprod1\r\n\r\n.Sothetrueplaintextis3904-20-11=3873byteslong:Thisiswhatis

displayedinFigure12.(Wewillnotreproducetheothersteptakenbytheserver,whichistoverifythe20-byteMACtag.)Summary.Theentireprocess,fromtheClientHellomessagetothetransmissionofthefirstencryptedapplicationdata,took0.24seconds.Let'srecapthecryptographicmethodswesawused:

• Securerandomnumbergenerationwasusedtoproducetheinitial28-byterandomblockssentbybothclientandserver,andtogeneratethepremastersecret.

• RSAdigitalsignatureswereusedtoauthenticatetheservertotheclient.Theclientverifiesthesignatureontheserver'scertificateusingthepublicverificationkeyonthecertificateauthority'scertificate.

• RSAencryptionwasusedbytheclienttoencryptthepremastersecretwiththeserver'spublickey,obtainedfromtheserver'scertificate.

• AESsymmetricencryption,with256-bitkeysand128-bitblocks,wasusedtosendencryptedHTTPmessagesbetweenclientandserver.

• Cryptographichashfunctionswereusedinthreedifferentplaces:aspartofthepseudo-randomfunction,tohashtheserver'scertificateforsigning/signatureverification,andtocomputeandverifytheMACtagontheencryptedmessage.

#We define the PRF as specified in the standard, except we add a fourth parameter #for the number of blocks to output. def prf(secret,label,seed,numblocks): seed=label+seed output = '' a=hmac.new(secret,msg=seed,digestmod=hashlib.sha256).digest() for j in range(numblocks): output += hmac.new(secret,msg=a+seed,digestmod=hashlib.sha256).digest() a=hmac.new(secret,msg=a,digestmod=hashlib.sha256).digest() return output

Figure13:ThepseudorandomfunctioninTLSv1.2.

#Compute the master secret from the premaster secret. #premaster_secret, client_random and server_random have string type, that #is they are sequences of bytes represented as strings, #so the addition in this code is concatenation of strings. #We want 48-bit output, so we need to call prf to produce two #32-bit blocks def master_secret(pms,client_random,server_random): out=prf(pms,"master secret",client_random+server_random,2) return out[:48]

Figure14:Computationofthemastersecretfromthepremastersecret.

#generate the key block. We will need 20+20+32+32=104 bytes, so we need #to generate 4 blocks and partition. We are just doing the case AES256CBC-SHA def keyblock(ms,client_random,server_random): u=prf(ms,"key expansion",server_random+client_random,4) return (u[:20],u[20:40],u[40:72],u[72:104])

Figure15:Computationofthekeyblockfromthemastersecret.

%3B%20s_sq%3Dtargetcomprod%252Ctargetusglobal%253D%252526pid%25253Dcheckout%2525253A%25252520view%25252520%25252526%25252520manage%25252520cart%252526pidt%25253D1%252526oid%25253Dhttp%2525253A%2525252F%2525252Fwww.target.com%2525252Fcheckout_process%252526ot%25253DA%3B; tgtakalb=pkyvprod1\r\n\r\n\xb9L&(\x95\x05`w\xc8\rY\xc6\x8fbH\xc1\x10\xd9\x8a\xc7\n\n\n\n\n\n\n\n\n\n\n

Figure16:Theendofthedecryptedapplicationdata.Thelast11bytesarepadding,andthe20bytesbeforethataretheMACtag.