Viktor Dukhovni <postfix-us...@dukhovni.org> writes:

> On Wed, Oct 02, 2013 at 03:39:06PM -0400, Micah Anderson wrote:
>
>> From my understanding of the way postfix currently operates, there is no
>> smtpd/stmp TLS setting that can be set that would provide a
>> configuration that would result in a more 'hardened' configuration,
>> without causing interoperability problems. If I am wrong, I'm very
>> interested in knowing where.
>
> You get no benefit from hardening the Postfix SMTP server on port
> 25 (tighter mandatory parameters on the submission port may work
> for some).  This has little to do with Postfix and everything to
> do with the fact that SMTP servers accept messages from total
> strangers (many of the clients don't support TLS at all).

Regarding tighter mandatory parameters on the submission port - any idea
what these could reasonably be? For example, if I disable SSLv2/v3 am I
going to cut off Outlook users? 

It would be nice if we had a good survey of clients that are still out
there.

I looked at some of my logs and found the following from a small sample
over the last day:

# zgrep 'TLS connection' /var/log/postfix.log* |grep 'TLS connection'|awk 
'{print $12, $15}' |sort | uniq -c |sort -nr
 301849 TLSv1 DHE-RSA-AES256-SHA
 109117 TLSv1 AES128-SHA
  30032 TLSv1 RC4-SHA
  14446 SSLv3 DHE-RSA-AES256-SHA
   2532 TLSv1 AES256-SHA
   1552 TLSv1 DHE-RSA-AES128-SHA
    424 SSLv3 AES256-SHA
    178 SSLv3 DHE-RSA-AES128-SHA
     69 TLSv1 DES-CBC3-SHA
     26 SSLv3 AES128-SHA
     18 SSLv3 DES-CBC3-SHA
     17 SSLv3 RC4-SHA

but...the way this works: the server gets offered a list of ciphersuites
from the client, and then the server picks a ciphersuite, so without
knowing how the server picks its ciphersuites from the client, these
results are not clear. The client is expected to offer ciphersuites in
preferred order (https://tools.ietf.org/html/rfc5246#page-41), so if the
server just chooses the client's earliest-listed ciphersuite that the
server supports, then you have this situation.

So that leaves us with the unanswered question of what does that
translate into for restricting those paramters on the server?

On a slightly other subject, I know that the smtps port 465 has already
been reallocated as a port number, because it is considered deprecated,
but I dont understand why. Providing a TLS-wrapped, from the beginning,
port is better than offering STARTTLS. The STARTTLS offering is easily
stripped by a MiTM, and I know that clients are supposed to handle that,
but this seems incredibly brittle and prone to errors or manipulation,
or minor configuration mistakes. XMPP threw out the TLS-wrapped
connection as well, but they recently have brought it back because of
this very reason.

Reply via email to