selective disable of smtpd opportunistic TLS

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

selective disable of smtpd opportunistic TLS

Curtis Villamizar
I turned on opportunistic TLS last summer I think.  All was fine for a
long time.  btw - I'm currently running the FreeBSD
postfix-current-3.0.20151003,4 port but previously used 2.8.

Somewhat recently someone with a residential cable provider account
complained that he got mail from me but mail from him to me bounced
(soft, so repeated bounce messages).  I was still getting email from
everywhere else, gmail, verizon, corporations, universities, IETF,
lots of places, just no mail from that cable provider and only
recently.  This was with no significant change on my end on the
primary MX and none at all on the secondary MX.

A cable provider is using a useful new SMTP feature.  Can't complain
about that.  It would be nice if it didn't dump mail on the floor.

The logs revealed something about the nature of the problem.  A few of
these sort of messages were found.

Jan 13 17:08:22 mta3 postfix/smtpd[15958]:
   warning: TLS library problem:
   error:1408A0C1:SSL
   routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1411:
Jan 13 17:08:22 mta3 postfix/smtpd[15958]:
   lost connection after STARTTLS
   from resqmta-po-05v.sys.comcast.net[2001:558:fe16:19:96:114:154:164]

The workaround is change may to none:

    smtpd_tls_security_level = none

What I'd like to do is set smtpd_tls_security_level back to "may" and
then somehow set it to "none" if the EHLO domain is comcast.net (oops
the secret is out).

I see we have smtp_tls_policy_maps, but no smtpd_tls_policy_maps.

It seems the place in the code to hook that in would be near where the
smtpd_helo_restrictions get checked.

It would also be nice to have the smptd rough equivalent of
smtp_tls_note_starttls_offer to see when TLS was used and OK if
"smtpd_tls_loglevel = 0" is used, though "smtpd_tls_loglevel = 1" is
close but a bit more verbose than just knowing it was OK.

I think the problem is that All my keys are EC generated using openssl
1.0.2, which was a brand spanking new release in Jan 2015 (yes, last
year, not this year) and comcast recently enable opportunistic TLS but
is using a release that is a year older or more - 1.0.1 or prior.

OTOH- It could also be:

    smtpd_tls_mandatory_ciphers = high

Haven't tried cranking back on that.  Could it be that they compiled
out everything but the fairly weak "medium" ciphers?  Anyone know?

In any case I figured out a way to get more information.  It seems
rather than fall back and use unencrypted, the fallback is to the
secondary MX record.

So now I have "smtpd_tls_security_level = may" and debugging turned
way up for comcast.net on the primary MX and and no debugging but
"smtpd_tls_security_level = none" on the backup MX.  I should get
debugging and a failure on the primary and delivery of mail on the
secondary so no bounced mail.

btw- that wasn't a request to send me a test message.  I'll send to my
friend and ask for a reply if nothing arrives in the next few hours.

Any suggestions?  Any insights on this problem?

Curtis

ps - Somewhere in comcast someone is sitting back happy that they
deployed something new and nothing bad happenned (between them and the
other big guys anyway).  Oh well.
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Wietse Venema
Curtis Villamizar:
> What I'd like to do is set smtpd_tls_security_level back to "may" and
> then somehow set it to "none" if the EHLO domain is comcast.net (oops
> the secret is out).
>
> I see we have smtp_tls_policy_maps, but no smtpd_tls_policy_maps.

Use this to suppress the STARTTLS announcement selectively:

http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps

/etc/postfix/main.cf:
    smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/ehlo-map.cidr

/etc/postfix/ehlo-map.cidr:
    # The provider here.
    192.168.1.0/24 starttls

Or make your TLS server settings more tolerant.

(there's an analogous smtp_discard_ehlo_keyword_address_maps feature
for outbound delivery problems).

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Viktor Dukhovni
In reply to this post by Curtis Villamizar

> On Jan 13, 2016, at 8:52 PM, Curtis Villamizar <[hidden email]> wrote:
>
> The logs revealed something about the nature of the problem.  A few of
> these sort of messages were found.
>
> Jan 13 17:08:22 mta3 postfix/smtpd[15958]:
>   warning: TLS library problem:
>   error:1408A0C1:SSL
>   routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1411:
> Jan 13 17:08:22 mta3 postfix/smtpd[15958]:
>   lost connection after STARTTLS
>   from resqmta-po-05v.sys.comcast.net[2001:558:fe16:19:96:114:154:164]

Post the output of "postconf -n | grep tls".
Post the output of "openssl version -a"

Post a PCAP file of a single failed TLS handshake.  I know the person
at comcast in charge of their email transport security.   I can probably
get them to fix it once we nail down the problem, assuming it is not overly
aggressive settings on your end.

--
        Viktor.



Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Curtis Villamizar
In reply to this post by Wietse Venema
In message <[hidden email]>
Wietse Venema writes:
 

> Curtis Villamizar:
> > What I'd like to do is set smtpd_tls_security_level back to "may" and
> > then somehow set it to "none" if the EHLO domain is comcast.net (oops
> > the secret is out).
> >
> > I see we have smtp_tls_policy_maps, but no smtpd_tls_policy_maps.
>  
> Use this to suppress the STARTTLS announcement selectively:
>  
> http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps
>  
> /etc/postfix/main.cf:
>     smtpd_discard_ehlo_keyword_address_maps = cidr:/etc/postfix/ehlo-map.cidr
>  
> /etc/postfix/ehlo-map.cidr:
>     # The provider here.
>     192.168.1.0/24 starttls

Thanks.  I should have asked sooner and saved a lot of time.  Too bad
it is IPs and CIDRs only but it'll work.

> Or make your TLS server settings more tolerant.

If the issue is my cert files, I'd rather wait for comcast to upgrade
than regenerate select keys with weaker ciphers (just the two MTAs).

Looks like "high" was not a problems if I'm reading the logs right.
But I could tell for sure if I bump it down to medium.  Just bumped up
to smtpd_tls_loglevel = 3 so I might have better information soon.
This is a light duty email server so load is not an issue.

> (there's an analogous smtp_discard_ehlo_keyword_address_maps feature
> for outbound delivery problems).
>  
> Wietse

Nothing at all secret or confidential being exchanged with the few
comcast residential service users.  (Or anyone else for that matter).
So no big deal even of I set smtpd_tls_security_level to none.

I'll gather more info for now and try to get through comcast support.
I doubt there would be any new info relevant to this list.

Curtis
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Curtis Villamizar
In reply to this post by Viktor Dukhovni
In message <[hidden email]>
Viktor Dukhovni writes:

>
> > On Jan 13, 2016, at 8:52 PM, Curtis Villamizar <[hidden email]> wrote:
> >
> > The logs revealed something about the nature of the problem.  A few of
> > these sort of messages were found.
> >
> > Jan 13 17:08:22 mta3 postfix/smtpd[15958]:
> >   warning: TLS library problem:
> >   error:1408A0C1:SSL
> >   routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1411:
> > Jan 13 17:08:22 mta3 postfix/smtpd[15958]:
> >   lost connection after STARTTLS
> >   from resqmta-po-05v.sys.comcast.net[2001:558:fe16:19:96:114:154:164]
>  
> Post the output of "postconf -n | grep tls".
> Post the output of "openssl version -a"
>  
> Post a PCAP file of a single failed TLS handshake.  I know the person
> at comcast in charge of their email transport security.   I can probably
> get them to fix it once we nail down the problem, assuming it is not overly
> aggressive settings on your end.
>  
> --
> Viktor.


Hello Viktor,

The output you asked for is below for both MX servers.  Both fail in
the same way if I leave smtpd_tls_security_level = may which is why on
the secondary it was changed to smtpd_tls_security_level = none.  I
get debugging on the primary, mail delivered on the secondary.

btw - Now that I have debugging on I can see that IETF is using TLS
and I've been getting lots of IETF mailing list mail.  This indicates
that others are using TLS successfully.

  # egrep \
      'Trusted TLS connection from|TLS connection established from' \
      /var/log/maillog | awk '{print $6, $11, $12, $15;}' \
      | sort | uniq -c | sort -rn \
      | awk '{printf " %2d %s %s\n    %s  %s\n", $1, $2, $3, $4, $5;}'
  6 Anonymous mail.ietf.org[2001:1900:3001:11::2c]:
    TLSv1.2  ECDHE-ECDSA-AES256-GCM-SHA384
  4 Anonymous unknown[72.13.58.7]:
    TLSv1.2  ECDHE-ECDSA-AES256-GCM-SHA384
  3 Trusted msa3.somerville.occnc.com[2001:4830:c400:203::172]:
    TLSv1  ECDHE-ECDSA-AES256-SHA
  3 Trusted msa1-em1.orleans.occnc.com[2001:470:88e6:1::140]:
    TLSv1  ECDHE-ECDSA-AES256-SHA
  3 Anonymous mail.ietf.org[4.31.198.44]:
    TLSv1.2  ECDHE-ECDSA-AES256-GCM-SHA384
  2 Anonymous ml18tv7c8.sritis.lt[31.193.197.232]:
    TLSv1.2  ECDHE-ECDSA-AES256-GCM-SHA384
  1 Trusted mda37-em1.somerville.occnc.com[2001:4830:c400:203::1037]:
    TLSv1  ECDHE-ECDSA-AES256-SHA
  1 Trusted mda31-em1.somerville.occnc.com[2001:4830:c400:203::1031]:
    TLSv1  ECDHE-ECDSA-AES256-SHA
  1 Anonymous vm0157.cs03.seeweb.it[85.94.216.210]:
    TLSv1.2  ECDHE-ECDSA-AES256-GCM-SHA384
  1 Anonymous unknown[67.227.187.156]:
    TLSv1.2  ECDHE-ECDSA-AES256-GCM-SHA384
  1 Anonymous unknown[2a01:7c8:aab4:45e::1]:
    TLSv1.2  ECDHE-ECDSA-AES256-GCM-SHA384

The above output is reformated (by awk) for readability.  It seems
some spammers (rDNS = unknown) are running more recent software than
comcast.  But a lot more spammers are running old code and get tossed
out here.  Thats the prior 11 hours (not much mail here).

btw - I just added "!TLSv1.0" to get only TLSv1.2.  I wasn't sure I
could specify !TLSv1.0 so I just tried it.

Curtis


mta3 (primary MX)

/usr/local/sbin/postconf -c /etc/postfix -n | grep tls

smtp_tls_CAfile = /etc/postfix/CAcert.pem
smtp_tls_cert_file = /etc/postfix/cert.pem
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = aNULL MD5 DES
smtp_tls_key_file = /etc/postfix/key.pem
smtp_tls_mandatory_ciphers = high
smtp_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1.1
smtp_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1
smtp_tls_security_level = dane
smtpd_tls_CAfile = /etc/postfix/CAcert.pem
smtpd_tls_always_issue_session_ids = no
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_ccert_verifydepth = 5
smtpd_tls_cert_file = /etc/postfix/cert.pem
smtpd_tls_ciphers = high
smtpd_tls_eecdh_grade = strong
smtpd_tls_exclude_ciphers = aNULL MD5 DES
smtpd_tls_key_file = /etc/postfix/key.pem
smtpd_tls_loglevel = 2
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1.1
smtpd_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 300
tls_dane_digest_agility = on
tls_dane_digests = sha512 sha256
tls_dane_trust_anchor_digest_enable = yes
tls_disable_workarounds = 0xFFFFFFFF
tls_preempt_cipherlist = yes
tls_ssl_options = NO_COMPRESSION
tls_wildcard_matches_multiple_labels = yes

/usr/local/bin/openssl version -a

OpenSSL 1.0.2e 3 Dec 2015
built on: reproducible build, date unspecified
platform: BSD-x86_64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int)
blowfish(idx)
compiler: cc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB_SHARED
-DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -O2 -pipe
-fstack-protector -fno-strict-aliasing -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
OPENSSLDIR: "/usr/local/openssl"

mta1 (secondary MX)

/usr/local/sbin/postconf -c /etc/postfix -n | grep tls

smtp_tls_CAfile = /etc/postfix/CAcert.pem
smtp_tls_cert_file = /etc/postfix/cert.pem
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = aNULL MD5 DES
smtp_tls_key_file = /etc/postfix/key.pem
smtp_tls_mandatory_ciphers = high
smtp_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1.1
smtp_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1
smtp_tls_security_level = dane
smtpd_tls_CAfile = /etc/postfix/CAcert.pem
smtpd_tls_always_issue_session_ids = no
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_ccert_verifydepth = 1
smtpd_tls_cert_file = /etc/postfix/cert.pem
smtpd_tls_ciphers = high
smtpd_tls_eecdh_grade = strong
smtpd_tls_exclude_ciphers = aNULL MD5 DES
smtpd_tls_key_file = /etc/postfix/key.pem
smtpd_tls_loglevel = 0
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1.1
smtpd_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1
smtpd_tls_received_header = yes
smtpd_tls_req_ccert = no
smtpd_tls_security_level = none
smtpd_tls_session_cache_timeout = 300
tls_dane_digest_agility = on
tls_dane_digests = sha512 sha256
tls_dane_trust_anchor_digest_enable = yes
tls_disable_workarounds = 0xFFFFFFFF
tls_ssl_options = NO_COMPRESSION
tls_wildcard_matches_multiple_labels = yes

/usr/local/bin/openssl version -a

OpenSSL 1.0.2d 9 Jul 2015
built on: reproducible build, date unspecified
platform: BSD-x86_64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int)
blowfish(idx)
compiler: cc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB_SHARED
-DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -O2 -pipe
-fstack-protector -fno-strict-aliasing -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
OPENSSLDIR: "/usr/local/openssl"
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Viktor Dukhovni
On Thu, Jan 14, 2016 at 12:06:43PM -0500, Curtis Villamizar wrote:

> /usr/local/sbin/postconf -c /etc/postfix -n | grep tls
>
> smtp_tls_cert_file = /etc/postfix/cert.pem
> smtp_tls_key_file = /etc/postfix/key.pem

    Usually best to not configure client certificates.

> smtp_tls_ciphers = high

    Usually best to leave this at "medium".  This is opportunistic
    TLS, and if high fails, you'll send cleartext, which is NOT
    stronger than medium.

> smtp_tls_exclude_ciphers = aNULL MD5 DES

    Mostly harmless, but not ideal.  Instead try:

        smtp_tls_exclude_ciphers =
            MD5, SRP, PSK, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5

> smtp_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1.1

    This is a terrible idea, it results in unconditional use of
    TLS 1.0 (the hole in that list).  If you really want to force
    TLSv1.2, then you must also disable TLSv1

> smtp_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1

    This is worse, your opportunistic TLS is constrained to
    TLSv1.

> smtpd_tls_ask_ccert = yes

    To you do anything with client certs?  If not, don't request
    them.

> smtpd_tls_cert_file = /etc/postfix/cert.pem
> smtpd_tls_key_file = /etc/postfix/key.pem

    What kind of key is that?  RSA or ECDSA?  Can you
    post the output of:

    openssl x509 -in /etc/postfix/cert.pem -noout -text | egrep -v ':.*:.*:'

> smtpd_tls_ciphers = high

    This is a bad idea, leave it at medium.

> smtpd_tls_exclude_ciphers = aNULL MD5 DES

    This is not needed.

> smtpd_tls_loglevel = 2

    Level 1 is just right, 2 is too much.

> smtpd_tls_mandatory_ciphers = high
> smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1.1

    Less harmful on servers, but what do you have against TLSv1.1?
    It is not worse than TLSv1, in fact somewhat better.  Choose
    one of:

    smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
    smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1

> smtpd_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1

    For opportunistic TLS leave TLSv1, TLSv1.1 and TLSv1.2 enabled.

        smtpd_tls_protocols = !SSLv2 !SSLv3

    you're changing too many carefully chosen default settings,
    and doing more harm than good.

> smtpd_tls_session_cache_timeout = 300

   Longer is better, especially with Postfix 2.11+ and session
   tickets.  Let the default stand.

> tls_dane_digest_agility = on
> tls_dane_digests = sha512 sha256
> tls_dane_trust_anchor_digest_enable = yes
> tls_wildcard_matches_multiple_labels = yes

    These are defaults, don't force them on explicitly.

> tls_disable_workarounds = 0xFFFFFFFF

    Are you sure that's a good idea?  This is opportunistic TLS.

> tls_preempt_cipherlist = yes
> tls_ssl_options = NO_COMPRESSION

    These are fine.



> /usr/local/bin/openssl version -a
>
> OpenSSL 1.0.2e 3 Dec 2015

OK.

> mta1 (secondary MX)
>
> OpenSSL 1.0.2d 9 Jul 2015

Upgrade this one perhaps.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Curtis Villamizar
In message <[hidden email]>
Viktor Dukhovni writes:
 

> On Thu, Jan 14, 2016 at 12:06:43PM -0500, Curtis Villamizar wrote:
>  
> > /usr/local/sbin/postconf -c /etc/postfix -n | grep tls
> >
> > smtp_tls_cert_file = /etc/postfix/cert.pem
> > smtp_tls_key_file = /etc/postfix/key.pem
>  
>     Usually best to not configure client certificates.
>  
> > smtp_tls_ciphers = high
>  
>     Usually best to leave this at "medium".  This is opportunistic
>     TLS, and if high fails, you'll send cleartext, which is NOT
>     stronger than medium.

That's actually fine if it actuall fell back.  Comcast didn't fall
back, it tried secondary MX, then TEMPFAIL.  Its only intended for
internal servers that are supposed to bring up TLS with a trusted key
and then also SASL authenticate.  Otherwise I might just leave it at
none.

> > smtp_tls_exclude_ciphers = aNULL MD5 DES
>  
>     Mostly harmless, but not ideal.  Instead try:
>  
> smtp_tls_exclude_ciphers =
>    MD5, SRP, PSK, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5

OK.  Thanks.  Will do.

> > smtp_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1.1
>  
>     This is a terrible idea, it results in unconditional use of
>     TLS 1.0 (the hole in that list).  If you really want to force
>     TLSv1.2, then you must also disable TLSv1
>  
> > smtp_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1
>  
>     This is worse, your opportunistic TLS is constrained to
>     TLSv1.

The lines are the same.  What I'd like is TLSv1.2 only.  Documentation
recommended the !format rather than the "legacy" format (in case there
is later a 1.3 defined, for example), there is no TLSv1.0 and TLSv1
refers to TLSv1.x.  So no good way to exclude TLSv1.0 afaik (afaik is
now past tense, see below).

> > smtpd_tls_ask_ccert = yes
>  
>     To you do anything with client certs?  If not, don't request
>     them.

Since the primary reason for having this was for my own hosts,
particularly the MSA, the intent was to use them if I could.

Unfortunately I can't find an option that requires trusted TLS before
AUTH, just any TLS (no smtpd_tls_auth_only = trusted, just yes/no).

The primary reason for having this is for my own servers to use SASL
authenticate after strong TLS and then:

smtpd_tls_auth_only = yes  # would prefer trusted
smtpd_sasl_security_options = mutual_auth
smtpd_relay_restrictions = permit_sasl_authenticated reject_unauth_destination

If I used weak auth it could potentially be leveraged for relay
(although you would have to also get SASL authenticated).  A
man-in-the-middle could watch the SASL with weak encryption and SASL
doesn't offer even moderately strong encryption (DIGEST-MD5) though it
does at least do a weak mutual_auth underneath TLS.

The best I can get now is ask and log when a client cert is trusted.

> > smtpd_tls_cert_file = /etc/postfix/cert.pem
> > smtpd_tls_key_file = /etc/postfix/key.pem
>  
>     What kind of key is that?  RSA or ECDSA?  Can you
>     post the output of:
>  
>     openssl x509 -in /etc/postfix/cert.pem -noout -text | egrep -v ':.*:.*:'

Relevant parts:

    ASN1 OID: secp384r1
    Signature Algorithm: ecdsa-with-SHA256

Not supported in openssl 1.0.1, but that is > 1 year old version.

This is OK if the only thing I want authenticated is my own MSA and
MDA servers.

> > smtpd_tls_ciphers = high
>  
>     This is a bad idea, leave it at medium.
>  
> > smtpd_tls_exclude_ciphers = aNULL MD5 DES
>  
>     This is not needed.

same as smtp.

> > smtpd_tls_loglevel = 2
>  
>     Level 1 is just right, 2 is too much.

Maybe so.  Isn't hurting anything.

> > smtpd_tls_mandatory_ciphers = high
> > smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1.1
>  
>     Less harmful on servers, but what do you have against TLSv1.1?
>     It is not worse than TLSv1, in fact somewhat better.  Choose
>     one of:
>  
>     smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
>     smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1
>  
> > smtpd_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1
>  
>     For opportunistic TLS leave TLSv1, TLSv1.1 and TLSv1.2 enabled.
>  
> smtpd_tls_protocols = !SSLv2 !SSLv3
>  
>     you're changing too many carefully chosen default settings,
>     and doing more harm than good.

I thought (apparently incorrectly) that TLSv1 was TLSv1.x so I didn't
include it.  Documentation was not clear on that.

> > smtpd_tls_session_cache_timeout = 300
>  
>    Longer is better, especially with Postfix 2.11+ and session
>    tickets.  Let the default stand.

Hasn't been a problem.  What would it break?

> > tls_dane_digest_agility = on
> > tls_dane_digests = sha512 sha256
> > tls_dane_trust_anchor_digest_enable = yes
> > tls_wildcard_matches_multiple_labels = yes
>  
>     These are defaults, don't force them on explicitly.
>  
> > tls_disable_workarounds = 0xFFFFFFFF
>  
>     Are you sure that's a good idea?  This is opportunistic TLS.

This is TLS between my servers where I happen to get opportunistic TLS
as a result of having a STARTTLS.

> > tls_preempt_cipherlist = yes
> > tls_ssl_options = NO_COMPRESSION
>  
>     These are fine.
>  
>  
>  
> > /usr/local/bin/openssl version -a
> >
> > OpenSSL 1.0.2e 3 Dec 2015
>  
> OK.
>  
> > mta1 (secondary MX)
> >
> > OpenSSL 1.0.2d 9 Jul 2015
>  
> Upgrade this one perhaps.

Its about to get upgraded any day now (same status as a few months
ago).  It will actually get migrated to a different server.

> --
> Viktor.

As originally configured my MSA did unconditional relay for anything
authenticated but used the MTA to mail from internal host to my
domain.  It was that MSA to MTA that I wanted strong, and I want MSA
authentication to be even stronger.  Most non-MxA hosts smart host to
an MSA, mostly for root's periodic messages.  If I miss a host it
would use the MX record and relay to the MTA.

On the MSA I have manditory TLS and SASL:

smtpd_tls_security_level = encrypt
smtpd_relay_restrictions = permit_sasl_authenticated reject
smtpd_client_restrictions = permit_sasl_authenticated reject

Can't use smtpd_tls_req_ccert on MTA.

The MSA needs to be a little weak due to cell phones sending mail.  So
can't use smtpd_tls_req_ccert on MSA either (for now) and there is no
smtpd_tls_auth_only = trusted though it would be real nice to have.  I
haven't played with trying to install client certs on android (I
encourage the K9 MUA which supports client certs).  Client certs on
hosts is no problem, other than generating, installing, and keeping
track of them.

I may change this to relay from MSAs directly to MDAs (with MSAs
ignoring MX records for my domains).  Then I could weaken the MTA auth
and not allow any relay.  Right now any host that doesn't forward
through MSA fails due to no DKIM signature (which MSA does for them if
they can authenticate).

btw- Postfix documentation isn't perfect but its a whole lot better
than trying to figure out how to do anything with sendmail.  I think
I've only used postfix for about a year now and sendmail since 1980s,
so I appreciate anyone that can look over my config.

Thanks for all the good work you do in this area.

Curtis
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Viktor Dukhovni
On Thu, Jan 14, 2016 at 03:53:23PM -0500, Curtis Villamizar wrote:

> > > smtp_tls_ciphers = high
> >  
> >     Usually best to leave this at "medium".  This is opportunistic
> >     TLS, and if high fails, you'll send cleartext, which is NOT
> >     stronger than medium.
>
> That's actually fine if it actuall fell back.  Comcast didn't fall
> back, it tried secondary MX, then TEMPFAIL.  Its only intended for
> internal servers that are supposed to bring up TLS with a trusted key
> and then also SASL authenticate.  Otherwise I might just leave it at
> none.

This is an SMTP *client* setting for your outbound connections,
and has nothing to do with what happens when Comcast sends you
mail.  My point is that this is unwise, regardless of Comcast.

> > > smtp_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1
> >  
> >     This is worse, your opportunistic TLS is constrained to
> >     TLSv1.
>
> The lines are the same.  What I'd like is TLSv1.2 only.  Documentation
> recommended the !format rather than the "legacy" format (in case there
> is later a 1.3 defined, for example), there is no TLSv1.0 and TLSv1
> refers to TLSv1.x.  So no good way to exclude TLSv1.0 afaik (afaik is
> now past tense, see below).

To exclude TLSv1, use "!TLSv1".  Do check the docs for syntax,
that's what they're there for.

> > > smtpd_tls_ask_ccert = yes
> >  
> >     To you do anything with client certs?  If not, don't request
> >     them.
>
> Since the primary reason for having this was for my own hosts,
> particularly the MSA, the intent was to use them if I could.

Set that on port 587 only, master.cf.

> Unfortunately I can't find an option that requires trusted TLS before
> AUTH, just any TLS (no smtpd_tls_auth_only = trusted, just yes/no).

smtpd_tls_req_ccert=yes requires trusted TLS, that is the client's
certificate must be issued by a trusted CA.  For port 587 only,
and understand the consequences.

> > > smtpd_tls_cert_file = /etc/postfix/cert.pem
> > > smtpd_tls_key_file = /etc/postfix/key.pem
> >  
> >     What kind of key is that?  RSA or ECDSA?  Can you
> >     post the output of:
> >  
> >     openssl x509 -in /etc/postfix/cert.pem -noout -text | egrep -v ':.*:.*:'
>
> Relevant parts:
>
>     ASN1 OID: secp384r1
>     Signature Algorithm: ecdsa-with-SHA256

Well, that's probably why comcast is having trouble, they likely
don't support ECDSA.  You really should field an RSA certificate,
along with the (still bleeding-edge) ECDSA certificate.

> Not supported in openssl 1.0.1, but that is > 1 year old version.

Actually, even 1.0.0 supports ECDSA, but not on RedHat/CentOS
systems, for patent-fear reasons.

> This is OK if the only thing I want authenticated is my own MSA and
> MDA servers.

No, it means that Comcast can't perform a TLS handshake because
they don't support ECDSA.

> > > smtpd_tls_ciphers = high
> >  
> >     This is a bad idea, leave it at medium.
> >  
> > > smtpd_tls_exclude_ciphers = aNULL MD5 DES
> >  
> >     This is not needed.
>
> same as smtp.

The roles of the client and server are very differnt.  Just
because the settings are the same, does not make them right,
even if they are right for the other case.

    http://www.postfix.org/TLS_README.html#client_tls_limits

You're working too hard trying to make your system more secure,
and shooting yourself in the foot making it less secure as a result.
Apply the suggested settings, they're better, leave more things
at their defaults.

> > > smtpd_tls_loglevel = 2
> >  
> >     Level 1 is just right, 2 is too much.
>
> Maybe so.  Isn't hurting anything.

Actually it severely hampers performance under load, because syslog
gets overwhelmed with messages.

> I thought (apparently incorrectly) that TLSv1 was TLSv1.x so I didn't
> include it.  Documentation was not clear on that.

TLSv1 is just TLS 1.0.  That's what OpenSSL called it, (and then
later 1.1 came along.  At the time the only previous examples
were SSLv2 and SSLv3, so TLSv1 made sense.

> > > smtpd_tls_session_cache_timeout = 300
> >  
> >    Longer is better, especially with Postfix 2.11+ and session
> >    tickets.  Let the default stand.
>
> Hasn't been a problem.  What would it break?

SMTP clients connect less often than HTTP clients, longer session
time improve session reuse and cost you nothing (because the
session state is client-side).

> > > tls_disable_workarounds = 0xFFFFFFFF
> >  
> >     Are you sure that's a good idea?  This is opportunistic TLS.
>
> This is TLS between my servers where I happen to get opportunistic TLS
> as a result of having a STARTTLS.

Well it also affects inbound mail from Comcast and others, and
outbound mail to the world.

--
        Viktor.

> Can't use smtpd_tls_req_ccert on MTA.
>
> The MSA needs to be a little weak due to cell phones sending mail.  So
> can't use smtpd_tls_req_ccert on MSA either (for now) and there is no
> smtpd_tls_auth_only = trusted though it would be real nice to have.

How would that differ from "smtpd_tls_req_ccert".  What would
"trusted" mean?
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Curtis Villamizar
Hi Viktor,

I really appreciate all of the good information you have provided.  We
are going in circles in a few places because we have different goals.

See comments inline and at the end of this message.

In message <[hidden email]>
Viktor Dukhovni writes:

>
> On Thu, Jan 14, 2016 at 03:53:23PM -0500, Curtis Villamizar wrote:
>  
> > > > smtp_tls_ciphers = high
> > >  
> > >     Usually best to leave this at "medium".  This is opportunistic
> > >     TLS, and if high fails, you'll send cleartext, which is NOT
> > >     stronger than medium.
> >
> > That's actually fine if it actuall fell back.  Comcast didn't fall
> > back, it tried secondary MX, then TEMPFAIL.  Its only intended for
> > internal servers that are supposed to bring up TLS with a trusted key
> > and then also SASL authenticate.  Otherwise I might just leave it at
> > none.
>  
> This is an SMTP *client* setting for your outbound connections,
> and has nothing to do with what happens when Comcast sends you
> mail.  My point is that this is unwise, regardless of Comcast.

This is so that the MTA can authenticate to the MDAs.  My MDA config
goes have smtpd_tls_req_ccert = yes.

This doesn't seem to have caused any problem at all.

> > > > smtp_tls_protocols = !SSLv2 !SSLv3 !TLSv1.1
> > >  
> > >     This is worse, your opportunistic TLS is constrained to
> > >     TLSv1.
> >
> > The lines are the same.  What I'd like is TLSv1.2 only.  Documentation
> > recommended the !format rather than the "legacy" format (in case there
> > is later a 1.3 defined, for example), there is no TLSv1.0 and TLSv1
> > refers to TLSv1.x.  So no good way to exclude TLSv1.0 afaik (afaik is
> > now past tense, see below).
>  
> To exclude TLSv1, use "!TLSv1".  Do check the docs for syntax,
> that's what they're there for.

By now I figured this out (Note the afaik is now past tense, see
below).  Sorry if I'm seeming dense.

> > > > smtpd_tls_ask_ccert = yes
> > >  
> > >     To you do anything with client certs?  If not, don't request
> > >     them.
> >
> > Since the primary reason for having this was for my own hosts,
> > particularly the MSA, the intent was to use them if I could.
>  
> Set that on port 587 only, master.cf.

I have a separate MSA.  Completely different host (BSD jail on a VM).

> > Unfortunately I can't find an option that requires trusted TLS before
> > AUTH, just any TLS (no smtpd_tls_auth_only = trusted, just yes/no).
>  
> smtpd_tls_req_ccert=yes requires trusted TLS, that is the client's
> certificate must be issued by a trusted CA.  For port 587 only,
> and understand the consequences.

The difference would be if you have:

    smtpd_tls_ask_ccert = yes
    smtpd_tls_req_ccert = no
    smtpd_tls_auth_only = trusted

then the same config supports opportunistic TLS for the outside
without client key (they just don't provide one) but does allow an
internal client to authenticate and get relaying.

As I mentioned way down at the bottom, another and probably better
solution is to relay through the MSA.  Note that most of my hosts have
to relay with smart host because they are IPv6 only and need to relay
to get to the IPv4 only world.

> > > > smtpd_tls_cert_file = /etc/postfix/cert.pem
> > > > smtpd_tls_key_file = /etc/postfix/key.pem
> > >  
> > >     What kind of key is that?  RSA or ECDSA?  Can you
> > >     post the output of:
> > >  
> > >     openssl x509 -in /etc/postfix/cert.pem -noout -text | egrep -v ':.*:.*:'
> >
> > Relevant parts:
> >
> >     ASN1 OID: secp384r1
> >     Signature Algorithm: ecdsa-with-SHA256
>  
> Well, that's probably why comcast is having trouble, they likely
> don't support ECDSA.  You really should field an RSA certificate,
> along with the (still bleeding-edge) ECDSA certificate.

That was my first theory but stated a different way.  I said early on
that they are probably running older (openssl 1.0.1) code that doesn't
support secp384r1.

> > Not supported in openssl 1.0.1, but that is > 1 year old version.
>  
> Actually, even 1.0.0 supports ECDSA, but not on RedHat/CentOS
> systems, for patent-fear reasons.

But not secp384r1.  That came with 1.0.2.

> > This is OK if the only thing I want authenticated is my own MSA and
> > MDA servers.
>  
> No, it means that Comcast can't perform a TLS handshake because
> they don't support ECDSA.

I guess we agree that is most likely the problem.

My tcpdump has not picked up anything.  The MTA is a BSD jail and
tcpdump is running on the VM hosting the jail.  I may have to restart
the jail and make bpf available to the jail.

> > > > smtpd_tls_ciphers = high
> > >  
> > >     This is a bad idea, leave it at medium.
> > >  
> > > > smtpd_tls_exclude_ciphers = aNULL MD5 DES
> > >  
> > >     This is not needed.
> >
> > same as smtp.
>  
> The roles of the client and server are very differnt.  Just
> because the settings are the same, does not make them right,
> even if they are right for the other case.
>  
>     http://www.postfix.org/TLS_README.html#client_tls_limits

I'm going to keeping this strong and keeping an eye out for cipher
mismatch.  Until comcast a week or too ago there was no problem.

> You're working too hard trying to make your system more secure,
> and shooting yourself in the foot making it less secure as a result.
> Apply the suggested settings, they're better, leave more things
> at their defaults.

Thanks for the advice but I'm going to keep things at strong.  I will
take your earlier advice on changing smtp[d]_tls_exclude_ciphers.

Since my use of TLS is primarily for internal connections where
smtpd_tls_auth_only is used, I haven't made anything I care about
weaker by making setting strong or using a strong key, even if it is
still bleeding-edge.  See bottom of this reply.

> > > > smtpd_tls_loglevel = 2
> > >  
> > >     Level 1 is just right, 2 is too much.
> >
> > Maybe so.  Isn't hurting anything.
>  
> Actually it severely hampers performance under load, because syslog
> gets overwhelmed with messages.

I'm just doing this while watching the occasional comcast message.
This is a lightly loaded server.

> > I thought (apparently incorrectly) that TLSv1 was TLSv1.x so I didn't
> > include it.  Documentation was not clear on that.
>  
> TLSv1 is just TLS 1.0.  That's what OpenSSL called it, (and then
> later 1.1 came along.  At the time the only previous examples
> were SSLv2 and SSLv3, so TLSv1 made sense.

Yep.

> > > > smtpd_tls_session_cache_timeout = 300
> > >  
> > >    Longer is better, especially with Postfix 2.11+ and session
> > >    tickets.  Let the default stand.
> >
> > Hasn't been a problem.  What would it break?
>  
> SMTP clients connect less often than HTTP clients, longer session
> time improve session reuse and cost you nothing (because the
> session state is client-side).

There have been bugs here and this is a lightly loaded server so I'm
OK keeping this short.

> > > > tls_disable_workarounds = 0xFFFFFFFF
> > >  
> > >     Are you sure that's a good idea?  This is opportunistic TLS.
> >
> > This is TLS between my servers where I happen to get opportunistic TLS
> > as a result of having a STARTTLS.
>  
> Well it also affects inbound mail from Comcast and others, and
> outbound mail to the world.

Lets go through the list:

  SSL_OP_MICROSOFT_SESS_ID_BUG - SSLv2 only
  SSL_OP_NETSCAPE_CHALLENGE_BUG - SSLv2 only
  SSL_OP_LEGACY_SERVER_CONNECT - legacy insecure renegotiation (no thanks)
  NETSCAPE_REUSE_CIPHER_CHANGE_BUG - disabled by default
  SSLREF2_REUSE_CERT_TYPE_BUG - has no effect.
  MICROSOFT_BIG_SSLV3_BUFFER - has no effect.
  MSIE_SSLV2_RSA_PADDING - disabled by default
  SSLEAY_080_CLIENT_DH_BUG - OS X 10.8..10.8.3 broken for ECDHE-ECDSA
  TLS_D5_BUG - OS X 10.8..10.8.3 broken for ECDHE-ECDSA
  TLS_BLOCK_PADDING_BUG - OS X 10.8..10.8.3 broken for ECDHE-ECDSA
  TLS_ROLLBACK_BUG - disabled by default (in openssl)
  SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS - disable SSLv3/TLSv1.0 vuln fix
  CRYPTOPRO_TLSEXT_BUG - applies to GOST only

I don't think anyone is running old enough code that disabling any of
this matters.  Maybe for a web server it might.

> --
> Viktor.
>  
> > Can't use smtpd_tls_req_ccert on MTA.
> >
> > The MSA needs to be a little weak due to cell phones sending mail.  So
> > can't use smtpd_tls_req_ccert on MSA either (for now) and there is no
> > smtpd_tls_auth_only = trusted though it would be real nice to have.
>  
> How would that differ from "smtpd_tls_req_ccert".  What would
> "trusted" mean?

smtpd_tls_req_ccert = yes means all connections must provide a client
cert.  smtpd_tls_auth_only = trusted would mean that for auth to be
offered a client certificate must have been provided and that is for
internal hosts only.

----------------------------------------

I fully understand your points about using medium and other settings
that more reliably support opportunistic TLS to more places.  But that
is not a goal.  If comcast mail falls back to unencrypted no worries.
I'm still going to use very strong encryption but for other reasons.

A while back I decided that MSA and MTA configs were sufficiently
different to use separate servers (jails really so it is not for any
loading reasons, and jails on a VM set aside for MSA/MTA only).  The
secondaries are at a different site, so different server/VM/jails.
So I use port 25 on separate MSAs.  Nothing uses port 587.

A concern I had was internal mail going to the MTA rather than MSA due
to my own host not being configured with relayhost.  Once I'm sure
that all my hosts have been updated to relayhost to an MSA and the
MSAs to relay to the right MDA, I can tailor smtpd_ TLS config on the
MTA to better suit opportunistic TLS, or just set
smtpd_tls_security_level = none on the MTA.

I actually didn't really care much about opportunistic TLS.  It just
seemed to come for free and gave me no trouble until recently and only
for one provider.

For now I'm going to use smtpd_discard_ehlo_keyword_address_maps as
Wietse suggested at the very beginning of this thread.

Curtis
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Viktor Dukhovni
On Thu, Jan 14, 2016 at 11:54:13PM -0500, Curtis Villamizar wrote:

> > > > > smtp_tls_ciphers = high
> > > >  
> > > >     Usually best to leave this at "medium".  This is opportunistic
> > > >     TLS, and if high fails, you'll send cleartext, which is NOT
> > > >     stronger than medium.
> > >
> > > That's actually fine if it actuall fell back.  Comcast didn't fall
> > > back, it tried secondary MX, then TEMPFAIL.  Its only intended for
> > > internal servers that are supposed to bring up TLS with a trusted key
> > > and then also SASL authenticate.  Otherwise I might just leave it at
> > > none.
> >  
> > This is an SMTP *client* setting for your outbound connections,
> > and has nothing to do with what happens when Comcast sends you
> > mail.  My point is that this is unwise, regardless of Comcast.
>
> This is so that the MTA can authenticate to the MDAs.  My MDA config
> goes have smtpd_tls_req_ccert = yes.

Use dedicated transports in master.cf for connections to your MDAs,
say, the "relay" transport or a similar clone, and configure appropriate
master.cf overrides:

  master.cf:
    relay      unix  -       -       y       -       -       smtp
      -o smtp_tls_ciphers=$relay_tls_ciphers

  main.cf:
    relay_tls_ciphers = high

Do not set enforce overly stringent TLS settings for outbound
opportunistic TLS connections to the Internet at large.  Yes,
admittedly peers with just "MEDIUM" ciphers are becoming increasingly
rare, so you might not feel much pain, but there's no win from
enforcing stronger ciphers if when you don't get them, Postfix
fails over to cleartext.

> > smtpd_tls_req_ccert=yes requires trusted TLS, that is the client's
> > certificate must be issued by a trusted CA.  For port 587 only,
> > and understand the consequences.
>
> The difference would be if you have:
>
>     smtpd_tls_ask_ccert = yes
>     smtpd_tls_req_ccert = no
>     smtpd_tls_auth_only = trusted

I see, allow untrusted TLS, but only offer SASL to clients with
trusted certs, and what are the others supposed to do?

> then the same config supports opportunistic TLS for the outside
> without client key (they just don't provide one) but does allow an
> internal client to authenticate and get relaying.

Relaying is on port 587, where opportunistic connections simply
don't happen.  On port 25 you should have no submission clients.
So this is a non-issue.  Just unconditionally disable SASL on port 25.

> As I mentioned way down at the bottom, another and probably better
> solution is to relay through the MSA.

Relay through the MSA, or some other dedicated port.  You can use
client cert authorization for that, and not bother with SASL at
all.

> > > Relevant parts:
> > >
> > >     ASN1 OID: secp384r1
> > >     Signature Algorithm: ecdsa-with-SHA256
> >  
> > Well, that's probably why comcast is having trouble, they likely
> > don't support ECDSA.  You really should field an RSA certificate,
> > along with the (still bleeding-edge) ECDSA certificate.
>
> That was my first theory but stated a different way.  I said early on
> that they are probably running older (openssl 1.0.1) code that doesn't
> support secp384r1.

Except that 1.0.1 does support EC with that curve, but not on RedHat
systems (very cautious lawyers).

> > > Not supported in openssl 1.0.1, but that is > 1 year old version.
> >  
> > Actually, even 1.0.0 supports ECDSA, but not on RedHat/CentOS
> > systems, for patent-fear reasons.
>
> But not secp384r1.  That came with 1.0.2.

This is not true.  It was even present in 1.0.0, except with RedHat:

    $ OpenSSL_1_0_0/bin/openssl version
    OpenSSL 1.0.0t-dev xx XXX xxxx
    $ OpenSSL_1_0_0/bin/openssl ecparam -list_curves | grep 384
      secp384r1 : NIST/SECG curve over a 384 bit prime field

> > No, it means that Comcast can't perform a TLS handshake because
> > they don't support ECDSA.
>
> I guess we agree that is most likely the problem.

Yes.  For interoperability, deploy RSA certs in addition to or
instead of ECDSA certs.

> > The roles of the client and server are very differnt.  Just
> > because the settings are the same, does not make them right,
> > even if they are right for the other case.
> >  
> >     http://www.postfix.org/TLS_README.html#client_tls_limits
>
> I'm going to keeping this strong and keeping an eye out for cipher
> mismatch.  Until comcast a week or too ago there was no problem.

Forcing maximally strong settings gives you no additional security,
it reduces security, by forcing cleartext fallback by less capable
peers.  Yes, the absolutely weakest algorithms that nobody needs
anymore should be turned off to minimize attack surface, but with
opportunistic TLS you should avoid the temptation to turn it up to
11.

> Thanks for the advice but I'm going to keep things at strong.  I will
> take your earlier advice on changing smtp[d]_tls_exclude_ciphers.

Note that "strong" actually means less secure for the peers that
are not capable of meeting that standard.  See RFC7435.

> Since my use of TLS is primarily for internal connections where
> smtpd_tls_auth_only is used, I haven't made anything I care about
> weaker by making setting strong or using a strong key, even if it is
> still bleeding-edge.  See bottom of this reply.

You can use dedicated ports and IP addresses for intramural traffic.
No need to mix that in in the same ports as the unwashed massed.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Curtis Villamizar
In message <[hidden email]>
Viktor Dukhovni writes:
 

> On Thu, Jan 14, 2016 at 11:54:13PM -0500, Curtis Villamizar wrote:
>  
> > > > > > smtp_tls_ciphers = high
> > > > >  
> > > > >     Usually best to leave this at "medium".  This is opportunistic
> > > > >     TLS, and if high fails, you'll send cleartext, which is NOT
> > > > >     stronger than medium.
> > > >
> > > > That's actually fine if it actuall fell back.  Comcast didn't fall
> > > > back, it tried secondary MX, then TEMPFAIL.  Its only intended for
> > > > internal servers that are supposed to bring up TLS with a trusted key
> > > > and then also SASL authenticate.  Otherwise I might just leave it at
> > > > none.
> > >  
> > > This is an SMTP *client* setting for your outbound connections,
> > > and has nothing to do with what happens when Comcast sends you
> > > mail.  My point is that this is unwise, regardless of Comcast.
> >
> > This is so that the MTA can authenticate to the MDAs.  My MDA config
> > goes have smtpd_tls_req_ccert = yes.
>  
> Use dedicated transports in master.cf for connections to your MDAs,
> say, the "relay" transport or a similar clone, and configure appropriate
> master.cf overrides:
>  
>   master.cf:
>     relay      unix  -       -       y       -       -       smtp
>       -o smtp_tls_ciphers=$relay_tls_ciphers
>  
>   main.cf:
>     relay_tls_ciphers = high
>  
> Do not set enforce overly stringent TLS settings for outbound
> opportunistic TLS connections to the Internet at large.  Yes,
> admittedly peers with just "MEDIUM" ciphers are becoming increasingly
> rare, so you might not feel much pain, but there's no win from
> enforcing stronger ciphers if when you don't get them, Postfix
> fails over to cleartext.

Viktor,

Thanks.  I'll do this when I install the new server.  If so I might
have a rather long -o argument.

> > > smtpd_tls_req_ccert=yes requires trusted TLS, that is the client's
> > > certificate must be issued by a trusted CA.  For port 587 only,
> > > and understand the consequences.
> >
> > The difference would be if you have:
> >
> >     smtpd_tls_ask_ccert = yes
> >     smtpd_tls_req_ccert = no
> >     smtpd_tls_auth_only = trusted
>  
> I see, allow untrusted TLS, but only offer SASL to clients with
> trusted certs, and what are the others supposed to do?

There are three cases:

  1.  Anon TLS - they don't provide a cert
  2.  client provides cert with TLSA - trusted, they ignore the AUTH
  3.  internal client has trusted cert and SASL pw - they can relay

Lets leave this suggestion to die.  I don't need this as there is a
better way to do things (bottom of prior email).

> > then the same config supports opportunistic TLS for the outside
> > without client key (they just don't provide one) but does allow an
> > internal client to authenticate and get relaying.
>  
> Relaying is on port 587, where opportunistic connections simply
> don't happen.  On port 25 you should have no submission clients.
> So this is a non-issue.  Just unconditionally disable SASL on port 25.

See bottom of the prior email.

> > As I mentioned way down at the bottom, another and probably better
> > solution is to relay through the MSA.
>  
> Relay through the MSA, or some other dedicated port.  You can use
> client cert authorization for that, and not bother with SASL at
> all.

By MSA here I mean another host that serves as MSA (on port 25) not
same host on port 587.  Both approaches work.  See bottom of prior
email.

> > > > Relevant parts:
> > > >
> > > >     ASN1 OID: secp384r1
> > > >     Signature Algorithm: ecdsa-with-SHA256
> > >  
> > > Well, that's probably why comcast is having trouble, they likely
> > > don't support ECDSA.  You really should field an RSA certificate,
> > > along with the (still bleeding-edge) ECDSA certificate.
> >
> > That was my first theory but stated a different way.  I said early on
> > that they are probably running older (openssl 1.0.1) code that doesn't
> > support secp384r1.
>  
> Except that 1.0.1 does support EC with that curve, but not on RedHat
> systems (very cautious lawyers).

OK.  If you say so.  My emperical experience indicates that this
version does not support it.  OpenSSL 1.0.1p-freebsd 9 Jul 2015

> > > > Not supported in openssl 1.0.1, but that is > 1 year old version.
> > >  
> > > Actually, even 1.0.0 supports ECDSA, but not on RedHat/CentOS
> > > systems, for patent-fear reasons.
> >
> > But not secp384r1.  That came with 1.0.2.
>  
> This is not true.  It was even present in 1.0.0, except with RedHat:
>  
>     $ OpenSSL_1_0_0/bin/openssl version
>     OpenSSL 1.0.0t-dev xx XXX xxxx
>     $ OpenSSL_1_0_0/bin/openssl ecparam -list_curves | grep 384
>       secp384r1 : NIST/SECG curve over a 384 bit prime field

Maybe its not in FreeBSD either except the version from ports
collection.

Do you have a reference to the legal issue handy?

> > > No, it means that Comcast can't perform a TLS handshake because
> > > they don't support ECDSA.
> >
> > I guess we agree that is most likely the problem.
>  
> Yes.  For interoperability, deploy RSA certs in addition to or
> instead of ECDSA certs.

OK.  I hear you.  Or disable opportunistic TLS at least for now.

> > > The roles of the client and server are very differnt.  Just
> > > because the settings are the same, does not make them right,
> > > even if they are right for the other case.
> > >  
> > >     http://www.postfix.org/TLS_README.html#client_tls_limits
> >
> > I'm going to keeping this strong and keeping an eye out for cipher
> > mismatch.  Until comcast a week or too ago there was no problem.
>  
> Forcing maximally strong settings gives you no additional security,
> it reduces security, by forcing cleartext fallback by less capable
> peers.  Yes, the absolutely weakest algorithms that nobody needs
> anymore should be turned off to minimize attack surface, but with
> opportunistic TLS you should avoid the temptation to turn it up to
> 11.

Somehow you missed this statement (sic) "I don't care about
opportunistic TLS.  It came for free and didn't cause any trouble
until now".

> > Thanks for the advice but I'm going to keep things at strong.  I will
> > take your earlier advice on changing smtp[d]_tls_exclude_ciphers.
>  
> Note that "strong" actually means less secure for the peers that
> are not capable of meeting that standard.  See RFC7435.

See prior sentence.

> > Since my use of TLS is primarily for internal connections where
> > smtpd_tls_auth_only is used, I haven't made anything I care about
> > weaker by making setting strong or using a strong key, even if it is
> > still bleeding-edge.  See bottom of this reply.
>  
> You can use dedicated ports and IP addresses for intramural traffic.
> No need to mix that in in the same ports as the unwashed massed.

When I migrate to the new physical server RSN, I'll redo the configs.
For now, I'll keep what I have because I have other things to do and
things are working well enough.

> --
> Viktor.

Oops - you cut off the bottom of the old reply.  Anyway my prior email
explained how I plan to change my server setup.

Thanks again.  Lets not continue to beat a dead horse.

Curtis
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Curtis Villamizar
In reply to this post by Viktor Dukhovni
In message <[hidden email]>
Viktor Dukhovni writes:
 
> Post a PCAP file of a single failed TLS handshake.  I know the person
> at comcast in charge of their email transport security.   I can probably
> get them to fix it once we nail down the problem, assuming it is not overly
> aggressive settings on your end.
>  
> --
> Viktor.


Viktor,

If you are still interested below is a tcpdump.

If not interested, please just delete.

Curtis


# tcpdump -n -i em1 -K -l -t -vvv -X     'net 96.114.154.0/24 || net 2001:558:fe16:19:96:114:154:0/120'     | & tee /tmp/dumpfile

tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size 65535 bytes
IP (tos 0x0, ttl 53, id 60614, offset 0, flags [DF], proto TCP (6), length 60)
    96.114.154.163.59007 > 192.34.84.171.25: Flags [S], seq 2932514262, win 14600, options [mss 1460,nop,nop,TS val 3786830096 ecr 0,nop,wscale 3], length 0
        0x0000:  4500 003c ecc6 4000 3506 4912 6072 9aa3  E..<..@.5.I.`r..
        0x0010:  c022 54ab e67f 0019 aeca 9dd6 0000 0000  ."T.............
        0x0020:  a002 3908 7c18 0000 0204 05b4 0101 080a  ..9.|...........
        0x0030:  e1b6 7110 0000 0000 0103 0303            ..q.........
IP (tos 0x0, ttl 64, id 32208, offset 0, flags [DF], proto TCP (6), length 60)
    192.34.84.171.25 > 96.114.154.163.59007: Flags [S.], seq 277202429, ack 2932514263, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 3607830461 ecr 3786830096], length 0
        0x0000:  4500 003c 7dd0 4000 4006 ad08 c022 54ab  E..<}.@.@...."T.
        0x0010:  6072 9aa3 0019 e67f 1085 c5fd aeca 9dd7  `r..............
        0x0020:  a012 ffff e7c0 0000 0204 05b4 0103 0306  ................
        0x0030:  0101 080a d70b 1fbd e1b6 7110            ..........q.
IP (tos 0x0, ttl 53, id 60615, offset 0, flags [DF], proto TCP (6), length 52)
    96.114.154.163.59007 > 192.34.84.171.25: Flags [.], seq 1, ack 1, win 1825, options [nop,nop,TS val 3786830144 ecr 3607830461], length 0
        0x0000:  4500 0034 ecc7 4000 3506 4919 6072 9aa3  E..4..@.5.I.`r..
        0x0010:  c022 54ab e67f 0019 aeca 9dd7 1085 c5fe  ."T.............
        0x0020:  8010 0721 0c3a 0000 0101 080a e1b6 7140  ...!.:........q@
        0x0030:  d70b 1fbd                                ....
IP (tos 0x0, ttl 64, id 32211, offset 0, flags [DF], proto TCP (6), length 97)
    192.34.84.171.25 > 96.114.154.163.59007: Flags [P.], seq 1:46, ack 1, win 1040, options [nop,nop,TS val 3607830691 ecr 3786830144], length 45
        0x0000:  4500 0061 7dd3 4000 4006 ace0 c022 54ab  E..a}.@.@...."T.
        0x0010:  6072 9aa3 0019 e67f 1085 c5fe aeca 9dd7  `r..............
        0x0020:  8018 0410 fc2b 0000 0101 080a d70b 20a3  .....+..........
        0x0030:  e1b6 7140 3232 3020 6d74 6133 2e73 6f6d  ..[hidden email]
        0x0040:  6572 7669 6c6c 652e 6f63 636e 632e 636f  erville.occnc.co
        0x0050:  6d20 4553 4d54 5020 506f 7374 6669 780d  m.ESMTP.Postfix.
        0x0060:  0a                                       .
IP (tos 0x0, ttl 53, id 60616, offset 0, flags [DF], proto TCP (6), length 52)
    96.114.154.163.59007 > 192.34.84.171.25: Flags [.], seq 1, ack 46, win 1825, options [nop,nop,TS val 3786830374 ecr 3607830691], length 0
        0x0000:  4500 0034 ecc8 4000 3506 4918 6072 9aa3  E..4..@.5.I.`r..
        0x0010:  c022 54ab e67f 0019 aeca 9dd7 1085 c62b  ."T............+
        0x0020:  8010 0721 0a41 0000 0101 080a e1b6 7226  ...!.A........r&
        0x0030:  d70b 20a3                                ....
IP (tos 0x0, ttl 53, id 60617, offset 0, flags [DF], proto TCP (6), length 89)
    96.114.154.163.59007 > 192.34.84.171.25: Flags [P.], seq 1:38, ack 46, win 1825, options [nop,nop,TS val 3786830374 ecr 3607830691], length 37
        0x0000:  4500 0059 ecc9 4000 3506 48f2 6072 9aa3  E..Y..@.5.H.`r..
        0x0010:  c022 54ab e67f 0019 aeca 9dd7 1085 c62b  ."T............+
        0x0020:  8018 0721 5038 0000 0101 080a e1b6 7226  ...!P8........r&
        0x0030:  d70b 20a3 4548 4c4f 2072 6573 716d 7461  ....EHLO.resqmta
        0x0040:  2d70 6f2d 3034 762e 7379 732e 636f 6d63  -po-04v.sys.comc
        0x0050:  6173 742e 6e65 740d 0a                   ast.net..
IP (tos 0x0, ttl 64, id 32212, offset 0, flags [DF], proto TCP (6), length 200)
    192.34.84.171.25 > 96.114.154.163.59007: Flags [P.], seq 46:194, ack 38, win 1040, options [nop,nop,TS val 3607830739 ecr 3786830374], length 148
        0x0000:  4500 00c8 7dd4 4000 4006 ac78 c022 54ab  E...}.@.@..x."T.
        0x0010:  6072 9aa3 0019 e67f 1085 c62b aeca 9dfc  `r.........+....
        0x0020:  8018 0410 9707 0000 0101 080a d70b 20d3  ................
        0x0030:  e1b6 7226 3235 302d 6d74 6133 2e73 6f6d  ..r&250-mta3.som
        0x0040:  6572 7669 6c6c 652e 6f63 636e 632e 636f  erville.occnc.co
        0x0050:  6d0d 0a32 3530 2d50 4950 454c 494e 494e  m..250-PIPELININ
        0x0060:  470d 0a32 3530 2d53 495a 4520 3130 3234  G..250-SIZE.1024
        0x0070:  3030 3030 0d0a 3235 302d 5652 4659 0d0a  0000..250-VRFY..
        0x0080:  3235 302d 4554 524e 0d0a 3235 302d 5354  250-ETRN..250-ST
        0x0090:  4152 5454 4c53 0d0a 3235 302d 454e 4841  ARTTLS..250-ENHA
        0x00a0:  4e43 4544 5354 4154 5553 434f 4445 530d  NCEDSTATUSCODES.
        0x00b0:  0a32 3530 2d38 4249 544d 494d 450d 0a32  .250-8BITMIME..2
        0x00c0:  3530 2044 534e 0d0a                      50.DSN..
IP (tos 0x0, ttl 53, id 60618, offset 0, flags [DF], proto TCP (6), length 62)
    96.114.154.163.59007 > 192.34.84.171.25: Flags [P.], seq 38:48, ack 194, win 1959, options [nop,nop,TS val 3786830422 ecr 3607830739], length 10
        0x0000:  4500 003e ecca 4000 3506 490c 6072 9aa3  E..>..@.5.I.`r..
        0x0010:  c022 54ab e67f 0019 aeca 9dfc 1085 c6bf  ."T.............
        0x0020:  8018 07a7 c637 0000 0101 080a e1b6 7256  .....7........rV
        0x0030:  d70b 20d3 5354 4152 5454 4c53 0d0a       ....STARTTLS..
IP (tos 0x0, ttl 64, id 32213, offset 0, flags [DF], proto TCP (6), length 82)
    192.34.84.171.25 > 96.114.154.163.59007: Flags [P.], seq 194:224, ack 48, win 1040, options [nop,nop,TS val 3607830787 ecr 3786830422], length 30
        0x0000:  4500 0052 7dd5 4000 4006 aced c022 54ab  E..R}.@.@...."T.
        0x0010:  6072 9aa3 0019 e67f 1085 c6bf aeca 9e06  `r..............
        0x0020:  8018 0410 f4b5 0000 0101 080a d70b 2103  ..............!.
        0x0030:  e1b6 7256 3232 3020 322e 302e 3020 5265  ..rV220.2.0.0.Re
        0x0040:  6164 7920 746f 2073 7461 7274 2054 4c53  ady.to.start.TLS
        0x0050:  0d0a                                     ..
IP (tos 0x0, ttl 53, id 60619, offset 0, flags [DF], proto TCP (6), length 167)
    96.114.154.163.59007 > 192.34.84.171.25: Flags [P.], seq 48:163, ack 224, win 1959, options [nop,nop,TS val 3786830470 ecr 3607830787], length 115
        0x0000:  4500 00a7 eccb 4000 3506 48a2 6072 9aa3  E.....@.5.H.`r..
        0x0010:  c022 54ab e67f 0019 aeca 9e06 1085 c6dd  ."T.............
        0x0020:  8018 07a7 4af4 0000 0101 080a e1b6 7286  ....J.........r.
        0x0030:  d70b 2103 1603 0100 6e01 0000 6a03 0356  ..!.....n...j..V
        0x0040:  997f bb65 5bfc 2526 05ac 1d29 7165 2834  ...e[.%&...)qe(4
        0x0050:  a7d3 418c 740a 7522 08e2 1f9b 0ca7 ee00  ..A.t.u"........
        0x0060:  0012 0033 0032 002f 0039 0038 0035 0005  ...3.2./.9.8.5..
        0x0070:  0004 00ff 0100 002f 0023 0000 000d 0022  ......./.#....."
        0x0080:  0020 0601 0602 0603 0501 0502 0503 0401  ................
        0x0090:  0402 0403 0301 0302 0303 0201 0202 0203  ................
        0x00a0:  0101 000f 0001 01                        .......
IP (tos 0x0, ttl 64, id 32214, offset 0, flags [DF], proto TCP (6), length 59)
    192.34.84.171.25 > 96.114.154.163.59007: Flags [P.], seq 224:231, ack 163, win 1040, options [nop,nop,TS val 3607830835 ecr 3786830470], length 7
        0x0000:  4500 003b 7dd6 4000 4006 ad03 c022 54ab  E..;}.@.@...."T.
        0x0010:  6072 9aa3 0019 e67f 1085 c6dd aeca 9e79  `r.............y
        0x0020:  8018 0410 c8f9 0000 0101 080a d70b 2133  ..............!3
        0x0030:  e1b6 7286 1503 0300 0202 28              ..r.......(
IP (tos 0x0, ttl 64, id 32215, offset 0, flags [DF], proto TCP (6), length 52)
    192.34.84.171.25 > 96.114.154.163.59007: Flags [F.], seq 231, ack 163, win 1040, options [nop,nop,TS val 3607830836 ecr 3786830470], length 0
        0x0000:  4500 0034 7dd7 4000 4006 ad09 c022 54ab  E..4}.@.@...."T.
        0x0010:  6072 9aa3 0019 e67f 1085 c6e4 aeca 9e79  `r.............y
        0x0020:  8011 0410 0b05 0000 0101 080a d70b 2134  ..............!4
        0x0030:  e1b6 7286                                ..r.
IP (tos 0x0, ttl 53, id 60620, offset 0, flags [DF], proto TCP (6), length 52)
    96.114.154.163.59007 > 192.34.84.171.25: Flags [F.], seq 163, ack 231, win 1959, options [nop,nop,TS val 3786830518 ecr 3607830835], length 0
        0x0000:  4500 0034 eccc 4000 3506 4914 6072 9aa3  E..4..@.5.I.`r..
        0x0010:  c022 54ab e67f 0019 aeca 9e79 1085 c6e4  ."T........y....
        0x0020:  8011 07a7 073f 0000 0101 080a e1b6 72b6  .....?........r.
        0x0030:  d70b 2133                                ..!3
IP (tos 0x0, ttl 64, id 32216, offset 0, flags [DF], proto TCP (6), length 52)
    192.34.84.171.25 > 96.114.154.163.59007: Flags [F.], seq 231, ack 164, win 1040, options [nop,nop,TS val 3607830883 ecr 3786830518], length 0
        0x0000:  4500 0034 7dd8 4000 4006 ad08 c022 54ab  E..4}.@.@...."T.
        0x0010:  6072 9aa3 0019 e67f 1085 c6e4 aeca 9e7a  `r.............z
        0x0020:  8011 0410 0aa5 0000 0101 080a d70b 2163  ..............!c
        0x0030:  e1b6 72b6                                ..r.
IP (tos 0x0, ttl 53, id 60621, offset 0, flags [DF], proto TCP (6), length 52)
    96.114.154.163.59007 > 192.34.84.171.25: Flags [.], seq 164, ack 232, win 1959, options [nop,nop,TS val 3786830519 ecr 3607830836], length 0
        0x0000:  4500 0034 eccd 4000 3506 4913 6072 9aa3  E..4..@.5.I.`r..
        0x0010:  c022 54ab e67f 0019 aeca 9e7a 1085 c6e5  ."T........z....
        0x0020:  8010 07a7 073c 0000 0101 080a e1b6 72b7  .....<........r.
        0x0030:  d70b 2134                                ..!4
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Viktor Dukhovni
On Fri, Jan 15, 2016 at 06:47:38PM -0500, Curtis Villamizar wrote:

> Viktor,
>
> If you are still interested below is a tcpdump.
>
> If not interested, please just delete.

I was looking for a binary PCAP file, not an ASCII decode.  Yes,
it would be good to know whether Comcast was having ECDSA issues,
or something else.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Curtis Villamizar
In message <[hidden email]>
Viktor Dukhovni writes:

>
> On Fri, Jan 15, 2016 at 06:47:38PM -0500, Curtis Villamizar wrote:
>  
> > Viktor,
> >
> > If you are still interested below is a tcpdump.
> >
> > If not interested, please just delete.
>  
> I was looking for a binary PCAP file, not an ASCII decode.  Yes,
> it would be good to know whether Comcast was having ECDSA issues,
> or something else.
>  
> --
> Viktor.


OK.  I'll do another packet capture.  Binary this time.

Curtis
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Curtis Villamizar
In reply to this post by Viktor Dukhovni
In message <[hidden email]>
Viktor Dukhovni writes:

>
> On Fri, Jan 15, 2016 at 06:47:38PM -0500, Curtis Villamizar wrote:
>  
> > Viktor,
> >
> > If you are still interested below is a tcpdump.
> >
> > If not interested, please just delete.
>  
> I was looking for a binary PCAP file, not an ASCII decode.  Yes,
> it would be good to know whether Comcast was having ECDSA issues,
> or something else.
>  
> --
> Viktor.
Viktor,

It took a while to get a dumpfile.  My tcpdump command only covered a
subset of comcast.net mailhosts.

This has a failed TLS negotiation and a few packets from a next
attempt.  The log entry below covers this first connection.

This fails but fallback to the secondary MX happens and mail gets
delivered.

Curtis


Jan 21 16:42:07 mta3 postfix/smtpd[26462]: connect from resqmta-po-06v.sys.comcast.net[2001:558:fe16:19:96:114:154:165]
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: setting up TLS connection from resqmta-po-06v.sys.comcast.net[2001:558:fe16:19:96:114:154:165]
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: resqmta-po-06v.sys.comcast.net[2001:558:fe16:19:96:114:154:165]: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH:!aNULL:!MD5:!DES:!aNULL"
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: SSL_accept:before/accept initialization
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: SSL3 alert write:fatal:handshake failure
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: SSL_accept:error in error
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: SSL_accept:error in error
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: SSL_accept error from resqmta-po-06v.sys.comcast.net[2001:558:fe16:19:96:114:154:165]: -1
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: warning: TLS library problem: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1411:
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: lost connection after STARTTLS from resqmta-po-06v.sys.comcast.net[2001:558:fe16:19:96:114:154:165]
Jan 21 16:42:07 mta3 postfix/smtpd[26462]: disconnect from resqmta-po-06v.sys.comcast.net[2001:558:fe16:19:96:114:154:165] ehlo=1 starttls=0/1 commands=1/2
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: connect from resqmta-po-06v.sys.comcast.net[96.114.154.165]
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: setting up TLS connection from resqmta-po-06v.sys.comcast.net[96.114.154.165]
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: resqmta-po-06v.sys.comcast.net[96.114.154.165]: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH:!aNULL:!MD5:!DES:!aNULL"
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: SSL_accept:before/accept initialization
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: SSL3 alert write:fatal:handshake failure
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: SSL_accept:error in error
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: SSL_accept:error in error
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: SSL_accept error from resqmta-po-06v.sys.comcast.net[96.114.154.165]: -1
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: warning: TLS library problem: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher:s3_srvr.c:1411:
Jan 21 16:42:08 mta3 postfix/smtpd[26462]: lost connection after STARTTLS from resqmta-po-06v.sys.comcast.net[96.114.154.165]



20430.1453432273.2@harbor1-em2.v6only.occnc.com (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Viktor Dukhovni
On Thu, Jan 21, 2016 at 10:55:19PM -0500, Curtis Villamizar wrote:

> It took a while to get a dumpfile.  My tcpdump command only covered a
> subset of comcast.net mailhosts.
>
> This has a failed TLS negotiation and a few packets from a next
> attempt.  The log entry below covers this first connection.

Comcast's Client Hello:

    $ tshark -V -r file.pcap -T text
    ...
    Secure Socket Layer
        SSL Record Layer: Handshake Protocol: Client Hello
            Content Type: Handshake (22)
            Version: TLS 1.0 (0x0301)
            Length: 110
            Handshake Protocol: Client Hello
                Handshake Type: Client Hello (1)
                Length: 106
                Version: TLS 1.2 (0x0303)
                Random
                    gmt_unix_time: Jan 21, 2016 21:42:08.000000000
                    random_bytes: F015DF3A10F02A3715060148AFF41E28315A20155496A43A...
                Session ID Length: 0
                Cipher Suites Length: 18
                Cipher Suites (9 suites)
                    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
                    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
                    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
                    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
                    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                    Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
                    Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
                    Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
                ...

No sign of ECDSA support, or AESGCM, or anything else bleeding
edge.  Similarly configured MTAs will not be able to complete TLS
handshakes with your server unless you also deploy an RSA certificate.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Curtis Villamizar
In message <[hidden email]>
Viktor Dukhovni writes:
 

> On Thu, Jan 21, 2016 at 10:55:19PM -0500, Curtis Villamizar wrote:
>  
> > It took a while to get a dumpfile.  My tcpdump command only covered a
> > subset of comcast.net mailhosts.
> >
> > This has a failed TLS negotiation and a few packets from a next
> > attempt.  The log entry below covers this first connection.
>  
> Comcast's Client Hello:
>  
>     $ tshark -V -r file.pcap -T text
>     ...
>     Secure Socket Layer
> SSL Record Layer: Handshake Protocol: Client Hello
>    Content Type: Handshake (22)
>    Version: TLS 1.0 (0x0301)
>    Length: 110
>    Handshake Protocol: Client Hello
> Handshake Type: Client Hello (1)
> Length: 106
> Version: TLS 1.2 (0x0303)
> Random
>    gmt_unix_time: Jan 21, 2016 21:42:08.000000000
>    random_bytes: F015DF3A10F02A3715060148AFF41E28315A20155496A43A...
> Session ID Length: 0
> Cipher Suites Length: 18
> Cipher Suites (9 suites)
>    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
>    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
>    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
>    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
>    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
>    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
>    Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
>    Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
>    Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
> ...
>  
> No sign of ECDSA support, or AESGCM, or anything else bleeding
> edge.  Similarly configured MTAs will not be able to complete TLS
> handshakes with your server unless you also deploy an RSA certificate.
>  
> --
> Viktor.


Viktor,

The bug that it doesn't fall back then is likely because comcast mail
servers are running sendmail or something else other than postfix.  If
you do know someone at comcast, then please report that.  You might
also want to report that the keys they use are less than LOW security
but that might be a feature.  Please also ask when opportunistic TLS
was enabled.

Note that none of the ciphers used by comcast.net support even low
strength and forward secrecy.

  cat <<EOF | egrep 'TLS_ECDHE_|TLS_DHE_|TLS_ADH_|TLS_EDH_'

    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
    Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
    Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

  EOF

yields:

    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)

These four support forward secrecy.  But these and all the comcast
ciphers are less than low strength and would be excluded with !LOW.
They would be high with CBC3_SHA and CBC3_SHA is not bleeding edge.

So for me falling that far back to encoding in 56 bit DES and a SHA1
MAC seems a bit too far backwards to go (back to SSLv3 days).

The opportunistic TLS offered by comcast.net isn't much better than no
TLS at all.  So for now I'll stick with what I have as it is not a
problem otherwise and add:

  smtpd_discard_ehlo_keyword_address_maps =
    cidr:/etc/postfix/no-tls-for-you

  no-tls-for-you:
  69.252.207.0/24        starttls
  96.114.154.0/24        starttls
  69.252.76.0/24         starttls
  76.96.68.0/24          starttls
  2001:558:fe16:19::/64  starttls
  2001:558:fe21:29::/64  starttls

That covers the comcast.net mail servers according to
https://postmaster.comcast.net/outbound-mail-servers.html

In reviewing the logs very few non-spammer domains seem to be failing.
The most concerning non-spammer is cloud9.net.  I'm still considering
keeping the primary MX with the same sort of key and using either no
TLS or a weaker key on the secondary MX.

I'll also run tcpdump on the cloud9.net addresses and run it through
tshark and see what the problem is there.  If it is simply that they
don't use ECDSA or AESGCM, but they do offer something reasonable,
then I'll consider creating an alternate key.  Otherwise I'll just add
them to the cidr file.  I hope someone at cloud9.net is reading this
(they do host the postfix mailing lists), but if not I'll send
off-list email.

Either way I'll continue to watch the logs (or cron will) for
'SSL_accept error' lines (fail) and for 'Trusted TLS connection from'
(trusted) or 'TLS connection established from' (anon or untrusted).
Having a strict primary MX and a weak secondary allows me to do this
logging without dropping mail.

Note that smtpd_tls_ask_ccert does no damage as the client key is
accepted as untrusted and then AUTH is not offered but relay to my
MDAs still happens (which in the two cases today allowed connections
from google.com allowing spammers using gmail to connect - one sending
to spam@ - obviously having harvested that from a hidden div in web
page of mine requesting help building spam filters - I guess even
gmail has spammers openning free accouts).

Thanks for all of the help and good advice.  Thanks also to Wietse who
suggested using smtpd_discard_ehlo_keyword_address_maps.

Curtis
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Viktor Dukhovni
On Fri, Jan 22, 2016 at 03:14:22PM -0500, Curtis Villamizar wrote:

> You might
> also want to report that the keys they use are less than LOW security
> but that might be a feature.

You're mistaken.  These ciphers are HIGH.

> Note that none of the ciphers used by comcast.net support even low
> strength and forward secrecy.

You're mistaken.

> So for me falling that far back to encoding in 56 bit DES and a SHA1
> MAC seems a bit too far backwards to go (back to SSLv3 days).

You're mistaken.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: selective disable of smtpd opportunistic TLS

Curtis Villamizar
In message <[hidden email]>
Viktor Dukhovni writes:
 

> On Fri, Jan 22, 2016 at 03:14:22PM -0500, Curtis Villamizar wrote:
>  
> > You might
> > also want to report that the keys they use are less than LOW security
> > but that might be a feature.
>  
> You're mistaken.  These ciphers are HIGH.
>  
> > Note that none of the ciphers used by comcast.net support even low
> > strength and forward secrecy.
>  
> You're mistaken.
>  
> > So for me falling that far back to encoding in 56 bit DES and a SHA1
> > MAC seems a bit too far backwards to go (back to SSLv3 days).
>  
> You're mistaken.
>  
> --
> Viktor.


Viktor,

Yes.  I rechecked.  I was mistaken.  These four are high and offer
forward secrecy.

    DHE-RSA-AES128-SHA
    DHE-DSS-AES128-SHA
    DHE-RSA-AES256-SHA
    DHE-DSS-AES256-SHA

Due to the naming used:

    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
    Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
    Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

I did a few openssl ciphers commands and greps for CBC-SHA and
CBC3-SHA and got the wrong ones based on the naming.

I redid this with openssl ciphers -V and used to hex codes.  The last
two are MEDIUM.  The other six are HIGH.  Four offer forward secrecy,
the ones starting the DHE.

My understanding is that RC4 has multiple proven vulnerabilities so
not using the last two is justified.  SHA1 should be avoided, but
admitedly no one would bother with the computational load needed for a
SHA1 attack on our opportunistic TLS email, particularly no spammer
trying to find a relay to use.

You did not respond to the rest of the email.  Any comments on the
rest of it?

  So for now I'll stick with what I have as it is not a
  problem otherwise and add:
 
    smtpd_discard_ehlo_keyword_address_maps =
      cidr:/etc/postfix/no-tls-for-you
 
    no-tls-for-you:
    69.252.207.0/24        starttls
    96.114.154.0/24        starttls
    69.252.76.0/24         starttls
    76.96.68.0/24          starttls
    2001:558:fe16:19::/64  starttls
    2001:558:fe21:29::/64  starttls
 
  That covers the comcast.net mail servers according to
  https://postmaster.comcast.net/outbound-mail-servers.html
 
  In reviewing the logs very few non-spammer domains seem to be failing.
  The most concerning non-spammer is cloud9.net.  I'm still considering
  keeping the primary MX with the same sort of key and using either no
  TLS or a weaker key on the secondary MX.
 
  I'll also run tcpdump on the cloud9.net addresses and run it through
  tshark and see what the problem is there.  If it is simply that they
  don't use ECDSA or AESGCM, but they do offer something reasonable,
  then I'll consider creating an alternate key.  Otherwise I'll just add
  them to the cidr file.  I hope someone at cloud9.net is reading this
  (they do host the postfix mailing lists), but if not I'll send
  off-list email.
 
  Either way I'll continue to watch the logs (or cron will) for
  'SSL_accept error' lines (fail) and for 'Trusted TLS connection from'
  (trusted) or 'TLS connection established from' (anon or untrusted).
  Having a strict primary MX and a weak secondary allows me to do this
  logging without dropping mail.
 
  Note that smtpd_tls_ask_ccert does no damage as the client key is
  accepted as untrusted and then AUTH is not offered but relay to my
  MDAs still happens [...]

Ammending the above, now knowing that the comcast.net keys are high.
I might just add a longish RSA key as a solution for comcast.net but
keeping high in place.  That might also solve the cloud9.net and one
or two others that are non-spammers and currently fail and fall back
to the secondary MX.

[aside: Perhaps ECDSA-AES256-GCM-SHA384 was a bit too much for email.
It seems to not upset HTTPS and browsers.  OTOH- TLSA/DANE support in
browsers is non-existant without plugins but available for email.]

Thanks again.

Curtis