Tag Archives: TLS

What is SSL or TLS Perfect Forward Secrecy?

5 votes, average: 4.20 out of 55 votes, average: 4.20 out of 55 votes, average: 4.20 out of 55 votes, average: 4.20 out of 55 votes, average: 4.20 out of 5 (5 votes, average: 4.20 out of 5, rated)

A look at perfect forward secrecy in SSL with TLS 1.3

If you’re here because you want to understand what “forward secrecy SSL” or “SSL perfect forward secrecy” means, then you’ve come to the right place. Perfect forward secrecy is a now-mandatory component of SSL/TLS. Starting in TLS 1.3, all key exchange methods must be ephemeral Diffie-Hellman families — not RSA, which doesn’t support perfect forward secrecy.

What is Forward Secrecy in SSL / TLS and How Does It Work?

So, what is perfect forward secrecy? First, let’s talk about key exchange. Historically, key exchange has been performed using RSA asymmetric encryption. This method had a number of problems — hence its removal in TLS 1.3 — including Oracle padding attacks and something called Bleichenbacher’s CAT (don’t ask). The biggest may be its lack of ephemerality, though.

An ephemeral key exchange is one that allows for the regular rotation of the session keys. This is necessary for perfect forward secrecy and is impossible with RSA. That’s owed to the fact that RSA uses massive keys and transacts in huge prime numbers that are expensive to compute. The toll it takes on a website’s servers make ephemeral RSA schemes impractical at best (also, impossible).

Diffie-Hellman key exchange, specifically its elliptic curve-based variants, is much easier to compute and allows for regular key rotation. It also facilitates SSL perfect forward secrecy, which is incumbent upon regular key rotation and ensures that even if the private key associated with that site’s SSL certificate — and the private key plays a role in the generation of those session keys — is ever compromised, the session keys cannot be deciphered.

Normally, when your private key is compromised, it means that everything is compromised. The attacker will have no problem deriving keys from previous sessions and decrypting the information. SSL/TLS perfect forward secrecy prevents that, adding an additional layer of security to each session key beyond the computational hardness provided by the private key.

When Does SSL Perfect Forward Secrecy Become Effective?

Starting TLS 1.3, all SSL/TLS implementations will use perfect forward secrecy. It’s also advised that you stop using RSA key exchange and switch to an ephemeral Diffie-Hellman family in TLS 1.2 to enable forward secrecy there, too. If you’re running on a server that doesn’t currently support it, try updating your SSL/TLS software library to see if that helps. If not, it may be time to change servers.

Save Up to 80% on DV SSL Certificates

Protect a website in a few minutes with DV SSL or Domain Validated SSL Certificate.

Get a DV SSL certificate, starting at $12.42/year

The Difference Between Public Key and Private Key Explained

6 votes, average: 3.67 out of 56 votes, average: 3.67 out of 56 votes, average: 3.67 out of 56 votes, average: 3.67 out of 56 votes, average: 3.67 out of 5 (6 votes, average: 3.67 out of 5, rated)

What is the difference between private key vs public key encryption? It may not be what you think

“SSL Public Keys and SSL Private Keys are like ebony and ivory, living together in perfect harmony. Side-by-side on the piano keyboard, oh Lord, why don’t we.” — Paul McCartney and Stevie Wonder, when they addressed the difference between public and private keys in cryptography.

The above quote about public keys and private keys is fake, obviously. But we know if got your attention. Now, without further ado, we’ll explain the difference between public key and private key encryption.

Public Key vs Private Key Cryptography

In SSL, and in public key infrastructure (PKI) in general, keys are used to perform a range of cryptographic functions. When a client arrives at a website, the two use their public and private keys during a process called the SSL handshake. That handshake creates a third key, what’s known as a session key, to communicate during the connection.

A session key is symmetric, meaning it’s capable of both encrypting and decrypting. They tend to be smaller, but perform better and still offer ample security. When you communicate online, you’re using one of those symmetric session keys. You don’t use the public and private keys to communicate. Anyone that tells you that is a Charlatan and you should smite them where they stand.

The Roles of Public Keys vs Private Keys in Encryption

So, what do the public and private key do? Well, probably not what you think. Public/private key pairs are asymmetric — the public key can encrypt, and the private key can decrypt. Historically, when the RSA cryptosystem is in use, the public/private key pair handles the transmission of the session key. After all, how else would you exchange and encryption key securely?

Graphic: difference between public and private key -- this is an illustration of asymmetric encryption.

With RSA key exchange, the pre-master secret that will be used to derive the session key is encrypted with the public key, sent to the server and decrypted with the private key.

How These Roles Have Changed in TLS 1.3

In TLS 1.3, RSA key exchange was banned. So… this means there’s no longer asymmetric encryption in the handshake.


So, what do the public/private key pair do now? Digital signature authentication. Owing to the nature of the two keys, the public key can be used to verify signatures left by the private key. When a client is presented with a certificate, it uses the corresponding public key to trace the signatures back up the certificate chain and to its root store.

This is now the only use case for the public/private key pair as of TLS 1.3.

Save Up to 82% on DV SSL Certificates

Protect a website in a few minutes with a Domain Validated SSL Certificate (DV SSL).

Get a DV SSL certificate, starting at $12.42/year


7 votes, average: 4.00 out of 57 votes, average: 4.00 out of 57 votes, average: 4.00 out of 57 votes, average: 4.00 out of 57 votes, average: 4.00 out of 5 (7 votes, average: 4.00 out of 5, rated)

A primer on what each of these encryption terms entails and their impact on website security

TLS vs SSL vs HTTPS. So many acronyms, so little time. All of these terms relate to encryption and website security — however, many people who don’t spend their days entrenched in cyber security may not be intimately familiar with them.

HTTPS, an encrypted and secure networking protocol, is what we get when we use SSL/TLS to secure websites. You know how there’s a padlock security indicator in your browser’s address bar? Yeah, it’s because of that (and other things we aren’t going to get into here).

One of the most common questions we get regarding the topic of TLS vs SSL is “what the difference is between SSL and TLS?” The confusion makes sense, in a way. After all, SSL and TLS aren’t exactly the same thing, but they serve the same function.

So, how do we split the difference?

And the answer to that is incredibly technical — far more technical than most people care to go. So, we’re going to summarize it for you so you can rent it space in your brain at the expense of some other far more relevant piece of information. Say goodbye to the Pythagorean Theorem — we’re about to talk about SSL and TLS.

SSL — The OG

SSL, or secure sockets layer, was the original lynch pin of public key infrastructure (PKI). Initially, the internet was not designed for commercial use. It was basically just a network for the military and academia in its earliest iterations. As commerce and other vital services crept online, the need for data security arose. Unfortunately, HTTP or the Hypertext Transport Protocol, was never designed for security, so a mechanism needed to be invented to secure it.

Thus, SSL and HTTPS were born. The first couple of SSL versions were failures and never really got off the ground. SSL 3.0 was eventually released but was quickly found to be vulnerable to several exploits, too. That was 1996.

Enter TLS

TLS, or transport layer security, was created in 1999 as kind of a spiritual successor to SSL 3.0. It’s based on SSL, but there’s one really important, key difference — this isn’t the House of Saxe-Coburg and Gotha renaming itself the Windsors as a branding move — it’s an actual functional difference.

Knowing the Difference: SSL vs TLS

What’s the difference between SSL and TLS? SSL makes it connections by port. In computer networking, a port refers to a memory address that’s used to help organize traffic during a connection. This occurs at the transport layer of the connection; individual services have dedicated ports. 443 is the port for HTTPS. 80 is the port for HTTP. 21 is for FTP and so on. There are 65,535 ports total, and only a set few are dedicated to a particular service or function.

Since SSL makes its connections via port, it starts with port 443 for an HTTPS connection. This is called an explicit connection, and the port expects a negotiation before the session begins.

TLS, on the other hand, connects via protocol. This is an implicit connection. It begins with a client hello via an insecure channel to the server. Once the handshake commences, the connection switches to the correct port (443).

A lot of the other parts are basically the same. Both protocols authenticate and facilitate encryption. They both negotiate with handshakes. It’s the way that initial connection is made that differentiates the two. The security they both provide is exactly the same.

Problems with TLS

TLS is, by no means, faultless. While SSL was riddled with vulnerabilities, the early iterations of TLS also had their fair share of hiccups, too. POODLE, which stands for Padding Oracle On Downgraded Legacy Encryption, is a padding attack that can be used against block ciphers. This sick little puppy was basically the final nail in SSL 3.0’s coffin. They thought they fixed it with TLS. Needless to say, they were mistaken.

As it turns out, POODLE didn’t die. We still seeing variants of POODLE to this day. There are also exploits like downgrade and stripping attacks that take advantage of the backward compatibility that was included in TLS in the name of interoperability.

TLS 1.0 and TLS 1.1 are now considered insecure, with the major tech companies planning a mass deprecation of both by January 2020. TLS 1.2 is the current standard while TLS 1.3 was just finalized in Summer 2018.

TLS 1.3 Looks Toward the Future

TLS 1.3 will change SSL/TLS forever simply because it’s not backward compatible with any of the previous protocol versions. Currently, you have to support TLS 1.2 and 1.3 side by side, as users can’t roll back to 1.2 from 1.3.

In addition to eliminating backward compatibility, which should kill off older protocol versions, TLS 1.3 made several significant improvements over previous iterations:

  • It reduced the handshake, which adds latency to connections, to a single roundtrip and added 0-RTT resumption.
  • It eliminated older ciphers that have been found vulnerable, like RC4 and RSA.
  • It reduced the number of negotiations made during the handshake to just two.

What’s Better: TLS vs SSL

Given their similarities, and the known vulnerabilities facing SSL, this really should only be asked rhetorically. You did mean this rhetorically, right?

If you’re still supporting SSL, you’re only inviting trouble. Even supporting earlier versions of TLS is ill-advised. You should be using TLS 1.2 and TLS 1.3 by now.

SSL may be TLS’ predecessor, but it’s seriously outmoded now. Even if it’s still what we use colloquially to refer to TLS.

The Types and Validation Levels of SSL Certificates

There’s a lot to know about SSL certificates and their validation levels. We’ve got you covered.

Learn More About the Types of SSL Certificates

How to Fix ‘ERR SSL VERSION INTERFERENCE’ in Google Chrome

3 votes, average: 3.67 out of 53 votes, average: 3.67 out of 53 votes, average: 3.67 out of 53 votes, average: 3.67 out of 53 votes, average: 3.67 out of 5 (3 votes, average: 3.67 out of 5, rated)

What causes the “This site can’t be reached” Chrome error & how you can fix it

The internet is full of many things: cat videos, pornography, questionable social media posts, and bad advice. Lots and lots of bad advice. Anytime you search for help with a browser error, you’re bound to wade into a pool that’s waist deep with highly-optimized SEO content that doesn’t actually answer the question properly. Or, if it does, but it then offers egregious advice on working around it.

The Google Chrome ERR_SSL_VERSION_INTERFERENCE (sometimes written “ERR SSL VERSION INTERFERENCE”) is a perfect example of this. Most of these garbage answers start off with some keyword stuffed boiler plate language about how common SSL errors are.

Shade aside, there aren’t “many reasons” for this problem. There’s one reason only. And, aside from adjusting their protocol version support, there’s nothing that a user could responsibly do to solve this problem. Advising anything else is patently irresponsible and should be punishable by flogging.


The reason you get the “ERR_SSL_VERSION_INTERFERENCE” in Chrome is that the website you’re attempting to visit doesn’t support a mutually agreeable TLS protocol version. The most common iteration is one of you — either as the client or the server — is exclusively supporting TLS 1.3 and the other doesn’t support it at all.

TLS 1.3 is not backward compatible with former versions of the protocol. While this may initially seem like an oversight, it’s done quite a on purpose. Older versions are susceptible to oracle padding and downgrade attacks. The vast majority of the internet is still using TLS 1.2, but about 35-40% of the Alexa Top 100,000 have begun supporting TLS 1.3. The smart move would be to support both 1.2 and 1.3 until the latter achieves the right degree of proliferation.

Unfortunately, some sites have already turned off support for 1.2 in favor of 1.3. For most modern browsers, this won’t be an issue. But if you’re running an older version, or you don’t have support for 1.3 activated on your OS, you could run into this problem.


Provided your browser supports TLS 1.3 and TLS 1.2 — and with Chrome, that’s actually a decision made on the OS level — there’s not anything you can do to fix this beside contacting the site owner. Some of the bad advice you might see with regard to solving this from the client side includes:

  • Trying to reach the site in guest mode
  • Clearing your cache and data
  • Disable/Uninstall Security Programs
  • Disable TLS 1.3
  • Reset Chrome

The first two have absolutely no impact on this error. The next two are so egregiously bad as to actually pose a threat to anyone who heeds them. While resetting Chrome — or perhaps more appropriately uninstalling and then reinstalling it — might work, it means you had bigger problems than the ERR_SSL_VERSION_INTERFERENCE error if it does fix it.

Fixing ERR_SSL_VERSION_INTERFERENCE in Chrome If You’re a Site Owner

Chances are you’ve misconfigured your servers. The most likely explanation is you disabled version support for everything but TLS 1.3. This is very forward-looking of you but, ultimately, a little premature.

The other possibility is that you’re using an earlier version of TLS 1.3. It took 28 drafts to finally nail down TLS 1.3, but popular browsers and servers added support for it way before it was finished. Older versions don’t always play nicely. So, you might have TLS 1.3 enabled, but it’s an early build and you need to update the implementation.

Either way, it comes down to configuration.

Here’s some other advice:

  • Check your SSL certificate
  • Update your antivirus and firewall

Neither of these are all that likely to fix the issue — but, occasionally, they might. Most likely though, when you receive the “This site can’t be reached” or “ERR_SSL_VERSION_INTERFERENCE” message, you just need to reconfigure your server settings.

Save Up to 82% on DV SSL Certificates

Protect a website in a few minutes with DV SSL or Domain Validated SSL Certificate.

Get a DV SSL certificate, starting at $12.42/year