On Thu, Nov 06, 2014 at 03:08:47PM +0100, Lars Heide wrote:
> does anybody know how postfix handles a detected MITM attack based on
> POODLE?
POODLE, SSL 3.0 and more generally the "TLS_FALLBACK_SCSV" have
nothing to do with how Postfix handles TLS errors. There is not,
need not, and will not be specific code for TLS_FALLBACK_SCSV
in Postfix.
> With the advent of the POODLE vulnerability, the implementation of
> TLS_FALLBACK_SCSV in OpenSSL happened in order to mitigate MITM.
Opportunistic TLS in MTAs is vulnerable to active attack, for
example from Cisco PIX/ESA firewalls that replace "STARTTLS" with
"XXXXXXXX". Or from fake DNS replies that direct delivery to an
alternate MX host.
The Postfix SMTP client does not implement ANY fallback logic from
a higher TLS *protocol version* to a lower *protocol version*, nor
in fact makes two TLS handshake attempts with the same server for
any reason. When cleartext fallback is applicable, any second
delivery atempt is cleartext, not TLS. Therefore, since the Postfix
SMTP client never sends SCSV, it must never receive the alert in
question from non-buggy SMTP server implementations.
The Postfix SMTP server is at the mercy of its OpenSSL library.
If some non-Postfix SMTP client sends SCSV (possibly in error),
the library sends the fatal alert. Any logic to handle that
case is up to the non-Postfix SMTP client.
> In case that an inappropriate fallback is detected, the SSL library
> throws an error, like:
>
> TLS library problem: error:140A1175:SSL
> routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback
>
> I saw this happen in one of our logs with the connection from another
> MTA. What was worrying at that point is that the MTA fell back to
> unencrypted traffic, even though the error was (at least in theory) a
> clear indication of MITM.
Please post more detailed logging for this. Was this logged by
your postfix/smtpd SMTP server or by the postfix/smtp SMTP client?
Any idea what software the other end was using? ...
--
Viktor.
P.S. Yes, SSL 3.0 has a padding oracle attack. Yes, it could, in
theory, apply to applications other than browsers. Yes, folks
don't like to catergorically rule out potential problems. However,
there is no published way in which padding oracle attacks actually
apply to SMTP. Such attacks on SMTP seem rather unlikely. SMTP
3rd parties have no known influence over the content of an SMTP
transaction that also carry fixed sensitive content unknown and
wanted by the attacker after some content injected by the attacker.
