In message <20160410024851.gu26...@mournblade.imrryr.org> Viktor Dukhovni writes: > 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.
Can you say what is wrong. Let me paraphrase and expand a bit. mutual_auth implies you are using SASL. With Opportunistic TLS without SASL in postfix you have no authentication. With TLS but with SASL plaintext you provide a MITM a means to read your password. The simplest MITM is STARTTLS stripping. If the client end doesn't insist on TLS, then STARTTLS stripping is possible. The client TCP connection can be terminated at the MITM as plain text and a TLS to the MSA can be started. In both connections the IP address can be spoofed if the MITM is in the routing middle (or acting as a L2 bridge). If both ends insist on TLS but are willing to settle for SSL, then a MITM is still possible with a TLS downgrade (but harder to do). If both ends insist on TLS and not SSL but there is no client cert and no way to tell what the client should be signing for or no CAfile to check against then a MITM is possible if a rouge CA is used (which is likely going to be a nation surveilance situation). Postfix does not support validating the client cert. Which of these are wrong? OK to pick more than one. :-) Seriously, I did say I'm not an expert. > > 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. mutual_auth implies you are using SASL and with or without TLS it helps with MITM, but safe with TLS. mutual_auth such as SCRAM (or GSSAPI) are reasonably good and MITM resistant. > > 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. This statement was independent on MUA->MSA or MSA->MX which is a form of MTA->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. Sorry. We are saying the same thing here but I was keeping with MUA->MSA or MSA->MX since explaining to someone that possibly didn't know any of these terms. And MSA->MX is a form of MTA->MTA. To be pedantic, the focus of the paper is on MTA->MTA where the two MTA are in different domains. > -- > Viktor. I defer to you as an expert on this but I would like to know what is wrong in the "this is wrong" comment. Curtis
