5 ms·
A thousand times yes. PGP and SMIME is perfectly fine for high security scenarios (whistleblowing and such), in other words for the 0.000001% use case. For th
by capt_hotpants 11y ago
A thousand times yes.
PGP and SMIME is perfectly fine for high security scenarios (whistleblowing and such), in other words for the 0.000001% use case.
For the 99.9% use case, all that regular folks need is for the sending MX to verify that the recipient MX owns the domain before delivery.
PGP and SMIME with their key-signing parties, government-owned PKI et cetera, is either wild overkill or so utterly complex that it defeats the purpose for the 99.9% use case.
---
That said, you are going to break some of my software with this.
Specifically a SMTP reverse proxy, that looks at the domain part of RCPT TO, and transparently forwards the SMTP connection to the correct customer's MX for processing.
It could easily be unbroken again - BUT that would require that Postfix get their software together and add SNI support to their TLS stack (like all? other MX software does).
---
Implementation proposal:
1) Use RCPT domain-part for the SNI hostname.
2) Always try SMTPS port before SMTP port. Always try STARTTLS before plaintext.
3) Actually verify the certificate, duh.
4) Support a new EHLO header that mimics Strict-Transport-Security exactly.
- Flimm 11y agoActually, even PGP is not fine for high security scenarios. For example, it doesn't encrypt headers, including the subject line, which I would say is just as important as an email's body.
- capt_hotpants 11y agoGood point. S/MIME might also have some dependencies on PKI that in some scenarios could make it unsuitable for high security scenarios?
- hannob 11y agoSome people are trying to fix that: https://modernpgp.org/memoryhole/ https://modernpgp.org/memoryhole/
- pjc50 11y agoWhat is the 99% use case? Most people's email has one endpoint at either a big cloud provider or an employer, both of which are examining it at rest.
- capt_hotpants 11y agoGood question! For me personally, I'm not too worried about the NSA. But I do think it is quite silly that Gmail and Outlook has a little lock icon to indicate that security is ON, while the first thing that happens when you click Send is that your email is whizzed over half the internet in plaintext. For organizations and corporations, I imagine they would very much like to be able to verify the identity of the receiving organization before delivering possibly sensitive email. (The sender identity is already authenticated via DKIM.)
- thrownaway2424 11y agoFor organizations that subscribe to these cloud services (like Google Apps, or hosted Exchange) there are settings to enforce the use of TLS on both inbound and outbound. For example https://support.google.com/a/answer/2520500 https://support.google.com/a/answer/2520500
- capt_hotpants 11y agoIf you read the fine print in bullet #8, you'll discover that there is, per default, no validation of the presented certificate at all. Without proper certificate validation, the encryption step is cryptographically worthless. Anyone can MITM the traffic just by presenting a random certificate to the sender.
- capt_hotpants 11y ago5) Slap a nice name on the feature-set, so products can advertise it. (An important step often forgotten by engineers ;-))
- caf 11y agoYou are assuming that only one RCPT is being sent in the session. (What does happen with your reverse-proxy when someone opens up a session and sends two mails, to two different customers?)
- capt_hotpants 11y agoCurrently, this happens: if hostname != target { downstream.Write([]byte("452 Different domain, please reconnect and deliver separately.\r\n")) continue } else { As a side-effect, email to the secondary domain is slightly delayed. It is a full proxy, in the sense that it sees all of the traffic, so technically it could de-multiplex and spool to two different targets at the same time for the duration of the current email.. Hasn't been a noticeable problem so far. But it would be nice to add at a later point in time. If/when someone complains, probably.