>OpenPGP uses a decentralized “Web of Trust” where users vouch for each other’s keys.
This article fails to mention WKD [1] (Web Key Directory) which is supported by Proton Mail, doesn't rely on the "Web of Trust" and allows seamless PGP encryption of sent emails. Here is an example of how this works (and how it can get annoying) [2].
>Contrast all this with Signal or WhatsApp, where encryption works automatically because a single organisation controls the full software stack rather than using open protocols.
In a usability study involving Signal[1], 21 out of 28 computer science students failed to establish and maintain a secure end to end encrypted connection. There seems to be a tradeoff. We can do either usability or security, but never both at the same time.
Arguably things are now worse. Signal combined the safety number of you and your correspondent into one really big number[1]. The result is a less intuitive as a number no longer represents the identity of a correspondent.
Signal has been having multiple issues due to the poor usability of their identity management lately[2].
"... our study assesses if users are able to detect and deter man-in-the-middle attacks on the SIGNAL protocol. Our results show that the majority of users failed to correctly compare keys with their conversation partner for verification purposes due to usability problems and incomplete mental models. Hence users are very likely to fall for attacks on the essential infrastructure of today's secure messaging apps: the central services to exchange cryptographic keys."
Why not just describe the actual results? Most Signal users aren't subject to MITM attacks and establish secure end-to-end connections with zero effort or thought.
> Additionally, servers don’t verify certificates by default. […] This is because verifying the certificate adds no security when an active attacker could just fall back to an unencrypted connection.
But surely the eventual goal is encrypted-only, at which time that’s no longer the case. Not verifying certificates feels like it may just slow down the process, because now when it looks okay you may actually find it’s not, the error is just masked for now.
I self-host my email, in part because I wanted to enforce encryption whenever I send. My server does verify the certificate of the target MX, whether it uses MTA-STS or not. Delivery fails if the certificate is invalid, and also fails if the destination (or a man in the middle) downgrades or strips STARTTLS.
In eight years, I’ve seen zero servers that refused STARTTLS, and only two invalid certificates. In both cases, the certificates were from a valid CA and weren’t expired, but the hostname was wrong. Both were due to outdated DNS records, one of which was fixed as soon as I reported it, and the other resolved itself after a few months.
How often do you see self-signed certificates that are valid due to DNSSEC/DANE configuration versus certificates were issued by a trusted CA? When I checked two years ago I found that 99.3% of the top 1,000 domains supported STARTTLS and 94.1% used a TLS certificate issued by a CA. I suspect the numbers keep improving, but I don't think we're quite at 100% yet.
> My server does verify the certificate of the target MX
But how do you know if the target MX is correct, and not controlled by an attacker? You can't really know for sure unless the receiver has secured their domain name with DNSSEC or published an MTA-STS policy.
I am self-hosted: minimal smtp server, no TLS, only direct and basic delivery of emails. I don't even pay the DNS mob, namely I use IP literals (mailbox@[x.x.x.x] and more mailbox@[ipv6:...], see smtp RFC, yeah the email guys were smart enough not to make their protocol hard dependent on DNS neither on any crypto).
I do not trust the CA system. If I ever crypt the content of an email, it would be because a guy I saw gave me its public key in some way (QR code?) face to face. For really serious stuff, I would not use smtp anyway and with some modified-standard-cipher pre-shared key anyways.
Temporary states go on with a long tail. Look at the v6 transition. We're dual stack for the foreseeable future and it's my guess we'll be in partial deployment of secure mail transport for aeons.
Fastmail does support MTA-STS for inbound messages... sort of. For inbound MTA-STS the email provider needs to use a TLS certificate issued by a trusted certificate authority, which Fastmail does. Additionally, the domain name in the "to address" needs to enable MTA-STS using some DNS records. Fastmail does not provide the documentation for setting this up, although they have decent adoption by folks who figured it out on their own. I'm seeing about 0.2% of domains using Fastmail enforce MTA-STS inbound:
SELECT mta_sts_mode, COUNT(*) AS "count"
FROM read_parquet('dns-analytics-2026-q3-*.parquet')
WHERE exchange_suffix = 'messagingengine.com'
GROUP BY mta_sts_mode
ORDER BY count DESC;
---
mta_sts_mode count
- 174,877
enforce 354
testing 313
none 11
This is about the same as Protonmail (~0.2%), but higher than Outlook (~0.1%) and Google (<0.1%). I suppose this reflects Fastmail's popularity among technically minded folks.
I'd like to see Fastmail improve this by clearly documenting MTA-STS support, setup instructions, and validate MTA-STS in their custom domain dashboard. It looks like they may be adding MTA-STS policy hosting, which is a really promising sign, but I don't see this documented yet so this is probably being tested internally.
I just had my first foray into S/MIME. Tons of mail providers and software hide it behind enterprise licensing and I didn't want to do that for ~2 emails a year. I'm extremely thankful to the Thunderbird team and the OpenSC projects.
If Fastmail offered a CA certificate, then whenever I use Fastmail I would run another separate browser instance or mail client with all CA certs removed and Fastmail's CA certificate loaded.
This behavior, or lack of it, and resulting functionality is what differentiates the "follow the best practices consensus" security teams and the upper tiers of security teams.
> [...] Contrast all this with Signal or WhatsApp, where encryption works automatically [...]
This is an incredibly overconfident statement, given that no one can definitively prove WhatsApp or production consumer builds of Signal actually encrypt anything (note: this is unrelated to Signal builds compiled by users themselves).
Existing reverse-engineering papers on WhatsApp merely confirm the presence of cryptographic primitives and function markers. They fail to prove actual runtime encryption or decryption of user messages, nor guarantee the absence of a cryptographic bypass or secret switches embedded within the builds.
To maintain strict factual accuracy, the author should have instead mentioned Delta Chat and SimpleX Chat, that publish fully reproducible builds.
Thanks for pointing out Delta Chat, I definitely want to give it a try now.
I think we do know WhatsApp is encrypted... considering its population, by now we would know from any court cases (especially criminal cases) that bad guys were caught communicating on WA.
Its often backups signed with Google or Apple keys that are uploaded to Google or Apple that would be vulnerable to a warrant from Law enforcement. Even today, you need to enable end to end encryption on the backups to plug that hole (apparently).
This article fails to mention WKD [1] (Web Key Directory) which is supported by Proton Mail, doesn't rely on the "Web of Trust" and allows seamless PGP encryption of sent emails. Here is an example of how this works (and how it can get annoying) [2].
[1] https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...
[2] https://matduggan.com/why-cant-my-mom-email-me/
>Contrast all this with Signal or WhatsApp, where encryption works automatically because a single organisation controls the full software stack rather than using open protocols.
In a usability study involving Signal[1], 21 out of 28 computer science students failed to establish and maintain a secure end to end encrypted connection. There seems to be a tradeoff. We can do either usability or security, but never both at the same time.
[1] When SIGNAL hits the Fan: On the Usability and Security of State-of-the-Art Secure Mobile Messaging https://www.ndss-symposium.org/wp-content/uploads/2018/03/09...
Signal has been having multiple issues due to the poor usability of their identity management lately[2].
[1] Safety number updates https://signal.org/blog/safety-number-updates/
[2]
A Third Party Breached The Intercept’s Signal Tip Line and Has Been Soliciting Whistleblowers https://www.dropsitenews.com/p/intercept-signal-tip-line-bre...
Twilio Incident: What Signal Users Need to Know https://support.signal.org/hc/en-us/articles/4850133017242-T...
Russian State-Backed Hackers Intensify Attacks on Signal Messenger Accounts https://thecyberexpress.com/signal-attacks-russian-fackers-t...
End to End Encrypted Messaging in the News: An Editorial Usability Case Study (my article) https://articles.59.ca/doku.php?id=em:sg
"... our study assesses if users are able to detect and deter man-in-the-middle attacks on the SIGNAL protocol. Our results show that the majority of users failed to correctly compare keys with their conversation partner for verification purposes due to usability problems and incomplete mental models. Hence users are very likely to fall for attacks on the essential infrastructure of today's secure messaging apps: the central services to exchange cryptographic keys."
Why not just describe the actual results? Most Signal users aren't subject to MITM attacks and establish secure end-to-end connections with zero effort or thought.
But surely the eventual goal is encrypted-only, at which time that’s no longer the case. Not verifying certificates feels like it may just slow down the process, because now when it looks okay you may actually find it’s not, the error is just masked for now.
In eight years, I’ve seen zero servers that refused STARTTLS, and only two invalid certificates. In both cases, the certificates were from a valid CA and weren’t expired, but the hostname was wrong. Both were due to outdated DNS records, one of which was fixed as soon as I reported it, and the other resolved itself after a few months.
But how do you know if the target MX is correct, and not controlled by an attacker? You can't really know for sure unless the receiver has secured their domain name with DNSSEC or published an MTA-STS policy.
I do not trust the CA system. If I ever crypt the content of an email, it would be because a guy I saw gave me its public key in some way (QR code?) face to face. For really serious stuff, I would not use smtp anyway and with some modified-standard-cipher pre-shared key anyways.
But you do pay someone to delegate your IP, right? Or do you have your own ASN and do your own BGP?
https://support.google.com/mail/answer/81126
Fastmail does not enforce MTA-STS for outbound messages. I just checked here (https://email-security-scans.org/view/jktrld5e73b2dyxz0h1swu...). You can see how your email provider compares at https://email-security-scans.org.
Fastmail does support MTA-STS for inbound messages... sort of. For inbound MTA-STS the email provider needs to use a TLS certificate issued by a trusted certificate authority, which Fastmail does. Additionally, the domain name in the "to address" needs to enable MTA-STS using some DNS records. Fastmail does not provide the documentation for setting this up, although they have decent adoption by folks who figured it out on their own. I'm seeing about 0.2% of domains using Fastmail enforce MTA-STS inbound:
This is about the same as Protonmail (~0.2%), but higher than Outlook (~0.1%) and Google (<0.1%). I suppose this reflects Fastmail's popularity among technically minded folks.I'd like to see Fastmail improve this by clearly documenting MTA-STS support, setup instructions, and validate MTA-STS in their custom domain dashboard. It looks like they may be adding MTA-STS policy hosting, which is a really promising sign, but I don't see this documented yet so this is probably being tested internally.
With that said, I've been extremely happy with Fastmail for several years now and recommend it.This behavior, or lack of it, and resulting functionality is what differentiates the "follow the best practices consensus" security teams and the upper tiers of security teams.
This is an incredibly overconfident statement, given that no one can definitively prove WhatsApp or production consumer builds of Signal actually encrypt anything (note: this is unrelated to Signal builds compiled by users themselves).
Existing reverse-engineering papers on WhatsApp merely confirm the presence of cryptographic primitives and function markers. They fail to prove actual runtime encryption or decryption of user messages, nor guarantee the absence of a cryptographic bypass or secret switches embedded within the builds.
To maintain strict factual accuracy, the author should have instead mentioned Delta Chat and SimpleX Chat, that publish fully reproducible builds.
I think we do know WhatsApp is encrypted... considering its population, by now we would know from any court cases (especially criminal cases) that bad guys were caught communicating on WA.