When you use the internet, your computer has a conversation with a web server for every site you visit. Everything you submit in a form, any data you enter, becomes part of that conversation. The purpose of encryption is to ensure that nobody except you and the server you’re talking to can understand that conversation, because often sensitive information such as usernames and passwords, credit card data, and social security numbers are part of that conversation. Eavesdropping on these digital conversations and harvesting the personal information contained therein has become a profitable industry. But encryption isn’t an on/off switch. It requires careful configuration. In other words, the padlock isn’t always enough.
In the early days of the internet, SSL encryption was usually phased in on a handful of “secure pages,” such as login and payment forms, while the majority of the site remained unencrypted. The logic behind this was that, yes, most of the conversation is in plain text that anyone could read, but the important parts of the conversation are encrypted so that sensitive information can’t be lifted by potential attackers. Most websites followed this pattern initially, sprinkling encryption here and there as needed. Now, in 2016, many sites that have been around since the 90s (or configured like they were) still have the same encryption setup. But the threat landscape has evolved since the early days of the internet and bouncing people back and forth between encrypted and unencrypted connections can cause issues for several reasons.
Man-in-the-middle attacks exploit these types of redirects and handoffs to send people to fraudulent pages instead of what they expect. The fraudulent page will usually even have an SSL certificate installed, meaning that the padlock will show up in your browser and say that you are on an encrypted connection. These pages will often spoof whatever page they redirect for the purpose of capturing credentials and other information and storing them in the attacker’s database for later use.
If a website does not require its cookies to be transmitted over an encrypted connection, those cookies can be read by an attacker and used to impersonate people back to the website, a dangerous proposition for most personal sites these days. The Secure cookie flag protects against this, but can only be used by a site with a very wide, if not total, encryption setup.
Pick-and-choose encryption requires human intervention to say “this page should be encrypted and this one shouldn’t,” which, given the sheer quantity of pages and sites within even a single enterprise, will eventually lead to error. This error is usually failing to encrypt a page that should be secure. Therefore data from this page will be transmitted in plain text. If, for instance, a password is part of that page, that password is now simple to compromise for anyone looking to do so.
Considering what can happen with a selective encryption setup, we have to ask the question: why not just encrypt the entire conversation?
Search for "free vulnerability scanner" and you'll see plenty of options. So why are breaches due to known vulnerabilities still so common?
If we go back to the early days of the internet, there was the question of performance. Encryption requires additional processing power to encode and decode the messages as they are sent back and forth. When bandwidth was dear and every byte precious, it might have made financial sense to limit encryption as much as possible to keep the user experience responsive. In 2016, we’re shipping billions of HD video streams across the internet at the same time, playing multiplayer HD video games with people around the world, transacting more online business than ever and a whole host of other things that make the performance dip caused by encryption negligible to the point of invisibility.
Likewise, older browsers may not have always supported certain encryption schemes, so companies were wont to avoid it, so as not to alienate customers with incompatible browsers. However, internet use has become ubiquitous and nearly everyone uses one of the big browsers, and all of them have ramped up releases to keep up with security protocols. In fact, many security changes are now driven by the browser manufacturers when they decide to stop supporting older, insecure protocols or ciphers. Encryption is no longer a compatibility issue.
Is it more expensive to encrypt the entire site? Nope. An SSL certificate covers at least an entire site, such as www.upguard.com. Any pages hosted on that site can be encrypted using that one certificate. So in a sense, it’s actually a waste of money to selectively encrypt pages, since you’re already paying for the site certificate. A handful of relatively minor configuration changes on the web server will enforce SSL encryption across the board and redirect unencrypted connections to the proper channel, so administrative overhead shouldn’t be a problem.
"To answer our earlier question: there is really no good reason to leave parts of the website unencrypted."
To answer our earlier question: there is really no good reason to leave parts of the website unencrypted. It’s a legacy practice that has stretched out into a time when the environment calls for something different. The digitization of business often leaves security as an afterthought— after something goes really bad, everyone wishes they had thought about it before. Advances for big enterprises are often reactions to a major outage or data breach that did a large amount of financial and reputational damage to the company. Implementing sitewide SSL/TLS encryption is something organizations can do now to get ahead of the game, and protect their customers from the attacks and vulnerabilities mentioned above.
To make things even more complicated, many pages pull in items from various sources, such as images, scripts and ads, which may or may not be encrypted. Although it looks like one webpage to a person, dozens of web servers could be responsible for the displayed content. Furthermore, once the information you've submitted hits the web server, it's usually handed off behind the scenes to various other locations, database servers, log servers, etc. Are those internal communications encrypted? Your information is only as secure as the least secure link in the data flow chain, requiring organizations to actively monitor their internal configurations as well as their external profiles.
It would be nice if online security were as simple as whether or not the padlock icon showed up in the address bar of your browser. Unfortunately, cybersecurity is a constantly evolving and very complex interworking of various technologies, and as such requires more advanced analysis to fully understand. We here at UpGuard have developed our free CSTAR webscan and chrome extension for this very purpose. Using a single score between 0 and 950, we rate an organization’s external security profile based on several criteria, including how well their encryption is configured. This allows customers and companies alike to better understand the risks they face doing online business and provides people relevant data about sites before they trust them with sensitive information.
Look up the sites you use (or run) and see how you stack up: UpGuard External Risk Grader
How CSTAR Works What's In the Website Risk Grader? Understanding Risk in the 21st Century
All the information needed to perform a CSTAR assessment is bundled into the UpGuard platform. Learn more about CSTAR.
Read Article >
The UpGuard Website Risk Grader provides a low friction way to get an initial assessment of a business' risk profile.
Read Article >
And as we enter 2016, the risk of data breaches in particular threatens to hamper business innovation.
Read Article >