2023-01-20 23:33:17 +00:00
|
|
|
---
|
|
|
|
layout: post
|
2023-01-27 18:12:17 +00:00
|
|
|
title: Email & privacy/security concerns
|
2023-01-20 23:33:17 +00:00
|
|
|
date: 2020-03-21 01:46 -0400
|
|
|
|
draft: true
|
|
|
|
---
|
|
|
|
|
2023-01-27 18:12:17 +00:00
|
|
|
## Plaintext email
|
2023-01-20 23:33:17 +00:00
|
|
|
|
2023-01-27 18:12:17 +00:00
|
|
|
Email is inerently insecure. By default, everything is sent in plaintext from
|
|
|
|
one server to the next with no encryption whatsoever. Servers can encrypt mail
|
|
|
|
in-transit by implementing SSL and TLS but that still leaves copies of your data
|
|
|
|
in plaintext on both servers. For example, see [this email I sent to
|
2023-01-20 23:33:17 +00:00
|
|
|
myself](https://bin.nixnet.services/?f76b8366e6b7a7b0#95skPFhsptkfyMH3i1n25ENZeUzrmYEUHzDVezaToGn).
|
2023-01-27 18:12:17 +00:00
|
|
|
At the very bottom, the content of my email is shown in the file for anyone with
|
|
|
|
access to the server to see. At first glance, this may not seem like such a huge
|
|
|
|
deal. It does, however, become a big deal when you're conducting private
|
|
|
|
business over email. If I so chose, I could go to that directory and read
|
|
|
|
everything you're saying and there's nothing you could do about it. Any mail
|
|
|
|
provider has this capability: Gmail, Yahoo! Mail, Fastmail, the list goes on.
|
|
|
|
Unless special measures are taken to encrypt your emails _at rest_, this holds
|
|
|
|
true in every single case.
|
|
|
|
|
|
|
|
## Encrypted email
|
2023-01-20 23:33:17 +00:00
|
|
|
|
|
|
|
Providers like [Protonmail](https://protonmail.com) and
|
2023-01-27 18:12:17 +00:00
|
|
|
[Tutanota](https://www.tutanota.com/) do exactly this and that is their main
|
|
|
|
draw. Mail to and from other users of the same platform (Protonmail ->
|
|
|
|
Protonmail, Tutanota -> Tutanota) is encrypted from end-to-end as well as at
|
|
|
|
rest so the only parties that can read it are the sender and the receiver; the
|
|
|
|
provider itself can't access them. However, the benefit of at-rest encryption
|
|
|
|
becomes absolutely meaningless the _second_ you communicate with someone on a
|
|
|
|
server that _doesn't_ implement it. Protonmail -> Gmail is 100% insecure and
|
|
|
|
Google is free to perform whatever text analysis and user profiling they wish.
|
|
|
|
NixNet Mail will implement at-rest encryption in the near future but, even then,
|
|
|
|
there is no way to verify that that's _actually_ the case unless I gave everyone
|
|
|
|
root access to my server at all times (security and compliance **_nightmare_**).
|
|
|
|
The only viable solution is to take your privacy into your own hands and encrypt
|
|
|
|
emails yourself.
|
|
|
|
|
|
|
|
## GPG encryption
|
|
|
|
|
|
|
|
"GPG" stands for "GNU Privacy Guard" and is a libre implementation of "PGP" or
|
|
|
|
"Pretty Good Privacy", originally created by [Phil
|
|
|
|
Zimmerman](https://en.wikipedia.org/wiki/Phil_Zimmermann). PGP was eventually
|
|
|
|
bought by Symantec and became Symantec Encryption Desktop and GPG quickly became
|
|
|
|
the most widely used implementation of [OpenPGP
|
|
|
|
standards](https://tools.ietf.org/html/rfc4880). GPG integration is especially
|
|
|
|
common in open source email clients such as
|
2023-01-20 23:33:17 +00:00
|
|
|
[Thunderbird](https://www.thunderbird.net/) and
|
2023-01-27 18:12:17 +00:00
|
|
|
[Evolution](https://wiki.gnome.org/Apps/Evolution). It relies on [public-key
|
|
|
|
cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography) and allows
|
|
|
|
users to encrypt their emails with another user's public key. The email would
|
|
|
|
then be *de*crypted using the receiver's _private_ key. Take a look at this
|
|
|
|
[encrypted email I sent to
|
2023-01-20 23:33:17 +00:00
|
|
|
myself](https://bin.nixnet.services/?70f0ac93b8df9416#Fske8BYAVdoYzD76VgBb5AimRqm2yY8HgnpdcAzUwuD7).
|
2023-01-27 18:12:17 +00:00
|
|
|
As admin of the server, that is literally all I can see. The text between `BEGIN
|
|
|
|
PGP MESSAGE` and `END PGP MESSAGE` is the email body and it just looks like a
|
|
|
|
block of random characters to me. To the person receiving the message, however,
|
|
|
|
after decryption, they'll be able to read it just like the plaintext one linked
|
|
|
|
in the first section.
|
|
|
|
|
|
|
|
If you want to learn more about GPG encryption and protecting your privacy when
|
|
|
|
using email, I recommend reading through [Email
|
|
|
|
Self-Defense](https://emailselfdefense.fsf.org/en/), a fantastic resource from
|
|
|
|
the Free Software Foundation.
|
|
|
|
|
|
|
|
**_NOTE:_** Encrypting an email _does not_ encrypt the metadata. When you sign
|
|
|
|
up for a new email service, send one to yourself and inspect the headers to see
|
|
|
|
if they obfuscate identifying details.
|
|
|
|
|
|
|
|
## Metadata
|
|
|
|
|
|
|
|
Another thing to keep in mind with emails is metadata in the headers of the
|
|
|
|
emails. In Roundcube, you can view these by clicking `More` then `View source`.
|
|
|
|
In Thunderbird, just press `CTRL` + `U`.For other clients and web UIs, you'll
|
|
|
|
just have to look around for options to show headers, view source, download,
|
|
|
|
something like that. You can also take a look at the [email I sent
|
2023-01-20 23:33:17 +00:00
|
|
|
myself](https://bin.nixnet.services/?f76b8366e6b7a7b0#95skPFhsptkfyMH3i1n25ENZeUzrmYEUHzDVezaToGn).
|
|
|
|
|
2023-01-27 18:12:17 +00:00
|
|
|
I'll break down some of the lines and explain what they are. Some of it is
|
|
|
|
irrelevant to this and will be skipped though.
|
2023-01-20 23:33:17 +00:00
|
|
|
|
2023-01-27 18:12:17 +00:00
|
|
|
`Return-Path: <amolith@nixnet.xyz> ` 👉 Address your reply will go to
|
2023-01-20 23:33:17 +00:00
|
|
|
|
2023-01-27 18:12:17 +00:00
|
|
|
`Delivered-To: amolith@nixnet.email ` 👉 Address the email was sent to
|
2023-01-20 23:33:17 +00:00
|
|
|
|
2023-01-27 18:12:17 +00:00
|
|
|
`To: Amolith <amolith@nixnet.email> ` 👉 The _displayed_ receiver
|
2023-01-20 23:33:17 +00:00
|
|
|
|
2023-01-27 18:12:17 +00:00
|
|
|
`From: Amolith <amolith@nixnet.xyz> ` 👉 The _displayed_ sender
|
2023-01-20 23:33:17 +00:00
|
|
|
|
2023-01-27 18:12:17 +00:00
|
|
|
`Subject: Email demonstration ` 👉 Subject of the email
|
2023-01-20 23:33:17 +00:00
|
|
|
|
2023-01-27 18:12:17 +00:00
|
|
|
`Date: Sat, 23 Nov 2019 00:20:46 -0500 ` 👉 Timestamp at which the email was
|
|
|
|
sent. This does include the timezone and can be used to identify you
|
2023-01-20 23:33:17 +00:00
|
|
|
|
2023-01-27 18:12:17 +00:00
|
|
|
`User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
|
|
|
|
Thunderbird/68.2.2 ` 👉 Full user-agent the email application includes with the
|
|
|
|
email. In this case, it consists of the organisation, my display server, my
|
|
|
|
operating system and architecture, the HTML rendering engine, and the email
|
|
|
|
client and version. This can _really_ be used to identify you.
|
2023-01-20 23:33:17 +00:00
|
|
|
|
2023-01-27 18:12:17 +00:00
|
|
|
The rest of it is server-side stuff that doesn't matter too much for _this_
|
|
|
|
document but will likely be discussed elsewhere in the future. Together, all of
|
|
|
|
this metadata can be used to identify people in a conversation. Timezone (vague
|
|
|
|
location), OS, email application, correspondents, and client version. That last
|
|
|
|
component could actually be useful for determining whether or not the client is
|
|
|
|
susceptible to certain malware attacks
|