On a blackboard, wiggly lines passing through a padlock and coming out straight on the other side—representing a security solution concept

Intro to Internet Security: Protecting In-Transit Information

Protecting your sensitive information is paramount when using the web. Every day, private information like credit cards credentials, internet bank logins, email passwords, and social networks travel over the web—important information you probably don’t want falling into the wrong hands. That’s why internet security measures like encryption are becoming must-haves, not nice-to-haves.

While client-side security solutions like regular operation system updates, firewalls and antivirus software are widely used, we can’t neglect server-side security. This is because accessing the Internet involves connections between several computers, not just your own. This means that your data, like passwords, credit card credentials, and post to social networks, are “traveling” over a network until they reach their endpoint—that final destination being a server.

Say you store your money in a secure safe deposit box within a bank. To get it there your account manager must physically carry your million dollars to the bank. Do you want that money traveling in a plastic bag, or a locked briefcase? The endpoints—you and the bank—aren’t the only things that need protecting. The same goes for the internet: you must encrypt the data that’s in transit.

In this article, we’ll discuss a fast and easy way to to secure traffic between the client (browser) and server. But first, let’s identify a few of the kinds of risks we want to avoid.

  • Man in the middle (MITM) attacks. Public WiFi networks in bars, cafes and other public spaces are not too well-guarded for this kind of attack because it’s often not clear if the network is legitimate, or if it’s a network created by a hacker with a 3G (LTE) WiFi hub who’s looking for their next victim. However, even with a legitimate Wi-Fi network, hackers can still intercept and steal your information if the connection is not secure. By using special software or bugs inside a router, a hacker can manage the route of traffic over the public network and extract your private information by including his computer inside route.

Infographic showing how a hacker can intercept information travelling between users and servers

The best practice solution to avoid this situation is by using an HTTPS protocol (a secure, encrypted connection) because it offers point-to-point encryption. This means that all of your data has been encrypted in your browser by a very strong algorithm and sent to a destination server. With this type of encryption, that destination server is theoretically the only other machine on the web that can decrypt that data.

Let’s look more at the theory of Internet protocols, encryption, and how to start using encryption on your web server—starting with SSL.

TLS vs. SSL: What’s the Difference?

What is the difference between SSL (Secure Sockets Layer) and TLS (Transport Layer Security)? The answer is: nothing. TLS is simply a newer version of SSL. Protocol SSL was created by Netscape Communication for their browser, Netscape Navigator. It was an excellent advancement, proving that Netscape had predicted security and privacy issues before they became bigger threats. The first version of SSL, 1.0, was never available to the public, and version 2.0 had a lot of security issues and bugs. Version 3.0 of this protocol offered good security and was generally bug-free. Visa, MasterCard, American Express and many other large, global companies are licensed to use SSL for commercial purposes. SSL 3.0 served as the basis for TLS 1.0 (sometimes TLS 1.0 is even referred to as SSL 3.1 because there are so few differences between the two).

TSL (SSL) is a session layer protocol between the Application and Transport layers in an OSI model. SSL (TLS) is a high-level encryption (instead of IPSec), meaning while an outside party may still access your data, it is encrypted and without a key it can’t be decrypted and read.

Infographic showing the relationship and flow from applications, to protocols, and to records

How does it work?

Side note: If you’re interested in learning more about the deeper technical aspects of the internet or even local networks and how they work, you should definitely have a good understanding of the OSI model.

Now, let’s dive deeper into HTTPS. HTTPS is not actually a stand-alone protocol but a set of other protocols: HTTP, TLS(SSL) and TCP. Together, they can do a lot to protect the security of your online activity.

Infographic called, "HTTPS is a Set of Protocols" showing the combination of protocols that comprise HTTPS

Imagine your internet traffic to and from your network as layered pipelines, like the following:

Infographic called, "Layered Encryption of Internet Traffic" that shows how TLS/SSL is compatible with other protocols

You can see from the diagram that the application layer data has been encrypted by SSL/TLS, then sent via TCP/IP. The magic of TLS/SSL is that they’re compatible with other protocols and work with them without affecting them. If someone were to create a new application protocol, for example, it will be already compatible with the SSL/TLS.

Adding Trust to Google Chrome Browsing (and How SSL Will Affect Google Rankings)

SSL and HTTPS are not only valuable to security, but they’re also going to be helpful when it comes to SEO, ecommerce, and visual notifications about the security of a page in Google Chrome. On September 8, 2016, the Google Security Team announced that the 56th version of Google Chrome will alert users when they’re on an unsecure website without SSL certificate.


Also, if you visit a page within a website without SSL where there are fields to input sensitive information like credit cards credentials or passwords, Google Chrome will label it more aggressively:


What does this mean to owners of website and applications? If your website is not secure and Google gives visitors the above notification, you risk losing business. (Personally, I would never buy anything on a website without HTTPS encryption.)

Also, we can anticipate that this could have an effect on a site’s rank and SEO. It’s likely this will cause websites without SSL/TLS certificates to drop in SEO rank (whereas websites with a certificate will rank higher in search results than websites without certificate).

Now, let’s discuss how to get free SSL/TLS certificates and install them on your web server. While this is possible to do even if you’re not too familiar with IT, I strongly recommend engaging a skilled DevOps professional for this task (if you don’t already have one).

How to get free SSL/TLS certificates installed quickly and easily

Letsencrypt offers several ways to obtain SSL certificates. I like via run bash script from GitHub’s repository of Letsencrypt official profile.

I’ll use a clean virtual server with the LAMP stack installed (Apache running on Ubuntu).

1. First, let’s install git.

sudo apt-get install git


2. Next, clone the repository of Letsencrypt to your web server’s local directory:

git clone https://github.com/letsencrypt/letsencrypt


Now we are ready to create an automatic free SSL/TLS certificate from Letsencrypt and automatically configure your web server in a matter of minutes.

3. As we’re using the Apache web server, the following command will be next:

certbot-auto --apache

4. After running, you’ll see a welcome screen like this one:


This tells us that we haven’t specified any domains name in Apache’s config files. If you see this screen, just click ‘Yes,’ then you’ll be asked to enter a domain name. I’ll use upwork.netsh.pp.ua for demonstration purposes.

5. The last step is to set up the kind of HTTPS access you’ll be using. There’s Easy mode, where both URLs are available—http://upwork.netsh.pp.ua and https://upwork.netsh.pp.ua—but using the Secure option is strongly recommended by many so the whole website will be secured.


If this all works, you’ll see the following Success page:


Now you not only have a SSL/TLS certificate, but a well-configured web server (Apache for us).

Now, run a test website to see how the HTTPS is working:


For more security, you can run your website through a third-party solution to see how it performs:


As you can see, the above test site received an A rating.

While we didn’t cover every aspect of TLS/SSL or Letsencrypt today, you should now have some of the must-have information you need to begin securing your site. If you’d like to learn more, visit: OSI model, and ACME, client-side solutions for Letsencrypt based on various programming languages.

Remember: Stay safe on Internet, protect your clients from unauthorized access to their private data, and always think about your security when you’re using public networks.