Björn Jacke <bjacke@???> (Do 06 Aug 2015 17:20:27 CEST):
> On 06.08.2015 16:31, Heiko Schlittermann wrote:
> > begin authenticators
> >
> > …
> > server_advertise_condition = ${if def:tls_cipher}
> >
> > But as long as clients do not insist on TLS/SSL and do not verify the
> > servers certificate, a MITM can do anything.
> >
>
> let's assume your server where you do smtp auth is called
> smtp.exmple.com. You have your MUA set up for that host, port 587 and
> the setting in your MUA is "TLS, if possible". I'm the bad guy, when you
Why should I set "TLS if possible"? For my clients TLS is mandatory.
Because the servers I'm talking about don't accept authentication on
non-encrypted connections.
> come to my network I will send you DNS answers, that smtp.exmple.com is
> 10.6.6.6. That is of course my machine. There I have a SMTP server,
> which offers SMTP AUTH *without* TLS on port 587. Then I just log
> everything that's coming in to port 587. It is trivial to steal other
> people's smtp auth data this way.
I won't accept your DNS answers because I do DNSSec validation. If the
client's doesn't do it, then it's the clients problem.
> And no also DNSSec, would not work, I could also give you the right IP
> and then send a spoofed ARP reply for the right IP address.
The DNS answer you can't attack, because of DNSSec (see above). The IP
will be outside of your network. ARP spoofing won't help. But of course
you can hijack the outgoing connection with destination NAT.
Now(!) the client may be lost, if the client doesn't verify the servers
certificate. But I believe, most clients verify the servers certificate,
don't they? You would need to offer a X509 certificate my client
accepts.
But that's the same on Port 465.
> This is also
> trivial to do. Because so many MUAs are not behaving sane (opportunistic
> starttls is as safe as no TLS), it is not a good idea to use port 587
> and starttls as long as you can't make sure that no such clients are
> being used.
It should be about the same effort in the client's configuration for 'TLS
required' as for TLS on port 465.
As long as the client considers encryption as an opportunistic feature,
we're out of luck anyway.
> And when you say "465 and plain SSL are still deprecated" you are
> talking about what some RFC authors wrote. RFCs are no laws and when you
> see that an RFC is proposing something bad, you should not follow it
> IMHO ;-)
Agreed. But I do not see the advantage of using a non-standard port for
message submission.
> And by the way, the same problem is therw with imap and starttls,
> dovecot mentions the problem here: http://wiki2.dovecot.org/SSL
It's the same game, except that the ports are are assigned by IANA.
> In the whole network of a German provider a related MITM attack was done
> some years ago (accidently of course ;), see:
> http://www.heise.de/security/meldung/Eingriff-in-E-Mail-Verschluesselung-durch-Mobilfunknetz-von-O2-206233.html
Yes, if the servers would have disabled SMTP-AUTH on non-encrypted
connections, no client would have sent the user credentials, because a
well behaving client expect the "AUTH" token in the response to the
EHLO command. But as long as the provider offers SMTP AUTH via
clear text connections, port 465 doesn't offer additional security.
> The very least we should do is mention the problem and the security risk
> and not just write that SSMTP is "obsolete" in the exim documentation
> IMHO. This is what that patch does.
IMHO Exim tries to follow the standards. That's what standards are for,
aren't they?
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
