Ask a Security Pro: What Is Website Encryption?

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.

HTTPS and SSL Certificates

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.

What Is Website Encryption?

When it comes to the subject of website 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 modern website encryption and how it works in reference to 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!