Securing web connections

There are several “layers” of responsibility to make a network function, and these are represented in the Open Systems Interconnection model (OSI). These layers include the following:

• The physical network layer, which sits at the bottom of the network. This layer takes care of the actual physical transmission of data, meaning it is responsible for making sure that if the sender sends a 1 the receiver receives a 1 as well. The physical layer can transmit data over light (optical) cables, for example. It needs to determine if traffic can be sent both ways at the same time, how the connection is established and so on.

• The data link layer is responsible for error detection and correction, as well as packaging the data in packets called frames. It is a gatekeeper for the data to enter the actual network. It also defines what hardware address the data is meant for. This can be different network interfaces in the same computer, for example.

• The network layer is the layer responsible for routing the data to the target machine in the network. Remember that the network can be connected to another network and might not even use the same communication protocol. The network layer passes the data to the transport layer.

• The transport layer manages the connections between the starting node (the physical pieces that make up a network) and the end node. It also defines how the connection is handled, whether the packets are expected to arrive in order and whether a packet will be requested to be resent if it is missed. The transport layer also handles the throughput so that faster nodes do not overwhelm the slower ones.

• The session layer manages the establishment of connections and maintains the connections.

• The presentation layer manages, for example, the encoding that computers with different ways to represent data internally can communicate in a way that is understandable by both nodes. The presentation layer also handles the encryption in some cases, such as when browsing the internet on a secured site.

• The application layer handles the actual protocol layer. For example, in a web browser the HTTP protocol defines how the application requests a web page.

Each bit of data sent, for example the web page of this course, goes through the network layers (called a “network stack”). This course site uses TLS, or transport layer security (SSL in the above image has mostly been superseded by TLS), which is a way of encrypting the data to prevent the lower layers peeking inside the packets to observe the data. If the course site did not use TLS, your data would be sent in cleartext through all the layers and all the computers participating in the transmission of the data. This can be dozens of nodes in the worst-case scenario. All of those computers could in theory observe and steal the data.

Securing web connections

When you send and receive data through the internet, you very often do so through a web browser. Secure browsers use a protocol called TLS (transport layer security) to protect the traffic between the browser you are using to access the internet (the client), and the server you are sending data to or receiving data from (e.g. a website server).

You can verify that you’re protected with TLS by looking at the address bar of the browser you are using, and making sure it shows a padlock along with the correct domain name. If you do not see a padlock next to the URL, you are not protected by encryption.

As a network security layer, TLS uses cryptographic protocols to authenticate, verify, and provide a secure exchange of encrypted communication from the point of the browser to the target server, protecting the contents of the data packets from being exposed to lower network layers and third-party nodes transmitting the data along the way.

TLS protocols handle the exchange of the actual encryption keys in a secure way. Remember- the encryption key is what protects the confidentiality and verifies the integrity of the communication (message) being sent.

Browsers using TLS try to protect you by verifying the validity of the website's server certificate and that the certificate matches the website domain name (the URL). If the certificate of the server is not valid or if it is used on another site, the browser warns that you're not protected. In this case, a message on your screen warns against invalid certificate authority that could for example mean that an attacker is inserting their own certificate instead of Google’s.

Some sites still allow connections to them with the insecure HTTP protocol. This means all the data sent between your browser and that site server can be eavesdropped by anyone who controls any nodes the data is routed through.

Attacks against TLS

Just relying on the padlock icon is not enough, however. Anyone can create a certificate that is used to tell browsers what encryption to use for the connection.

An attacker can try to fool you into using their site instead of the original by using simple tricks such as changing the URL address of the site to closely resemble the original one. This can be done for example by changing the lower-case letter L with the number 1. In most fonts they look close enough to each other to fool the user if they are not careful. These sites can use encryption too, so just seeing the padlock icon does not mean you’re secure. If you receive a message containing a link you might be fooled into accessing a site this way. A good way to avoid this kind of URL substitution is to type the address yourself instead of clicking the link you received.

A man-in-the-middle (MITM) attack is an attack where the attacker sits between you and the server and is decrypting your traffic, storing it and encrypting it again before relaying it to the server. This kind of attack is quite easy to do if you’re not using encryption. The way TLS exchanges keys and verifies the server is meant to try and protect you from these attacks. However, if you ignore the warning messages regarding unsecure sites, a man-in-the-middle attack is still feasible.

Note

Tips for verifying browser & website network security:

Always check for the validity of the certificate by looking for the padlock in the address bar. Make sure you do not skip the warnings the browser shows you. If the browser says the server certificate can’t be trusted, do not use the site.

It is important to note that TLS and other security protocols like SSL are not just for communication between web browsers and website servers. They currently can be and are used in other types of applications like email clients, cloud services, and mobile apps. This is important because more and more of the data we send and receive on the internet is via mobile apps and the cloud. Determining whether these communications are secure is a bit more complicated though, as we will see later on in this section.

Using a VPN for protection

How can you protect yourself from internet eavesdropping or man-in-the-middle attacks? A really good solution is using a VPN (virtual private network). A VPN encrypts your data and routes it from your computer to a known and trusted intermediate node that decrypts the data and passes it on to continue its trip to the destination node.

Think of a VPN as a kind of additional envelope that encrypts the contents (the original data envelope) from your computer's node, and then once at the exit node, decrypts the outer envelope’s encryption and allows the original data to continue as usual. This can prevent, for example, hostile Wi-Fi networks from eavesdropping on your communication.

An example of a VPN solution is an app on your mobile phone or installed on a physical device at the edge of your trusted network (such as a company internal network router). When activated, both implementations secure and hide the communication from the underlying network layers and, in doing so, also the nodes handling the traffic.

Something you should be aware of however, is that once the encrypted VPN traffic exits the VPN service provider’s server node, it continues its journey towards the target node as normal – so if you are not using a secured network protocol like TLS or end-to-end encryption (see chapter 3.1), the traffic is available to every node on the rest of the route.

A VPN can also be used to hide the origin of your traffic and make it look like it’s coming from the VPN exit node. This feature can be used to circumvent geographical restrictions or hide your traffic from potentially hostile networks. VPNs can also be used to hide the communications from hostile governments trying to eavesdrop on their countries' citizens. A VPN does this by encrypting and masking the target of the communication until the connection is terminated in an exit node that can be in another country.

A VPN solution is often used to connect separate networks together. This is often done to extend a network between multiple offices of a company. Even though the separate networks are not physically connected together, a VPN can make the networks seem like a single one. Traffic that is meant to be internal network traffic is routed through the encrypted VPN connection to the exit node, which is in this case on the edge of the other network.

Security in apps and cloud services

Traditionally, data is hosted by someone using a computer called a server, and there is a person who manages the server and its security. The origins of the many cybersecurity practices such as access control and logging are grounded in the early days of computing when all devices were simpler and all data resided locally.

In the 80s and 90s, the commercialisation and consumerisation of personal computing brought a personal responsibility for consumers to secure their computers – or “endpoints” as they are commonly called in corporate environments. Typically, this meant installing an antivirus program. Today we know that this is hardly enough, especially for corporate-level cybersecurity. At a minimum it is good practice to have regular training on basic cybersecurity protocol if company employees are engaging in remote work, including traveling for work.

Currently, endpoints like workstations, mobile phones and tablets are not strictly just for either work or private use. Instead, there is a crossover between these purposes with the usage of the devices and the content stored on them. Where the data resides has also become less clear. This makes it challenging to find out where the security controls are for your everyday apps.

Just “cloud”, or IaaS, PaaS or SaaS?

You might have heard the phrase “the cloud is secure by default”. Alternatively, some say that “the cloud is just someone else’s computer”.

While sometimes almost true, both are among the many modern cybersecurity myths. To understand the nature of the “cloud”, we need to ask a few more questions. Depending on the answers, the nature of the cybersecurity controls and practices are also determined.

The cloud has almost become a synonym for any data processing handled by someone else. However, differences exist between the types of cloud, IaaS, PaaS and SaaS:

• IaaS (infrastructure as a service) means a hosting provider such as AWS, Azure or GCP hosts virtual servers in a scalable environment. Here, the customer still needs to maintain the security of the operating systems and services.

• PaaS (platform as a service) is offered by the same providers as above, but it also offers database or data intelligence software as a service, for example. Here, the customer can focus on the feature of the platform while also securing it through a proper configuration.

• SaaS (software as a service) includes services like Salesforce, Office365 and Gmail. Here, the customer has the least say on how to secure the service. However, it is still the customer’s responsibility to manage their identities for the service and practice good network security hygiene as we have learned in this course.

“Is it safe to install this app?”

This is a very common question. Familiarising yourself with the information published along with the app gives hardly any information on how securely the data in the app or in the backend of the app is processed.

To analyse the cybersecurity of an app, you need to consider the following questions:

• Who is publishing the app? Is it the manufacturer's store or an unknown entity? App stores (Google Play, Apple store) have some level of vetting for apps for harmful functionalities (such as stalkerware, malware, and backdoors).

• What information does the app collect from the user, with or without consent?

• How is information secured between the app and the backend? (To read more, see chapter 3.)

• How is information secured between the sender and the receiver (end-to-end encryption)?

• What is the security of the encryption protocols and their key management? - Does the app have a TLS certificate, for instance?

• How can the publisher of the app technically process your information?

• Is the publisher working within a legislation where it’s legally required to hand over your information to local authorities (for example China)?

• Is the publisher intercepting and altering the content of the information in transit (also for example WeChat in China)?

To verify facts would be a major effort even for a professional, so you can see what others have done to find out. You can start by asking if there has been a recent code audit and an independent security analysis.

Perhaps the best publicly available analysis is the comparison of the security and privacy features of the different chat applications (Signal, Telegram, WhatsApp, Facebook Messenger).

To compare different applications, see for example the EFF (Electronic Frontier Foundation) comparison. However, it is outdated, so a more recent and much more detailed version can be found here at Securemessagingapp.com.