SSL Handshake

 

Let's Learn about SSL  Handshake which is very good topic

What is SSL ? SSL ⇒ Secure Socket Layer SSL is designed to provide security and compression services to data generated from the application layer So, SSL provide security to the data that is transferred between web browser and server SSL encrypt the link between a web server and a browser which ensures that all data passed between them remain private and free from attack. Secure Socket Layer Protocols: SSL record protocol Handshake protocol Change-cipher spec protocol Alert protocol Some Keypoints on SSL ⇒ The internet and web has become widely popular today. However, it is vulnerable to serious attacks. For this purpose, various security approaches are possible. These approaches are mainly dependent on which network layer they operate on The SSL (Secure Socket Layer) is a whole new layer of protocol which operates above the Internet TCP protocol and below high-level application protocols There are different protocols which are associated with SSL which are used in the management of SSL exchanges. One among those is SSL handshake protocol. SSL Handshake Protocol It is one the most complex protocols of SSL. It allows client and server to: Authenticate each other To negotiate encryption & MAC algorithm. To negotiate cryptographic keys to be used. The Handshake Protocol is used before any application data is transmitted. The handshake protocol is made up of a series of messages exchanged between both parties (server & client) which is of the format These messages are communicated as a series of messages in phases (4 phases) The reason it's called handshake because it's between two partied - client and server come across each other for the first time The handshake involves a number of steps that start from validating the identity of the other party and concludes with the generation of a common key – secret key if you may call it. So, the SSL handshake is nothing but a conversation between two parties (client and server) wanting to accomplish the same purpose – securing the communication with the help of symmetric encryption.   Imagine this SSL Handshake Process as a dialog between the two.   Let’s see how it goes.   Client: “Hello there. I want to establish secure communication between the two of us. Here are my cipher suits and compatible SSL/TLS version.”   Server: “Hello Client. I have checked your cipher suits and SSL/TLS version. I think we’re good to go ahead. Here are my certificate file and my public key. Check ‘em out.”   Client: “Let me verify your certificate. (After a while) Okay, it seems fine, but I need to verify your private key. What I’ll do is, I will generate and encrypt a pre-master (shared secret key) key using your public key. Decrypt it using your private key and we’ll use thing master key to encrypt and decrypt the information”   Server: “Done.” [Now that both the parties know who they’re talking to, the information transferred between them will be secured using the master-key. Keep in mind that once the verification part is over, the encryption takes place through the master-key only. This is symmetric encryption.]   Client: “I’m sending you this sample message to verify that our master-key works. Send me the decrypted version of this message. If it works, our data is in safe hands.”   Server: “Yeah, it works. I think we’ve accomplished what we were looking for.”

SSL Related ATTACKS ⇒ SSL Stripping Attacks Man-in-the-Middle (MITM) Attacks Self-Signed and Wildcard Certificates Unknown, Untrusted, and Forged Certificate Authorities Attacker Encrypted Communications Expired SSL/TLS Certificates Phishing Scams POODLE Attack Padding Oracle On Downgraded Legacy Encryption (POODLE) BEAST Browser Exploit Against SSL/TLS (BEAST) CRIME (CVE-2012-4929) Compression Ratio Info-leak Made Easy (CRIME) BREACH rowser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) Heartbleed SSL-based DDOS Attacks SSL Flood Attacks SSL Renegotiation Attack SSL Hijacking

TLS TLS ⇒ Transport Layer Security It is an IETF standardization initiative whose goal is to come out with an Internet standard Version of SSL IETF ⇒ Internet Engineering Task Force Core idea between SSL and TLS is quite similar TLS ⇒ a protocol that ⇒ ensures privacy between communicating applications and their users on the internet When a server and client communicate, TLS ensures that no third party may eavesdrop or tamper with any message TLS is successor to the SSL [Secure Socket Layer] TLP Protocol ⇒ based on the Netscape's SSL 3.1 protocol however TLS and SSL are not interoperable TLS Protocol does contain a mechanism that allows TLS Implementation to back down to SSL 3.1. TLS version 1.0 actually began development as SSL version 3.1 The most recent browser versions support TLS TLS ⇒ composed of 2 Layers ⇒ TLS Record Protocol TLS Handshake Protocol TLS vs HTTPS HTTPS is an implementation of TLS encryption on top of the HTTP protocol which is used by all websites as well as some other web services Any website that uses HTTPS is therefore employing TLS encryption. What does TLS do? There are three main components to what the TLS protocol accomplishes: Encryption, Authentication, and Integrity. Encryption: hides the data being transferred from third parties. Authentication: ensures that the parties exchanging information are who they claim to be. Integrity: verifies that the data has not been forged or tampered with. Raccoon Attack The Raccoon attack is a newly discovered vulnerability in TLS 1.2 and earlier versions. It allows hackers (in certain situations) to determine a shared session key and use that to decrypt TLS communications between the server and client. The attack doesn’t allow a hacker to obtain the private key, so they’d have to perform the attack individually on each connection they want to eavesdrop on. In order to execute the Raccoon Attack, a hacker needs several conditions in place: Successfully setup a man-in-the-middle attack to intercept communications Connection must use TLS 1.2 or previous (but we’ve all disabled SSL 3.0, TLS 1.0, and TLS 1.1 already…right?) Connection must use Diffie-Hellman key exchange Server must re-use Diffie-Hellman public keys The attacker needs to be near the target server in order to run precise timing measurements