SSL version question
Locked
 
|
I have a client that's triggering these errors in my logs (and is therefore unable to send even though he can read mail ok):
Searching on the error string isn't helping me particularly, and I'm not sure how to discover what SSL version is being attempted. That he can read mail suggests to me that it's not really an SSL version issue, but I see that dovecot is not being as strict. I'd like to do what I can to verify/understand and not just relax
constraints blindly. On my server I've set this, which I thought was permissive enough
but not too much:
Thanks for any pointers. (Fwiw, the client is running thunderbird on Windows 10.
Hopefully that's not relevant.) -- Jeff Abrahamson +33 6 24 40 01 57 +44 7920 594 255 http://p27.eu/jeff/ http://mobilitains.fr/ |
|
|
On 16/02/2021 10:28, Jeff Abrahamson wrote: > > I have a client that's triggering these errors in my logs (and is > therefore unable to send even though he can read mail ok): > > postfix/submission/smtpd[310140]: connect from [...] > postfix/submission/smtpd[310140]: SSL_accept error from [...]: -1 > postfix/submission/smtpd[310140]: warning: TLS library problem: > error:14209102:SSL > routines:tls_early_post_process_client_hello:unsupported > protocol:../ssl/statem/statem_srvr.c:1685: > postfix/submission/smtpd[310140]: lost connection after STARTTLS > from 53.6.119.80.rev.sfr.net[80.119.6.53] > postfix/submission/smtpd[310140]: disconnect from [...] ehlo=1 > starttls=0/1 commands=1/2 > > Searching on the error string isn't helping me particularly, and I'm > not sure how to discover what SSL version is being attempted. That he > can read mail suggests to me that it's not really an SSL version > issue, but I see that dovecot is not being as strict. > > I'd like to do what I can to verify/understand and not just relax > constraints blindly. > > On my server I've set this, which I thought was permissive enough but > not too much: > > smtpd_tls_mandatory_protocols = SSLv3, TLSv1 > > Thanks for any pointers. > > (Fwiw, the client is running thunderbird on Windows 10. Hopefully > that's not relevant.) > auth clients I have: smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 This refuses anything below TLSv1.2, and works fine with clients running Thunderbird on Windows 10. Thunderbird v78 disables TLSv1.0 and TLSv1.1 by default for good safety reasons. This is almost certainly the reason for the errors you are seeing - your server is trying to force the client to connect with outdated protocols (SSLv3 or TLSv1) and the client refuses. |
|
|
On 16/02/2021 11:46, Dominic Raferd wrote:
> > On 16/02/2021 10:28, Jeff Abrahamson wrote: >> >> I have a client that's triggering these errors in my logs (and is >> therefore unable to send even though he can read mail ok): >> >> [...] >> >> [...] >> >> I'd like to do what I can to verify/understand and not just relax >> constraints blindly. >> >> On my server I've set this, which I thought was permissive enough but >> not too much: >> >> smtpd_tls_mandatory_protocols = SSLv3, TLSv1 >> >> [...] >> > Those are terrible settings, probably the opposite of what you want. > For auth clients I have: > > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 > > This refuses anything below TLSv1.2, and works fine with clients > running Thunderbird on Windows 10. > > Thunderbird v78 disables TLSv1.0 and TLSv1.1 by default for good > safety reasons. This is almost certainly the reason for the errors you > are seeing - your server is trying to force the client to connect with > outdated protocols (SSLv3 or TLSv1) and the client refuses. Thanks. That was, indeed, the issue, and I'm happy to have discovered this error in our config. I'm not sure quite why the TLS string was set thus (recommendation somewhere that I clearly read with an inverted '!'). But no one was looking at it recently. Thanks again. -- Jeff Abrahamson +33 6 24 40 01 57 +44 7920 594 255 http://p27.eu/jeff/ http://mobilitains.fr/ |
|
|
In reply to this post by Dominic Raferd
On 16 Feb 2021, at 5:46, Dominic Raferd wrote:
> On 16/02/2021 10:28, Jeff Abrahamson wrote: >> >> I have a client that's triggering these errors in my logs (and is >> therefore unable to send even though he can read mail ok): >> >> postfix/submission/smtpd[310140]: connect from [...] >> postfix/submission/smtpd[310140]: SSL_accept error from [...]: -1 >> postfix/submission/smtpd[310140]: warning: TLS library problem: >> error:14209102:SSL >> routines:tls_early_post_process_client_hello:unsupported >> protocol:../ssl/statem/statem_srvr.c:1685: >> postfix/submission/smtpd[310140]: lost connection after STARTTLS >> from 53.6.119.80.rev.sfr.net[80.119.6.53] >> postfix/submission/smtpd[310140]: disconnect from [...] ehlo=1 >> starttls=0/1 commands=1/2 >> >> Searching on the error string isn't helping me particularly, and I'm >> not sure how to discover what SSL version is being attempted. That >> he can read mail suggests to me that it's not really an SSL version >> issue, but I see that dovecot is not being as strict. >> >> I'd like to do what I can to verify/understand and not just relax >> constraints blindly. >> >> On my server I've set this, which I thought was permissive enough but >> not too much: >> >> smtpd_tls_mandatory_protocols = SSLv3, TLSv1 >> >> Thanks for any pointers. >> >> (Fwiw, the client is running thunderbird on Windows 10. Hopefully >> that's not relevant.) >> > Those are terrible settings, probably the opposite of what you want. > For auth clients I have: > > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 That punishes older MTAs by forcing them to use cleartext if they don't do TLSv1.2+ In what way does that improve your security over the default, which allows 1.0 and 1.1? -- Bill Cole [hidden email] or [hidden email] (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire |
|
|
On 16/02/2021 17:41, Bill Cole wrote: > On 16 Feb 2021, at 5:46, Dominic Raferd wrote: > >> On 16/02/2021 10:28, Jeff Abrahamson wrote: >>> I have a client that's triggering these errors in my logs (and is >>> therefore unable to send even though he can read mail ok): >>> >>> postfix/submission/smtpd[310140]: connect from [...] >>> postfix/submission/smtpd[310140]: SSL_accept error from [...]: -1 >>> postfix/submission/smtpd[310140]: warning: TLS library problem: >>> error:14209102:SSL >>> routines:tls_early_post_process_client_hello:unsupported >>> protocol:../ssl/statem/statem_srvr.c:1685: >>> postfix/submission/smtpd[310140]: lost connection after STARTTLS >>> from 53.6.119.80.rev.sfr.net[80.119.6.53] >>> postfix/submission/smtpd[310140]: disconnect from [...] ehlo=1 >>> starttls=0/1 commands=1/2 >>> >>> Searching on the error string isn't helping me particularly, and I'm >>> not sure how to discover what SSL version is being attempted. That >>> he can read mail suggests to me that it's not really an SSL version >>> issue, but I see that dovecot is not being as strict. >>> >>> I'd like to do what I can to verify/understand and not just relax >>> constraints blindly. >>> >>> On my server I've set this, which I thought was permissive enough but >>> not too much: >>> >>> smtpd_tls_mandatory_protocols = SSLv3, TLSv1 >>> >>> Thanks for any pointers. >>> >>> (Fwiw, the client is running thunderbird on Windows 10. Hopefully >>> that's not relevant.) >>> >> Those are terrible settings, probably the opposite of what you want. >> For auth clients I have: >> >> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 > That punishes older MTAs by forcing them to use cleartext if they don't > do TLSv1.2+ > > In what way does that improve your security over the default, which > allows 1.0 and 1.1? STARTTLS. There is no problem for us in enforcing it for them, they don't use old MTAs anyway and if they did this would force them to upgrade, which would be good. This also seems to be the OP's scenario (as his logs imply the problem comes from submission port i.e. 587). We use standard postfix settings for permitted protocols for outsider emails (port 25) because (as frequently advised here) lower security is better than no security at all. HTH |
|
|
> On Feb 16, 2021, at 3:57 PM, Dominic Raferd <[hidden email]> wrote:
> >> In what way does that improve your security over the default, which >> allows 1.0 and 1.1? > As stated this is for auth clients i.e. our own people, using SMTPS or STARTTLS. There is no problem for us in enforcing it for them, they don't use old MTAs anyway and if they did this would force them to upgrade, which would be good. This also seems to be the OP's scenario (as his logs imply the problem comes from submission port i.e. 587). We use standard postfix settings for permitted protocols for outsider emails (port 25) because (as frequently advised here) lower security is better than no security at all. HTH Yes, on the submission port, dropping support for TLS < 1.2 is much more reasonable, because presumably you can make informed judgements as to what software the authorised users have at their disposal. -- Viktor. |
|
|
On 2021-02-16 18:34:32 -0200, Viktor Dukhovni wrote:
> > On Feb 16, 2021, at 3:57 PM, Dominic Raferd <[hidden email]> wrote: > > > >> In what way does that improve your security over the default, which > >> allows 1.0 and 1.1? > > As stated this is for auth clients i.e. our own people, using SMTPS or STARTTLS. There is no problem for us in enforcing it for them, they don't use old MTAs anyway and if they did this would force them to upgrade, which would be good. This also seems to be the OP's scenario (as his logs imply the problem comes from submission port i.e. 587). We use standard postfix settings for permitted protocols for outsider emails (port 25) because (as frequently advised here) lower security is better than no security at all. HTH > > Yes, on the submission port, dropping support for TLS < 1.2 > is much more reasonable, because presumably you can make > informed judgements as to what software the authorised users > have at their disposal. But since smtpd_tls_mandatory_protocols is not specific to the submission port, I suppose that this should be done with a -o option in the master.cf file. Is that right? After searching a bit, I've seen that on https://forum.chatons.org/t/configuration-postfix-notation-cryptcheck/1684 some user has submission inet n - n - - smtpd -o smtpd_enforce_tls=yes -o smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1 Is there any reason that he uses smtpd_tls_protocols and not smtpd_tls_mandatory_protocols? This seems incorrect since smtpd_enforce_tls=yes is mandatory TLS. -- Vincent Lefèvre <[hidden email]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) |
|
|
On 17/02/2021 14:49, Vincent Lefevre wrote: > On 2021-02-16 18:34:32 -0200, Viktor Dukhovni wrote: >>> On Feb 16, 2021, at 3:57 PM, Dominic Raferd <[hidden email]> wrote: >>> >>>> In what way does that improve your security over the default, which >>>> allows 1.0 and 1.1? >>> As stated this is for auth clients i.e. our own people, using SMTPS or STARTTLS. There is no problem for us in enforcing it for them, they don't use old MTAs anyway and if they did this would force them to upgrade, which would be good. This also seems to be the OP's scenario (as his logs imply the problem comes from submission port i.e. 587). We use standard postfix settings for permitted protocols for outsider emails (port 25) because (as frequently advised here) lower security is better than no security at all. HTH >> Yes, on the submission port, dropping support for TLS < 1.2 >> is much more reasonable, because presumably you can make >> informed judgements as to what software the authorised users >> have at their disposal. > But since smtpd_tls_mandatory_protocols is not specific to the > submission port, I suppose that this should be done with a -o option > in the master.cf file. Is that right? > > After searching a bit, I've seen that on > > https://forum.chatons.org/t/configuration-postfix-notation-cryptcheck/1684 > > some user has > > submission inet n - n - - smtpd > -o smtpd_enforce_tls=yes > -o smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1 > > Is there any reason that he uses smtpd_tls_protocols and not > smtpd_tls_mandatory_protocols? This seems incorrect since > smtpd_enforce_tls=yes is mandatory TLS. smtpd_tls_mandatory_protocols applies only where tls is mandatory. I define it in main.cf, where I also define 'smtpd_tls_security_level = may'. Then in master.cf, for connections by MTAs (our users) I define '-o smtpd_tls_security_level=encrypt' (also '-o smtpd_sasl_auth_enable=yes'). The effect is that the settings for smtpd_tls_mandatory_protocols are applied for the MTAs ('tls security level is encrypt' means 'tls is mandatory') and not for connections on port 25 because tls is not mandatory there. But yes you could put the definition of smtpd_tls_mandatory_protocols in the smtpd settings in master.cf for all ports used for auth connections instead of putting it once in main.cf - it might make the logic easier to follow. smtpd_enforce_tls=yes is an old setting available for Postfix 2.2+ but not advised for Postfix 2.3+. man 5 postconf is your friend! |
|
|
In reply to this post by Viktor Dukhovni
On 16/02/2021 21:34, Viktor Dukhovni wrote:
>> On Feb 16, 2021, at 3:57 PM, Dominic Raferd <[hidden email]> wrote: >> >>> In what way does that improve your security over the default, which >>> allows 1.0 and 1.1? >> As stated this is for auth clients i.e. our own people, using SMTPS or STARTTLS. There is no problem for us in enforcing it for them, they don't use old MTAs anyway and if they did this would force them to upgrade, which would be good. This also seems to be the OP's scenario (as his logs imply the problem comes from submission port i.e. 587). We use standard postfix settings for permitted protocols for outsider emails (port 25) because (as frequently advised here) lower security is better than no security at all. HTH > Yes, on the submission port, dropping support for TLS < 1.2 > is much more reasonable, because presumably you can make > informed judgements as to what software the authorised users > have at their disposal. I was surprised by the level of disagreement on what best practice is. I spent a bit of time this afternoon rereading that part of the postconf manual. I thought I'd summarise what I've understood, both for other readers and to be contradicted if I've misunderstood. Setting these two should guarantee that no incoming connection is unencrypted. smtpd_use_tls = yes smtpd_tls_auth_only = yes But which versions? This seems to make sense: require high grade ciphers. But the man page makes a good argument for setting this to medium. I'd originally set smtpd_tls_mandatory_ciphers = high, I've switched it to medium. I had initially set smtpd_tls_exclude_ciphers = RC4, aNULL, but, again, I see the man page makes a good argument against that, so I've removed the exclusion. The default value of smtpd_tls_mandatory_protocols is !SSLv2, !SSLv3. The suggestion on this thread was to set it as follows, which was certainly better than what I had (an explicit inclusion rather than an explicit exclusion). I'm rather tempted, based on the man page, to change it to its default value (essentially, >= TLSv1). I'm open to argument. smtpd_tls_mandatory_ciphers = medium # smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 -- Jeff Abrahamson +33 6 24 40 01 57 +44 7920 594 255 http://p27.eu/jeff/ http://mobilitains.fr/ |
|
|
On Wed, Feb 17, 2021 at 07:04:54PM +0100, Jeff Abrahamson wrote:
> But the man page makes a good argument for setting this to medium. > I'd originally set smtpd_tls_mandatory_ciphers = high, I've switched > it to medium. You can set it back to "high". Perhaps that should even be the new default in the upcoming Postfix 3.6... > > Yes, on the submission port, dropping support for TLS < 1.2 > > is much more reasonable, because presumably you can make > > informed judgements as to what software the authorised users > > have at their disposal. > > I was surprised by the level of disagreement on what best practice is. There is no substantive disagreement, there's a well known trade-off between: A. Righteously sending a signal to the folks in the long tail of the curve to finally get off their behinds and support modern TLS specs. B. Barring substantive downgrade exposure, raising the ceiling and leaving the floor alone, until such time as the long tail withers away to effectively nobody. (RFC7435). This improves security without needlessly forcing laggards to cleartext. Some laggards don't get the message until some folks take option A, while the pragmatic and sensible thing is option B. Do you want to be a hero or a pragmatist? > Setting these two should guarantee that no incoming connection is > unencrypted. > > smtpd_use_tls = yes > smtpd_tls_auth_only = yes Sorry, no. The first is an obsolete syntax to *enable* TLS, it was replaced with "smtpd_tls_security_level = may". The second also does not enforce TLS, but it does cause SASL AUTH to not be offered as option until and unless a TLS connection is established. > But which versions? This seems to make sense: require high grade > ciphers. See RFC7435. At this point the *only* medium cipher that's still used by a very few laggards is RC4-SHA1. Otherwise "high" is no longer an issue. For most sites, even RC4-SHA1 is never seen in practice. We have now probably reached the point in time where the long tail for medium has withered away. You can use "high" or "medium", either is fine. OpenSSL 1.1.1 by default disables RC4 at compile time, leaving just SEED, which nobody needs for interoperability. $ openssl ciphers -s -tls1_2 -v MEDIUM DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1 DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1 SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1 > I had initially set smtpd_tls_exclude_ciphers = RC4, aNULL, but, > again, I see the man page makes a good argument against that, so I've > removed the exclusion. You don't need to and should not exclude aNULL, and "high" already excludes "RC4", so you're all set in terms of the basic algorithms. > The default value of smtpd_tls_mandatory_protocols is !SSLv2, !SSLv3. > The suggestion on this thread was to set it as follows, which was > certainly better than what I had (an explicit inclusion rather than an > explicit exclusion). I'm rather tempted, based on the man page, to > change it to its default value (essentially, >= TLSv1). I'm open to > argument. > > smtpd_tls_mandatory_ciphers = medium > # smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 The default is still reasonable for opportunistic TLS in SMTP. On the submission port, you can reasonably require >= TLS 1.2, if all the authorised clients are expected to be able to do that. -- Viktor. |
«
Return to Postfix Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |