- Overview
- History
- Client Hello
- Server Hello
- Certificate
- Server Key Exchange
- Server Hello Done
- Client Key Exchange
- Change Cipher Spec
- Finished
- Change Cipher Spec
- Finished
- Conclusion and References
- Contact Me
- References
- Recent Blog Post
Overview
If you have ever browsed an HTTPS URL through a browser, you have experienced the SSL handshake. Even though might not notice it, the browser and the website is creating an HTTPS connection using a one-way SSL handshake.
The main purpose of an SSL handshake is to provide privacy and data integrity for communication between a server and a client. During the Handshake, the server and client will exchange important information required to establish a secure connection.
There are two types of SSL handshakes described as one-way SSL and two-way SSL (Mutual SSL). The difference between those two is that in one-way SSL, only the client validates the identity of the server whereas in two-way SSL, both server and client validate the identity of each other. Usually, when we browse an HTTPS website, one-way SSL is used where only our browser (client) validates the identity of the website (server). Two-way SSL is mostly used in server-to-server communication where both parties need to validate the identity of each other.
During an SSL handshake, the server and the client follow the below set of steps.
History
The Secure Sockets Layer (SSL) protocol was first introduced by Netscape in 1994. The Internet was growing and there was a need for transport security for web browsers and for various TCP protocols. Version 1.0 of SSL was never released because it had serious security flaws. The first official release of SSL, version 2.0, was out in 1995. The final version of the SSL protocol, SSL 3.0, was released in November 1996.
In 2011, the Internet Engineering Task Force (IETF) announced that SSL version 2.0 is deprecated. IETF recommended SSL v2 to be completely abandoned because according to a document that they released (RFC 6176) the protocol has several major deficiencies. These included using MD5 for message authentication, lack of protection for handshakes, using the same key for message integrity and encryption, and easy session termination. In June 2015, IETF also announced that SSL 3.0 is deprecated. As stated in a document released by IETF (RFC 7568), any TLS version is more secure than all versions of SSL. SSL also cannot use features of the TLS protocol such as Authenticated Encryption with Additional Data (AEAD), Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA), stateless session tickets, a datagram mode of operation (DTLS) and application-layer protocol negotiation.
The current version of TLS, TLS 1.3, was released in August 2018 (RFC 8446). It took IETF 10 years and 28 drafts to complete. This time, the protocol underwent some major changes with the focus on simplicity. Several unsafe technologies were removed, including SHA-1, MD5, RC4, DES, and 3DES. The protocol was streamlined for better performance: the handshake now requires only one round-trip (in some cases even zero). Other changes include encryption of SNI information for better privacy and a new signature standard (RSA-PSS). All modern browsers support TLS v1.3.
Now that we've traversed the rich history of SSL/TLS, let's shift our focus to a more granular exploration. Join me as we delve into the anatomy of SSL handshake messages, dissecting each step to uncover the inner workings of secure communication. Buckle up for a journey through the nuances of the SSL/TLS handshake process, where every message contributes to the robust framework of online security. It's time to decode the language of secure connections and empower ourselves with a comprehensive understanding of SSL/TLS handshake messages.
Client Hello
The client will send the information that will be required by the server to start an HTTPS connection.
- The first message is called the “ClientHello.”
- This message lists the client’s capabilities so that the server can pick the cipher suite that the two will use to communicate.
- It also includes a large, randomly picked prime number called a “client random.”
- The ClientHello message is always the first message sent in a new handshake. It’s used to communicate client capabilities and preferences to the server.
- Clients send this message at the beginning of a new connection, when they wish to renegotiate, or in response to a server’s renegotiation request (indicated by a HelloRequest message).
Server Hello
- The server politely responds with a “SeverHello” message. In this message it tells the client what connection parameters it has selected from the provided list and returns its own randomly selected prime number called a “server random.”
- If the client and server do not share any capabilities in common, the connection terminates. Server Hello will be as follows.
Certificate
- In the “Certificate” message, the Server sends its SSL certificate chain (which includes its leaf certificate and intermediate certificates) to the client.
- To provide authentication to the connection an SSL certificate is signed by a CA, which allows the client to verify that the certificate is legitimate.
- Upon receipt, the client performs several checks to authenticate the certificate. This includes checking the certificate’s digital signature, verifying the certificate chain, and checking for any other potential problems with the certificate data (expired certificate, wrong domain name, etc).
- The client will also make sure the server has possession of the certificate’s private key. This is done during the key exchange/generation process.
** Certificate chain
chain [0] = [
[
Version: V3
Subject: CN=server, OU=ID, O=IBM, L=Hursley, ST=Hants, C=GB
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
Key: Sun RSA public key, 2048 bits
modulus: 17397562757879783124811507432494159361243533796048391161052829821122241422546147907779583980536886743765496985274573369668302996974964349098220930856827026983442125212118340479175872257401994146576001849503528844021528618702289642320157895787705650513758990004411195572445830613057931701313142946380207623174021376881040589912594451781207558263630010509870784494298596448861811827669869221033031956053367890915692918086795954628465637743034777850129818069833958463245749899713073673871721233098662285260745282530972322499603703844901496085490388703767606182211892402117158287170480970610942364235511256363933850852797
public exponent: 65537
Validity: [From: Sat Jul 28 09:08:48 IST 2018,
To: Sun Jul 28 09:08:48 IST 2019]
Issuer: CN=server, OU=ID, O=IBM, L=Hursley, ST=Hants, C=GB
SerialNumber: [ 7d834874]
Certificate Extensions: 1
[1]: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: C7 24 EA C3 1E 3E 58 8E BD E3 AE A9 17 01 00 51 .$…>X……..Q
0010: B0 83 D4 68 …h
]
]
]
Algorithm: [SHA256withRSA]
Signature:
0000: 4B FA 93 D8 56 78 05 D8 89 BC 2A 3A B6 C3 7F A5 K…Vx….*:….
0010: 03 D8 56 3B E6 9F 0B 17 B5 A2 61 AE 43 46 A4 85 ..V;……a.CF..
0020: 3F 60 2E 04 41 0D C2 7A 35 0D 56 F5 FE 9D 05 51 ?`..A..z5.V….Q
0030: 4A 0B BB 5B 30 ED 85 AF 1C 95 13 15 7D A0 2C DE J..[0………,.
0040: B4 A1 7A D0 5D E4 C0 91 37 C2 ED 37 39 65 7D 02 ..z.]…7..79e..
0050: B5 A4 72 FF EB 6C D5 F4 FD BC 32 FD 9F C8 3A 49 ..r..l….2…:I
0060: 53 64 F8 C6 A0 D6 DB 89 2C 36 60 97 8B 33 8F 95 Sd……,6`..3..
0070: 18 9C 1A F2 F8 F1 66 5E F3 0B 76 54 08 AB A9 88 ……f^..vT….
0080: 5D E9 2D 6B AE 6D 98 09 57 A0 2A 9E C6 6B 89 53 ].-k.m..W.*..k.S
0090: 8E B3 58 C3 8D 73 C5 D3 58 2F 68 F0 4E 0A EF 29 ..X..s..X/h.N..)
00A0: 54 95 00 34 6A C4 D2 56 22 64 05 F9 9F A4 81 44 T..4j..V"d…..D
00B0: 44 77 95 A7 86 5A D3 EE EA 8E 06 19 ED 94 F1 83 Dw…Z……….
00C0: F4 A1 F4 A0 76 94 02 40 30 C0 95 6A F2 4F 32 BB ….v..@0..j.O2.
00D0: 79 A2 1B 40 F5 EB 37 5B B7 0C FA 18 DE 04 18 7D y..@..7[……..
00E0: 5A 1A 95 D7 E7 00 4C 7F 3C 71 CE 8E 03 07 BD 50 Z…..L.<q…..P
00F0: 6D 49 52 75 66 D2 CA 45 AB B8 EE B1 C2 C9 72 8A mIRuf..E……r.
]
***
Server Key Exchange
- This is an optional message, only needed for certain key exchange methods (Diffie-Hellman) that require the server provides additional data.
*** ECDH ServerKeyExchange
Signature Algorithm SHA256withRSA
Server key: Sun EC public key, 256 bits
public x coord: 49880139518100326927648337356136531406906846853753693344570844017045565963249
public y coord: 95714017526253024568876509155195989984116809887282783483716821451591048546410
parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)
Server Hello Done
- The “Server Hello Done” message tells the client that it has sent over all its messages.
Client Key Exchange
This message needs to be sent by the client following the Client Certificate message. If the client certificate is not being presented (in one-way SSL), the client key exchange message should be sent after the client receives the ServerHelloDone message.
As we all know the data transferred between the server and the client in an HTTPS connection will be encrypted. Symmetric encryption[7] is being used for this purpose as the computational cost is much lower than Asymmetric encryption. In order to use symmetric encryption, there needs to be a common key between the two ends. The purpose of this message is to generate that common key between that client and the server without exposing to an outsider.
There are two client key exchange methods described in the TLS v1.2 spec. They are RSA[8] and Diffie-Hellman.
If RSA is used as the key exchange algorithm, the client generates a 48-byte pre-master secret. The client encrypts the pre-master secret by the public key of the certificate and sends to the server. Only the server will have the corresponding private key to decrypt and get the client generated pre-master secret.
If Diffie-Hellman is used, the Diffie-Hellman parameters are transmitted to allow both client and server to generate the same pre-master secret.
After that, both sides will generate a master secret using the pre-master secret and the master secret will be used to generate the symmetric key for encrypting the session data
Change Cipher Spec
- The “Change Cipher Spec” message lets the other party know that it has generated the session key and is going to switch to encrypted communication.
Finished
- The “Finished” message is then sent to indicate that the handshake is complete on the client side. The Finished message is encrypted, and is the first data protected by the session key. The message contains data (MAC) that allows each party to make sure the handshake was not tampered with.
Change Cipher Spec
- Now it’s the server’s turn to do the same. It decrypts the pre-master secret and computes the session key. Then it sends its “Change Cipher Spec” message to indicate it is switching to encrypted communication.
Finished
- The server sends its “Finished” message using the symmetric session key it just generated, it also performs the same check-sum to verify the integrity of the handshake. ...
Conclusion
we've embarked on a journey through the intricate landscape of SSL/TLS handshake messages, unraveling the complexities that underpin secure Internet communication. From the initial ClientHello to the conclusive Finished messages, each handshake step plays a pivotal role in establishing a secure connection between clients and servers.
Understanding these messages not only provides insight into the robust security mechanisms employed by SSL/TLS protocols but also empowers developers and cybersecurity enthusiasts to make informed decisions in implementing and optimizing secure communication.
As we navigate the digital realm, the SSL/TLS handshake stands as a guardian, ensuring that our data remains confidential, integral, and secure. The handshake's dance may seem complex, but its significance in fortifying the foundations of online security cannot be overstated.
For those eager to delve deeper into the world of SSL/TLS or explore related topics, references abound. Feel free to continue the exploration, building upon the knowledge gained here to bolster your understanding of cybersecurity essentials.
Thank you for joining me on this journey through the SSL/TLS handshake. As technology evolves, so does the importance of robust security practices. May your future endeavors in the digital landscape be secure and your connections always encrypted.
Contact Me
- LinkedIn: Pavankumar Hegde
- GitHub: Pavankumar Hegde
Feel free to reach out for collaborations, questions, or just to say hello!
References
Recent Blog Post
Happy reading and exploring the fascinating world of cybersecurity and technology!😎👍
Top comments (0)