Keeping up with hacking, phishing, malware, viruses and all other forms of dirty dealings on the web is a big business. The cyber security industry is anticipated to reach $170 billion by 2020. The growth is pretty much in lockstep with the increase in cyber crimes, an industry in its own right that’s responsible for the loss around $450 billion a year. How does the average internet user and casual browser stay safe amidst the “series of tubes”? One effective method is to both understand and actively utilize websites with Secure Socket Layer (SSL) encryption.
SSL in less than 100 words
Secure Socket Layer encryption is a high-level encryption standard that utilizes a combination of asymmetric and symmetric key algorithms. This means that, aside from the asymmetric public key, the cryptographic keys utilized are unique every time a connection is made between two machines. SSL Certificates utilize an asymmetric public key (the website server) and a private key (the user’s browser) that work together to authenticate data and secure it. Once the initial “handshake” is formed, SSL connects the two machines with a cipher that constantly encrypts and monitors data transfers, verifying that the data is both secure and unchanged.
A short primer on encryption (for security greenhorns)
If you’re more of a pro, feel free to move right along. However, if all this talk on SSL and network security feels a bit over your head, let’s break down some of what we’re talking about so you’ll feel a bit less confused.
All information is data
This is something you may already know. At the most basic level, everything you send and receive online is, at a fundamental level, coded data. Even the words you’re reading on the page right now are translated by your browser into a readable, more visually appealing format. You wouldn’t actually want to try reading what that data looks, as you would perceive it as nothing but a bunch of letters and numbers that make no sense untranslated.
For example, here’s a snapshot from the University of Miami on what an email address might look like in its pure data form:
You would hardly be able to understand the data in its mid-transfer state. But your browser translates that data into a readable form — in this case, as an email address.
Data packets
For the most part, all computers speak the same languages. So when two computers connect to each other over a network and start sending data in the aforementioned coded language, or one of many other code languages, they can translate that language to a more readable format to the user upon receipt. All of that data does not come as one continuous stream, however, but is broken down into smaller packets sent quickly. Data packets typically exist in the following form:
- A Header containing information such as sender IP and receiver IP addresses, network protocol number and other useful information
- The Payload, which is the actual packet of data to be received and translated
- A Trailer, which indicates that the packet has ended and helps to correct any errors that might have occurred during the sending process
Most networks will actually have a limit on how much data each packet can contain. This means that the payload amount can vary, which will also impact how long it takes to send data. As the data can be intercepted or stolen en route, as long as someone has a computer that can translate the data in the packets (almost anyone, really), the data needs to be encrypted before it’s sent, and then decoded once it’s received
Data encryption
Because any computer can translate data passed over networks, and due to the vulnerability in networks that aren’t protected, encryption exists to make sure that data packets are effectively impossible to translate. Here’s how that encryption works.
All encryption is derived from cryptography, the study behind sending messages in coded messages. Cryptography has been famously employed in many parts of history during the last several decades, most notably in World War II when both the Allies and Axis powers ramped up their efforts to send and coded messages over public airwaves.
In today’s time, cryptography is more commonly employed through network encryption. With encryption, the data is scrambled before passing through the network and to the receiving party. To anyone snooping in, the once-translatable data would just look like nonsense.
Cryptographic hash functions
So how is it that the data gets scrambled? Complex algorithms running through cryptographic hash functions. These functions essentially take any data of any size and convert it into a scrambled function of a predetermined size. Here’s an example of what that might look like:
Data is input into the hash function which then converts it into a bit string, as shown above. As you can see, the different inputs each get translated into a bit string of the same size, regardless of the input data. This is designed to make brute-force attacks (ones where someone tries to guess the scrambled data by trying to guess all possible solutions) more difficult. In the case of SSL and other modern encryption standards, brute-force is impossible due to the large number of possibilities. Which brings us to our next topic.
Encryption bit size
When data gets encrypted, the predetermined bit string size is the most important factor for preventing brute-force attacks. The longer the bit string size, the harder it becomes to guess every possible combination to decode the string. As a whole, the digested data is called a “key”, and the strength of that key is partially measured in how many bits it contains.
So why not just create a key that has, say, a million bits? The answer is processing power and time. The larger the bit key, the more time and processing power a computer needs to actually effectively decrypt the message on the receiving end. SSL actually utilizes different key sizes for different purposes and based on how updated the machine itself is.
For initial handshakes (that is, validation that the receiving machine is the correct recipient), a much larger 2048-bit RSA key is used. The data in this key is small but is only utilized to verify that exchange of data. Once the systems have verified each other, SSL moves over to 128, 192 or 256-bit keys.
Do key sizes matter? Of course. The larger the key size, the more potential combinations. Nevertheless, even the smaller 128-bit key size is incredibly difficult to break with a brute-force attack, given the large number of potential combinations. With current computing power, it would be possible to break a 128-bit key, but it might take a million years to do so. That said, the biggest concern in computing right now is how quantum computing will make it easy to break SSL keys, thus requiring an extension of key sizes. But that technology won’t be widely available anytime soon.
Encryption in a nutshell
To sum it all up, encryption does all of the following:
- Scrambles data before it’s sent over a network
- Locks that data down with a nearly-unbreakable (for now) hash algorithm
- Transports that data securely in transmission, preventing snooping
- Only allows the data to be received by a secured party and decrypted upon receipt
What are the benefits to SSL?
SSL encryption has 2 key benefits:
- It secures data passing between your computer and a website’s servers through heavy encryption
- It provides verification that the website has both an updated and authenticated security certificate.
Data security is extremely important, especially for websites that collect credit card and bank information or passwords and usernames. Any website that does either of these should have SSL encryption. Otherwise, the website is left open to hack attacks where data can get stolen en route.
Verification is extremely important for SSL certificates. There’s a long list of companies that provide SSL certification, and it does not always come cheap or easy. Web sites that apply for high-assurance SSL certification must provide:
- A Whois record identifying who owns the domain name
- A complete Certificate Signing request (CSR)
- Independent validation of the website and the company that owns it
This process comes at a cost to the website owners as well. This is why phishing sites will never utilize highly secure SSL certificates. They would never be able to pass inspection, and most are in the business of stealing money, not paying it out to other companies.
Certificate Authority companies are unlikely to issue high-assurance SSL certificates to a non-reputable site. Most of the CA companies are well known names. The list includes:
- Symantec
- GoDaddy
- DigiCert
- Trustwave
- GlobalSign
- StartCom
- SwissSign
- Network Solutions
- Thawte
- com
- Let’s Encrypt
- GeoTrust
- Entrust
- Comodo
For the most part, CA entities tend to be web hosts and cyber security companies.
How to tell if a site uses SSL
It’s actually fairly easy to determine if a website utilizes SSL encryption. Once you connect to a website, the initial handshake between your browser and the server will result in verification that the website is using SSL encryption. This is shown in two ways:
- The website’s address shows as an HTTPS site (Hypertext Transfer Protocol Secure)
- A lock symbol appears directly to the left or right of the HTTPS
Additionally, some websites may even have the company’s name appear with the lock symbol. Web sites that have purchased Extended Validation SSL certificates, the highest level, have the company name appear next to the address bar.
Here’s what this all looks like.
The website Stack Exchange does not use SSL encryption on many of its pages. As such, no HTTPS or lock symbol appear by the website address:
Clicking in on the “i” will reveal that the website is indeed not secure:
Meanwhile, Google Docs has SSL encryption, but not the highest level:
While the website for the American bank Capital One utilizes Extended Verification, with all the trimmings:
When SSL is important — and when it’s not
One question you may be wondering is whether SSL encryption is always necessary. To put it plainly, the answer is no. SSL encryption is not always necessary. However, those websites that do use it have varying needs for which type of SSL encryption they do or should have.
Sticking with the examples from the previous section, StackExchange really doesn’t need SSL encryption on all areas of its site. And indeed, the website actually does have SSL encryption, but only where it’s actually needed. If you create an account and login to the website, look what happens:
This is because any website that requires you to create an account and login to its server should have SSL encryption, at least at the most basic level. SSL encryption will help prevent someone from stealing your account login information as that data passes between your machine and the website’s server.
Generally speaking, the more important the data passing between you and a website’s server, the higher assurance level that website should have. This is why a bank like Capital One has Extended Verification, while a website like StackExchange has an Organizational Verification certificate.
Web sites that don’t collect any information or require a login to access parts of the website could certainly use SSL encryption, but it’s not entirely necessary. That said, there’s always the concern over whether a site is on the up and up, or whether it’s a fake phishing website set up to steal data.
Because of the intense verification needed to obtain SSL certificates, phishing sites will not have the highest level of encryption, but they may still have an HTTPS address or even a lock symbol. However, they will never have the green bar with a company name, as this is only given to websites with high-assurance certificates. Additionally, some websites may have expired or unverified SSL certificates. You can see what this looks like by going to badssl.com, a simple, educational website that provides solid examples of every kind of SSL certificate aberration.
For example, a website with a revoked SSL certificate may come up in a Chrome browser session like this:
All told, a website doesn’t need SSL encryption, but when you’re going to a website you’re unsure of, it’s best to avoid creating a login on that website until you fully vet it first.
Related: Guide to SSL Decryption with Wireshark
Different types of SSL
As SSL is a form of encryption and verification, there are different types. Each type services a slightly different purpose. It is important to note, however, that different types of SSL certificates do not mean that the website provides more or less security. Certificate types indicate how trustworthy the website is, as these different types require differing levels of validation to obtain.
Domain Validated Certificates
DV certificates are the least expensive SSL certificates available. These certificates do little more than check the domain name registry against the certificate. The requirements for obtaining these certificates are typically low, meaning many phishing websites can actually obtain them quite easily. These certificates do not require a more rigorous background and validation checks that the other certification levels require.
As such, many Certificate Authority entities actually do not offer this certificate, as most consider it too low security, and for the most part, not secure. You will still see the lock symbol appear for these websites, but they still present some risk. When you check the website’s certificate information, it will only inform you of the domain name and the CA.
This type of certificate is common for websites that have very limited security concerns. The Anime website MyAnimeList.net is one such website. Here are its certificate details:
In fact, parts of the website are not secure, which led to my web browser blocking those parts:
While DV certificates can be useful, the kind of websites that typically use them do not allow for individual user accounts and therefore do not collect usernames and passwords.
Organization Validated Certificates
These SSL certificates require a more rigorous validation process to obtain and are therefore more expensive as well. Unlike the DV certificates, OV certificates meet the Request for Comments (RFC) standards set by the Internet Engineering Task Force (IETF) and the Internet Society (ISOC). Websites must exchange validation information and a CA may contact the company directly to verify information.
When you check the certificate information, you’ll see the website name and who it’s verified by. You will not get the owner information, however.
Wikipedia is an example of a website that uses an OV certificate:
Extended Validation Certificate
An EV certificate is the highest level, providing the most assurance and validation. The process required to receive an EV certificate is both extensive and expensive. Only websites with the EV certificate will get the green bar validation by their website name in your web browser as well. Unfortunately, not all web browsers can display the EV green bar. It’s only available for the following browsers:
Google Chrome, Internet Explorer 7.0+, Firefox 3+, Safari 3.2+, Opera 9.5+
Older browsers will not display it. This does not mean that it’s not there, however. It simply means that those using older browsers may have to check the certificate information to verify the validation level.
Bringing up the more detailed information for Capital One reveals the fact that the website does indeed use an EV SSL certificate:
EV certificates are by far the most trusted and most secure, but not entirely necessary for every website. Most websites can actually get by with a DV or an OV. However, if a website is collecting information from you, you should not trust it unless it has an OV certificate or higher.
That said, some websites will redirect you to an external site when making payments. Those websites may utilize external services for their payment system, such as PayPal, which does have high-assurance EV certification. That way, they don’t have to purchase their own EV, instead relying on the external services to provide that security and assurance layer.
Troubles with DV and OV Certificates
Although many CAs do not offer DV certificates, some do. As CA certificates do not require further background checks and validation, some phishing site owners have taken to purchasing these certificates in order to game the system. Unfortunately, there is no direct way to distinguish between DV and OV websites without actually looking at the certificate information in more detail. This is why many websites turn to EV (high-assurance) certificates. Like OV certificates, they require more extensive validation, but also come with the green bar that gives the company name as well as the lock symbol and an extensive amount of validation information provided.
For most browsers, you can check the certificate by clicking on the lock symbol, clicking on “More Information”, and then click on “View Certificate”:
This will bring up the detailed information on this website’s certificate:
Here we can see that Stack Exchange is indeed using a High Assurance EV Certificate, issued by DigiCert. We can trust their website and should not need to worry about logging into it with a secure password.
Are there any alternatives to SSL?
Although SSL eats up a large bulk of all secured internet traffic, there a few notable alternatives to this encryption method.
Transport Socket Layer
TLS, or Transport Socket Layer, is the successor to SSL. Indeed, in many cases, what is referred to as an SSL certificate may actually be a TLS certificate. This is not by accident. TLS, a newer standard, is based heavily on SSL, with changes that are small enough that many people, even those directly in the industry, will still refer to TLS and SSL together (typically with the notation “SSL/TLS”). The key differences between SSL and TLS are updated ciphers and better security for TLS, which is why it has replaced SSL. Nevertheless, most people still refer to TLS as SSL, given that the two protocols are extremely similar. As both use the same certificates, the transition for most websites was fairly simple.
Secure Shell
Secure Shell (SSH) is directly competitive to SSL and in many ways just as secure. However, SSH differs most significantly in two ways. First, SSH is essentially free to obtain. Unlike SSL, SSH does not utilize Certificate Authorities to verify and deal out authentication. Also, unlike SSL, SSH also employs a various number of utilities that operate with the encryption. This can include remote operation of networked machines and creating login requirements through a secure network. SSH is more popular among network administrators. The reason SSH is less secure than SSL/TLS is that key management has little oversight, unlike with SSL. This means encryption keys can get lost, stolen or improperly used, making it more difficult to verify ownership.
IPSec
Internet Protocol Security takes a different approach to network security and encryption. While SSL/TLS operates on the application level, IPSec was designed to be a point-to-point encryption for an entire network. As such, IPSec operates on a different network protocol layer (SSL operates at layer 1, HTTP, while IPSec operates at layer 3, IP). This gives IPSec a more holistic approach to network security. IPsec is also more designed for permanent connections between two machines, while SSL is designed for impermanent sessions.
IPSec was originally mandated for IPv6, as it provides network security at the IP level. Indeed, IPsec was originally developed as the network security method for IPv6. However, the largest weakness to IPSec is that it does not provide more individualized authentication. Once someone has gained access to a network secured by IPSec, they are free to access anything on the network; as long as no other authentication is in place, there is no restriction on access.
Additionally, IPSec is not exceptional regarding remote access. It is more designed for point-to-point connections between networks, such as a large company creating secure connections to its servers for all of its business locations. Allowing remote users to connect (such as workers who want to work from home or while traveling) requires more maintenance while requiring separate applications.
SSL extensions and VPN solutions
As SSL is primarily an application-based encryption standard, solutions have developed to ensure that SSL can also be applied in different ways.
OpenSSL on VPN
OpenSSL is an open-source version of SSL that is utilized in many non-browser applications. Most noteworthy, it is the primary security method used by VPNs that operate using the OpenVPN platform. OpenSSL is exactly as it sounds: an open-source version of SSL that is free to use and play around. As with many open-source initiatives, OpenSSL is highly reliant the community that uses it to stay updated. This has resulted in some frustration, as OpenSSL does not come with as much assurance as a browser-based SSL certificate purchased through a Certificate Authority. Notable vulnerabilities have been found, but OpenSSL is also updated frequently to counteract those vulnerabilities.
Several forks for this program exist, including Google’s own BoringSSL. On the positive end, the OpenSSL toolkit allows for constant improvements given that it is open source.
Secure browsing with HTTPS Everywhere
A free product from the Electronic Frontier Foundation, HTTPS Everywhere is a browser extension for Chrome, Firefox, and Opera that makes your browser opt HTTPS pages when possible. HTTPS Everywhere also works by helping to protect your data while you’re connected to a site that uses HTTPS on some, but not all of its pages. As long as the website supports HTTPS, HTTPS Everywhere can convert the pages to HTTPS and encrypt the data. However, as indicated by EFF’s FAQ page, websites that link to questionable third-party links, such as images, cannot be fully secured by HTTPS.
You can also set HTTPS Everywhere to block insecure links and phishing websites, a distinct safety feature to help prevent internet users from accidentally stumbling upon phishing sites.