A RSA application: A Deep Dive Into HTTPS and TLS
Every time you visit a website with a little padlock in the address bar, RSA might be working behind the scenes. But how does it actually protect your data online? Let's explore in this post
Introduction: why we need encrypt in the web?
Imagine you’re sitting in a coffee shop—just like I am now—connected to public Wi-Fi and logging into your Gmail account. Without protection, it’s surprisingly easy for someone nearby to capture your network traffic using tools like Wireshark and potentially steal your username and password.
That’s why encrypting your data before it leaves your device is so important. And this is exactly what the “S” in HTTPS stands for: Secure.
But how does it actually work under the hood? Let’s explore how RSA helps make this security possible.
What is HTTP and HTTPS?
When you visit a website, you’re actually accessing a URL, like this one: https://www.google.com
The beginning of the URL—http or https—tells your browser how to communicate with the website. Technical term is a protocol.
We’ve already talked about the “S” in HTTPS, which stands for Secure. But what about HTTP itself? What does that mean?
Let’s break it down.
HTTP stands for Hypertext Transfer Protocol. It is a method to communication between clients ( your web browsers) and servers. Step by step can see in this digram
Or in your browsers, when you access to a website and inspect/network tab, you can see the request/response data:
And you can see, there is no encryption steps in HTTP, so anyone on the network can read or modify the data.
Let’s move to next session to how HTTP use TLS to improve secure of your data.
What is TLS?
TLS which stands for Transport Layer Security.
Compared to plain HTTP, which involves just two basic steps (request and response), HTTPS requires several additional steps — to establish a secure connection.
The first and most crucial step is the TLS handshake,
Let’s break down the TLS handshake to understand how it lays the foundation for secure communication
The TLS Handshake
Like people in the real world, the first step your browser said hello with the server and share some information:
The client (your browsers) say hello, include data: TLS version, a random number, and cipher suites( list of algorithm to make the connection secure).
The server reply: which cipher suites server want, a random server number and SSL certificate. We will discuss later about the certificate.
The client verifies the server's SSL certificate with the certificate authority that issued it. This confirms that the server is who it says it is, and that the client is interacting with the actual owner of the domain.
After the client verifies the server SSL certificate okay, it generate another random number and encrypt by server’s RSA public key and send the cipher text to the server
Server decrypt the cipher by its RSA private key.
Both client and server generate session keys from the client random, the server random, and the random secret number in step 4 . They should arrive at the same results.
The client sends a "finished" message that is encrypted with a session key. The session key now use for symmetric algorithm (AES)
The server sends a "finished" message encrypted with a session key., AES too.
The diagram below show how the handshake work:
Certificate Authority (CA)
In step 2 and step 3, we mention about CA, it is is a trusted organization that issues digital certificates to websites. A digital certificate include those information
Website domain name
Organization info (optional)
Public key (RSA or ECDSA)
Signature from the CA
Expiration date
With the digital certificates, the client can know that the server it is connect with is real entities, not a faker.
Example of real cerf, you can use curl -v --head <your url>
curl -v --head https://example.com
* Host example.com:443 was resolved.
* IPv6: (none)
* IPv4: 23.192.228.84, 23.215.0.136, 23.215.0.138, 96.7.128.175, 96.7.128.198, 23.192.228.80
* Trying 23.192.228.84:443...
* Connected to example.com (23.192.228.84) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /opt/anaconda3/ssl/cacert.pem
* CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
* subject: C=US; ST=California; L=Los Angeles; O=Internet Corporation for Assigned Names and Numbers; CN=*.example.com
* start date: Jan 15 00:00:00 2025 GMT
* expire date: Jan 15 23:59:59 2026 GMT
* subjectAltName: host "example.com" matched cert's "example.com"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1
* SSL certificate verify ok.
* Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://example.com/
* [HTTP/2] [1] [:method: HEAD]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: example.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> HEAD / HTTP/2
> Host: example.com
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200
HTTP/2 200
< content-type: text/html
content-type: text/html
< etag: "84238dfc8092e5d9c0dac8ef93371a07:1736799080.121134"
etag: "84238dfc8092e5d9c0dac8ef93371a07:1736799080.121134"
< last-modified: Mon, 13 Jan 2025 20:11:20 GMT
last-modified: Mon, 13 Jan 2025 20:11:20 GMT
< cache-control: max-age=2444
cache-control: max-age=2444
< date: Fri, 18 Jul 2025 04:46:05 GMT
date: Fri, 18 Jul 2025 04:46:05 GMT
< alt-svc: h3=":443"; ma=93600,h3-29=":443"; ma=93600
alt-svc: h3=":443"; ma=93600,h3-29=":443"; ma=93600
<
* Connection #0 to host example.com left intactBase on the value of issuer (issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1) we can know that:
C=US Country = United States
O=DigiCert Inc Organization = DigiCert Inc — the name of the CA
CN=DigiCert Global G3 TLS ECC SHA384 2020 CA1 Common Name = Name of the specific intermediate CA certificateIf we want full version of cerf we can use openssl s_client -connect example.com:443
Summary
Today, many CA use Elliptic Curve Cryptography (ECC) instead of RSA because it's:
Faster and lighter than RSA
Uses smaller keys for the same security
Better for mobile and modern devices
But RSA is still important:
Works everywhere — very compatible
Often used in HTTPS to encrypt session keys
Many websites still use RSA keys
That why we will have another post to discuss about ECC. See you there!!!
Very good!!!!