On Sat, Apr 09, 2016 at 09:31:48PM -0400, Curtis Villamizar wrote:
> > 1) It looks to me that starttls really only protects the path to the
> > first server. Classic case being sending email over the non-secure
> > coffee shop wifi.
>
> If you are using TLS to port 587 then that is protecting the first
> hop. If both your MUA (email app) and the MSA (mail submission agent)
> you are talking to insist on using TLS and have some means to mutually
> authenticate (such as either a client cert or mutual_auth in postfix
> on the MSA end), then this is subject to MITM. Postfix does not
> support validating the client cert (AFAIK - not a guru I said).
This is wrong.
> There is really no name to validate the client cert against, other
> than the hostname provided in the EHLO.
Submission clients are usually authenticated via SASL, and while
that does not provide "channel binding", it is good enough in
practice, if the client properly authenticates the server.
> The point of the article is that unless both ends insist on TLS then
> MITM is possible.
The topic of the articles is TLS between email relays, not MUA to
submission or IMAP client to IMAP srever.
MITM is possible when SMTP relays (sending MTAs) don't (and generally
can't even if they wanted to) authenticate the nexthop MTA.
> The focus of the paper was on the use of TLS between the MSA and the
> MX of the destination domain (an MTA - mail transfer agent). That is
> usually the next hop.
No, the topic was relay-to-relay SMTP, TLS is much more prevalent
with submission and IMAP and generally works adequately with WebPKI.
--
Viktor.
