secluded/content/posts/2020-03-21-email-privacy-se...

109 lines
5.7 KiB
Markdown
Raw Normal View History

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