Is HTTPS Really Safe? Unveiling the Risks Behind Secure Connections

The internet has become an integral part of our lives, and with that comes a growing concern about online security. You’ve likely noticed the padlock icon in your browser’s address bar when visiting websites – this signifies an HTTPS connection. But how safe is it really? This blog post delves into what HTTPS is, why it exists, and explores some surprising vulnerabilities that can arise even with seemingly secure connections.

The Background: Why We Need HTTPS

For quite some time, I’ve been running multiple HTTP servers on my personal server for testing purposes. These public-facing applications often attract unwanted attention – attempts to access environmental credentials or probe for exposed Git repositories. This experience prompted me to investigate how quickly new domains become targets for malicious activity. Initially, I suspected that the domain registration process itself might be leaking information, potentially notifying attackers of newly available servers. However, further investigation revealed a more nuanced issue: the very act of securing a website with HTTPS seems to attract attention.

When I created simple HTTP (unsecured) servers, I observed significantly fewer attempts to connect compared to those protected by HTTPS. This difference highlighted a crucial point – HTTPS isn’t just about encryption; it’s about how its implementation exposes information that can be exploited.

What is HTTPS and Why Does It Matter?

HTTPS stands for Hypertext Transfer Protocol Secure. It’s essentially HTTP, the foundation of data communication on the web, but with an added layer of security provided by Transport Layer Security (TLS) or its predecessor, Secure Sockets Layer (SSL). This encryption protects data transmitted between your browser and the website server, preventing eavesdropping and tampering.

The key component here is the certificate. To obtain an HTTPS certificate, you typically use services like Let’s Encrypt (LACERT), which automate the process. This seemingly simple act has a surprising side effect: it registers the issuance of a new certificate with public registries.

The Unexpected Vulnerability: Certificate Registries and Subdomain Discovery

The core issue lies in how these certificate authorities (CAs) operate. When you request an SSL/TLS certificate, the CA records this information. These records are then stored in publicly accessible databases. This is where the problem arises – these registries can be exploited to discover subdomains associated with a given domain.

Here’s how it works:

  • Certificate Issuance: When you create a certificate for a subdomain (e.g., test.example.com), the CA registers this issuance.
  • Public Registries: These registries hold records of certificates issued, including the associated domains and subdomains.
  • Subdomain Profiling: Attackers can query these registries to profile domains, identifying previously unknown or unregistered subdomains. This allows them to target those newly discovered subdomains with malicious probes.

Essentially, by simply securing a website with HTTPS, you’re inadvertently announcing its existence to potential attackers through the certificate registration process.

How Attackers Exploit This Information

Once an attacker identifies a new subdomain, they typically launch automated attacks targeting common vulnerabilities:

  • Credential Checks: Attempts to access default login pages or test for exposed credentials.
  • Git Repository Probes: Searching for publicly accessible Git repositories containing sensitive information.
  • Secret Hunting: Scanning for files containing API keys, passwords, or other confidential data.

These attacks aren’t sophisticated human-driven efforts; they are automated scripts designed to quickly scan and exploit vulnerabilities.

Mitigating the Risks: Defense in Depth

While HTTPS is essential for securing your website, it’s not a foolproof solution. Here’s how you can strengthen your defenses:

  • Fail2ban: This intrusion prevention framework monitors log files (like SSH login attempts) and automatically blocks IP addresses exhibiting suspicious behavior. I use Fail2ban to protect my Raspberry Pi against unauthorized access, and it can be adapted for other services as well. Link to Fail2ban article
  • IP Address Blacklisting: Utilize publicly available IP address blacklists to proactively block known malicious sources. These lists are often updated regularly and can be integrated into your firewall or security scripts. I’ve found two useful providers: Spamhaus Drop List and Emerging Threats Compromised IPs.
  • Automated Scripting: Develop scripts to automatically download, merge, and apply IP address blacklists to your firewall (e.g., using iptables). This ensures that you’re always up-to-date with the latest threat intelligence. The script should:
    • Download blacklists from providers.
    • Merge duplicate entries into a unique list.
    • Maintain a whitelist of trusted IP addresses.
    • Periodically update firewall rules based on the blacklist.
    • Include logging for auditing and troubleshooting.
  • Sanity Checks: Regularly review your firewall configuration to ensure that legitimate IP addresses aren’t accidentally blocked.

A complete script can be found below.

Some content is only available for the people who support me. If you would like to access that content consider buying me a coffee ☕. Thank you!

update_blacklist.sh


This script can be run daily as a cron job to keep your firewall updated with the latest threat intelligence. Make it executable and then add an entry to your crontab like so:

chmod +x /path/to/update_blacklist.sh
crontab -e

Insert the following line to run the script daily at midnight:

0 0  * * *  root  /path/to/update_blacklist.sh

Conclusion: HTTPS is Necessary, But Not Sufficient

HTTPS remains a cornerstone of online security, providing essential encryption and data integrity. However, the process of obtaining and registering certificates inadvertently exposes information that can be exploited by attackers. The key takeaway is that relying solely on HTTPS isn’t enough. A layered approach to security – combining HTTPS with proactive measures like Fail2ban, IP address blacklisting, and automated scripting – is crucial for protecting your online assets.

Remember, the internet landscape is constantly evolving, and new vulnerabilities are discovered regularly. Staying informed about emerging threats and implementing robust defense-in-depth strategies is essential for maintaining a secure online presence. Don’t just rely on the padlock icon; actively work to strengthen your defenses!

Additional Resources:

Enjoying the content? Buy me a coffee ☕ and help keep new posts coming!
Your support fuels fresh articles and keeps this space free of ads. Thank you for being part of this journey!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.