Table of contents of the article:
When it comes to the security of internet communications, the two acronyms that come up most often are SSL and TLS . They've become so familiar that they even appear in browsers with the little padlock icon next to the web address, a now universal symbol of a secure connection. But what are they really? And above all, what implementations exist behind the scenes to ensure our data can't be intercepted by prying eyes?
To understand this, it's worth taking a step back. SSL (Secure Sockets Layer) was developed in the 90s by Netscape, with the aim of creating an encrypted channel between client and server to protect passwords, credit card numbers, and any private information exchanged online. The first versions of SSL were pioneering but not without flaws, so much so that in the late 90s, the decision was made to move forward with a more robust standard called TLS (Transport Layer Security) . TLS can be considered the natural successor to SSL, so much so that today, when we say "SSL," we almost always mean TLS, even though the original SSL protocols have long been considered insecure and deprecated.
TLS is based on a set of cryptographic primitives: encryption algorithms, hash functions, elliptic curves (RSA) for key exchange, and handshake protocols for negotiating a secure session. It's a layer that sits above TCP and below the applications: whether HTTPS, IMAPS, or SMTP with STARTTLS, everything works according to the same principle: establishing an encrypted and authenticated channel between two communication endpoints.
So much for theory. But how does it work in practice? Who implements all this? This is where the software libraries that implement TLS come into play, namely the cryptographic engines used by web servers, operating systems, browsers, and embedded devices. The landscape is diverse and reflects different needs: performance, portability, security, ease of use, and compatibility with local regulations. Some libraries were born as forks of existing projects, others as radical alternatives, and still others as responses to sensational vulnerabilities that have shaken confidence in the standards.
In this article, we'll delve into the most important implementations: OpenSSL , the mother of all, and its most famous forks like LibreSSL , BoringSSL, and BabaSSL . We'll then look at independently developed solutions like WolfSSL , designed for the IoT, GnuTLS , an expression of the GNU world, and NSS , Mozilla's historic library. Each of these has a history, a context of use, and strengths that have made it suitable for certain scenarios.
How does SSL work in theory, in broad terms?
Imagine having to talk to a friend across a room full of curious people. You don't want anyone to understand what you're saying, so you need a way to encode your messages . However, you can't simply say your "secret word" out loud, because someone might hear it and use it against you. So you devise a method: you first exchange a few coded phrases that allow you both to arrive, without anyone else noticing, at a common key known only to the two of you. Once you've found this key, you can speak freely from then on: anyone listening will only hear a set of incomprehensible sounds.
This is exactly what SSL/TLS does : it establishes a secure channel between two parties (typically a browser and a web server) through an initial negotiation process called a handshake , and then protects the data exchange with encryption and integrity checks.
The TLS handshake explained step by step
Behind the scenes, the protocol follows a well-defined sequence. We can summarize it in broad phases:
-
ClientHello : The client (e.g., browser) sends a message to the server with the list of TLS versions it supports, the available cipher suites (sets of algorithms), and a random number (nonce) that will be used in key generation.
-
ServerHello : The server responds by choosing a TLS version and cipher suite compatible with those proposed by the client. It then sends a nonce and, importantly, the X.509 digital certificate proving its identity.
-
Certificate verification : The client verifies that the certificate is valid, signed by a recognized certification authority, and not revoked. This is the step that tells us, "Yes, I'm really talking to example.com and not an impostor."
-
Key exchange : This is where asymmetric cryptography comes into play. Using RSA, ECDHE, or other algorithms, clients and servers collaborate to generate a symmetric session key . Importantly, this key is never transmitted in the clear: it is derived from mathematical calculations based on the exchanged nonces and cryptographic parameters.
-
Confirmation : Once the key is derived, the client and server send each other encrypted messages to prove that they have the same key.
-
Secure session : From now on, all data travels encrypted with symmetric algorithms (for example AES or ChaCha20), which are much faster to calculate.
The theoretical pillars: confidentiality, integrity, authenticity
SSL/TLS is not just an encryption protocol, but a set of safeguards.
-
Confidentiality : Thanks to symmetric encryption, only the two communicating parties can read the data.
-
Integrity : Each message is accompanied by a code (MAC or HMAC, depending on the version) that allows us to detect if it has been modified.
-
Authenticity : Digital certificates allow you to be reasonably sure of the identity of the server (and sometimes the client).
From simple to technical: symmetrical and asymmetrical
One of the key aspects is the combination of asymmetric and symmetric cryptography.
-
Asymmetric cryptography (RSA, Diffie-Hellman, elliptic curves) was used initially because it allowed two parties to establish a common key without having to transmit it in clear text. It is very secure, but also slow.
-
Once the session key is established, symmetric encryption takes over , where both parties use the same key to encrypt and decrypt data. It's much faster, making it perfect for handling large amounts of traffic.
This balance between the two types of encryption is what makes TLS both secure and efficient.
TLS Versions and Evolution
Over time, the protocol has undergone several updates. SSL 2.0 and SSL 3.0 are currently considered insecure. TLS versions have progressively improved security:
-
TLS 1.0 and 1.1 are now deprecated.
-
TLS 1.2 is still very widespread, stable, and considered secure.
-
TLS 1.3 , the latest version, greatly simplified the handshake, eliminated weak algorithms, and improved speed. Establishing a secure session now requires fewer message exchanges, reducing latency.
An overview
In conclusion, in theory, SSL/TLS is like a ritual of introduction and agreement between two interlocutors: first, they recognize each other, then they decide together how to communicate, and then they exchange messages securely from outside view. In practice, this happens thanks to sophisticated encryption mechanisms, digital certificates, and integrity codes, which operate transparently for the user.
The magic of the protocol is precisely this: behind a simple green padlock in the browser lies a complex system, made of mathematics and shared standards, that allows billions of people every day to browse, shop, exchange messages, and work online with a level of security that, until a few decades ago, would have been unthinkable.
OpenSSL: The cornerstone of open-source encryption
You can't talk about SSL/TLS without mentioning OpenSSL , the most popular and long-lived library. Born in the late 90s as an evolution of SSLeay, it has become the de facto standard for the entire open source world and beyond. Apache HTTP Server, Nginx, Postfix, MySQL—practically every software that requires encrypted communications relies or has relied on OpenSSL.
Its main strength has always been its completeness . OpenSSL provides not only the TLS protocol implementation, but also a huge collection of cryptographic primitives: RSA, DSA, DH, elliptic curves, AES, ChaCha20, SHA, HMAC, legacy ciphers, and much more. It's a kind of Swiss Army knife that goes far beyond TLS and is used to generate X.509 certificates, manage PKIs, verify digital signatures, build VPNs, or file encryption systems.
Its widespread use is also due to its Apache-style license , which has encouraged its integration into both free software and proprietary solutions. However, this same ubiquity made its critical role painfully evident when the Heartbleed vulnerability exploded in 2014 , a flaw in the implementation of the TLS heartbeat extension that allowed server memory to be read. Heartbleed shook the IT world, revealing that such a crucial infrastructure was maintained by very few developers, with limited funding and code that was not always easy to maintain.
Since then, the project has undergone a revitalization phase, with increased funding, security audits, and more regular releases. Today, OpenSSL is still the reference library for compatibility and support, but that crisis paved the way for various forks seeking to offer more secure or lightweight alternatives.
LibreSSL: OpenBSD's Response to Heartbleed
LibreSSL was born as a reaction to Heartbleed , a fork of the OpenBSD team. The philosophy behind this project was very clear: clean up. OpenSSL had grown chaotically, with a lot of legacy code, APIs considered insecure, and compatibility issues maintained for obsolete systems. The OpenBSD developers therefore decided to eliminate unnecessary features, simplify the API, and focus on security and readability.
LibreSSL stands out for its attention to code rigor . OpenBSD's approach has always been known for its "secure by default" culture, and this same spirit inspires this library. It's no coincidence that many parts of the code have been rewritten, brought to modern C standards, and cleaned up from dangerous functions such as those that don't properly check buffers.
LibreSSL's main limitation is compatibility . Being more minimalist, it can't always keep up with all the APIs required by software that expect OpenSSL's feature set. This has slowed its spread outside the *BSD world and some Linux distributions. However, it remains a point of reference for those seeking a simple implementation focused on code security rather than absolute compatibility.
BoringSSL: Google's implementation for Chrome and Android
Another fork born from specific needs is BoringSSL , maintained by Google. In this case, the problem wasn't so much Heartbleed as the need for SSL/TLS code tailored for Google's huge platforms, such as Chrome, Android, gRPC, and cloud services.
BoringSSL never had the ambition to become a universal library like OpenSSL. On the contrary, Google always presented it as an internal project, optimized for its own needs and not recommended for general use. The goal was to reduce complexity, eliminate legacy features, and achieve a faster development cycle, in line with the pace of security patches needed to protect billions of users.
Its strengths are therefore its development speed , its focus on memory-safe security (even though it is still written in C, many mitigations have been introduced), and its integration with the Google ecosystem. BoringSSL also provides secondary libraries such as AWS-LC , the fork maintained by Amazon Web Services.
Its main limitation, again, is compatibility . BoringSSL doesn't expose all of OpenSSL's APIs and isn't intended to be a transparent replacement. For this reason, it never became a standard choice for third-party developers, but it was enormously influential in demonstrating that leaner libraries are possible and desirable in certain contexts.
WolfSSL: the ideal choice for IoT and embedded systems
If OpenSSL is the generalist giant, WolfSSL represents the specialty. Originally known as CyaSSL and later renamed, this library is specifically aimed at the world of embedded systems and the Internet of Things. Microcontrollers, routers, industrial or medical devices have limited resources: limited memory, underpowered CPUs, stringent latency requirements. In these scenarios, a massive library like OpenSSL is often inadequate.
WolfSSL is written in portable C, with a meticulous focus on lightweight design . The binary size is small, modules are configurable as needed, and hardware optimizations are used to reduce power consumption. It is no coincidence that it supports a wide range of architectures and RTOS environments.
Another strong point is certification . WolfSSL has been validated against various standards such as FIPS 140-2 and DO-178C for avionics applications, making it attractive for industries where compliance is critical. This has made it popular among embedded device manufacturers who must ensure not only technical security but also regulatory compliance.
Its limitation, however, is that it doesn't always offer the same legacy algorithm extensions or APIs found in OpenSSL. It's designed for those seeking efficiency and portability, rather than those who need to maintain universal compatibility.
GnuTLS: The GNU World's Alternative
The open source landscape couldn't fail to include a GNU-branded solution: GnuTLS . This library was created with the aim of providing a TLS implementation compatible with the GNU Project and Free Software Foundation guidelines. At the time, OpenSSL had a license considered not fully compatible with the GPL, and GnuTLS was intended to be the fully "free" answer.
Its main strength is its integration into the GNU/Linux world . Many GNU-based software programs have preferred to adopt GnuTLS precisely for licensing reasons and philosophical consistency. Over time, however, the project has also distinguished itself for some technical features, such as the early adoption of modern protocols and a strong focus on configurability.
Compared to OpenSSL, GnuTLS has often been less popular in the enterprise world, but it plays a crucial role in the free software ecosystem. It's widely used by applications that want to break away from the OpenSSL juggernaut and adopt a library consistent with GNU principles. Even in terms of API, it's sometimes simpler and more straightforward, though less universal.
NSS: Mozilla's historic library
Another implementation that deserves attention is NSS (Network Security Services) , originally developed by Netscape and now maintained by Mozilla and Red Hat. It has been the cryptographic heart of Firefox for years , but not only that: it is also used in enterprise solutions, in mail systems and in various Red Hat products.
NSS stands out because it goes beyond TLS: it includes a full PKI , with certificate management, S/MIME libraries, and digital signature and authentication tools. It's designed as a broader security stack, with a focus on browser and operating system integration.
Its strength lies in its maturity and robustness . Having been used in Firefox and other widely used contexts, it has received considerable attention in terms of security and bug fixes. Furthermore, its extensive support for certificate management makes it suitable for complex enterprise authentication scenarios.
The downside is that, outside of the Mozilla and Red Hat context, it has lost ground to OpenSSL and its forks. It remains a historic pillar, however, which has helped evolve the TLS standard in browsers and continues to be carefully maintained.
BabaSSL, now Tongsuo: the Chinese variant with national algorithms
A lesser-known implementation in the West but of great relevance in Asia is now known as Tongsuo , an evolution of what was previously called BabaSSL . It is a fork of OpenSSL developed in China with a very specific goal: to natively integrate mandatory national cryptographic standards, such as SM2, SM3, and SM4 . Unlike the rest of the world, where encryption relies primarily on AES, RSA, or NIST curves, in China the law requires the use of a set of local algorithms, and Tongsuo represents the technical response to this requirement.
Tongsuo is therefore the ideal choice for those who must operate in compliance with local regulations, and for this reason it is adopted in several Chinese products and services. In addition to supporting NTLS (National TLS) , the "national" equivalent of the TLS protocol, it also maintains compatibility with international protocols, making it suitable for mixed scenarios in which it is necessary to communicate with both global clients and clients compliant with Chinese standards.
Its main strength is therefore regulatory compliance . In a large market like China's, having a library that natively implements national algorithms is essential to ensure interoperability and legal compliance. At the same time, this same focus limits its diffusion outside of China: in Western contexts, few have a real need to use algorithms like SM2 or NTLS, which is why Tongsuo remains a very specialized and niche library.
Conclusions: which one to choose?
As we've seen, there isn't just one TLS implementation, but an entire ecosystem of libraries designed to meet different needs. OpenSSL remains the most universal, ensuring maximum compatibility. LibreSSL , though less widely used, is a symbol of code rigor and cleanliness. BoringSSL demonstrates Google's pragmatic approach, focused on its own services. WolfSSL opens the doors to IoT and embedded systems. GnuTLS remains the flagship of the GNU world. NSS continues to ensure security for browsers and enterprise solutions. Finally, BabaSSL represents the adaptation to Chinese national standards.
What's clear is that cryptography and security are never static. The evolution of SSL/TLS libraries reflects both the history of the Internet and the constant tension between compatibility, performance, compliance, and security. Each implementation tells a part of this story, and the choice depends on the context: a global data center, an IoT device, a browser, a national market.
Ultimately, the wealth of alternatives is a sign of vitality: it means that TLS, the heart of web security, continues to evolve and find targeted answers to the challenges of an increasingly complex and diverse digital world.
