Is SSL really a sign of security?
Reading time: 10 minutesOver the past few years, we've seen SSL/TLS growth like never before.
And that's due, in part, to a series of events boosted by companies like Google with their famous announcement of HTTPS as a ranking signal, Mozilla, Cisco, Akamai, other big players with the Let's Encrypt project, cPanel's free AutoSSL features released to the web hosting industry, and many others making strides toward a better, safer internet.
It's been a while since the SSL ball started rolling, and today almost all professional websites have SSL/TLS encryption implemented.
And yet, the phishing attacks keep coming. Banks and financial institutions get hacked. E-commerce stores suffer massive data breaches. Shouldn't the web be more secure by now?
The truth is, while technical experts in the IT industry know the importance of SSL certificates, and are well-versed in measuring SSL security levels, many bloggers, webmasters and entrepreneurs don't realize that even if their site is labeled 'secure' or bears the 'padlock' icon in the browser URL bar, they can still get hacked—and easily.
Google Chrome will soon change the way it refers to an HTTPS encrypted webpage, by removing the classic padlock security icon. Image Courtesy of Google.
A website using an SSL/TLS certificate may or may not be truly secure. It depends on a number of factors.
In past blog posts about SSL, we've mentioned the cybersecurity issues surrounding stale DNS records and free SSL certificates. Today we'll move a step forward and find out why having an SSL/TLS certificate doesn't automatically mean that your site is "secure," and why—thanks to free SSL—some types of cybersecurity attacks are now even more difficult to detect for the average non-technical user.
- HTTPS doesn't mean your site is secure
- How "secure" is your SSL/TLS certificate?
- Phishing domains and SSL certificates
- SSL expirations: the unseen enemy
- Conclusion
HTTPS doesn't mean your site is secure
It's quite normal to see SSL or web hosting providers advertising that you need to acquire an SSL certificate to make your site secure. It isn't a lie, but it isn't entirely true either.
There's a common belief that users must always look for the green padlock or the word "Secure" at the top of the browser's URL bar to identify a website as, just that, "secure." Yet the very concept of a secure website remains open to debate for many.
Securing your web application utilizing the best code-security practices is a good starting point, but the hardening part doesn't always end up in the application layer. What if your app is secure at the code level, but you're hosting the app in an insecure server environment?
Hardening your server stack is one of the most important things you need to consider.
This is often a very complicated task, requiring the hands of experienced Sr. System Administrators to secure all services at the OS level.
We're not only talking about securing the HTTP server (Nginx, Apache, LiteSpeed, etc), PHP or your MySQL database; that's just the "surface" area. The process also involves OS hardening and updating, kernel tweaking and patching, network hardening, OpenSSH, DNS auditing and DNS server hardening to prevent DNS attacks. There are so many things to fix at the server and network level!
And hardening your server-side stuff doesn't end there. Is your web application hosted in a VPS or cloud environment? If so, there's a chance that the master-node (where all virtual machines are hosted) could also be exploited, thanks to running software that isn't hardened and constantly patched against latest vulnerabilities.
At this point you might think: 'All right, my application is secure at the code level, my server-stack is secure, great, I'm done!'. Not so fast. You're missing one of the key components in hardening an HTTPS-based application, and that's SSL/TLS hardening.
While most system administrators do a good job hardening the classic LAMP stack, they tend to forget about SSL hardening, a key factor in dealing with data encryption.
Think about it. Your site may have an SSL certificate installed, but your server allows SSL 3.0 protocol, or it's configured to use lightweight cipher suites that can be easily cracked by known exploits.
In other cases, users who install SSL certificates on their own often forget to install intermediate certificates, making the SSL chain less secure..
How "secure" is your SSL/TLS certificate?
Let's suppose your web and server-network stack is secure. Is your SSL security at the top level? How can you test your SSL security?
For this, let's refer to one of the top SSL testing websites in existence, Qualys SSL Test.
This SSL deep security test will run a full test against your SSL server configuration. It's honestly the best SSL security testing tool available on the Internet, and 100% free for anyone who wants to run a full SSL audit.
It can scan both IPv4 and IPv6 addresses, giving you a security grade ranging from F to A+, as you can see below in our scan against the domain name www.wikipedia.com:
By clicking the IP address you'll get a detailed report on how hardened your SSL security is right now. This is calculated from several tests conducted against the certificate, protocol support, key exchange, and cipher strength:
Even if your SSL security grade is an A+, you're bound to find several things to examine when it comes to hardening the protocols and cipher suites used in your SSL encryption.
In this case, wikipedia.com shows they're supporting old TLS 1.0 and 1.1 protocols, as well as a few old, weak cipher suites that can make the server prone to several types of attacks:
The app also shows detailed information about critical, known SSL-based vulnerabilities such as BEAST attack, POODLE (SSLv3), GOLDENDOODLE, Heartbleed, etc.
As we've seen, a lot of websites still use weak ciphers and vulnerable TLS protocols. This is normal when it comes to low/mid-size websites, but what can happen to high traffic websites or government agencies, those expected to have high skilled cybersecurity teams?
We went to our Fortune 500 domain list and picked a few random domains to check out their level of security. What we found was that a lot of them were prone to several types of SSL vulnerabilities, including Grade B and C for supporting insecure ciphers in TLS 1.2, supporting weak Diffie-Hellman key exchange parameters, as well as direct exposure to to Zombie POODLE vulnerability.
On the other hand, we found fbi.gov to be one of the best hardened SSL-based websites among the major government agencies we tested, while others like nsa.gov or whitehouse.gov use a lot of weak ciphers for the TLS 1.2 protocol:
As you can see, finding the right balance between proper SSL/TLS security and avoiding the loss of many visitors (or even worse, potential customers) due to browser incompatibilities is a difficult task that almost all online businesses and companies must face sooner or later.
Using the Qualys SSL Test is a good way to start. However, there are also other useful resources, such as SecurityHeaders.io, a full HTTP-security test tool created by Scott Helme.
This tool will perform a full HTTP and HTTPS header analysis that includes several test areas such as Strict-Transport-Security, X-Frame-Options, Content-Security-Policy, X-Content-Type-Options, X-XSS-Protection and Referrer-Policy Feature-Policy.
Along with the results, you'll be provided with general guidelines on how to fix these weaknesses.
Phishing domains and SSL certificates
Since the announcement of free SSL certificates, the infosec community has discussed how they could be used by attackers. And with good reason.
A Netcraft publication from 2015 reported that numerous certificate authorities were issuing SSL certificates for domain names involved in phishing activities. In a 2018 blog post, Brian Krebs confirmed that half of all phishing domains use SSL/TLS certificates.
Yes, that's a harsh reality. There's no doubt that benefits can be obtained through the adoption of massive free SSL certificates, but they can, and often are, turned against users.
Today, phishing attackers use free SSL certificates (in some cases even paid ones) to look like legitimate websites, as a ploy to gain trust from non-technical users. Then, they obtain sensitive information once users send the requested data.
SSL encryption has been always around, but phishing attacks found its usefulness through projects like Let's Encrypt. It's always been possible to validate SSL certificates for any domain in your control, but the free availability of Let's Encrypt sealed its popularity with regard to phishing attacks.
Let's Encrypt shared on this topic back in 2015, essentially stating that DV (Domain Validation) SSL certificates are advised to secure data transfer between websites and browsing clients.
In that blog post, The CA's Role in Fighting Phishing and Malware, they literally stated:
Treating a DV certificate as a kind of "seal of approval" for a site's content is problematic for several reasons.
And that's where the problem resides. The media, the web hosting providers, as well as the SSL providers in their efforts to promote the adoption of this encryption technology, have missed their opportunity to correctly inform non-technical people what an SSL certificate is, and how to differentiate between SSL and an actual secure website.
SSL expirations: the unseen enemy
In the same way that domain names have their expiration day set since initial registration, SSL/TLS certificates work by setting public records of both the issue date and expiration date.
This information can be retrieved by anyone, letting others know when your critical and sensitive data will no longer be encrypted between the server and its visitors.
It's not unusual to detect expired SSL certificates on many websites, often because the renewal email has fallen into the spam folder, or as a mere matter of forgetfulness.
That's why knowing the exact renewal date for all your SSL certificates is useful on both fronts: for the attackers who can trace and track each one of your SSL certificates; and for you, the website owner, to keep all your SSL's renewed in a safe and timely fashion.
Let's Encrypt SSL certificates aim for automatic renewal, but all too often the domain validation process can fail on the remote servers, or be blocked by random reasons (.htaccess misconfiguration, wrong directory permissions, security firewalls, etc) that may lead to your site's unencryption with an expired SSL.
Regularly, this problematic renewal process doesn't happen with paid certificates, where other domain validation methods are taken into account when you decide to renew your certificate.
Tip: For a deeper insight into how to analyze SSL certificates, jump over to the following article: Analyzing SSL Certificates with SurfaceBrowser.
Users need to keep a closer eye on the type of SSL renewal process they use with their SSL certificates, as well as their exact expiration dates, to avoid losing traffic or getting hit by targeted expired-SSL-based attacks (man in the middle attacks, for example).
Conclusion
SSL/TLS certificates are here to stay. Thanks to companies like Google, Mozilla and others, most of the crucial information that is sent and received over today's network is encrypted.
However, too many websites using SSL/TLS certificates still do not follow best-recommended practices to harden their encryption mechanisms.
Having an SSL/TLS certificate implemented correctly can save your business and protect the privacy of your users and their sensitive information. That's why it's so important to keep your ciphers and SSL protocols updated to maintain the highest level of security—although if you set this too hard, your visitors may not be able to use some of your products or pages, due to browser incompatibilities.
Also, having an SSL/TLS certificate installed doesn't mean you'll never be hacked. While it can help prevent certain types of attacks, you'll be exposed to exploits and vulnerabilities over your web applications if other critical areas are not well-hardened.
Do you want to access the DNS, IP, and domain name shadow infrastructure data about any HTTPS-based website? Book a SurfaceBrowser demo today!
