On Wed, Jul 30, 2014 at 08:41:51AM +0200, BlueStar88 wrote:
> Regardless how difficult it would be to develop a reliable solution for
> that, I keep thinking here and throw another idea, inspired by Tor and
> it's multilayer crypto: Is there a way, once a connection is established
> to the server, to establish another one downwards within that
> connection?
This would add nothing. The server, having no way to prevent MiTM
of the client in the first place, does not not know who the client
is supposed to be, and therefore cannot "connect back" to the "true"
client. Nor does the message envelope reveal the "true" client
system, since email (architectural feature not SMTP bug) is a
multi-hop store and forward protocol.
> Like this we could add another layer of trust and MitM
> sensitivity covering the other direction using the same tools we already
> have (maybe using SPF to stick to a set of hosts to verify given client
> certificates against).
I'm afraid your desire for a solution is overwhelming your analytical
skills to assess the problem. Your best bet is to hope that the
folks with the requisite skills are not negligent in addressing
the issue to the extent possible.
> Is there any possible support for that in the TLS
> protocol or would it be able to do on the application level (assuming
> both sides using postfix)?
Contrary to popular belief, in no application protocols (not just
SMTP) do TLS client certificates solve the MiTM problem when the
client fails to authenticate the server. Rather, what client
certificates do is channel-bind the presented client credentials
(which may or may not be those of the "true" or "original" client),
so that the server can be sure that there is no MiTM between it
the holder of the presented private key and associated certificate.
That private key might belong to the attacker. Such channel-binding
is useful, but does not address the nation-state intercept problem
if the client fails to verify the server certificate.
In SMTP, the added complication is that client certificates are
not required, and thus the easiest attack is to simply suppress
them, while also modifying the signalling (HELO name, ...) that
might lead a server to demand a private key from some clients
that are expected to have one.
The problem has no solution, and cannot have a solution. The
responsibility for ensuring channel security falls on the client,
it knows who the server is supposed to be. Only when the server
is designed to admit a single authorized client and no others is
it possible for the server to block MiTM when the client does not
do so, and even then only when the MiTM is unwilling to simply
redirect the message away from its true destination (deliver
elsewhere or discard). With SMTP the MiTM might simply return a
"4XX" code after "." and then allow the retransmission to be
delivered normally.
Bottom line, we're doing what's possible to protect SMTP and no
more.
--
Viktor.
