A Deep Dive into SSL/TLS: The Protocols That Secure the Internet

SSL (Secure Sockets Layer) and its successor, TLS (Transport Layer Security), are the cryptographic protocols that secure data transmitted over the Internet. They ensure:

• Confidentiality: Your data is only accessible to the client and server.
• Integrity: Your data is not altered in transit.
• Authentication: You are communicating with the real server.

When you see the padlock icon in your browser, that’s TLS protecting your connection.

SSL was the original protocol developed at Netscape in 1994, but it is now obsolete due to security flaws. TLS is its modern, secure successor. Today, when people say “SSL,” they almost always mean “TLS.” The current version, TLS 1.3, is faster and more secure than its predecessors.

The Internet: A Network of Networks

At its core, the Internet is not one big “thing” owned by a single company. it’s thousands of independent networks connected together. These networks belong to:

• Internet Service Providers (ISPs)
• Telecom companies
• Cloud providers (e.g., AWS, Azure, GCP)
• Enterprises
• Governments
• Universities

Each network is called an Autonomous System (AS), and they peer with each other using protocols like Border Gateway Protocol (BGP) to share routes.

What is an Autonomous System (AS)?

• An Autonomous System is a collection of IP networks (prefixes) that are managed by a single organization and that share a common routing policy.
• Each AS has a globally unique number called an Autonomous System Number (ASN).
• Routers inside an AS speak internal routing protocols (like OSPF, IS-IS, or iBGP), and communicate with other AS using BGP (Border Gateway Protocol).
• Example:
  1. Google (AS15169)
  2. Cloudflare (AS13335)
  3. Jio(AS55836)
  4. Airtel(AS9498)

Why ASNs matter and who Assigns it ?

There is a hierarchy of organizations that manage Internet number resources (IP addresses and ASNs):

1. IANA (Internet Assigned Numbers Authority)

   • IANA is at the top level.
   • It manages global IP address space and ASN pools.
   • It is operated by ICANN (Internet Corporation for Assigned Names and Numbers).

2. RIRs (Regional Internet Registries)

   • IANA delegates blocks of IP addresses and ASN ranges to 5 RIRs, each covering a specific region:
   • ARIN (North America)
   • LACNIC (Latin America & Caribbean)
   • RIPE NCC (Europe, Middle East, parts of Central Asia)
   • APNIC (Asia Pacific)
   • AFRINIC (Africa)

3. NIRs (National Internet Registries)

   • In some regions, there are National Internet Registries (NIRs) that further manage allocation within a country.
   • For example these are some NIRs operating under APNIC:
     • IRINN, Indian Registry for Internet Names and Numbers
     • CNNIC, China Internet Network Information Center
     • JPNIC, Japan Network Information Center

4. Local ISPs, Enterprises, Organizations

   • These entities apply to their RIR or NIR to request an ASN. -They must justify why they need an ASN (usually because they plan to run BGP with other networks).
   • Once assigned, they are globally registered.

Every BGP router announces IP prefixes with its ASN as it helps establish routing policies, peering agreements, and routing decisions.

When you visit google.com, your data may flow through:

Each router uses BGP to decide how to route traffic across AS boundaries.

Since your packets cross multiple ASes you don’t control. Any compromised router in any AS could inspect or modify unencrypted traffic.

TLS ensures that even though your data flows through all these ASes, only you and the server can read it.

How SSL/TLS protects your data ?

When you connect to a website over HTTPS, TLS works behind the scenes to secure your connection.

Since your data is flowing through someone else networks and routers to the destination server anyone in midle can read and write to the data.

TLS protects your data in three key ways:

1. Confidentiality

   • Data is only accessible by client and server.
   • TLS achieves confidentiality through a cryptographic technique called Encryption.
   • TLS encrypts all the data you send and receive.
   • Even if someone intercepts your traffic (e.g. ISP, hacker, rogue router), they only see scrambled, unreadable data.
   • Only your browser and the server have the keys to decrypt the data.

2. Integrity

   • Data hasn’t been modified between client and server.
   • TLS achieves integrity through a cryptographic technique called Hashing.
   • TLS ensures that the data hasn’t been tampered with during transmission but it does’t prevent from modification.
   • If any data is altered, it will be detected instantly and the connection will fail.

3. Authentication

   • Client and server are indeed who they say they are.
   • TLS achieves authentication through a system called PKI (Pulbic key infrastructure).
   • TLS verifies the identity of the server using digital certificates issued by trusted Certificate Authorities (CAs).
   • This prevents attackers from impersonating a real website (e.g., phishing, man-in-the-middle attacks).

Key players of SSL & TLS

Understanding TLS requires knowing the three main actors involved in the process:

1. The Client: This is the application that initiates the secure connection. Most commonly, this is your web browser (like Chrome, Firefox, or Safari) when you visit a website. However, it can be any application that needs to communicate securely, such as an email client or a mobile app.

2. The Server: This is the machine that the client wants to communicate with. It hosts the website or service (e.g., google.com or your-bank.com). The server holds the digital certificate and the private key necessary to prove its identity and establish a secure connection.

3. The Certificate Authority (CA): A Certificate Authority is a trusted third-party organization that issues digital certificates. Its job is to verify the identity of the server’s owner before issuing a certificate. This is crucial for the “Authentication” part of TLS. When you browser sees a certificate from a trusted CA (like Let’s Encrypt, DigiCert, or GlobalSign), it knows it can trust that the server is who it claims to be. Your browser and operating system come with a pre-installed list of trusted CAs.

Server Verification and Certificate Types

Before a Certificate Authority (CA) issues a certificate, it must verify that the entity requesting it is who they say they are. The rigor of this verification process determines the type of certificate issued. This is crucial for establishing trust. There are three main levels of validation:

1. Domain Validation (DV) Certificates:

   • Verification Level: This is the most basic level of validation. The CA only verifies that the applicant controls the domain name. This is usually done by email verification, adding a DNS record, or uploading a specific file to the website.
   • Trust Level: It confirms that your connection is encrypted and that you are connected to the correct domain, but it doesn’t verify who owns the domain.
   • Best for: Blogs, personal websites, and small projects where identity assurance is not a high priority. Let’s Encrypt is a popular provider of free DV certificates.

2. Organization Validation (OV) Certificates:

   • Verification Level: This involves a more substantial vetting process. The CA verifies not only domain control but also the legal existence and details of the organization (e.g., name, city, country). This requires submitting business registration documents.
   • Trust Level: Provides a higher level of trust by confirming the identity of the legal entity behind the website. Users can view these details in the certificate information in their browser.
   • Best for: E-commerce sites, public-facing corporate websites, and services that handle sensitive user information.

3. Extended Validation (EV) Certificates:

   • Verification Level: This is the highest level of validation and involves a strict, globally standardized vetting process defined by the CA/Browser Forum. The CA performs a thorough background check on the organization, verifying its legal, physical, and operational existence.
   • Trust Level: Offers the highest level of trust and assurance. In the past, browsers would display the company’s name in a green address bar, though this UI has been mostly phased out. Still, the verified company name is visible in the certificate details.
   • Best for: Financial institutions (banks), government agencies, and large enterprises where proving identity and building user trust is paramount.

Choosing the right certificate type depends on the website’s purpose and the level of trust it needs to establish with its users.

Encryption and Confidentiality

Encryption is the process of converting plaintext data into a scrambled, unreadable format called ciphertext. This is the core mechanism TLS uses to ensure confidentiality. Only parties with the correct key can decrypt the ciphertext back into its original, readable form.

TLS cleverly uses two types of encryption:

1. Asymmetric Encryption (Public-Key Cryptography):

   • This involves a pair of keys: a public key and a private key.
   • The public key can be shared with anyone. The private key must be kept secret by the owner (in this case, the server).
   • Data encrypted with the public key can only be decrypted with the corresponding private key.
   • TLS uses asymmetric encryption during the initial handshake to securely exchange a key for symmetric encryption. This is crucial for establishing a secure channel without having to pre-share a secret.

2. Symmetric Encryption:

   • This uses a single, shared secret key for both encryption and decryption.
   • It is much faster and more efficient for encrypting large amounts of data than asymmetric encryption.
   • Once the initial handshake is complete, the client and server use the securely exchanged symmetric key to encrypt all the actual application data (like your HTTP requests and the website’s responses).

By combining these two methods, TLS gets the best of both worlds: the secure key exchange capability of asymmetric encryption and the high performance of symmetric encryption for the bulk of the data transfer.

A Closer Look at Asymmetric Encryption: How RSA Works

The RSA (Rivest-Shamir-Adleman) algorithm is the most well-known asymmetric encryption algorithm. Its security is based on the practical difficulty of factoring the product of two large prime numbers.

The Core Concept: A Mailbox Analogy

Imagine you have a special mailbox with two keys:

• A public key (the mailbox slot): You can make copies of this key and give it to anyone. Anyone with this key can open the slot and drop a message in.
• A private key (the mailbox door key): This key is yours alone. It is the only key that can open the mailbox door to retrieve the messages.

This is the essence of RSA. The server’s public key is like the mailbox slot, and its private key is the only thing that can unlock the messages sent to it.

A Demo: RSA in Action

Let’s see how this is used for both Confidentiality (encryption) and Authentication (digital signatures).

1. For Confidentiality (Encrypting the Session Key):

This is the primary role of RSA in the TLS handshake.

• Step 1: The Server sends its certificate to the Client. This certificate contains the Server’s public key.
• Step 2: The Client generates a small, random piece of data (the “pre-master secret”) that will be used to create the final session key.
• Step 3: The Client uses the Server’s public key to encrypt this pre-master secret. Now, it’s just scrambled, unreadable data.
• Step 4: The Client sends this encrypted data to the Server.
• Step 5: The Server uses its private key to decrypt the data and retrieve the pre-master secret. No one else could have done this, because no one else has the private key.
• Result: Both the Client and Server now share a secret, which they use to independently generate the same symmetric session key. Confidentiality is achieved.

2. For Authentication (How a CA Signs a Certificate):

RSA also works in reverse for digital signatures, which is how a CA guarantees a certificate is authentic.

• Step 1: A server owner gives their certificate information (domain name, public key, etc.) to a Certificate Authority (CA).
• Step 2: The CA creates a hash of all that information.
• Step 3: The CA uses its own private key to encrypt that hash. This encrypted hash is the digital signature.
• Step 4: The CA attaches this signature to the certificate and sends it back to the server owner.
• Step 5 (Verification): When your browser receives the certificate, it sees it was signed by the CA. Your browser already trusts this CA and has its public key. It uses the CA’s public key to decrypt the signature, revealing the original hash. It then computes its own hash of the certificate. If the two hashes match, the signature is valid.
• Result: Your browser has just mathematically proven that the certificate is authentic and has not been tampered with. Authentication is achieved.

Hashing, Hashing algorithms and Collisions

Hashing is a fundamental concept in cryptography that ensures data integrity. It’s the process of taking an input (of any size) and running it through a mathematical function to produce a fixed-size output string, known as a hash.

A good hashing algorithm is:

• Deterministic: The same input will always produce the same hash.
• Efficient: The hash is quick to compute.
• Pre-image Resistant: It’s computationally impossible to determine the original input from its hash. This makes it a one-way function.
• Collision Resistant: It should be extremely difficult to find two different inputs that produce the same hash.

Common hashing algorithms include SHA-256 (Secure Hash Algorithm 256-bit), which is widely used today. Older algorithms like MD5 and SHA-1 are now considered insecure because “collisions” have been found. A collision means two different inputs produce the same hash, which can allow an attacker to pass off a malicious file as a legitimate one.

Data integrity - How TLS uses Hashing

So how does TLS use hashing to ensure data hasn’t been tampered with? It uses a clever mechanism called an HMAC (Hash-based Message Authentication Code).

Here’s how it works:

1. During the initial TLS handshake, the client and server securely negotiate a shared secret key.
2. For every message they exchange, the sender combines the message content with the secret key and then hashes the result. This creates the HMAC, which is attached to the message.
3. The receiver gets the message and the HMAC. It independently computes its own HMAC using the message content and the shared secret key it already has.
4. If the received HMAC matches the one it just computed, the data is considered authentic and unaltered. If they don’t match, the connection is terminated immediately, as this indicates tampering.

This process guarantees both integrity (the data wasn’t changed) and authentication (we know who sent it, because only they have the secret key).

What is a Cipher Suite?

A cipher suite is a bundle of algorithms that, together, provide all the security guarantees of TLS. Think of it as a single name that defines the exact tools for the job. During the handshake, the client sends a list of cipher suites it supports (its “menu” of security options), and the server chooses the one it prefers, usually the strongest one they both support.

A typical cipher suite name, like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, looks complex, but it’s just a combination of four distinct types of algorithms, each mapping directly to a core TLS goal:

1. Key Exchange Algorithm (ECDHE): This algorithm’s job is to let the client and server securely agree on a shared secret key for symmetric encryption, even if someone is listening in. This is the foundation for confidentiality. Using an “ephemeral” method like ECDHE provides Perfect Forward Secrecy, meaning past conversations remain secure even if the server’s long-term key is compromised later.

2. Authentication Algorithm (RSA): This determines how the server proves its identity to the client. The server uses this algorithm (e.g., RSA) to sign its certificate, proving it owns the corresponding private key. This directly provides Authentication.

3. Bulk Encryption Algorithm (AES_128_GCM): This is the high-speed symmetric cipher that will encrypt all the actual data (your requests, the website’s content, etc.) after the handshake is complete. This provides Confidentiality.

4. Hashing Algorithm (SHA256): This algorithm is used to create a Message Authentication Code (MAC), which is like a tamper-proof seal on every message. This provides Integrity.

So, the cipher suite is the complete package. By agreeing on one, the client and server are explicitly defining how they will achieve Authentication, Confidentiality, and Integrity for the entire session.

The TLS Handshake

Now that we understand the key players and the types of encryption, let’s walk through how they all come together in the TLS handshake. This is the negotiation process that happens in milliseconds before any actual data is sent. The goal is simple: for the client and server to verify each other and securely agree on a session key for symmetric encryption.

Here’s a simplified look at the steps (for TLS 1.2, as it’s a bit more explicit for learning, though TLS 1.3 is faster and more common today):

1. Client Hello: The client sends a “hello” message to the server. This message includes:

   • The TLS versions it supports.
   • A list of cipher suites it can use (the combination of encryption, authentication, and hashing algorithms).
   • A random string of bytes, known as the “Client Random.”

2. Server Hello: The server receives the client’s hello and responds with its own “hello” message. This includes:

   • The TLS version and cipher suite it has chosen from the client’s list.
   • Its digital certificate, which contains its public key.
   • Another random string of bytes, the “Server Random.”

3. Certificate Verification: The client examines the server’s certificate. It checks:

   • Is the certificate expired?
   • Is it for the correct domain (google.com, etc.)?
   • Is it signed by a Certificate Authority (CA) that the client trusts? (The client checks this against its built-in list of trusted CAs). If any of these checks fail, the browser will show a security warning, and the connection is terminated.

4. Key Exchange: This is the clever part. The client generates another random string of bytes called the “Pre-Master Secret.”

   • The client encrypts this Pre-Master Secret using the server’s public key (which it got from the certificate).
   • The client sends this encrypted Pre-Master Secret to the server.
   • Because it was encrypted with the public key, only the server, with its corresponding private key, can decrypt it.
   • Now, both the client and server use the Client Random, Server Random, and the Pre-Master Secret to independently calculate the same session key.

5. Handshake Complete & Secure Communication: The handshake is now finished.

   • Both client and server send a “Finished” message, which is encrypted with the newly created session key.
   • From this point on, all communication between the client and server is encrypted using this symmetric session key, ensuring confidentiality and integrity for the rest of the session.

How to Inspect a Website’s Certificate

Everything we’ve discussed is visible right in your browser. This is the best way to see how these concepts apply in the real world. Try this on any https:// site:

1. Click the Padlock: In your browser’s address bar, click the padlock icon to the left of the website’s URL.
2. View the Certificate: Look for an option that says “Connection is secure,” which will lead to a “Certificate is valid” button. Clicking this will open the certificate viewer.
3. What to Look For:
   • Issued To: You’ll see the “Common Name” (the domain the certificate belongs to) and often the organization’s name, city, and country (for OV and EV certificates).
   • Issued By: This shows you which Certificate Authority (CA) verified and signed the certificate.
   • Validity Period: You can see the “Not Before” and “Not After” dates.

By doing this, you can directly see the results of the TLS handshake and verify the identity and security of the websites you visit.

Learning Resources

• Practical TLS Playlist

Conclusion

SSL/TLS is a cornerstone of modern internet security. It works silently in the background, providing the essential guarantees of confidentiality, integrity, and authentication. While the process is complex, the result is a secure channel that protects our sensitive information from prying eyes and tampering.