Over the last year I’ve led a multitude of security workshops aimed to educate entry-level WordPress users about website security. Some of the questions I regularly field in these workshops are related to the mechanics of SSL certificates, and their role in protecting website data from prying eyes. As you may know, the installation of an SSL certificate on a web server allows the server to accept traffic on the hypertext transfer protocol (secure), or simply ‘HTTPS,’ the primary form of encrypted data transfer between websites and visitors. I’d like to share the answers to some of the most frequently asked questions I’ve had on the subject.
The first thing I’d like to clarify on the subject of HTTPS and SSL certificates specifically is that the use of SSL certificates and HTTPS do not in any way, shape, or form protect the data on your website itself. HTTPS encrypts data in transit only. Neither does it protect data resting on visitors’ computers. You should consider HTTPS the armored truck of websites, not the bank vault. It acts as the protection against adversaries while data travels from point ‘A’ to point ‘B’.
Did you know that most HTTPS connections are actually using TLS (Transport Layer Security) ciphers, not Secure Sockets Layer (SSL) ciphers? SSL ciphers have been phased-out in favor of newer TLS technology. Vendors continue to use the term SSL likely due to consumer familiarity with the term.
While SSL certificates form a very important part of your overall security posture as a WordPress website owner, the security of your website itself should instead be entrusted in security processes and mechanisms, such as a secure development life cycle (SDLC), the implementation of network and web application firewalls (WAF), and regular malware and vulnerability scans.
When it comes to the subject of encryption, I think most of us correctly visualize the rather abstract concept of jumbled words or characters so the original message is no longer legible, and thus protected from adversaries. However, few that I’ve encountered outside the security community have a firm understanding of what exactly the mechanics are behind that process. Encryption holds very ancient roots in human society, most obviously in military communications, where it’s designed to conceal the true message from enemies attempting to intercept to learn about troop movements and strategies. However, avoiding a verbose lesson in cryptographic history, for this article we’re going to focus on the concept of encryption and how it works in reference to modern websites utilizing SSL certificates for HTTPS.
Modern-day websites using HTTPS typically rely on a system called public key cryptography, also known as asymmetric cryptography, to protect data in transit. In public key cryptography the website owner generates a set of unique keys, one public key and one private key. The public key is as its name denotes, the non-private half of the relationship used by the public to facilitate private communication that can be nearly impossible to decode without possession of the associated private key. The integrity of this system depends entirely on both the secrecy of the private key and its strength against breaches. Much like if the keys to your house are stolen, if the private key is stolen, you are compromised and the only solution is to change the locks. This process is called re-keying in terms of SSL certificates.
Web servers will typically support a variety of different encryption ciphers. When you visit a website using an SSL certificate to provide HTTPS, a discussion occurs between your browser and the website server to communicate what ciphers you both support. The browser and website server will then agree upon the strongest common cipher to use. This process is called negotiation. Once your browser and the website server have agreed upon a cipher to use, the web server provides your browser a public key to use for the initial encryption of the data your browser wishes to send. Once this asymmetric key relationship has been established, a second symmetric key relationship is formed using the same cipher already agreed upon and the initial public key so that both parties can encrypt and decrypt messages from each other.
The reason that both asymmetric and symmetric keys are used in these communications is due to the initial stages where an agreed upon cipher has to be transmitted over plain text, and the following communications are what need to be protected. As a result, the website server hands your browser the method for keeping the main symmetric keys safe by providing its public key in the beginning of the conversation, essentially providing two layers of protection for the data that follows.
Not all ciphers are created equally. The strength of a cipher is determined by the difficulty involved in reversing encrypted data back to plain text without possession of its associated private key. This is measured in the time and computational resources required to complete the process. Some ciphers would take hundreds of thousands of years to reverse by the current modern computational power available, where as other older ciphers may now only take but a few minutes to break. Cipher generations evolve relative to the average computational power available to the public because while we want our data to be secure, we also demand that websites load quickly. The strongest ciphers generally create messages that take a long time to decrypt, so a balance must be struck between speed and security. As computers become faster, we are able to use stronger ciphers without sacrificing speed. On the other side of the coin, we must increase security because computers are able to break encryption with more ease. This is why you may hear about ciphers becoming outdated or obsolete. Modern encryption has become an arms race between brilliant mathematicians and their computers, and hackers and theirs.
Have a question for our security professionals or a topic that you would like us to write about? Message @SiteLock and use the #AskSecPro tag!
Last year we published an #AskSecPro series where we explained how signature-based malware analysis works, as well as how traditional signatures are created. An area we don’t often talk about in public channels, but has played a pivotal role in SiteLock becoming a global leader in website security solutions, is our research and development efforts in new security technologies. In addition to our more traditional approaches to malware detection, SiteLock continues to explore new frontiers in technological improvement to push the field of security research forward. For some time SiteLock has been developing machine learning mechanisms as part of its process for discovering new malware iterations on an automatic basis. Our research in the field has shown that machine learning promises to be an important part of early malware detection and preliminary identification. One of the most significant breakthroughs we’ve had in machine learning as it pertains to malware detection and signatures, has been in feature-based signature analysis.
In Part One of our #AskSecPro series on WordPress Database Security, we learned about the anatomy of WordPress. Now that we have a firm understanding of the role the WordPress MySQL database plays in a WordPress installation, we can take a look at the various ways an adversary can exploit the mechanisms involved. We’ll also explore some of the ways to defend your database against compromise.
Over the last few days you may have heard the term #Cloudbleed thrown around the water cooler. Some of the questions our customers are asking us include, “What is Cloudbleed?” and “Am I protected from Cloudbleed?” As your resident Security Professional, I’ll be glad to help you to understand what the Cloudbleed buzz is all about and how it may impact you.
— First, I want to be very clear that the Cloudbleed bug does NOT impact SiteLock TrueShield™ WAF/CDN. More below.
For most people the year is still just getting started, but for some website owners the year has already packed quite a punch in the form of website attacks. This month hackers exploiting a vulnerability in the WordPress REST API successfully defaced over a million websites in what has become one of the largest website defacement campaigns to date. The attacks injected content that overwrote existing posts on WordPress websites running versions 4.7 and 4.7.1, leaving website owners with an immeasurable number of “Hacked by” posts across the droves of impacted websites.
Many website owners who have unfortunately found themselves in the proverbial trenches of a digital battlefront, some of which had at least some security measures, are facing a difficult data recovery situation. It is from these recent events that the next Ask a Security Professional question was crafted; How can I better protect my data?
I feel that it’s important to fully understand what the problem is in order to best understand what forms a solution can take. In Part One of #AskSecPro we’ll cover an introduction to some of the infrastructure behind WordPress. Let’s start at the beginning.
So far in this #AskSecPro DDoS series we’ve covered both Application Layer DDoS Attacks and Protocol-Based DDoS Attacks. We’ve also identified the differences between a DoS and a DDoS attack. In this final segment of the DDoS series, we’ll discuss the third category of DDoS attacks, Volumetric Attacks, also known as Volume-Based Attacks
Continuing our #AskSecPro DDoS series where we last discussed Application Layer Attacks, today we’ll focus on some of the most popular protocol-based DDoS attacks we’ve seen hit our customers’ web application firewall, SiteLock TrueShield™, over the years. TrueShield™ is SiteLock’s distributed cloud-based web application firewall (WAF) with the capability of defending against attacks across layers 3, 4, and 7.
In our last #AskSecPro article we discussed the differences between a DoS and a DDoS attack. Now that we understand what a DDoS attack is in concept, let’s learn a little more about the mechanisms involved in these attacks. In Part Two of the DDoS Attacks series we’ll focus on some of the attack vectors utilized by adversaries when launching a denial of service attack.
There’s a lot of buzz going around in many online communities concerning the recent distributed denial of service (DDoS) attacks the world has witnessed. In many of my own circles I’m often the only security guy in the room so I end up fielding a lot of questions, the most common of which is, “how do they do this stuff?!” In this District #AskSecPro series, I’ll be explaining the anatomy of D/DoS attacks and the practical weaponization of regular computers.
There are times when a website may want to send a visitor to another page either immediately or after a specified amount of time (usually seconds). As an example, consider an outdated page that you believe your visitors have bookmarked – You don’t want to lose the traffic, so you just automatically redirect them to another page. While less common today, these redirects and forwards do still exist, but if not setup properly, they could pose an outside risk to your online presence.
While there are many ways to create a redirect or forward, the exploit in this case boils down to the destination URL being included in the address bar for the source page. When the redirect or forward is activated, the application will read the destination URL from the address bar and forward a user to that address. Consider this example source URL:
We can see here that the “About Us” page is being redirected back to the home page. The problem with this is that there is potential for anyone to take that full URL and insert their own redirect destination address and then send it to a site’s users. From there, depending on that source page, users’ could be tricked into thinking they are still on the source site. These unvalidated redirects/forwards could ultimately lead to a phishing scam in which users are fooled into giving up sensitive information about themselves.
© Copyright 2017, SiteLock LLC.