ºÝºÝߣ

ºÝºÝߣShare a Scribd company logo

SSL-image

•Download as DOCX, PDF•
•
Rajat Toshniwal
Rajat Toshniwal

SSL handshake involves the following steps: 1. The client sends a client hello with SSL version, random data, session ID, and cipher details. 2. The server responds with a server hello containing SSL version, random data, session ID, cipher, and certificate. It may also request client authentication. 3. If requested, the client sends its certificate and generates a premaster secret to establish encrypted communication.

1 of 4
In this blog i will try to highlight the basic functionality of SSL handshake. ï‚· SSL Secure Socket Layer is most widely deployed security protocol now a days. ï‚· Originated by Netscape. ï‚· This protocol works at application layer that is above transport layer TCP protocols. It is independent protocol which means it can be used with any protocol in application layer. Without discussing much theory, let's first check the steps involved in SSL handshake As we all know the connection is always initiated by client eg. Web browser. First request is of client-hello where client sends the following details SSL version : Where client sends the list of versions it supports to the server. Random data number : This is used along with random number generated by server in order to produce the premaster key. SessionID : To shorten the handshake process, whenever the connection between the two happens again, it stores all the required cryptographic parameter negotiated in the original connection making. Cipher : Cipher algorithm supported or used by both serverand client in order to perform encryption and decryption. Eg DES Compression : Compression algorithm details, if used. Clienthello ServerHello+Certificates+ClientCertificate request ClientCertificate +pre-masterkey+Finished Finished DATA Client Server
NextpacketisServerHellowhichissentbyserver. SSL version: Out of the versionlistprovidedby clientabove, serverselectsthe versionwhich is supportedby server also. Ifthere are multiple versionssupportedbyboth client and serverthan the highestwill be selected. Random Data : As mentionedabove this will be requiredbyclientin order to generate premaster key. SessionID : To shorten the handshake process. Cipher: Similar to discussedabove. Along withthat, serveralso sendsa certificate. Certificate:It can be selfsignedor signedby certificate authorities.If it is self signedor your browser doesnot recognize the certificate authority, inthat case you will get a warning page on browser from where you can accept or reject the certificate. Certificate authoritiesare third party entitieswhichsignedand verify the certificates. Certificate generallycomprisesof company and locationdetails.It also comprisesofpublic key requiredfor initial clientkeyexchange. Besidesthat there are otherfieldsalso whichare seldomused. ClientCertificate request:Where the serversendsthe requestto clientto send its certificate details also. If required. ServerHelloDone : Last message in the sequence tosignifythat server has done and iswaiting for clientresponse. Response fromClient: Clientusesthe above informationto authenticate the serverand check whethersecure connection can be establishedwithabove negotiatedalgorithms. If not then it generatesthe error/warning. If successthen it proceeds. ClientCertificate :As discussedabove ifit is asked by the serverthen clientsendsits certificate back to server . Clientalso sendthe SSL versiondetailsagain so that servercan again cross-verifyit,generallyto avoid attacks. Clientalso generatesthe premasterkey from the random number generatedby both clientand server and then encrypts thiskey with the public keyobtained from certificate and sendit to server. ServerSide
If the serverhas requestedforauthentication also thenit validatesthe clientauthenticationalso, If the authenticationfails,serverterminatesthe connection.If the clientcan be authenticated successfullythenthe server usesits private key to decrypt the premasterkey and start a processof generatingmaster secret. Both the clientand server use the master secretto generate sessionkeyswhichare symmetric keys usedto encryptand decrypt the informationexchangedduring this session. Both clientandserversendsthe handshake finishpacketatthe end. SSL Protocol It isa fourlayerprotocol SSL Handshake protocol SSL RecordLayer Protocol SSL Change CipherProtocol SSL alertprotocol Stack ismentionedbelow SSL RECORDPROTOCOL:This providestwoservices HTTP SSL ALERT SSL CHANGESSL HANDSHAKE PROTOCOL CIPHER PROTOCOL SSL RECORD PROTOCOL TCP IP
a) Confidentiality:Encryption b)Integrity:Message authenticationcode MAC a) Dividesthe applicationdataintofragments of manageableblocksof notmore than2^14 i.e 16384 bytesor less. b) Blocksare thenoptionallycompressedwhichmustbe losslessandmaynotincrease the content lengthbymore than 1024 bytes. c)MAC isthencomputedovercompresseddatausing sharedsecretkey.Thisisthenappliedto compressedblock. d) Compressedmessage +MAC are thenencryptedusingsymmetricencryption.Againencryptionmay not increase the lengthbymore than1024 bytes.Somaximumfragment size will notbe more than (16384 + 1024 + 1024 ) bytes. HeaderFormation Contenttype (8 bits) : Nextlayerprotocol toprocessthe enclosedfragment. Major Version(8bits) : SSL majorversioninuse. Minor Version(8bits) :SSL minorversioninuse. CompressedLength(16bits) : lengthinbytesof compressedfragment. Change Cipher Spec Protocol The change cipherspecprotocol isusedto change the encryptionbeingusedbythe clientandserver.It isnormallyusedaspart of the handshake process toswitchto symmetrickeyencryption.The CCS protocol isa single messagewhichisencryptedandcompressedunderthe currentCipherSpec.The message consistsof asingle byte of value 1 that tellsthe peerthatthe senderwantstochange to a new setof keys,whichare thencreatedfrominformationexchangedbythe handshake protocol. Alert Protocol One of the contenttypessupportedbythe SSLrecord layeristhe alerttype. It consistsof twobytesthe firstof whichtakesthe values1(warning),2(fatal). Alertmessagesconveythe severityof the message and a descriptionof the alert. Alertmessageswithalevel of fatal resultinthe immediate terminationof the connection. Inthiscase, otherconnectionscorrespondingtothe sessionmaycontinue,butthe sessionidentifiermustbe invalidated,preventingthe failedsession frombeingusedtoestablishnew connections. Like othermessages, alertmessagesare encryptedandcompressed,asspecifiedbythe currentconnectionstate.

More Related Content

SSL-image

  • 1. In this blog i will try to highlight the basic functionality of SSL handshake. ï‚· SSL Secure Socket Layer is most widely deployed security protocol now a days. ï‚· Originated by Netscape. ï‚· This protocol works at application layer that is above transport layer TCP protocols. It is independent protocol which means it can be used with any protocol in application layer. Without discussing much theory, let's first check the steps involved in SSL handshake As we all know the connection is always initiated by client eg. Web browser. First request is of client-hello where client sends the following details SSL version : Where client sends the list of versions it supports to the server. Random data number : This is used along with random number generated by server in order to produce the premaster key. SessionID : To shorten the handshake process, whenever the connection between the two happens again, it stores all the required cryptographic parameter negotiated in the original connection making. Cipher : Cipher algorithm supported or used by both serverand client in order to perform encryption and decryption. Eg DES Compression : Compression algorithm details, if used. Clienthello ServerHello+Certificates+ClientCertificate request ClientCertificate +pre-masterkey+Finished Finished DATA Client Server
  • 2. NextpacketisServerHellowhichissentbyserver. SSL version: Out of the versionlistprovidedby clientabove, serverselectsthe versionwhich is supportedby server also. Ifthere are multiple versionssupportedbyboth client and serverthan the highestwill be selected. Random Data : As mentionedabove this will be requiredbyclientin order to generate premaster key. SessionID : To shorten the handshake process. Cipher: Similar to discussedabove. Along withthat, serveralso sendsa certificate. Certificate:It can be selfsignedor signedby certificate authorities.If it is self signedor your browser doesnot recognize the certificate authority, inthat case you will get a warning page on browser from where you can accept or reject the certificate. Certificate authoritiesare third party entitieswhichsignedand verify the certificates. Certificate generallycomprisesof company and locationdetails.It also comprisesofpublic key requiredfor initial clientkeyexchange. Besidesthat there are otherfieldsalso whichare seldomused. ClientCertificate request:Where the serversendsthe requestto clientto send its certificate details also. If required. ServerHelloDone : Last message in the sequence tosignifythat server has done and iswaiting for clientresponse. Response fromClient: Clientusesthe above informationto authenticate the serverand check whethersecure connection can be establishedwithabove negotiatedalgorithms. If not then it generatesthe error/warning. If successthen it proceeds. ClientCertificate :As discussedabove ifit is asked by the serverthen clientsendsits certificate back to server . Clientalso sendthe SSL versiondetailsagain so that servercan again cross-verifyit,generallyto avoid attacks. Clientalso generatesthe premasterkey from the random number generatedby both clientand server and then encrypts thiskey with the public keyobtained from certificate and sendit to server. ServerSide
  • 3. If the serverhas requestedforauthentication also thenit validatesthe clientauthenticationalso, If the authenticationfails,serverterminatesthe connection.If the clientcan be authenticated successfullythenthe server usesits private key to decrypt the premasterkey and start a processof generatingmaster secret. Both the clientand server use the master secretto generate sessionkeyswhichare symmetric keys usedto encryptand decrypt the informationexchangedduring this session. Both clientandserversendsthe handshake finishpacketatthe end. SSL Protocol It isa fourlayerprotocol SSL Handshake protocol SSL RecordLayer Protocol SSL Change CipherProtocol SSL alertprotocol Stack ismentionedbelow SSL RECORDPROTOCOL:This providestwoservices HTTP SSL ALERT SSL CHANGESSL HANDSHAKE PROTOCOL CIPHER PROTOCOL SSL RECORD PROTOCOL TCP IP
  • 4. a) Confidentiality:Encryption b)Integrity:Message authenticationcode MAC a) Dividesthe applicationdataintofragments of manageableblocksof notmore than2^14 i.e 16384 bytesor less. b) Blocksare thenoptionallycompressedwhichmustbe losslessandmaynotincrease the content lengthbymore than 1024 bytes. c)MAC isthencomputedovercompresseddatausing sharedsecretkey.Thisisthenappliedto compressedblock. d) Compressedmessage +MAC are thenencryptedusingsymmetricencryption.Againencryptionmay not increase the lengthbymore than1024 bytes.Somaximumfragment size will notbe more than (16384 + 1024 + 1024 ) bytes. HeaderFormation Contenttype (8 bits) : Nextlayerprotocol toprocessthe enclosedfragment. Major Version(8bits) : SSL majorversioninuse. Minor Version(8bits) :SSL minorversioninuse. CompressedLength(16bits) : lengthinbytesof compressedfragment. Change Cipher Spec Protocol The change cipherspecprotocol isusedto change the encryptionbeingusedbythe clientandserver.It isnormallyusedaspart of the handshake process toswitchto symmetrickeyencryption.The CCS protocol isa single messagewhichisencryptedandcompressedunderthe currentCipherSpec.The message consistsof asingle byte of value 1 that tellsthe peerthatthe senderwantstochange to a new setof keys,whichare thencreatedfrominformationexchangedbythe handshake protocol. Alert Protocol One of the contenttypessupportedbythe SSLrecord layeristhe alerttype. It consistsof twobytesthe firstof whichtakesthe values1(warning),2(fatal). Alertmessagesconveythe severityof the message and a descriptionof the alert. Alertmessageswithalevel of fatal resultinthe immediate terminationof the connection. Inthiscase, otherconnectionscorrespondingtothe sessionmaycontinue,butthe sessionidentifiermustbe invalidated,preventingthe failedsession frombeingusedtoestablishnew connections. Like othermessages, alertmessagesare encryptedandcompressed,asspecifiedbythe currentconnectionstate.