Viktor Dukhovni wrote:
>
>> Solarus <solarus@xxxxxxxxxxxxx> wrote:
>>
>> SSLv2 is no longer used or seen by MTA, so we can reasonably drop
>> it's support. But cleartext is still more used than SSLv3, so why
>> would you drop SSLv3 support before forbidding cleartext inbound
>> and outbound your MTA ?
>
> As I mentioned upthread, SSLv3 is also no longer used. It makes
> to not carry around useless baggage that increases the attack
> surface and looks bad in audits. No additional traffic is
> protected by enabling SSLv3, the SSLv3-only MTAs are gone from
> the public Internet (O.K. a negligible number may remain, but
> this is no longer worth the penalty of keeping SSLv3 around).
This looks like an exxageration of what is not even a problem.
The issue was not about newly adding SSLv3 support to IETF mail
servers ("new baggage"), but about leaving something enabled that
_is_already_there_, has been there for quite a while, and does not
hurt the slightest bit.
You should know pretty well that there is provably ZERO additional
attack surface. The SSLv3 handshake protocol protection ensures
that two TLS peers will always use TLS when both ends support it.
In the face of active attackers (man-in-the-middle), the attack
will succeed even with TLSv1.2 on both links client<->MitM<->server
due to the complete lack of authentication in SMTP with TLS.
"Looking bad in audits" is due to sending the wrong message and
obviously bogus audit checklists. It would be preferable to get
the bogus audit checklists fixed, rather than creating an illusion
of security that provably doesn't exist here.
Even the (last) PCI 3.1 compliance standard got it correct in that
pretty much all of the alleged "vulnerabilities" known for SSLv3
and TLSv1.0 are non-practical for most programmatic SSLv3-protected
communication. And when performing mutual cert-based authentication
the alleged weaknesses become pretty much irrelevant.
-Martin