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 week the SiteLock team gathered at the Tempe Mission Palms to attend and sponsor Pressnomics. If you’re not familiar, Pressnomics is a conference focused squarely on entrepreneurs and influencers who are committed to the WordPress community.
Malware comes in a great deal of unique shapes and sizes. Most people know someone who has had the misfortune of an infected computer at some point. Ransomware, trojans, and viruses that affect consumers’ physical devices are generally built with compiled code, which means you can’t easily “take a look under the hood” to get a solid idea of how it works.
This past weekend we found ourselves at WordCamp San Diego…and it was classy. This came as no surprise as the WordCamp theme was “Stay Classy,” a line taken from the comedy gem Anchorman set in the same city. SiteLock was a Gold sponsor (classy!) and along with our seasoned WordCamp goer Adam Warner, our own Web Security Consultant Managers, JC Bustillos and Evan Richardson, also attended the event.
We recently discussed a particularly sneaky piece of malware that’s been disguising itself as fake plugin and targeting Joomla! users. While this phenomenon is not unique to the Joomla! content management system, SiteLock has discovered a recent trending fake plugin for WordPress, one of the world’s largest open source applications.
The fake plugin the SiteLock Research team found is called WP-Base-SEO. It is a forgery of a legitimate search engine optimization plugin, WordPress SEO Tools. Malicious content was found in /wp-content/plugins/wp-base-seo/wp-seo-main.php. At first glance, the file appears to be legitimate, including a reference to the WordPress plugin database and documentation on how the plugin works.
Fake plugin header
This past weekend we found ourselves at WordCamp Atlanta, one of the largest WordCamps in the country. Because this event fell on the St. Patrick’s Day holiday, the theme was “Find your Pot of Gold with WordPress.” This theme was pervasive throughout the entire weekend, even the various speakers built this theme into their sessions!
SiteLock was lucky enough to sponsor the event (no pun intended) and Adam Warner, one of our staples in the WordPress community, had the pleasure of presenting his own story of finding WordPress.
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.
A Day of REST Boston was a one-day conference all about the WordPress REST API. Speakers included members of the team who are building the REST API, and developers using it in production websites. Attendees learned how to use the REST API for their projects, along with insights into best practices, tools, coding, and specific use cases.
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.
© Copyright 2017, SiteLock LLC.