Elastomeric respirators for covid protection
Since there is a small number of people who still refuse to participate in the recurring infection party, many of us have traded single-use masks or reusable fabric masks for elastomeric respirators that offer good seal and good protection at a manageable cost. I have been using an elastomeric respirator for a bit over a year, I have tried several different ones, and I’m going to write up a little how-to for people interested in making the switch.
Pros
Advantages of elastomeric respirators over other types of masks:
- Better seal (if and only if they fit your face, we will talk about this more), better chance at sealing over stubble.
- Secure fit, you can move freely without it slipping or sliding.
- If it’s safe enough for the nuclear apocalypse, it’s safe enough for the tram. You really do not need to worry anymore.
- Cheaper in the long run, especially if you go through a lot of single-use masks.
- Easy to breathe, designed to be worn during heavy manual labour, you will not struggle for air.
- The filters last a looooong time.
- Most parts have spare parts available, meaning if you manage to break a valve or a strap, you can usually replace only that part instead of the whole mask.
Cons
Aspects where elastomeric respirators fall short:
- Nobody will be able to understand you when you speak. I have a 3M mask with a speaking diaphragm (3M HF-800), it does not help much. This may be better with the type that does not have a separate inlet and outlet and you speak directly through the filter (Flomask style), but I decided against trying those for reasons explained later.
- You get a lot of condensation inside the mask. This does not affect safety but it’s annoying and a little unpleasant if you can’t take a break and wipe it dry in between.
- Depending on how perfectly the masks fits your particular face, chances are you will be in serious pain if you wear it for longer than a few hours.
- It does need regular cleaning. This is quickly done but it needs to be said.
- High upfront cost, especially if you have to try out several models to find one that really fits.
- People will absolutely stare at you. In my experience they don’t confront, they just stare and sometimes laugh and point fingers.
- Most do not have an outlet filter (“source control”), meaning other people are not protected from your germs. I figure that if I can’t get infected, I also won’t have anything to infect other people with, but that’s your own calculation to make.
How to choose a mask
I am very happy with my 3M 3000. But finding one that suits your need and fits your face can be quite difficult.
Even though the masks are elastic, their ability to adapt to the shape of your face is limited. If they do not fit well, this can cause pain, chafing, and sometimes it can affect the seal. For example, I once tried a mask (GVS Elipse with source control) that fit my face in such a way that bending my head down made my double chin push the mask away from my face, breaking seal entirely. I have one other mask (the 3M HF-800) that kind of fits, but presses too hard on my nose and causes pain after half an hour. I have my favourite mask (the 3M 3000) that is good and comfortable, but still starts hurting after 2 hours, after 6 hours I am seriously suffering, and after 12+ hours I will have blisters on my face. The longest I’ve worn it in one go was 16 hours and it took a week for my face to heal.
There are different basic types of masks. One style I am sceptical about are the masks with a single filter for inlet and outlet, like the Flomask. Personally I am not convinced by this design, as it combines the drawbacks of elastomeric masks and single-use masks: Filter is vulnerable to damage, rubber means inflexible fit, mask is expensive, filters are expensive. YMMV
The traditional style with separate inlet and outlet is in my opinion easier to manage. Click-on or screw-on filters are available with protective casings so the filter is protected from the elements and mechanical damage; most filters are somewhat resistant to moisture. The filters can be taken off and the mask can be thoroughly cleaned. Usually, the filter does not need to be touched directly, avoiding contact with germs.
There are some masks, like the GVS Elipse with source control, that are somewhere in between – inlet and outlet are separate, exhaled air is filtered, and they don’t look quite as intense as the ones with click-on or screw-on filters.
When it comes to a specific model, unfortunately there is no replacement for trying it out and seeing how well the shape fits your actual face.
In summary, here is a list of things to consider when choosing an elastomeric respirator:
- Do you need source control? Models that filter exhaled air are few and far in between.
- How easy do you need the filter installation and change to be? Click or screw systems are easiest to replace.
- What do you put this mask through? How protected does the filter need to be? Do you shove the mask in your bag, do you walk through rain? If you do, then you need the filter do be inside a casing that offers some protection.
- Do you need people to understand your speech? What is your plan for when they inevitably fail to do so?
- How okay are you with looking like you’re waiting for the zombies to arrive?
- Properties of the mask: Weight of the mask; shape and position of the straps. Personally I love the 3M strap system because it is absolutely secure.
Basic instructions for using the mask
- The correct filters are P3. This corresponds to the filtration level of FFP3 masks. A vapour filter will not protect you unless combined with a P3 filter, and does not offer additional protection against germs. Screwing on a vapour filter is the easiest way to do a fit test though, so it may be a useful-to-have thing anyway.
- A filter that is protected from mechanical damage and moisture will be good for at least 6 months, probably longer, because these things are designed for industrial applications and have very high capacity. They are hardly touched by filtering out some environmental dust and the odd virus.
- You should wipe the seal area with sanitiser after each wear, mostly because otherwise your skin will be unhappy.
- You can basically just spray / wipe the entire inside and outside of the mask with sanitiser (just make sure not to get any on the filters) if it starts getting smelly or got dirty.
- Checking the seal is very easy. If you don’t feel a stream of air in the seal area, you’re good. You will usually feel some air on your face on the inside of the mask though, because the stream of air you inhale tickles your cheeks. This is good and means the mask is working correctly. A second check you can do is to listen or feel for the closing of the valves, usually you can perceive a small pop when you inhale and exhale. If you feel that pop, this means the valves have closed. If you want to be 110% sure, you can install a vapour filter and spray some sanitiser. If you can’t smell it, the seal is good.
Conclusion and experience
I would absolutely recommend switching to an elastomeric respirator, especially for high-risk situations with lots of people who don’t give a single fuck about infecting everyone around them with a deadly virus. But there are drawbacks; you are going to be stared and laughed at, you won’t be able to communicate effectively through speech, and comfort is lower than with single-use masks. For me, this means that I use my trusty 3M 3000 for shopping and public transport, and single-use masks in situations where I want to be comfortable and/or be able to speak and be understood.
My 3M has never slipped, it has never leaked, the straps have never broken. When I wear that mask, I do not worry about its seal, I don’t have to keep messing with it and adjusting it. It has given me blisters on my face, but this allowed me to travel to a different country in a long-distance bus during a large covid wave without getting infected. When it gets smelly, I take off the filters and spray it inside and out with sanitiser. The seal area gets wiped down after each wear.
Due to the drawbacks, these masks are not a replacement for a safer environment. But they make it possible to survive the way from your house to other safer places.
How to guarantee the security of encrypted communication
My messages are encrypted. Is that enough?
Short answer: Somewhere between “no” and “it depends”. For the long answer and explanation what it depends on, read on.
Hier klicken für deutsche Version
What this article is: An overview of factors that affect the security of message exchange over the web. It is directed at people who would like to learn how to better protect themselves. It aims to provide a general understanding of the topic and empower readers to evaluate their threat models and choose the right tool for the job. Towards the end, you will be given a list of best practices that you need to follow in order to have secure communication. The purpose of this article is to give you enough knowledge to understand what problems each of the points on that list solves.
What this article is not: An in-depth explanation of current technology, a list of recommended services, or in any way interesting for people who deal with this stuff on a daily basis.
Structure:
- Why do we need encrypted messaging?
- Threat models: What are we defending against?
- Basic knowledge
- Which factors limit the security of encrypted message exchange?
- Limiting factor 1: The user
- Limiting factor 2: The device, its OS, its configuration
- Limiting factor 3: The app
- Limiting factor 4: The server(s)
- Limiting factor 5: The connection
- Limiting factor 6: The key verification (or lack thereof)
- Limiting factor 7: The rest of the data
- So what do I actually need to do?
1. Why do we need encrypted messaging?
Or: I don’t need this because I do not commit crimes!
In an ideal world, someone who does not act immorally would have nothing to fear by communicating without complex safety layers. Sadly, we do not live in an ideal world.
In reality, we have much to defend against: We have to defend ourselves against adversaries from our personal lives (ex-boyfriends, abusive parents and the likes) or from our business lives (your own employer, as well as any interested parties that would like to get their hands on your business partners’ or your employer’s internals and/or their money), as well as, yes, against governments.
This does not mean that this information is intended to serve people who wish to commit evil acts. On the contrary: It is without question that governments often act in evil ways. Not only do they frequently break their own laws, but laws themselves are often morally wrong. Across the globe, authoritarian governments can be found just as often as those which apparently strive to get there. Peaceful protesters, journalists, pregnant people, queer and trans people, women, racial, cultural and religious minorities and many other groups regularly suffer injust and immoral, albeit often legal, repression. Protecting one’s communication data can help reduce the impact of repressive acts. It is, I hope, an obvious truth that breaking unjust laws is an ethical imperative.
2. Threat models: What are we defending against?
The concept of threat models in IT is usually intimidating to people not immersed in the topic. This is not because they are hard to understand, but because they are usually presented by listing the names of tools, protocols and software that most people have never heard of.
In human-understandable terms, a threat model is simply a concept of what (or who) you are defending yourself against. You are already aware of most of them.
You have a need to protect yourself against:
- Automated attacks, aimless scam / spam / phishing attempts: These are often high-volume, low-cost. If one mark among thousands pays out, it is already a profit.
- Automated analysis of your data for the purpose of advertisement and influencing your behaviour: While this is often seen as a nuisance rather than a security risk, it is also that. Your data can be used to inform an interested party of your political leanings, your medical condition including pregnancy and abortion, your whereabouts, your media preferences, and much more.
- Automated analysis of your data for the purpose of detecting real or presumed violations of laws and term of services (TOS), such as copyright violations, CSAM, terrorism, sex work, etc.: Some of these TOS and laws are morally wrong and deserve to be broken. Some of them simply do not justify the immense violation of privacy that comes with scanning and evaluating private message exchange. And in many cases, automatic detection of a presumed violation of laws or TOS has already ruined a person’s life without them ever doing what they were accused of. Corporations are not required to justify their punitive actions to anyone.
- Analysis of connections between people in order to model the social structures of movements and organisations (social network analysis): This method is often used to identify leaders of movements or informal organisations so they can be singled out and targeted. This is used for example for union busting or for destroying human rights movements and any organisations a government may deem a threat, irregardless of its legality or morality.
- Physical or remote access to your devices: People with access to a device may intentionally or accidentally install spyware / malware or perform changes to the system. Uninvited interested parties can gain physical access to devices by infiltrating home or work spaces, or in the case of authorities, by simply confiscating them, for example during a search of your person or your home.
- Sniffing and/or manipulation of private communication by third parties: The third party here can be your local stalker, or it can be someone who wants to make your business partner send the large sum of money to the interested party’s bank account in one way or another. It is generally someone who in interested in their target personally and the attacks are carried out manually. The interested party may install trojans, use exploits, utilise social engineering) techniques, or depending on their resources go so far as to install hardware surveillance technology (let’s be real, if it gets that far, most of us have already lost).
3. Basic knowledge
3.1. Encryption keys
When we are talking about modern encryption methods and end-to-end encryption in messaging, we are virtually always talking about asymmetric encryption. This means that every key comes as a pair of a public and a private key.
If person A and person B would like to communicate, at the start of the exchange both A and B have only their own set of public and private keys.
A has these keys:
- A-public
- A-private
B has these keys:
- B-public
- B-private
A public key is used to encrypt a message, and a private key is used to decrypt it. There is no other way to decrypt a public-key encrypted message than with the matching private key. (There are some additional interesting quirks, but knowing them is not necessary for our purposes. Look up how cryptographic signatures work if you would like to learn more.)
In order to encrypt the message that A wants to send to B, A needs to receive B’s public key in some way or other, and in order to reply, B needs A’s public key. So, after the initial exchange of keys,
A has these keys:
- A-public
- A-private
- B-public
B has these keys:
- B-public
- B-private
- A-public
The advantage of asymmetric encryption over symmetric encyrption, in which the same key is used for encryption and decryption, is the fact that a third party that intercepts the initial key exchange cannot decrypt the messages. A public key is called that because it is truly public: Even when it is known to uninvited third parties, the communication remains secure.
Modern algorithms with multiple valid keys (see: double ratchet) add much complexity, but knowing how this principle works helps us understand two very important basic facts:
- Before end-to-end encrypted communication begins, keys are exchanged. This is always true, even when it happens invisibly, and the fact that it often happens invisibly is a problem we will talk about later in the section on key verification.
- If the key is the only layer of security (as in: you do not need to enter a password every single time you receive a message in order to read it), then whoever has your private key can read all your messages.
3.2. Message transmission over the internet
This section serves to explain the basic elements of message exchange over the web, and the potential points of attack.
Let us consider the simple scenario: Person A uses Device 1 to send a Message that is received by Device 2 and read by Person B.
Person A ⇒ Device 1 ⇒ transmission ⇒ Device 2 ⇒ Person B
How many potential points of attack can you identify? I will give you a minute to think about it. No, really do. How many points of attack are in this image?
Have you thought about it? Do you have an answer? The answer is seven.
- The message can be intercepted on its way.
- Device 1 and Device 2 can be compromised.
- So can Person A and Person B.
- An often ignored risk factor is the environment that person A and B are in, where intentional or accidental observation by third parties can take place.
If this simple layout seems manageable, I’m sorry to tell you that it’s about to get much worse, because this would only be true if A and B communicated directly, for example by sending the message via Bluetooth. The internet, however, is anything but direct.
The first additional node we need to add in the middle is the server. Virtually every service we use online runs through a server that receives the message and delivers it to its recipient. This is the case for a centralised service, such as Telegram or Signal.
Now our little diagram looks like this:
Person A ⇒ Device 1 ⇒ transmission ⇒ Server ⇒ transmission ⇒ Device 2 ⇒ Person B
In case of a decentralised service such as e-mail or Matrix, where multiple servers communicate and A and B have their accounts in different places, it looks a little bit worse:
Person A ⇒ Device 1 ⇒ transmission ⇒ Server 1 ⇒ transmission ⇒ Server 2 ⇒ Device 2 ⇒ Person B
But, I did warn you, it gets even worse. Let’s look at the “transmission” part. It seems straightforward, doesn’t it? Your bits travel through the air or through wires and arrive at their destination… Only they don’t, at least not directly. “Transmission” is a shorthand for everything that happens in between, so let’s remove the shorthand and look at the reality.
Consider your home network: There’s a router in between you and the internet, and it receives and reroutes every single bit of data you send and receive. And between you and your server, there are a dozen routers whose only purpose is pushing those bits into the right cable… Or, in some cases, to store those bits and analyse them and surveil their senders.
Now our neat little scenario of sending one message looks kind of like this:
Person A ⇒ Device 1 ⇒ Router ⇒ Router ⇒ Router ⇒ Server 1 ⇒ Router ⇒ Router ⇒ Router ⇒ Server 2 ⇒ Router ⇒ Router ⇒ Router ⇒ Device 2 ⇒ Person B
Thanks, I hate it. And this is a gross oversimplification — in reality there’s way more steps in between. You can try this at home if you install a traceroute program and simply run it on random domains you like to visit. You will usually see dozens of hops, and each of them is basically a computer that can run its own code and do with the data you sent what it pleases. If your data is not encrypted, that also means each of these nodes knows the contents. So if you, for example, send an unencrypted e-mail over an unsecured connection, then every single of the machines it passes through now potentially knows the content of your e-mail. If you send a password over plain HTTP, then every one of them knows your password. If you visit a plain HTTP website, every one of these nodes can serve you a false website. Before the widespread adoption of SSL/TLS, this is what we used to do. It is unclear how we managed to survive that phase of the internet. We will talk more about TLS and certificates when we talk about the connection as a security-limiting factor. For now, let’s just say this: Encryption is the only thing that prevents all of your online communication from being read by a dozen little spies 100% of the time.
Having a basic idea of how messages travel over the internet teaches one crucial lesson: There are dozens of potential risk factors between the sender and the recipient, and some of them are social.
3.3. Types of attacks
In order to understand what we are defending ourselves against, we must have a basic idea of the ways in which our data can be compromised. The description of these methods could fill an entire book, therefore this section describes only a few select techniques very broadly.
- Spyware: Spyware is a type of malware that is installed on a system. Many spyware applications are sold the same as regular software and can even be installed through app stores. Spyware is often advertised for the purpose of surveilling the activity of children or employees of an enterprise. Many of the applications that are installed on work devices contain spyware. Spyware may for example include a keylogger, it can track online activity, take screen captures, log location data, utilise cameras and microphones and send all this to a configurable recipient, without the surveilled person ever noticing. In many cases, the installed spyware application is either hidden or disguised as benign software, for example a calculator app.
- Man In The Middle: This is a type of attack that does not take place on your own device, but somewhere between the sender and the recipient. An interested party intercepts the communication between A and B and either passes it on unchanged or applies certain changes. A and B are under the impression that they are talking directly to each other. If the messages are not altered, it is possible that A and B never realise that they are being surveilled. An example for the manipulation of messages would be the Man In The Middle intercepting an e-mail that contains bank account data and changing it to point to their own bank account before passing the e-mail on to the recipient.
- Alteration of browser, app or system settings: This can be done either manually or for example by running a script or application that needs to be executed only a single time in order to make permanent changes. These changes could for example be additional user accounts, the installation of TLS root certificates (we will talk about this later) or the activation of certain services. These things can allow an interested party to access private data.
- Acquisition of login data: If the interested party knows a password, it can use this password to log in and copy data. Especially system accounts or for example a user’s Apple, Microsoft or Google accounts often contain large amounts of very sensitive data which is accessible to everyone who has the password. Acquisition of login data is especially easy if insecure passwords are used, if passwords are reused, if a user is observed while entering a password, or if the data is entered on an unsafe system that contains spyware. Multi factor authentication can minimise this risk.
- Social engineering and phishing: There are many methods to get a target to install spyware, change settings or enter login data on fake websites. Some of them are so sophisticated that even professionals struggle to identify them.
4. Which factors limit the security of encrypted message exchange?
We can apply the information from the basic knowledge we just talked about to identify the factors that limit protection against the threats from our threat model. This helps us understand which protections we need and why we need them.
4.1. Limiting factor 1: The user
Your own behavior limits your security.
How secure are your passwords? Do you reuse passwords? Do you write them down in a notebook? Who has access to the notebook? Do you store them in a password manager? How secure is your password manager?
What networks do you trust? Do you use unsecured connections?
Do you keep your system up to date? Do you install random software and hope for the best?
What devices do you trust? Do you use a computer that other people have access to? Who are they?
Do you hand over your data to other people? Do you store some of your data in insecure places? Do you upload backups to unencrypted cloud services?
Can you identify phishing attacks? Do you use multiple factor authentication? Do you plug in any USB stick that a stranger gives you? Do you let random people use your device?
Do you verify encryption keys?
We will talk about most of these questions in more detail. The important takeaway from this section is that your digital safety is controlled mainly by yourself. Nobody else will do it for you, and even a reasonably secure system will not provide security if it is not used in the right way.
4.2. Limiting factor 2: The device, its operating system, its configuration
All data that you can access without entering a password can be copied and altered by everyone with physical access to your device. Face ID and fingerprint authentication are child-proofing and do not provide security. A photo of your face can be enough to open a Face ID lock, and your fingerprints can be lifted directly from the device they unlock. There is no secure alternative to good passwords. Patterns and PINs count as passwords, but must be very long and random to provide the same level of security as a password.
However, a secure login password will not save you if your data is not encrypted on the drive itself. Why not?
Imagine you have a USB drive connected to your laptop. If your screen is locked, only someone who knows your password can log in to access the data on the stick. Except, if the stick is not encrypted, they can just pull it out, stick it in their own laptop, and copy or change all your data. Now, understand that the hard drive in your laptop (or the one in your computer, or the storage in your phone) is only a slightly less convenient USB stick.
Therefore, we need disk encryption in order to have data that is what we call “secure at rest”: When the device is switched off or disconnected, there is no way to retrieve the data on the drive without also having the password and/or the key file (which of these to use depends on whether or not you expect an attacker to be able to find and use a key file that you keep on a separate device, or to obtain your password in some way).
Why do we call it “secure at rest”? Because it is not secure in operation. While the drive is in use, the encryption key is in your device’s RAM. Someone who has access to the device can dump the RAM contents (for example by cold boot attack) and obtain the key. Disk encryption without login protection is as useless as login protection without disk encryption. So yes, you do need both: One secure password that you enter every time you access the device (yes, even your phone) and one secure password for encrypting the actual data on your drive.
Having these two things does not mean your device is automatically safe: Any malware that runs on the system can access your data; so can any malicious hardware like for example hardware keyloggers that simply detect and store every single thing you type.
This leads us to another conclusion: As soon as an untrustworthy party has had physical access to your device, you need to consider both its hardware and its software as burned. You may be able to retrieve your precious data from its drive, but under no circumstances should you turn the device on and enter your passwords in order to do so. Any executable on the machine, including its UEFI or its bootloader, is as dangerous as its potentially modified hardware.
During normal usage, there are best practices that should be followed to ensure a safe environment on your operating system:
- Do not install or execute software that you do not trust, as it could be malware/spyware and it could make changes that remain even after uninstalling the software.
- Do not make changes to your system or your browser that you do not understand, as you could be changing settings that affect your security.
- Keep your system and all software up to date, as updates usually contain security fixes. (As a side note: It is possible for malicious software to be included in updates, which is why environments with extremely high risks sometimes disable automatic updates and only apply them after checking. For everyday applications, automatic updates are a good solution.)
- Do not run unnecessary services. Everything that communicates to the outside is a potential source of problems.
- Uninstall unused software. Things that aren’t there cannot cause problems.
- If anything seems wrong or you have reason to believe that your system is compromised, you need to do a full reinstallation / factory reset. You can backup files (pictures, documents, browser bookmarks etc.) but you should not backup any settings or configuration files that you cannot (or do not know how to) manually check for correctness, because they could contain customisations that open backdoors.
- Once your system is compromised, you must work under the assumption that everything that was on your screen has been seen, every one of your files has been opened, and every keystroke you have made has been logged. This also means that you must change all of your passwords (and that doing this while using the compromised system is pointless).
- If your employer expects you to install specific software or make changes to your system, avoid using your work system privately, as these applications often include spyware and the changes may make it possible to intercept your communications.
4.3. Limiting factor 3: The app
If you are sending encrypted messages, you are almost certainly using an application to do so. This app may run in a browser or on your device directly. In both cases, you need to be able to trust the app:
- You need to trust that the app you downloaded has not been manipulated on its way and is really the correct app and not an impostor. App Store and Google Play are very good at ensuring the further and atrocious at the latter. If you use a Linux/BSD package manager, you can only be sure about the veracity of the software if packages have signatures and if these signatures are checked. Not every package management system supports signing. If you download the software directly from a website, you need to be sure that the website is the correct one.
- Even if you have the correct app, that does not necessarily mean you are safe. The app may have exploitable security issues, or the distributor may intentionally have inserted backdoors to be able to spy on its users. Governments may have requested or mandated those backdoors. The app may even go so far as to scan your messages proactively for the purpose of targeted advertising or to comply with government requirements (chat control). These points are where open source software shines: People who care about security will read the code and ring the alarm bells if they discover backdoors or surveillance code.
- Is the encryption true end-to-end encryption? Does the data get decrypted on your device and your device only? If you lose your device and your password at the same time, is there any way at all to recover your data? If the answer is yes, this point is to be considered a fail and the encryption is not secure.
4.4. Limiting factor 4: The server(s)
Server configuration is usually intransparent to the user. This is a problem because servers have access to an immense amount of data, even in the case of true end-to-end encryption. It is also a point in favour of utilising decentralised services and choosing a server whose operator you can trust to both care about your privacy and be competent enough to ensure it through the server’s configuration.
If you are using a closed-source service, it is hard to know whether or not the server receives your key at any point, or if it possesses the ability to decrypt and analyse your data, effectively compromising the concept of end-to-end encryption.
Web apps (those are applications you access through your browser, for example Telegram or Whatsapp on your computer, or the Element web interface): As the application is not installed locally, every visit of the website equals downloading a new version of the app. If the server is compromised, it may send you a false website and steal all of your data.
Even if your messages are fully encrypted, cannot be read by the server, and the server has not been compromised, storing unnecessary additional data can get you into deep trouble (see the section on “the rest of the data”).
4.5. Limiting factor 5: The connection
As mentioned before, messages on the internet are passed on across many different routing points. One of them is generally under your control, and that is your router. If your router is running malware, you are in for a bad time. Routers need to be thoughtfully maintained like any other device: Secure passwords, regular updates, factory resets of second-hand devices.
These days, the vast majority of data sent over the internet is encrypted with TLS. This means that even data that does not have its own encryption layer cannot easily be sniffed or manipulated by third parties, including any of the routers passing it on. TLS is fairly secure in that it cannot just be broken from outside, and you need to have access to either the server or the client in order to access or manipulate the data being transmitted.
In order to understand in which cases we can or cannot trust TLS, we need to understand a little bit about how TLS works.
A secure connection via TLS is established by something called the TLS handshake. This handshake serves to establish session keys that use symmetric encryption, which requires less computing power and is therefore better suited for bulk data transfers. In order to prevent third parties that surveil the connection from being able to obtain the session keys, the messages they are sent in are encrypted with a different algorithm.
Each TLS server has a public/private key pair. The handshake message sent by the client is encrypted with the server’s public key, and only the server can decrypt this message, because (hopefully) nobody else has the server’s private key.
The challenge with asymmetric encryption is identity verification: You need to be able to ensure that the key you have received really does belong to the person that you think has sent it. In TLS, identity verification is solved by way of certificates. There are a number of Certificate Authorities (CAs) which own so-called root certificates. Through a “chain of trust”, these root certificates are used to sign intermediate certificates that are then in turn used to sign the server certificate, which contains, among other things, the server’s public key. If the server has a certificate that your operating system and your browser accept as valid, this means that ultimately, one of the CAs whose root certificates you have saved on your computer (they are shipped and updated with your operating system or your browser) has verified that the public key you are using belongs to the server you are talking to.
This makes root certificates the point at which TLS can be broken. If a malicious root certificate is marked as trusted on your system, this malicious root certificate can be used to sign malicious server certificates, which are then automatically trusted by your device, making it possible for the malicious actor to carry out Man-In-The-Middle attacks.
It is possible to manually install additional root certificates. You could create your very own root certificate, and anyone that saves it on their system among the trusted certificates would automatically trust any certificate signed by you. In fact, many employers do exactly this.
These facts add up to the following limitation:
TLS is only secure if 1. no malicious certificates have been installed for example through user error, employer demand, malware activity, or unauthorised device access and 2. the CAs are themselves trustworthy.
As the large CAs are under control of large corporations, most of which are located in the USA, in order to fully trust TLS, you need to not only trust your device and the software you are using, but also the corporations controlling TLS root certificates es well as the governments of the countries they are in. This is why an additional cryptographic layer of end-to-end encryption is necessary to protect sensitive information.
If your personal threat model means that TLS is not trustworthy, or if governments succeed in forcing their own root certificates to be automatically trusted, web apps are no longer a secure choice for communication, even if they possess their own encryption (Matrix, Telegram, …), as a Man In The Middle could simply serve a false website that extracts or manipulates your data. This is less easy with standalone applications; however, many mobile apps are at their core simply a browser, so the problem may remain.
Using VPN or tor-browser does not make your connection more secure. They only hide your physical location by masking your IP address. You may still be identified through browser fingerprinting and there is no additional encryption to protect the content of your messages. Only Tor onion services use their own cryptographic layer and do not rely solely on TLS for security.
4.6. Limiting factor 6: The key verification (or lack thereof)
Most messenger apps these days utilise end-to-end encryption through asymmetric algorithms. When you open a new chat, public keys are exchanged automatically. You begin communicating and you simply trust that the keys were exchanged correctly, that no Man In The Middle served both of you their own key with the intention of intercepting or manipulating your communication.
If your communication is sensitive or you have reason to believe that you are being targeted, you should not simply trust.
Security-focused applications always offer a way to show the keys used in a chat session. They are not always called keys; they may be called safety numbers or may be presented through emoji, which does not make it easy to give a universal description. If in doubt, ask a search engine how to verify keys in your specific app. (Technically, what you will be comparing here is not the actual key that’s used to encrypt the messages, but a number derived from it, but this explanation is a bit more involved than this article allows for.)
When you open a new session, before you begin with any sensitive communication, you should tell the application to display your communication partner’s key. Then you use an independent mode of communication (a different application, a phone call, literally anything outside the application itself) to verify that this is, in fact, their key, and do the same the other way round.
This needs to be repeated every time a key change occurs. As a side note, in some applications it may be possible to insert a key for a man-in-the-middle attack and then change it back to the original key. Because of the way that the algorithms work (look up “double ratchet” to learn more), the inserted key cannot decrypt older messages, but can be used to decrypt all future messages even after the original key has been reestablished. If this happens, the only hint that something is wrong may be an unequal number of key changes on both ends, e.g. person A sees one key change and person B sees 3, or person A sees 0 changes and person B sees 2.
Therefore, not only do the keys need to be identical, but the number of key changes needs to match up as well.
If you do not manually verify your communication partner’s key through an independent communication pathway, you can never fully trust the communication. Incidentally, this is what makes PGP so powerful: Because the keys are not exchanged automatically but communicated manually, you cannot easily be served a false key.
4.7. Limiting factor 7: The rest of the data
The biggest chunk of extra data is what we call metadata. This metadata is usually not encrypted and can very easily be sniffed, even if the actual content of the communication remains secure. Metadata includes all information that is not contained in the message itself: IP addresses, communication partners, send time, device identifications, etc. This means that even without knowing the content of the communication, interested parties are often able to find out who is talking to who, when and how often messages are exchanged, the location of the participants, what devices and software they use, and similar information. In the case of PGP encrypted e-mail, subject lines and attachments remain unencrypted.
Metadata can be sufficient to model connections between people.
Servers may store metadata such as IP addresses, connection times and device information as part of their server logs. If you do not know your server admin and have no way to find out which data is or is not stored and who has access to it, you must assume that it is stored and passed on. If necessary, you must take additional steps to anonymise your data for example by using a VPN, Tor, or a privacy focused browser.
But metadata is not the only potentially dangerous data storage: Local caches, backups, system log files, screenshots, and other additional data storage may accidentally make sensitive data accessible to unauthorised parties.
5. So what do I actually need to do?
5.1. The quick and dirty list
- Use end-to-end encryption.
- Verify keys through an independent mode of communication and pay attention to key changes.
- Use strong passwords, do not rely on Face ID or fingerprints. A password manager can help.
- Use multi-factor authentication where possible.
- Keep your operating system and your applications up to date, as updates usually include security patches.
- Do the same for all devices in your home network, but especially for your router.
- Keep good backups of your valuable data, because in case of an attack, you may need to wipe your system.
- Disable all unnecessary services and access modes.
- Encrypt your disk and any storage devices.
- Never store sensitive data unencrypted in “the cloud” or on untrusted devices.
- Be careful who you share a device with. Utilise guest accounts.
- Do not install sketchy applications or make changes to your system that you do not fully understand.
- If an employer forces you to install surveillance software or make changes to your system, or if an untrusted person has had access to your device, these devices are no longer suitable for secure communication.
- Use VPN or Tor if you wish to mask your IP address.
- Combine these with a browser that reduces fingerprinting if you do not wish to be identified.
- The most secure data is data that does not exist. Delete what you can.
If this list seems overwhelming, keep in mind that every single of these measures improves your security. Protecting yourself imperfectly is better than not protecting yourself at all. I hope that this article has helped you understand what exactly each of these best practices protects you against, so that you can more competently choose which of them to utilise under which circumstances.
5.2. To PGP or not to PGP?
PGP is a powerful tool for guaranteeing the security of encrypted content. Because of the way it is designed, not only does it make the serving of false keys all but impossible, but it also comes with functionality for signing keys and establishing a web of trust. If you are using a sufficiently trusted PGP key to communicate, and both participants are following good security practices (including but not limited to strong passwords, not using malware-infested devices, etc.), you can be very certain that your messages can only be read by the person you sent them to.
But because PGP keys are inherently tied to an identity, they are by design unsuitable for anonymous communication. Without significant efforts and nonstandard ways of usage it is impossible to deny authorship of PGP encrypted communication (technically it’s recipientship, but in case of a two-sided conversation, there’s no difference). The greatest strength of PGP is also its greatest weakness.
5.3. Encryption is not anonymity
This article explained how to protect the content of your communication. This is not sufficient to hide your identity from the people you are speaking to, and even less to hide it from the server that processes your communication. Explaining how to communicate anonymously would require its own article, but for now I will simply give you a short and potentially incomplete list of things that identify you, and how to obfuscate them.
- Browser fingerprint: Identifies you to every web server you access with your browser. Anonymising it is very difficult. It can be kept in server logs and be used to track you across the web.
- IP address: Identifies you to every server you communicate with, but not to the recipient of your messages, who usually cannot see your IP. VPN and Tor hide your IP. IP addresses are often kept in server logs. If you do not know the server log policy, you must assume that every single IP address you ever accessed it with is stored forever.
- Device information and other metadata: May be sent to the server by an application without your knowledge. May be accessible to the recipient. An easily visible example would be e-mail headers. Many apps do not allow anonymous communication and are not transparent about which data is sent and stored.
- Contact data: If you have registered an account with your e-mail address or your phone number, then your identity is known to the service operator. It is sometimes possible to hide it from a recipient, but this is not very reliable.
- Social net: If you register with a service and connect with the same people as on other services and/or in real life, these connections can be used to identify you even in the abscence of any other identifying data.
- Pictures, self-descriptions, anything you post, obviously: Things that you delete are often not actually deleted and can be used to identify you later. Even when they are really deleted from the server (large commercial services do NOT delete stuff!), they may still live on in backups.
- The encryption key: This is especially apparent in the case of PGP, as explained before. If the key is tied to your identity in any way, then it automatically negates all anonymity.