Permalink
Cannot retrieve contributors at this time
Name already in use
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
DADA/Articles/st16_communications.md
Go to fileThis commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
125 lines (97 sloc)
5.82 KB
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Eavesdroppers on the Web # | |
When we have conversations in public, we know that people overhearing | |
is a risk and wouldn't consider discussing personal matters where | |
others could hear. | |
Unfortunately, many people don't realise how public their internet | |
traffic is. Wi-Fi hotspots can allow anyone connected to the same | |
hotspot to listen-in to (or "sniff" to use the jargon) your | |
communication. Even if you're not on Wi-Fi, the Internet works by | |
connecting up many other networks and your data travels across the | |
world through the networks and routers of other companies and | |
countries. Do you trust them all? | |
## The Lock Icon - HTTPS ## | |
The most important first step to ensure safety of communication is to | |
use encrypted channels. On the Web, this is through the HTTPS | |
protocol. You might notice websites like google have URLs like | |
"https://google.co.uk". The first portion, before the "://" tells the | |
browser and server what protocol to use for communicating. HTTP is | |
the "hyper-text transfer protocol" and HTTPS is the secure version. | |
When you're using HTTPS, you should be able to see "https://" in the | |
URL and not "http://", although some browsers hide this part of the | |
address. It is now almost a universal trait of browsers to show a | |
lock symbol next to the address bar when a site is using HTTPS. | |
### How does it work? | |
HTTPS is actually the same protocol as HTTP, but with an added step: | |
before data is exchanged, the browser and the server agree to encrypt | |
their data. | |
The initial communication actually uses asymmetric cryptography, which | |
means the server has a public key and a private one. Unfortunately, | |
this is quite slow and so the initial exchange is just used to agree | |
on a key to use for the much faster symmetric-key cryptography. | |
## The Man-in-the-Middle ## | |
HTTPS doesn't solve every problem, unfortunately. You can be pretty | |
sure that if the website is using HTTPS that nobody can see what you | |
are browsing, but do you know for sure that you are connected to the | |
website you expected? | |
There is a class of attack called *man-in-the-middle*, often shortened | |
to just MITM. In such an attack, communication is routed through a | |
nefarious third-party, who then passes the data from the real source | |
and destination, but now has access to it in the middle. HTTPS | |
doesn't really help here because the MITM attacker will play along and | |
create a secure connection to the browser, and then another to the | |
real server, so you see a lock icon and HTTPS in use, but it's only | |
being used to securely send your data to the attacker! | |
## Certificates and Authorities ## | |
The current most successful mitigation of MITM and eavesdropping | |
attacks is the use of certificates and certificate authorities. | |
Put simply, a certificate is a documented proof of who the server | |
really is by having a record of the expected public key. Since you | |
can't calculate someone's private key from their public one, if you | |
know what the public key for a server *should* be, then you can check | |
to see if it matches. | |
Of course, if there is a man-in-the-middle, then they could send you | |
their own certificate to match their key. For this reason, we have | |
certificate authorities that can be queried to check the certificate. | |
Again, proof here is created through the use of the authority's public | |
and private keys to sign the certificate. | |
Unfortunately, not all certificate authorities are trustworthy, and it | |
is possible that someone who *really* wants to steal your data will be | |
able to use MITM methods to tell you that the certificate of their | |
false website is correct. We're getting into quite detailed and | |
sophisticated attacks here, but it's not beyond a well-funded | |
organisation or government to do this. | |
One solution that has been proposed is "pinning", in which browsers | |
record the expected public key of each server they see and then can | |
alert the user in future if it changes. Google were a big proponent | |
of this system, but have since given up on it because it was not | |
prevalent enough in browsers or participating sites. | |
# What Does it Mean in Practice? | |
The best advice for staying safe against these types of issue is: | |
1. Check for HTTPS on websites. If you're expected to log-in or your | |
accessing of the site contents is somehow personal, only do so for | |
secured sites. | |
2. If your browser or other applications warn you of untrusted | |
certificates, keys or identities, investigate. Sometimes sites | |
forget to renew their certificates, and sometimes you can get | |
errors because the clock on your computer is not correct (making | |
the certificate look like it comes from the future, for example), | |
but it *could* be someone trying to intercept your traffic. | |
3. If you have to use public Wi-Fi to do anything sensitive, consider | |
a VPN (virtual private network). Many organisations have their | |
own VPN systems so that staff can work safely off-site, but it is | |
possible to get individual VPN services too. | |
# Activity | |
The article | |
https://blog.cloudflare.com/understanding-the-prevalence-of-web-traffic-interception/ | |
discusses the prevalence of intercepted traffic on the web. Not all | |
of the interception is malicious, but might still be harmful. | |
Most workplaces have acceptable-use policies for their IT equipment. | |
It was not uncommon for this to be enforced through analysis of | |
traffic, going as far as to intercept and decrypt connections to web | |
services - essentially MITM by the organisation to determine breaches | |
of policy. | |
Read the article and consider the benefits and issues around | |
decryption and inspection for policy enforcement. | |
Now read and compare the following articles dealing with GDPR [this has not been covered yet]() and traffic inspection: | |
- https://blog.sonicwall.com/en-us/2017/11/why-gdpr-makes-it-urgent-to-scan-encrypted-traffic-for-data-loss/ | |
- https://www.alienvault.com/blogs/security-essentials/when-your-employer-can-see-your-banking-information-decrypting-ssl |