If we use web browsers to browse the websites, we don’t need to know how SSL/TLS handshake works. All have been taken care behind the scene. But if as application developers, we might need to know more about how it works sometimes.

There are many excellent articles, for example [1, 2, 3], about how SSL/TLS handshake works. The screenshot below is from [3]

ssl tls handshake process - how does tls work

The key takeaway is that client and server exchange information at initial contact, client verifies the server certificate, and then client and server agree upon how to communicate on further web requests after this handshake is done.

As I mentioned above, if we use web browsers to browse the websites, we don’t need to know how SSL/TLS handshake works. As developers, we usually don’t program again SSL/TLS handshake and TCP/IP directly either. We usually use SDK to interact with servers / APIs. Most of web servers / APIs exposed nowadays are protected with https (SSL/TLS). So the SDK behaves like the client above in the screenshot, it must know how to communicate and negotiate with web servers / APIs over the handshake.

Here is the problem coming in. Depending on the technology currency of SDK we use, it might not negotiate correctly with APIs over the handshake. Depending on what phases of handshake the negotiation is at (the phases are in screenshot above), we might see different error messages. So we have to:

1. Upgrade the SDK if there is a higher version of SDK solving the issue, or

2. Get hands dirty by developing walk-arounds (/headaches).

References:

  1. https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/
  2. https://www.websecurity.digicert.com/security-topics/how-does-ssl-handshake-work
  3. https://cheapsslsecurity.com/blog/what-is-ssl-tls-handshake-understand-the-process-in-just-3-minutes/