>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.
"... 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.
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].
> 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.
> 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.
Nope, in my "first world" country, some consumer IAPs does offer a static IPv4 with a non-filtered SMTP port and a static IPv6 prefix (usually a /64 which is very convenient to change email address/hosting IPs when compromised, well if you use an address email with an IPv6 literal). But I don't really use IPv4 anymore for my self-hosting, IPv6 has been around _here_ for a very, very long time for nearly everybody if not everybody (even mobile internet).
Yes, I know my IPv4 is the target of distributed port scans, by IPs known as compromised by the "security" community. I guess my IAP "security" team knows, and they may probably be 'in the process of doing something to deal with them'... (which would more than IP blocking and would involve authorities...).
FTTH(8GB), static IPv6, static IPv4 plus opened SMTP port, ~30 bucks a month (for millions).
OK, so now you can't move or change ISP without having to change your email. That seems incredibly inconvenient. Also your ISP could change their plan at any time.
Also, you are still paying your ISP to delegate the IP, it's just bundled into your ISP plan.
Changing ISP is rare, then does matter less than being self-hosted.
Giving a IPv4 and IPv6 prefix is what an ISP do...
Mine is doing even more: you have access to some of its sub-domains at no additional charge. But I don't use them because they are gated by whatwg web engines (a mistake or they should be ashamed of themselves).
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.
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.
> [...] 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.
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).
With the massive improvements to AI, it'd be pretty trivial to decompile Signal and compare against the source, or have it reverse engineer WhatsApp to see if there's some kind of backdoor.
Give me a compelling reason why I should care? The Signal Foundation hasn't done anything to undermine its trust. They already do reproducible builds on Android, so why would they backdoor the iOS app.
If it bothers you, why don't you do it and show that it can or cannot be done, or that it isn't as trivial as I say showing the assertion false. Feel free to accept this nerd snipe.
Otherwise, continue to sook because you didn't get what you want.
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).
Well I only do manual backups, but my point is that if your data would be avail to LE, we would already know through some criminal cases which majority is unsealed. Up to my best knowledge, we don't have such example, although I be the last one to trust Mark Lizardman.
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.
I recently suggested to a larger group which needed to stay in the loop to use age keys for encryption and discuss instructions in broad strokes in threads. This keeps everyone generally informed while technical people exchange privileged payloads as attachments. This ensures privileged data is protected at rest and in transit, ans keeps discussion in a channel everyone is familiar with.
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.
We haven't considered this seriously because the market of people who would actually be interested in it and do it is a rounding error, and the probability of human error is also quite high both at your (not you personally but customers generally) and our (providers in general, look at the failures that DNSSEC has had over the years) end.
This would certainly be ideal compared to the current situation where we're all one eMudhra away from compromise; but I don't see a path there which is proportionate, reasonable, and implementable. In this area, Fastmail isn't a first-mover, because it's not our core expertise. We follow "best practices consensus" as you put it, because that's what actually protects the vast majority of people against realistic threats in a way that they can follow.
I didn't realize I was replying to the CEO of Fastmail until I had written the entire comment. In retrospect I'm glad I wrote without any filter.
I have generally thought Fastmail is a pretty cool guy, eh serves email without frills and doesn't afraid of anything.
So by association my working assumption is the CEO is too.
edit 2:
okay apparently the open source channel of Cyrus IMAP, which I used relatively tangentially at an ancient time, still doesn't have the same configuration flexibility as Dovecot (thanks ChatGPT..). A whole 'nother config file and K8s/init/whatever service entry becomes necessary for another TLS listener, boo hoo I guess.
edit 3:
embedded sha512 hash of comment in file name so no one can say I mutated the file after the edit window is closed.
Fair. Can you name any others in the "$5-10/month" range? You said "Yes" but then didn't elaborate. Sure if you've spending tens of thousands of dollars per month and selling to large corporates where they have a Helpdesk and golden image deploys to every device this is eminently practical.
When you're selling to hundreds of thousands of end-consumers, less so.
Again, I'd be really keen to see what other SaaS consumer products use certificate pinning. Or, let's expand it to banks and government departments in most countries.
Google Mail's $5/seat offering is the first one that comes to mind.
04 May 2011
Starting with Chrome 13, we'll have HTTPS pins for most Google properties. This means that certificate chains for, say, https://www.google.com, must include a whitelisted public key. It's a fatal error otherwise.
https://www.imperialviolet.org/2011/05/04/pinning.html
ImperialViolet is Adam Langley’s personal technical blog. Langley worked at Google on HTTPS infrastructure and Chrome’s SSL stack.
A Tauri app, which is essentially a Chromium browser instance with no address bar and widgets to access browser settings, a Fastmail desktop "app" made with Tauri can potentially even the playing field between Google the Goliath and Fastmail the David on the TLS certificate pinning front. Tauri is like Electron but sucks a lot less.
https://tauri.app/
_
> if you've spending tens of thousands of dollars per month
Such as, 8,000 users at $40k/month for Google Mail.
Yubico has great volume discounts for a part of the CapEx side of a sane deployment of this.
The basic WebAuthn/FIDO2-only Yubikeys with a Fastmail logo on them would be, as the kids said a generation ago, "dope".
_
> where they have a Helpdesk
Quality attention to cicd and artifact release may avoid and potentially reduce conventional helpdesk activity.
For individual users of SaaS, provided the .dmg or .msi of the downstream Betterbird/Thunderbird (or other MUA) has sound cicd and decent release attention, no more additional support tickets than reasonable should occur beyond an initial phase.
A downstream MUA distro can eliminate manual configuration and superfluous details, such as the shit experience with Thunderbird on macOS (Thunderbird's fault 100%) with Oath2 I saw in the last few months. Such a distro could be tuned with a slew of relatively small adjustments reducing existing support ticket traffic.
Startups with headcount of 20 to 30, a good chunk of that being developers, where I have historically preferred to dwell, helpdesk is not there nor wanted for. Higher quality customers are here.
_
> and golden image deploys
Chromebooks, which not including K-12 did outnumber macOS in non-personal environments around a half-decade ago during that Event 201 thing. Super low IT overhead with those.
I have been distant from MIS type of IT for a while but have heard echoes or binocular'd in a bit and believe the golden image era has quietly passed us.
Conventional image pattern shouldn't be necessary anywhere now.
Somewhere in 2019, Apple warped native tooling in tandem with device firmware behavior to squeeze out the conventional image pattern ; killed it off.
Apple Business now includes built-in mobile device management which can enroll and set up Apple devices then apply standard settings and apps through "Blueprints" ; the .dmg would be trivial to push out. The successor to Jamf.
With Microsoft Intune, propagation of .msi packages to enrolled devices is a day-to-day task.
Ubuntu, RedHat, SuSE, Qubes, and all related distros, when under IT teams that can code on a rudimentary level, are managed with Ansible or Salt, without the "enterprise tax" part.
What all of these have in common is centralized org-wide device management where the ability to push out a .msi or .dmg or .deb/.rpm/.AppImage is there.
In similar spirit to certificate pinning, the advanced customers have dedicated private cicd consume source code from the OS vendor.
The more advanced are on
Bootstrappable builds: how and why
https://lwn.net/Articles/1088279/
which in tandem with cryptography-grade hashes, has over half way solved the "Trusting Trust" problem that Ken Thompson raised.
_
> what other SaaS consumer products use certificate pinning.
Slack has the low-hanging-fruit opportunity to with their Electron app, but has reportedly dropped the ball. This is great for tech workers who like to divert all Slack contents to a separate local data sink for archiving and discovery and non-shitty data access.
This repo from about seven years ago looks abandoned and inactive, but
> let's expand it to banks and government departments in most countries.
With the episodic exposure I had with computer vision -> flow chart startups in the SF Bay Area many years ago, relatively ongoing time sinks with some archetypal MBA twat types, and some perceived legendary tier banks running on one of the two legit clouds (neither of which is that Azure garbage), who then fell on customer-facing downtime by not deploying with rudimentary cloud patterns that startups don't fail to do (as we recently found out), I am left feeling not confident that banks can do IT with self-reliance these days.
They can still push out .msi and group policy objects though, for sure.
From anecdotes I hear of and distant observations of state governments, departments of the big federal government sans some of the cooler TLA, and govs in Europe, I am not optimistic about those.
About a decade and a half ago we used to look at these two types of institutions and go "ah, the big guys, in their big buildings, they broker a thing I need, with their marble floors and reassuring smiles, these egregore have got it all figured out".
As a staff level DevOps / DevSecOps / whatever who has been along for the ride with a share of Silicon Valley culture-OS startups with enterprise customers, closely followed practices and white papers of hyperscalers and elite security firms, thus can see through any IT product/pattern transparently for its base principles...
-- having witnessed various sitcoms, heard of or read over 9,000 of first-hand accounts of such sitcoms, on top of the broadly spread cultural decay we are experiencing in the West upcoming on this Fourth Turning, with the rot of these institutions, and the major cultural shifts on computer illiteracy/obliviousness being normalized among "professionals" observed over the last couple of decades, I think more often than not some scrutiny of IT patterns at these institutions uncovers that they are severely retarded.
I suspect on the mid to lower end of the gov side it's just checkboxes, misdirection, and casual corruption almost all of the way down. Anyone who actually gives a shit about IT security and tries to fix things gets railroaded out.
The subcontractors who pick up the slack and handle real shit, like SpaceX is something NASA is dependent on (macro example), the upper echelon of the private sector, supranational organizations run by elite characters, are where not the progressive-minded IT teams are found but where IT is treated with some seriousness by leadership. But no transparency into IT patterns will be offered by these outside of talks at cool parties like DEF CON and AWS Re:Invent (shitty DJs but still a great party).
I don’t know if Google still pin their certificates or if Chrome still pins Google’s certificates in some way, but the wind has definitely shifted against that approach. In 2015, Chromium and Firefox introduced the general-purpose HTTP Public Key Pinning <https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning>; but within a couple of years they agreed it was a bad idea, and it was removed entirely by 2020. Certificate Transparency and CAA records are the closest thing to a replacement. Many sites that did fancy certificate stuff 10–15 years ago (e.g. EV certificates) have unceremoniously dropped it since.
August 2023
To defend against this risk, Chrome contains a pin set for all Google properties, and we only consider an HTTPS input trustworthy if it’s authenticated using a key in this pin set. Chrome contains a pin set for all Google properties, and we only consider an HTTPS input trustworthy if it’s authenticated using a key in this pin set. This protects against malicious certificate issuance by third parties.
https://security.googleblog.com/2023/08/making-chrome-more-secure-by-bringing.html
is the most recent first-source writing a cursory search just found, consistent with pinsets in transport_security_state_static_pins.json
If Google were to ever abdicate their position such that Chromium or Android let a non-Google CA deem a national treasure like mail.google.com valid, especially by some rando chud CA from some third world shithole, oh how crushingly disappointing that would be, a dagger to USA's greatness.
_
If HKP specification had worked out (RIP, lol), that may have over the last decade-ish spared some config lines for CA config behind commands like
to load browsers with whitelisted CA in Firejail, Capsicum (BSD Jails), or kvm/bhyve/xen/SwiftBoot/whatever.
It's odd how that, for the unwashed masses' use of browsers with the default CA config, high-value clearnet websites' PKI robustness is, from all I've read over the years, more often than not functionally outperformed by prominent LSD/tryptamine vendors of various DarkNet Markets.
LoL
_
A more meaningful answer on the "other organizations" question above, for a project one might get one or more CA and relevant details in a PGP/MIME or S/MIME or by-hand gpg/sq message with the implicit "you already know what to do".
Some commercially operated services, geared more towards high-value customers, have casually offered a first-party CA cert. Perhaps due to being operated by and for relatively higher value demographic (thus, I'll not advertise them here), even at general or low pricing (high trust societies just hit different).
Some "far left" or whatever anarchist-ish communities often not chasing profit casually do first-party CA too, which is no less based than any other subculture doing it.
Any time someone may have ever manually sent you a VPN config file to load, this is in essence sort of what they were doing but without the existing known-pubkey part.
Across the globe, competent IT teams transparently propagate dedicated browser instance profiles with explicitly whitelisted CA that show up in users' toolbar/dock as differently styled icons with appropriate splash images/dialogue when clicked.
The ability to do this correctly and without mistakes, is, as mentioned above, a litmus test for (when asked to do so) if an IT team is legit or not.
This functional pattern of the people who get the real shit done has been in place for more than, as far as I personally for over two decades have happened to know. And, functionally in its substance, no matter what form on the surface, it's not going away, not ever.
At least not until a cosmic event leading to the dissolution of this current run of civilization.
As I imagine, you already probably know. I see your pubkeys on Keybase. Imported.
_
Super lame anecdote: at one hilarious and sad juncture I witnessed a self-titled ""CTO"" at a sham company, self-proclaimed "security guru", expose himself as a total fucking fraud when he announced boldly to a room that all OpenStack APIs functionally (not a directive, but functionally) are unable to use in-house CA, in what was surfaced as a lame attempt to shirk applying a skill he'd hyped everyone up he like totally had fluency in. Then a good chunk his own team on the side derided him as a "fucking LARP" immediately after that before anyone else could have commented.
"The thing about computers are is they are objective"
(roughly accurate quote of)
~ Jonathan Blow
>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].
[1] https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s...
[2] https://matduggan.com/why-cant-my-mom-email-me/
The article on end to end email encryption:
>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...
I think you greatly overstate the results:
"... 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.
This paper is from 2016. Signal's UX has improved massively in many ways since this was published.
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].
[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
> 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.
> 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.
> I don't even pay the DNS mob
But you do pay someone to delegate your IP, right? Or do you have your own ASN and do your own BGP?
Nope, in my "first world" country, some consumer IAPs does offer a static IPv4 with a non-filtered SMTP port and a static IPv6 prefix (usually a /64 which is very convenient to change email address/hosting IPs when compromised, well if you use an address email with an IPv6 literal). But I don't really use IPv4 anymore for my self-hosting, IPv6 has been around _here_ for a very, very long time for nearly everybody if not everybody (even mobile internet).
Yes, I know my IPv4 is the target of distributed port scans, by IPs known as compromised by the "security" community. I guess my IAP "security" team knows, and they may probably be 'in the process of doing something to deal with them'... (which would more than IP blocking and would involve authorities...).
FTTH(8GB), static IPv6, static IPv4 plus opened SMTP port, ~30 bucks a month (for millions).
OK, so now you can't move or change ISP without having to change your email. That seems incredibly inconvenient. Also your ISP could change their plan at any time.
Also, you are still paying your ISP to delegate the IP, it's just bundled into your ISP plan.
Changing ISP is rare, then does matter less than being self-hosted.
Giving a IPv4 and IPv6 prefix is what an ISP do...
Mine is doing even more: you have access to some of its sub-domains at no additional charge. But I don't use them because they are gated by whatwg web engines (a mistake or they should be ashamed of themselves).
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.
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.
Google is easily in a position to force it unilaterally.
They already do, but unfortunately only for mass senders.
https://support.google.com/mail/answer/81126
That indicates that they require it for all inbound mail, but it doesn’t yet cover outbound.
Google blocks IP literal email addresses (which is stronger than SPF and should be part of DMARC).
This is a good overview of email encryption, but it doesn't cover what Fastmail actually supports which I think makes this misleading.
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.> [...] 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.
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).
With the massive improvements to AI, it'd be pretty trivial to decompile Signal and compare against the source, or have it reverse engineer WhatsApp to see if there's some kind of backdoor.
If it's so incredibly trivial, can you please do and publish the results?
(but also, absence of evidence isn't the same as proof of absence)
I don't care to, I trust the fidelity between the open source code and the compiled application for the phone. Find someone that cares.
yawn… sure pal. "you don't care to"… that's the only obstacle here.
Give me a compelling reason why I should care? The Signal Foundation hasn't done anything to undermine its trust. They already do reproducible builds on Android, so why would they backdoor the iOS app.
If it bothers you, why don't you do it and show that it can or cannot be done, or that it isn't as trivial as I say showing the assertion false. Feel free to accept this nerd snipe.
Otherwise, continue to sook because you didn't get what you want.
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.
A few more pointers here:
https://github.com/n0-computer/awesome-iroh
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).
Well I only do manual backups, but my point is that if your data would be avail to LE, we would already know through some criminal cases which majority is unsealed. Up to my best knowledge, we don't have such example, although I be the last one to trust Mark Lizardman.
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.
I recently suggested to a larger group which needed to stay in the loop to use age keys for encryption and discuss instructions in broad strokes in threads. This keeps everyone generally informed while technical people exchange privileged payloads as attachments. This ensures privileged data is protected at rest and in transit, ans keeps discussion in a channel everyone is familiar with.
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.
Do you do this with any other organization?
We haven't considered this seriously because the market of people who would actually be interested in it and do it is a rounding error, and the probability of human error is also quite high both at your (not you personally but customers generally) and our (providers in general, look at the failures that DNSSEC has had over the years) end.
This would certainly be ideal compared to the current situation where we're all one eMudhra away from compromise; but I don't see a path there which is proportionate, reasonable, and implementable. In this area, Fastmail isn't a first-mover, because it's not our core expertise. We follow "best practices consensus" as you put it, because that's what actually protects the vast majority of people against realistic threats in a way that they can follow.
I didn't realize I was replying to the CEO of Fastmail until I had written the entire comment. In retrospect I'm glad I wrote without any filter.
I have generally thought Fastmail is a pretty cool guy, eh serves email without frills and doesn't afraid of anything.
So by association my working assumption is the CEO is too.
edit 2:
okay apparently the open source channel of Cyrus IMAP, which I used relatively tangentially at an ancient time, still doesn't have the same configuration flexibility as Dovecot (thanks ChatGPT..). A whole 'nother config file and K8s/init/whatever service entry becomes necessary for another TLS listener, boo hoo I guess.
edit 3:
embedded sha512 hash of comment in file name so no one can say I mutated the file after the edit window is closed.
Fair. Can you name any others in the "$5-10/month" range? You said "Yes" but then didn't elaborate. Sure if you've spending tens of thousands of dollars per month and selling to large corporates where they have a Helpdesk and golden image deploys to every device this is eminently practical.
When you're selling to hundreds of thousands of end-consumers, less so.
Again, I'd be really keen to see what other SaaS consumer products use certificate pinning. Or, let's expand it to banks and government departments in most countries.
Google Mail's $5/seat offering is the first one that comes to mind.
ImperialViolet is Adam Langley’s personal technical blog. Langley worked at Google on HTTPS infrastructure and Chrome’s SSL stack.A Tauri app, which is essentially a Chromium browser instance with no address bar and widgets to access browser settings, a Fastmail desktop "app" made with Tauri can potentially even the playing field between Google the Goliath and Fastmail the David on the TLS certificate pinning front. Tauri is like Electron but sucks a lot less.
_> if you've spending tens of thousands of dollars per month
Such as, 8,000 users at $40k/month for Google Mail.
Yubico has great volume discounts for a part of the CapEx side of a sane deployment of this.
The basic WebAuthn/FIDO2-only Yubikeys with a Fastmail logo on them would be, as the kids said a generation ago, "dope".
_
> where they have a Helpdesk
Quality attention to cicd and artifact release may avoid and potentially reduce conventional helpdesk activity.
For individual users of SaaS, provided the .dmg or .msi of the downstream Betterbird/Thunderbird (or other MUA) has sound cicd and decent release attention, no more additional support tickets than reasonable should occur beyond an initial phase.
A downstream MUA distro can eliminate manual configuration and superfluous details, such as the shit experience with Thunderbird on macOS (Thunderbird's fault 100%) with Oath2 I saw in the last few months. Such a distro could be tuned with a slew of relatively small adjustments reducing existing support ticket traffic.
Startups with headcount of 20 to 30, a good chunk of that being developers, where I have historically preferred to dwell, helpdesk is not there nor wanted for. Higher quality customers are here.
_
> and golden image deploys
Chromebooks, which not including K-12 did outnumber macOS in non-personal environments around a half-decade ago during that Event 201 thing. Super low IT overhead with those.
I have been distant from MIS type of IT for a while but have heard echoes or binocular'd in a bit and believe the golden image era has quietly passed us.
Conventional image pattern shouldn't be necessary anywhere now.
Somewhere in 2019, Apple warped native tooling in tandem with device firmware behavior to squeeze out the conventional image pattern ; killed it off.
Apple Business now includes built-in mobile device management which can enroll and set up Apple devices then apply standard settings and apps through "Blueprints" ; the .dmg would be trivial to push out. The successor to Jamf.
With Microsoft Intune, propagation of .msi packages to enrolled devices is a day-to-day task.
Ubuntu, RedHat, SuSE, Qubes, and all related distros, when under IT teams that can code on a rudimentary level, are managed with Ansible or Salt, without the "enterprise tax" part.
What all of these have in common is centralized org-wide device management where the ability to push out a .msi or .dmg or .deb/.rpm/.AppImage is there.
In similar spirit to certificate pinning, the advanced customers have dedicated private cicd consume source code from the OS vendor.
The more advanced are on
which in tandem with cryptography-grade hashes, has over half way solved the "Trusting Trust" problem that Ken Thompson raised._
> what other SaaS consumer products use certificate pinning.
Slack has the low-hanging-fruit opportunity to with their Electron app, but has reportedly dropped the ball. This is great for tech workers who like to divert all Slack contents to a separate local data sink for archiving and discovery and non-shitty data access.
This repo from about seven years ago looks abandoned and inactive, but
was not necessary for anyone who wanted to do it._
> let's expand it to banks and government departments in most countries.
With the episodic exposure I had with computer vision -> flow chart startups in the SF Bay Area many years ago, relatively ongoing time sinks with some archetypal MBA twat types, and some perceived legendary tier banks running on one of the two legit clouds (neither of which is that Azure garbage), who then fell on customer-facing downtime by not deploying with rudimentary cloud patterns that startups don't fail to do (as we recently found out), I am left feeling not confident that banks can do IT with self-reliance these days.
They can still push out .msi and group policy objects though, for sure.
From anecdotes I hear of and distant observations of state governments, departments of the big federal government sans some of the cooler TLA, and govs in Europe, I am not optimistic about those.
About a decade and a half ago we used to look at these two types of institutions and go "ah, the big guys, in their big buildings, they broker a thing I need, with their marble floors and reassuring smiles, these egregore have got it all figured out".
As a staff level DevOps / DevSecOps / whatever who has been along for the ride with a share of Silicon Valley culture-OS startups with enterprise customers, closely followed practices and white papers of hyperscalers and elite security firms, thus can see through any IT product/pattern transparently for its base principles...
-- having witnessed various sitcoms, heard of or read over 9,000 of first-hand accounts of such sitcoms, on top of the broadly spread cultural decay we are experiencing in the West upcoming on this Fourth Turning, with the rot of these institutions, and the major cultural shifts on computer illiteracy/obliviousness being normalized among "professionals" observed over the last couple of decades, I think more often than not some scrutiny of IT patterns at these institutions uncovers that they are severely retarded.
I suspect on the mid to lower end of the gov side it's just checkboxes, misdirection, and casual corruption almost all of the way down. Anyone who actually gives a shit about IT security and tries to fix things gets railroaded out.
The subcontractors who pick up the slack and handle real shit, like SpaceX is something NASA is dependent on (macro example), the upper echelon of the private sector, supranational organizations run by elite characters, are where not the progressive-minded IT teams are found but where IT is treated with some seriousness by leadership. But no transparency into IT patterns will be offered by these outside of talks at cool parties like DEF CON and AWS Re:Invent (shitty DJs but still a great party).
I don’t know if Google still pin their certificates or if Chrome still pins Google’s certificates in some way, but the wind has definitely shifted against that approach. In 2015, Chromium and Firefox introduced the general-purpose HTTP Public Key Pinning <https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning>; but within a couple of years they agreed it was a bad idea, and it was removed entirely by 2020. Certificate Transparency and CAA records are the closest thing to a replacement. Many sites that did fancy certificate stuff 10–15 years ago (e.g. EV certificates) have unceremoniously dropped it since.
_
If HKP specification had worked out (RIP, lol), that may have over the last decade-ish spared some config lines for CA config behind commands like
to load browsers with whitelisted CA in Firejail, Capsicum (BSD Jails), or kvm/bhyve/xen/SwiftBoot/whatever.It's odd how that, for the unwashed masses' use of browsers with the default CA config, high-value clearnet websites' PKI robustness is, from all I've read over the years, more often than not functionally outperformed by prominent LSD/tryptamine vendors of various DarkNet Markets.
_A more meaningful answer on the "other organizations" question above, for a project one might get one or more CA and relevant details in a PGP/MIME or S/MIME or by-hand gpg/sq message with the implicit "you already know what to do".
Some commercially operated services, geared more towards high-value customers, have casually offered a first-party CA cert. Perhaps due to being operated by and for relatively higher value demographic (thus, I'll not advertise them here), even at general or low pricing (high trust societies just hit different).
Some "far left" or whatever anarchist-ish communities often not chasing profit casually do first-party CA too, which is no less based than any other subculture doing it.
Any time someone may have ever manually sent you a VPN config file to load, this is in essence sort of what they were doing but without the existing known-pubkey part.
Across the globe, competent IT teams transparently propagate dedicated browser instance profiles with explicitly whitelisted CA that show up in users' toolbar/dock as differently styled icons with appropriate splash images/dialogue when clicked.
The ability to do this correctly and without mistakes, is, as mentioned above, a litmus test for (when asked to do so) if an IT team is legit or not.
This functional pattern of the people who get the real shit done has been in place for more than, as far as I personally for over two decades have happened to know. And, functionally in its substance, no matter what form on the surface, it's not going away, not ever.
At least not until a cosmic event leading to the dissolution of this current run of civilization.
As I imagine, you already probably know. I see your pubkeys on Keybase. Imported.
_
Super lame anecdote: at one hilarious and sad juncture I witnessed a self-titled ""CTO"" at a sham company, self-proclaimed "security guru", expose himself as a total fucking fraud when he announced boldly to a room that all OpenStack APIs functionally (not a directive, but functionally) are unable to use in-house CA, in what was surfaced as a lame attempt to shirk applying a skill he'd hyped everyone up he like totally had fluency in. Then a good chunk his own team on the side derided him as a "fucking LARP" immediately after that before anyone else could have commented.
Forward Email gives you stronger protection than Fastmail for mailboxes sitting idle, plus real DANE and optional PGP.
(2025)