119 lines
5.7 KiB
Markdown
119 lines
5.7 KiB
Markdown
|
---
|
||
|
layout: post
|
||
|
title: Email & Privacy/Security Concerns
|
||
|
date: 2020-03-21 01:46 -0400
|
||
|
draft: true
|
||
|
---
|
||
|
|
||
|
Plaintext email
|
||
|
---------------
|
||
|
|
||
|
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
|
||
|
myself](https://bin.nixnet.services/?f76b8366e6b7a7b0#95skPFhsptkfyMH3i1n25ENZeUzrmYEUHzDVezaToGn).
|
||
|
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
|
||
|
---------------
|
||
|
|
||
|
Providers like [Protonmail](https://protonmail.com) and
|
||
|
[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
|
||
|
[Thunderbird](https://www.thunderbird.net/) and
|
||
|
[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
|
||
|
myself](https://bin.nixnet.services/?70f0ac93b8df9416#Fske8BYAVdoYzD76VgBb5AimRqm2yY8HgnpdcAzUwuD7).
|
||
|
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
|
||
|
myself](https://bin.nixnet.services/?f76b8366e6b7a7b0#95skPFhsptkfyMH3i1n25ENZeUzrmYEUHzDVezaToGn).
|
||
|
|
||
|
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.
|
||
|
|
||
|
`Return-Path: <amolith@nixnet.xyz> ` 👉 Address your reply will go to
|
||
|
|
||
|
`Delivered-To: amolith@nixnet.email ` 👉 Address the email was sent to
|
||
|
|
||
|
`To: Amolith <amolith@nixnet.email> ` 👉 The *displayed* receiver
|
||
|
|
||
|
`From: Amolith <amolith@nixnet.xyz> ` 👉 The *displayed* sender
|
||
|
|
||
|
`Subject: Email demonstration ` 👉 Subject of the email
|
||
|
|
||
|
`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
|
||
|
|
||
|
`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.
|
||
|
|
||
|
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
|