Yes, yes, and yes.
2 Likes
You can mitm a DKIM’d SMTP conversation from a DNSSEC’d domain but you can’t subvert a cert chain? That’s a kind of arbitrarily fine line, there, isn’t it? It seems to me that if I own your ISP I can easily do both, but if I don’t own your ISP it’s extremely difficult to do either.
My cow-orkers mitm CA-certificate-secured traffice all the time, without much effort, using commercial products. Although granted, they do control the local windows GPOs. You’d have to work a little harder without that.
1 Like
Well, you bring up very valid points. If SPF, skim, dnssec, and dmarc are set up correctly, it is damn hard to subvert. But that’s kinda the whole point, basically at that point DNS is your chain, though not in a literal sense.
I love these kinds of conversations, because they aren’t simple. But if I can burn every self signed certificate in a fire I would.
3 Likes
Opportunistic encryption (with, in the simplest case, a self-signed certificate) will protect you from passive attackers who happen to be able to listen to your traffic as it passes them by. That is all that it promises, nothing more. If you want protection from active attackers who are in a position to tamper with your traffic, then opportunistic encryption isn’t going to help you because as japhroaig suggests, the attacker would be able to insert their own certificate in place of the one from the MTA you’re talking to, and would be able to decrypt and re-encrypt your traffic. This is where the certificate chain comes in (or for that matter other approaches such as DANE, which lets server operators use the DNS to vouch for the authenticity of their certificates), because it helps ensure that the certificate you see is actually the one provided by the remote MTA’s operator rather than some random certificate interposed by a “man in the middle”.
There’s no doubt that protection from active attackers is better than protection from passive ones, but the sad fact is that in the general case of mail distribution to arbitrary MTAs on the Internet, protection from active attackers is not really available because insisting on verifiable certificates would preclude a mail server from delivering mail to the majority of MTAs out there that, for whatever reason, don’t actually have a verifiable certificate to begin with. (Which is not to say that you couldn’t enforce it today, e.g., between the MTAs in different offices of your multinational enterprise.) This is likely to remain the case until we get everyone in the world to put a verifiable certificate on their MTA, which in the day and age of Let’s Encrypt is less infeasible than it used to be but would still be a Herculean task.
1 Like
You understand that I understand I am tilting at windmills. But I won’t stop, because it is important.
Encryption, identification, and authentication. These are the three legs. Lose one, then just use http or a socket.
Oh, I agree that this particular windmill is worth tilting at – mostly because putting a Let’s Encrypt certificate on a mail server probably counts as “low-hanging fruit” as far as possible security enhancements are concerned.
The main inconvenience with Let’s Encrypt is that you need to renew your certificate every three months, and from the POV of a MTA developer this is difficult because you need to control either a web server or a DNS server in order to pass Let’s Encrypt’s domain ownership verification. That makes it hard to come up with an MTA that does it automatically out of the box, but I’m sure we’ll see improvements on that front in due course.
It bears repeating: lack of a secure transport method does not mean insecure servers.
This topic was automatically closed after 5 days. New replies are no longer allowed.
