this post was submitted on 25 Sep 2024
31 points (100.0% liked)

Privacy

32108 readers
511 users here now

A place to discuss privacy and freedom in the digital world.

Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.

In this community everyone is welcome to post links and discuss topics related to privacy.

Some Rules

Related communities

much thanks to @gary_host_laptop for the logo design :)

founded 5 years ago
MODERATORS
 

Heya, I found how you can digitally sign and encrypt emails! (It even gives them a cool icon for others to see!), and I haven't seen anything about it before so I thought I'd share how I did it!

Do you also want to send encrypted emails and sign them? Just follow these few steps!

But beforehand, let's define some terms :

  • Signed email : Email with a valid numerical signature. Anyone can read it and know it has not been modified since it was sent.

  • Encrypted email : Email encrypted with the recipient's public key. They can decrypt it with their private key

  • S/MIME certificate : A .p12 file containing your private key (So keep it for yourself and don't send it to anyone!!) and your public key.

Okay, now it's time to...

Start the setup (Obtain an S/MIME certificate)

  • You'll need to ask to an authority for a certificate. Personally I use Actalis because they give free certificates for multiple email addresses, valid for a year (you need to redo the setup every year). If you don't want to use Actalis, more info is avilable here.
  • Don't forget to put the website in english if you don't understand italian.
  • Go on the page to request an S/MIME certificate, create an account and follow the setup. The verification email can take a little while (~2min)
  • When the setup ends, you'll have a valid certificate in your dashboard (It can take a few minutes to appear if you just verified it) that you can download, and a password that Actalis emailed you to enable your certificate.

Install the certificate

  • Download the .p12 file, then open it, type your password, and leave the default options to install the certificate on your device (Android or PC, on Android pick "For VPN and apps"). Don't delete your old one, so you can still decrypt old messages sent on the expired certificate
  • Use an S/MIME compatible email client. On PC, there is Thunderbird, on Android, FairEmail.
  • In your email client settings, importer the S/MIME certificate pofor signing AND encrypting your messages. It changes depending on your client, so here it is for Thunderbird :
    • In the top-right menu, go to Account settings, End-to-end encryption, underS/MIME click on Manage S/MIME certificates, Import and pick your.p12 file. Then, pick Select a certificate, and pick yours from the tab "Your certificates".

An image is worth a thousand words (Sorry for the french)

Don't forget to check the box to sign and/or encrypt every message just below, if you want!

Communicate with someone

Once this is done, here is how you can communicate...

  • ...While signing your messages :

It's easy, just click on "Sign" before sending. Usually, email clients show a small medal next to your name to show the email is signed.

  • ...While encrypting your messages :

For that, you'll need your recipient's public key. They needs to send you a signed message (not encrypted, since you don't have each other's key at this point) where you can get their public key from their signature, and add it to your email client, which will allow you to encrypt messages you send to them. Then, send them a signed email (you can encrypt it) so they can get your public key and add it to their client, and then you'll be able to exchange encrypted emails!

I'm not an expert and probably made a few mistakes, if you spot any please tell me in the comments and I'll try to fix the guide!

top 18 comments
sorted by: hot top controversial new old
[–] troublehelix@feddit.nu 4 points 1 month ago (1 children)

Personally I'd love to see more wider usage of S/MIME and/or PGP. What I take issue with actalis, is that they don't just sign your private key but you actually get the private key from them. It then depends on how much you trust the issuer. To me a key that wasn't always in your possession is basically compromised from the start.

(Although, I am also using protonmail's pgp, which arguably violates this rule as well, their transparency is more trustworthy to me. )

[–] Laser@feddit.org 3 points 1 month ago (4 children)

Personally I'd love to see more wider usage of S/MIME and/or PGP.

I'd rather see less. https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ is a good summary about the issue and they have a shorter follow-up post about why encrypting mail in general is bad at https://www.latacora.com/blog/2020/02/19/stop-using-encrypted/

What I take issue with actalis, is that they don't just sign your private key but you actually get the private key from them. It then depends on how much you trust the issuer.

By definition, that key can no longer be considered "private".

[–] Kualk@lemm.ee 2 points 1 month ago* (last edited 1 month ago)

https://www.latacora.com/blog/2019/07/16/the-pgp-problem/ is a good summary about the issue

Good counter discussion about PGP security

https://www.reddit.com/r/cryptography/comments/10cfslk/exactly_how_strong_is_pgp/

I would argue that latacora could be an attempt to push users into the systems that provide 3rd party service, which by definition of 3rd party service is not secure: WhasApp, Signal.

Only true P2P can be safe. PGP provides ability to send encrypted message using any means necessary: FTP, HTTP, anonymous services, USB sticks, anything.

[–] Kualk@lemm.ee 2 points 1 month ago

What I take issue with actalis, is that they don’t just sign your private key but you actually get the private key from them. It then depends on how much you trust the issuer.

By definition, that key can no longer be considered “private”.

It is very important to emphasize that the key in this model is not "private" anymore. Thus, all the communication using this key is not secure anymore.

Private key is the one generated by hardware owned by the user and immediately secured with strong password. Ideally, private key does not leave the hardware that generated it. Thus, every device shall have its own private key.

In less restricted model, private key gets copied by the user to other hardware using media like USB stick or P2P communication model that does not use cloud services.

[–] Kualk@lemm.ee 1 points 1 month ago

why encrypting mail in general is bad at https://www.latacora.com/blog/2020/02/19/stop-using-encrypted

The point about email having leaking matadata is 100% spot on.

The argument why Signal is better is very short and not substantiated IMO.

[–] troublehelix@feddit.nu 1 points 1 month ago

Those are some very good points. Some even eye opening to me. It seems that my viewpoint probably was a bit skewed as the email encryption I mostly deal with is between businesses as part of my day job. I guess, in that context things like the meta data issue are known but accepted as the relationships between parties in most cases are public knowledge and companies may have to keep records for LE/regulatory bodies anyway. I can also see how quite a bit of it could be considered performative.

I hadn't considered much that advocating for encrypted email outside of that context could keep people from using the right tool for their needs and possibly hinder acceptance of better choices.

The PGP article also made me roll my eyes a bit, as one of our vendors still doesn't support ECC keys today. The last reason communicated being that the relevant RFC was only a draft.

[–] Kualk@lemm.ee 4 points 1 month ago* (last edited 1 month ago)

Be aware, that trusted Certificate Authority (CA) configuration applies to ALL certificates issued by CA. Thus, if one elects to trust "actalis" CA, then they trust ALL actalis CA users.

If the process of obtaining certificate was extremely simple, easy and did not involve identity verification steps, then bad actors can take advantage of this process and create identities that your client application will trust.

By itself the bad actor identity is of little concern to anybody, but it can have a significant impact if trusted identity is used in spam filtering, exploits of email client bugs or other hack attempts. Trusted users may be given higher access privilege at the client application level, which may be just enough for hacker to gain required access. For example, client application may be configured to trust all trusted senders with MIME attachments. An unknown trusted user sends malicious Application as file attachment. Accidental double click lunches the application without "are you sure?" prompt. Congratulations, machine is pwned.

The problem is easily mitigated by not importing root CA for easy CAs.

[–] Kualk@lemm.ee 3 points 1 month ago* (last edited 1 month ago)

Yes, it exists.

S/MIME requires the receiving side to have its own certificate or, to be more correct, a private key represented by the certificate. The recipient's certificate needs to be known to the sender. The sender's certificate needs to be known by the recipient. That's why S/MIME is not used. It requires configuration on both sides, before it can be used.

Most people don’t know how to obtain certificate and configure email client with it or don’t bother to obtain certificate even if they know. The same problem exists if PGP is used, even if it is a bit different.

I will cover S/MIME and PGP because of similarities.

S/MIME or certificate based solution is supported by many clients, so it is easier on end user than PGP. S/MIME is part of the specification, that's why good email clients have built-in support. S/MIME problems are all around certificate management: how to obtain certificate (free or not), how to import certificate, how to trust certificate, how to import trusted root of the certificate.

It is easier to manage keys for free in PGP. PGP has no protocol level support in email clients, so it requires additional handling of underlying content. In effect PGP encrypted messages are injected into text message or sent as email attachments. In both cases PGP content has to be handled by external application (PGP encrypted text or image) or email client specific plug-in.

The technology is very old for both cases. It has not caught on due to friction of key management for both technologies. PGP has additional problem of content handling.

S/MIME is perfect if you want to communicate with family or friends as you can ensure everyone in your circle has their own private key. Even in this narrow case, I guarantee you will experience some friction to get this through.

Organizations can have it easier as they can issue certificates to their users. But then problem of trusted certificate authority comes into play, if they use their authority (every email client or OS running this email client has to import new Trusted Certificate Root, that is hard at ORG level and it gets worse when they have to tell their outside contacts how to work with them). If they use well known authority, they avoid Trusted Cert Root problem, but they have to pay for every user certificate.

So, you can see how there’s friction in S/MIME solution. IMO, S/MIME is a good solution, but friction made it unrealistic in major use cases.

At this point I recommend Delta Chat. I am not involved with it. I just like what I see. It is uses PGP technology. In the end it is looks like a modern P2P chat application with all the expected Chat functionality, but it is actually an email client sending PGP encrypted messages over email. Delta chat solved private key creation using built-in key generation. Public key exchange is solved via key exchange protocol. The problem of content attachment is solved by the application itself. Take a look at articles about it https://delta.chat/en/references

Signal vs Delta Chat. Signal metadata exposes your contacts and probably your time of contact. With Delta Chat you get the same level of meta data exposure: your contact and time of contact are in the open, because underlying protocol is email.

S/MIME protections. S/MIME keeps the same metadata in the open: contact and time of contact. That's because S/MIME protects the payload (message body), not the email protocol headers.

I might be a bit off on how PGP or S/MIME is passed around at SMTP headers level, but overall meaning shall stay the same.

[–] tapdattl@lemmy.world 2 points 1 month ago (1 children)

Question 1: What's the point of using Actalis? Can't you generate your own certificate?

Question 2: Is there a way to get your email.server to automatically publish your public key?

[–] helloyanis@jlai.lu 1 points 1 month ago (1 children)

So as I understand :

  1. Actalis is a trusted authority among others but is the only one to issue free S/MIME certificates that I found. You need to use a trusted authority to make the signature, or else your email client will say "Cannot verify signature authenticity" and show a red badge. This explains it better
  2. When you sign your email, you include your public key in the signature. So just sign every email (usually an option in your client) to let anyone you email have your public key. I don't really understand why you would need to change stuff in the email server.
[–] tapdattl@lemmy.world 1 points 1 month ago* (last edited 1 month ago) (1 children)

Ahh gotcha, that makes sense, so like the difference between a self signed SSL certificate and something like LetsEncrypt.

Re 2: I was thinking in the scenario to allow auto discovery of your certificate, so someone who is emailing you for the first time could look up your public key automatically and use it to encrypt their email.

Also, great writeup and thank you!

[–] helloyanis@jlai.lu 1 points 1 month ago

I don't think it's possible to do that, but I have no experience on this since I don't use my own email server so I could very well be wrong.

[–] TaviRider@reddthat.com 1 points 1 month ago (1 children)

Actalis sends you your private key. This means they have access to your private key, and theoretically could use it to sign and decrypt your emails. A more secure but somewhat more complex system would use a certificate signing request (CSR) instead. In that case, you are the only person who ever has your private key, so only you can sign or decrypt your email.

[–] helloyanis@jlai.lu 1 points 1 month ago

I have put a link with more info about this if you don't want to use Actalis

[–] TaviRider@reddthat.com 1 points 1 month ago (1 children)

Also delete your expired certificate if you have one (for example after a year)

This is likely a bad mistake. Keep the old cert around.

There’s two possibilities:

The first possibility is that Actalis uses the same key pair for the new cert. This is not a great approach because it doesn’t defend against a leaked key or key overuse. After all, if the key can be trusted longer than a year, the first cert they issued should be valid for longer.

The second, and much worse possibility, is that renewing the cert gets a different private key. This can case data loss. Deleting the old identity means you lose the ability to decrypt any messages that were encrypted using that key! Even if your mail client stores the previously encrypted emails in decrypted form, you may receive a new email from a sender who does not yet have your new cert.

[–] helloyanis@jlai.lu 1 points 1 month ago

Updated, thanks!

[–] poolhelmetinstrument@lemmy.world 1 points 1 month ago (1 children)

Great job and spot on! I know how good it feels to figure out stuff like this. I did this back in 2018. Was useful for sending encrypted emails to an organization with PKI setup. This was before they had other means through either O365 or a separate vault like sharing web app. Since there was no regular communication between this organization, I had no reason to keep it setup. I was employed by the organization and had an internal email.

[–] helloyanis@jlai.lu 1 points 1 month ago

Awesome, i spent a long time writing it and I'm happy you find it useful!