Hello folks! today, we present a brief refresher on cryptographic protocols to help you brush up on some of the key terms you've likely encountered—like SSL 3.0, TLSv1.3, Cipher Suites, Encryption, Algorithms, HTTPS, and SSL Certificates. This overview will connect the dots for those familiar with the terms but seeking a deeper understanding of how they secure data transmission on the internet.
We all know that staying secure in today's digital world means keeping up with an ever-changing landscape. The same is true when securing data in transit on the World Wide Web, particularly during the early days of the internet.
01 What Makes a Connection Secure?
A connection can be considered secure when the following conditions are met:
Authentication
Both parties (client and server) must prove their identities, preventing impersonation or fraud. Authentication ensures that the parties are who they claim to be.
Examples of Authentication Algorithms:
RSA (Rivest, Shamir, Adleman, names of inventors of the RSA algorithm) Commonly used for both key exchange and digital signatures.
ECDSA (Elliptic Curve Digital Signature Algorithm): Provides strong security with smaller key sizes.
DSA (Digital Signature Algorithm): Another method for creating digital signatures.
Integrity
Data integrity ensures that the information sent over a network remains unchanged during transmission. If someone tries to alter the data, the changes will be detected, ensuring the recipient receives exactly what was sent.
Examples of Integrity Algorithms:
SHA-256 (Secure Hash Algorithm 256-bit): A widely-used, secure hashing function.
SHA-1: An older hash function, now considered insecure.
BLAKE2: A fast and secure hash function.
Encryption
Encryption scrambles data so that unauthorised parties cannot read it without the correct key or algorithm. Even if an attacker intercepts the data, they cannot understand it.
Types of Encryption:
Symmetric Encryption: Uses the same key for both encryption and decryption, making it efficient for large amounts of data.
Examples: AES (Advanced Encryption Standard), DES (Data Encryption Standard), RC4 (deprecated).
Asymmetric Encryption: Uses a pair of keys (public and private); the public key is for encryption, and the private key is for decryption.
Examples: RSA, ECDSA, DSA.
Key Exchange
Key exchange algorithms securely share cryptographic keys between parties, allowing them to establish a secure connection.
Examples of Key Exchange Algorithms:
RSA: A widely-used public-key cryptosystem.
DHE (Diffie-Hellman Ephemeral): Provides perfect forward secrecy (PFS).
ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): Offers strong security with shorter key lengths.
02 Cipher Suites: Combining Algorithms for Security
A cipher suite is a combination of cryptographic algorithms used to establish a secure connection. It includes algorithms for key exchange, authentication, encryption, and hashing.
Examples of Cipher Suites:
Cipher Suite | Key Exchange | Authentication | Encryption | Hash |
TLS_RSA_WITH_AES_128_CBC_SHA | RSA | RSA | AES-128-CBC | SHA |
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | ECDHE | ECDSA | AES-256-GCM | SHA384 |
TLS_DHE_RSA_WITH_CHACHA20_POLY1305 | DHE | RSA | ChaCha20 | Poly1305 |
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ECDHE | RSA | AES-128-GCM | SHA256 |
03 SSL and TLS Versions: A Brief History
The evolution of SSL (Secure Socket Layer) and TLS (Transport Layer Security) has brought continuous improvements in security, performance, and cryptographic strength. SSL was first introduced in 1995 and was soon succeeded by TLS in 1999.
Here's a brief look at their timeline:
SSL 2.0: Released in February 1995 (no RFC published)
SSL 3.0: Released in 1996 (Published as RFC 6101)
TLS 1.0: Released in January 1999 (Published as RFC 2246)
TLS 1.1: Released in April 2006 (Published as RFC 4346)
TLS 1.2: Released in August 2008 (Published as RFC 5246)
TLS 1.3: Released in August 2018 (Published as RFC 8446)
Each iteration has brought improvements in performance, integrity, authentication, and encryption.
04 Why Are Old Cipher Suites Deprecated?
Older cipher suites are often deprecated because vulnerabilities are discovered that compromise one or more of the following:
Authentication: Risk of impersonation or fraud.
Integrity: Data could be tampered with undetected.
Encryption: Data could be exposed due to weak encryption algorithms.
Examples of Vulnerabilities:
CVE-2021-3450 (OpenSSL TLS 1.2 Certificate Validation Bypass)
Issue: Allows an attacker to bypass certificate validation during a TLS 1.2 handshake.
Recommendation: Upgrade to OpenSSL 1.1.1k or later.
CVE-2018-16868 (GnuTLS Timing Side-Channel Attack)
Issue: Allows an attacker to recover RSA keys.
Recommendation: Update GnuTLS to version 3.6.4 or later and avoid using RSA key exchange.
CVE-2015-2808 (Bar Mitzvah Attack on RC4)
Issue: Exploits known biases in the RC4 stream cipher.
Recommendation: Disable RC4 cipher suites and use stronger encryption like AES-GCM.
05 Current Recommendations for Secure Cipher Suites
As of Oct 2024, these cipher suites are recommended for TLS 1.2 and TLS 1.3:
Recommended Cipher Suites for TLS 1.2:
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Recommended Cipher Suites for TLS 1.3:
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256
These cipher suites utilise modern cryptographic algorithms that provide strong security against contemporary attacks.
06 How to Create a Self-Signed SSL Certificate
Let’s walk through the steps to create your own self-signed certificate using OpenSSL. Don’t worry—this isn’t as hard as it sounds!
Generate a Private Key for Your Certificate Authority (CA):
Start by creating an RSA private key for your CA. This key should never be shared.
openssl genrsa -aes256 -out ca-key.pem 4096
Create the CA’s Self-Signed Certificate:
Use the key you just generated to create a self-signed CA certificate.
openssl req -new -x509 -days 3650 -key ca-key.pem -out ca.pem
Generate a Private Key for the SSL Certificate:
Now, generate a private key for the SSL certificate itself.
openssl genrsa -out server-key.pem 4096
Create a Certificate Signing Request (CSR):
Before generating the SSL certificate, you’ll need to create a CSR, which includes the necessary details about your server.
openssl req -new -key server-key.pem -out server.csr
Sign the CSR with Your CA:
Now, use the CA’s certificate to sign the server CSR and generate the actual SSL certificate.
openssl x509 -req -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server.pem -days 3650
Bundle the Certificates:
Finally, combine the CA and SSL certificates into a full-chain certificate for the server to use.
cat server.pem ca.pem > full-chain.pem
07 How to Check and Validate SSL Certificates on Windows and Linux Servers
After creating your SSL certificates, it’s essential to verify that they’ve been correctly installed and are functioning as expected. Let’s look at how to check and validate SSL certificates on Windows Server and Linux Server.
7.1 Checking SSL Certificates on a Windows Server
Windows provides several built-in tools to validate SSL certificates. Here’s how you can check if your certificate is installed and working properly.
7.1.1 Using PowerShell to Check the SSL Certificate
PowerShell is a powerful tool in Windows Server for certificate management. Follow these steps to validate an SSL certificate:
Open PowerShell with administrator privileges.
Run the following command to retrieve the SSL certificate details for a specific website:
Test-Connection "your-website.com" -Port 443
This will give you details about the SSL certificate such as issuer, expiration date, and whether it's trusted.
7.1.2 Using certlm.msc to Check Certificates
Open the Run dialog (Windows key + R), type certlm.msc, and press Enter.
Navigate to Certificates > Personal > Certificates to see the list of installed SSL certificates.
Double-click the certificate you want to check, and verify the following:
Validity Period: Make sure the certificate is not expired.
Issuer: Confirm that the issuer is either your CA (for self-signed certs) or a trusted CA.
Certificate Path: Verify that the certificate chain is complete and trusted.
7.1.3 Testing SSL with Internet Information Services (IIS)
If you're hosting a website on IIS, follow these steps:
Open IIS Manager.
Click on Sites in the Connections pane and choose the site bound with the SSL certificate.
In the Actions pane, click Bindings and check that your site has a binding for port 443 (HTTPS).
Click on Edit, and verify that the SSL certificate is selected.
Bonus Tip: Use SSL Labs’ SSL Test (https://www.ssllabs.com/ssltest/) for a comprehensive external validation of your SSL certificate configuration.
7.2 Checking SSL Certificates on a Linux Server
Linux servers offer several ways to check and validate SSL certificates. The OpenSSL command-line tool is most commonly used to inspect SSL certificates.
7.2.1 Using OpenSSL to Check SSL Certificate
You can quickly inspect SSL certificates using OpenSSL. Here's how:
Check an SSL Certificate on a Remote Server:
Use this command to inspect the SSL certificate of any domain:
openssl s_client -connect your-website.com:443
This will return details about the SSL certificate such as:
Issuer
Subject
Validity Period
Certificate Chain
Scroll through the output to verify these details, ensuring that the certificate is not expired and is properly issued.
7.2.2 Checking Local SSL Certificate Files
To validate the details of a locally stored SSL certificate file (for example, server.pem), use:
openssl x509 -in /path/to/your/certificate.pem -text -noout
This command will display information like:
The certificate’s subject (who it’s for),
The issuer (who signed it),
Validity dates (to check expiration), and
The public key used.
7.2.3 Verify SSL Certificate Chain
To check if your SSL certificate chain is correctly configured (i.e., if the certificate chain is complete), you can use the following command:
openssl verify -CAfile /path/to/your/ca.pem /path/to/your/certificate.pem
This will check if the certificate is correctly chained to a trusted Certificate Authority (CA).
08 Conclusion
Cryptographic protocols like SSL and TLS have continuously evolved to meet the growing demands of securing data in transit across the internet. From the early days of SSL to the current TLS 1.3 standard, improvements in encryption, authentication, and integrity have bolstered online security. Understanding these protocols and their components—such as cipher suites, key exchange methods, and encryption algorithms—is essential for ensuring secure communication in today's digital landscape.
Comments