SSL/TLS Handshake between Server and Client

-

In today's communication over the internet mostly servers and client communication are using secure communication and that's HTTPs not HTTP. To make this communication secure we use a protocol that is part of session layer (TCP OSI layer) TLS (Transport layer security) before a TCP session is initiated for data flow between a client and server TLS/SSL handshake is a must for HTTPs enabled servers. We will just discuss the type of SSL handshake without going into the details of its process. In SSL handshake process server and client can share their respective certificates (chain of certificates) signed by CA authorities or it can be signed locally (that communication will be only between trusted sources not for everyone over the internet. After receiving the certificate at client and server end respective nodes will verify the certificates either via root CA or via locally CA store certificates (if communication is only in between trusted parties). For a server to serve public users, it's a must that its chain certificates are signed by public trusted intermediates CA like DigiCert so certificate can be validated by client and communication can be enabled as client is now sure that's server is the right one.

 Hope so till now you will be able to get understanding of TLS/SSL importance in HTTPs communication. We have two type of SSL/TLS handshake.

1)One way SSL handshake

2)Two-way SSL handshake

One way SSL handshake

Mostly over the public internet to access a website/Application using a browser/SDK one way SSL handshake is used in that case only server present it certificate to the client and then client validated. Server present 3 certificates Root certificate, Intermediates certificate and server/leaf certificate it's a chain of certificates which is signed by using private key of root CA. When a client receives the certificate, it sees that trusted root certificate (private key) is used to sign the server certificate (chain of certificate/Intermediate and server/leaf), so it trusts the certificate and it get verified then client and server communication is enabled for the respective flow, in case provided chain of certificate is not validated clients drop the connection to the server.



Chain of Certificates


Wireshark output where we can see server CA is not validated and connection is drop by client.

Server root certificate is validated.


 2)Two-way SSL handshake

In two-way SSL handshake both client and server need to present its certificate, and both need to verify it and after that communication can be enabled. Mostly two-way SSL handshake is enabled between integrations of different organizations and not for the public client. Two-way SSL handshake can be enabled between SDK in mobile Apps but for that feature set should be enabled in the application as server will require the client certificate for the enablement of communication and if it's not provided server will drop the connection as client certificate verification is a must. In two-way SSL handshake both parties need to store the Certificate chain in its local certificate store so that can be present and validated during the SSL handshake. All three are must to be present and validated during the SSL handshake.

                                                Two way SSL handshake, Wireshark output


I am sure after reading this you need to do some more research how to get a signed certificate and what's it processes in another article i will discuss it. Application building is important but understanding the working beneath is also important to secure and improve the performance of your application/website and make the deployment ease. Tools which we can use to further explore the certificates and its validation is OPENSSL it's really helpful to convert the certificates into format supported in Load balancer or servers. 

Raja Shajeel Ahmad
Enterprise DC Engineer
Happy Learning
The limit is the sky.

Comments

Post a Comment

Popular posts from this blog

Flow with respect to Networks in AWS

-
Image
Flow with respect to Networks in AWS which need to be clear to expose any application on AWS and having some of services in on-premises. I will compare AWS services with on-prem technology, so it become ease to understand.                                                           Building Block of AWS Networking VPC: Consider it as a switch place in multiple Data center and all switches are connected with each other we can further have small subnets on it which can be part of all switches or only one depend upon the planning and requirements. Route Tables : Each subnet we create in VPC can have each route table or all subnets have one, Route table is used to control the routing of subnets and how traffic will be routed for any workload on the subnets. Route table can be attached to few other services of AWS as per requirements. NAT Gateway: I...
Read more

Important concepts in ACI Physical/Access polices Concepts

-
Image
I know Cisco ACI has been around for a long time. The first time I got into it was in 2021. It was not that hard to relate the legacy concepts with ACI but doing a job via CLI and doing it via GUI have a lot of differences. In this particular blog, I will discuss the key concepts without explaining the ACI core components like leaf switches, spine switches, and APIC. Cisco ACI is a policy-driven solution in which everything has an object assigned to it, and you need to connect all those dots to make your network work. In a legacy network, we have devices like bare metal servers, L2 switches, L3 switches, routers, and firewalls. We connect the networks using different protocols to make our network work, but sometimes there are physical requirements that need to be fulfilled to get the required topology. In Cisco ACI, we have all these kinds of devices, and they are connected to our fabric. However, in ACI, we have a term called "domains," which include four different types: Ph...
Read more

1 sec and Team work Story

-
Image
 I n the world of IT, a single second can be the difference between success and failure. Recently, I experienced this firsthand when a 1-second delay caused a critical application flow to shut down. Through intense troubleshooting, collaboration, and respect for diverse opinions, we identified and resolved the issue. This experience taught me the importance of: - Active listening among all stakeholders - Exploring all options and possibilities - Embracing the value of diverse perspectives - The power of collaboration and teamwork - The crucial role of TCP dumps in troubleshooting In IT, every problem requires a unique solution, and collaboration is key to finding it. Delay we Observe at Client end server end had no delay though Raja Shajeel Ahmad Enterprise DC Engineer Happy Learning The limit is the sky. #TeamWork#TCPDump#HappyLearning
Read more