What is SSL and how it works
Programmers usually know what SSL is, but do you? This article will try to explain what the popular term SSL means in simple words for people who are not very keen to computer programming.
In very simple words, SSL (short for Secure Socket Layer) is the most popular method of encrypting internet communications. A newer protocol called TLS has taken the reigns for a long time now, but people are used in the term SSL so everyone uses this word to describe the standard method for encrypting communication.
If you wonder why would anyone want to encrypt communications, the answer is simple. Internet shopping requires you to enter your credit card number, and you don't want to risk someone stealing this information. When you search in Google, you may not want to risk someone eavesdropping. In general, when you communicate sensitive information, you want it to be as safe as possible.
One important thing to know about SSL is that it only encrypts your communication channel. It does not ensure that the information is securely stored in the server you are communicating with.
So, how does this SSL actually work? Well, before we answer that let's see how browsers communicate. Let's say you type-in the address http://www.creativepulse.gr/en/blog . When you hit <Enter>, your browser opens a dialog with the server behind "www.creativepulse.gr" and it asks for page "/en/blog". If everything goes well, the server returns the contents of that page. That is how web pages normally work. With SSL the communication becomes a little more complicated. You would type the address as before, but when you hit <Enter> the path is different. In the surface the only thing you may notice is a small delay, but under the hood what's really happening is this:
Your web browser asks www.creativepulse.gr to start an encrypted communication. If the website supports SSL it responds with its credentials. Your web browser uses a third-party certificate authority (e.g. Let's Encrypt, Geotrust, VeriSign, Symantec etc) to verify those credentials. When everything checks out your browser generates two random passwords, one for encrypting messages and one for decrypting. It sends the server the one for encryption, but it never sends the one for decryption to ensure privacy. The server uses that password to tell your browser which encryption protocols it supports. Then your web browser picks one protocol in random and it informs the server about it, along with a new random password. All that process is called a "handshake"; it is how the communication starts. Once both sides have agreed on the encryption protocol and the "session password", the SSL protocol ends and the real communication starts. Now that everything is safely encrypted your browser tells the server that it's interested in the page "/en/blog" and the server sends over the content of that page. Usually the encrypted communication channel stays online for a while more in case you request another page from that server. Then the channel is closed and that concludes the communication. If you later need to visit another page the process starts over.
This kind of communication is not just for websites. SSL is used in a similar way to send emails, to access FTP, to send messages via Web Sockets etc.
Especially for websites, the way to understand if you are communicating under an encrypted SSL channel or not is to look for a green padlock icon in the address bar of your browser. Also, you may notice the word "http" in front of the address. A simple "http" means that the page is not encrypted. If you add an "s" (secure), and make it "https", then the page is encrypted. So in the example above "http://www.creativepulse.gr/en/blog" is not encrypted whereas "https://www.creativepulse.gr/en/blog" is.
Regular and self-signed SSL certificates
As you read above, the SSL process includes a third-party "Certificate Authority" (CA) to ensure that the certificate is known and valid. Well, that means that there is a certificate involved somewhere. Certificates in SSL contain an encryption key and some information about the website such as the name of the organization that runs the website, its address, email etc. Certificates are the key elements that start the communication explained above.
There is a couple of ways to classify SSL certificates. The obvious way to the user is by cost. Different certificate authorities issue them in all kinds of price ranges. There are two main differences between the cheap and the expensive ones. The expensive ones ("EV SSL" - Extended Validation) authenticate that the entity who bought them is an existing company somewhere in the world. The other difference is the insurance paid to the certificate owner in the case the SSL certificate is compromised by a black-hat hacker. Of course, most people have no idea about those differences so free, cheap or expensive don't make much of a difference in the real world.
Self-signed SSL certificates are those who don't use an issuing certificate authority at all. Web servers issue them by themselves. Browsers do not welcome them, but they do accept them. When a website uses a self-signed certificate the user's web browser shows alerts/warnings before it allows the user to access the page. In these cases browsers also offer a way to close the alerts and make the page accessible. At the time of the last update of this article (year 2018) there is a well respected CA called Let's Encrypt that offers free SSL certificates. That makes self-signed certificates almost meaningless. The substantial difference between regular and a self-signed certificate is a thing called "chain of trust". Browsers have a list of worldwide recognized CAs. When you issue a certificate from these CAs the browser knows that your certificate is trusted because the CA says so. Self-signed certificates don' get to be as accepted because the only person who says they are valid is you, the issuer. So, self-signed certificates are perfectly fine if you use them for yourself or for people who trust you personally. If you want to be trusted outside your circle you should prefer a regular SSL certificate from an accredited CA.
One more important difference between regular and self-signed certificates you should know about is central control. There have been a few incidents in the recent past when CAs found to be vulnerable or even compromised. Popular browsers decided to remove them from their trusted lists. This was a positive change for us users because we were able to be warned about specific websites with these vulnerabilities. This was feasible because of the chain of trust that stems from browsers to root CAs. It is not possible for self-signed certificates. If a self-signed certificate is found to be compromised the issuer (usually you) is responsible to update it. But how realistic is it for you to figure out you have been compromised? That's one more reason to prefer a CA over a self-signed solution.
How can things go wrong
There are a few ways things can go wrong in the SSL process.
Self-signed certificates
As we explained above, if the SSL certificate is self-signed the browser shows alerts before it allows users to access a web page. If you trust the website administrators then this is not a serious problem.
Expired certificates
Similar problems can happen if the SSL certificate is expired. An expired SSL certificate means that the server administrator needs to go back to the certificate authority and renew the certificate. As with self-signed certificates, pages with expired certificates can work equally well once the alerts are closed. What is really wrong with this case is that the certificate authority will not ensure that the certificate is safe nor that the company behind the server still exists - in case it uses EV SSL. But, for the reasons I explained above, in practice that has limited impact on the security of the communication process.
Forms
A recent change in popular browsers makes them show warnings in non-SSL web pages that contain input forms. The message usually informs users that the information they are about to send is not going to be delivered in an encrypted/secure channel.
Mixed usage
Another way SSL can cause trouble is a mixed usage of regular and SSL content in the HTML source code of a web page. This is something website authors are to blame; users cannot do anything to fight it. This problem is caused when a regular page (non SSL) contains SSL resources (CSS, JavaScript), or visa versa. When this happens browsers usually show a padlock icon with some symbol that tries to alert users, not the usual green padlock you get from encrypted pages.Only the website author can really solve this problem by making all web page calls either regular or SSL.
Moving between regular and SSL web pages
Older browsers can show notifications that seem scary to simple users for a problem that is similar to the previous one. This may occur when you are in a regular page and then move to an SSL page, or visa versa. Some browsers may show a notification alerting you that you "enter or exit a secure website". This is a simple notification but for some users this is perceived as critical, just because it contains the word "secure".
Is SSL secure?
It is secure, but not 100%. No encryption is or will ever be 100% secure; unless there is a major breakthrough in cryptography.
That does not necessarily mean you will be hacked any time soon. The vast majority of hacking attacks try to find easy or high-value targets. So, an encrypted communication, with SSL or otherwise, would escape 99.9% of attacks.
One small detail you should know is about identity and location. When you use an SSL encrypted communication you hide the content of your communication but not internet identity (IP) and therefore your location. So, someone eavesdropping on you, or on the incoming calls of a website would know that you had a communication with the website but probably not what page you visited.
What if my SSL communication is broken. How bad can it be?
There are two answers to that question. Eavesdropping and tampering. The hacker could simply listen to what your are sending/receiving, or s/he could change that information as you interact with the website. Realistically speaking, changing the information requires a lot more effort, so that makes it less probable.
How to protect yourself
1. Use modern browsers. There are many versions of the TLS/SSL protocol where older ones are more breakable and unsecure. The newer your browser is, the latest encryption technology it can support.
2. Use a well respected VPN. With VPN the entire communication is encrypted. It is important to use a well established and respected VPN because they can hide your communication from others but they have access for themselves. So it's important to check they are the kind of services that allow audits in their business process to assure quality of service.
3. Use TOR. TOR is a browser that adds a lot of extra security levels. It is something like accessing a page in 4 SSL'ed stages. TOR is an open source project, so there is the maximum transparency you can get and no central authority that would have motivation to act against you. TOR's obsession to security can also be a disadvantage because it does not allow you to make use of certain technologies.
4. Log-out. When you login into a secure website do not forget to log-out when your work is done.
5. Use ad-blocking add-ons in your browser. Ads may inform third party sites on what pages you are visiting.
6. Avoid accessing public websites with self-signed or expired SSL certificates. As explained above, self-signed SSL certificates are only acceptable for websites owners you know an trust.
7. Use updated anti-virus and anti-spyware software in your computer.
8. Avoid internet access from public networks. Choose to access the internet from your own house over an internet-cafe or a public access point.
9. If you are a website author yourself, issue SSL certificates with the highest number of bit length you can get.
10. If you are using wireless networks (WiFi) make it a habit to change the password every once in a while.
-----
UPDATE: On 2018-04-20 we made a number of updates to cover important events in the security world. Normally old articles are not supposed to be heavily edited but this one is a special case because it gets some attention and influence people.