STARTTLS and PCI requirements

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

STARTTLS and PCI requirements

James B. Byrne
We have logged this problem with some of our e-mail correspondents:

Jan  2 11:32:20 mx31 postfix-p25/smtpd[55167]: connect from
rockmx03.rockwool.com[195.191.109.227]
Jan  2 11:32:20 mx31 postfix-p25/smtpd[55167]: SSL_accept error from
rockmx03.rockwool.com[195.191.109.227]: -1
Jan  2 11:32:20 mx31 postfix-p25/smtpd[55167]: lost connection after
STARTTLS from rockmx03.rockwool.com[195.191.109.227]
Jan  2 11:32:20 mx31 postfix-p25/smtpd[55167]: disconnect from
rockmx03.rockwool.com[195.191.109.227] ehlo=1 starttls=0/1
commands=1/2

When I connect to the sender I see this:

openssl s_client -connect rockmx03.rockwool.com:25 -starttls smtp
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign
Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization
Validation CA - SHA256 - G2
verify return:1
depth=0 C = DK, ST = Hedehusene, L = Hedehusene, OU = Group IT, O =
Rockwool International A/S, CN = rockmx03.rockwool.com
verify return:1
---
Certificate chain
 0 s:C = DK, ST = Hedehusene, L = Hedehusene, OU = Group IT, O =
Rockwool International A/S, CN = rockmx03.rockwool.com
   i:C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization
Validation CA - SHA256 - G2
 1 s:C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization
Validation CA - SHA256 - G2
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
. . .
issuer=C = BE, O = GlobalSign nv-sa, CN = GlobalSign Organization
Validation CA - SHA256 - G2

---
No client certificate CA names sent
Peer signing digest: MD5-SHA1
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3348 bytes and written 492 bytes
Verification: OK
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID:
CE4800003053F9E7B2DC6821EE8E9FE2F362B9EDEB4751BB203252D637B32DB1
    Session-ID-ctx:
    Master-Key:
D217D8A488ED2296FBA5C9889FE88238066B2E1FD50D41F54653CA2D046667F9164CD914C4E75DCAD0C4F0B0FB83E50E
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1577982813
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
250 CHUNKING
QUIT
DONE


We recently were forced by our PCI compliance audit to change our
permissible ciphers.  I speculate that this is the source of our
problem.   Our revised cipher list is:

# postconf | grep tls | grep cipher
lmtp_tls_ciphers = medium
lmtp_tls_exclude_ciphers =
lmtp_tls_mandatory_ciphers = medium
lmtp_tls_mandatory_exclude_ciphers =
milter_helo_macros = {tls_version} {cipher} {cipher_bits}
{cert_subject} {cert_issuer}
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = MD5, aDSS, SRP, PSK, aECDH, aDH, SEED,
IDEA, RC2, RC4, RC5, DES, 3DES
smtp_tls_mandatory_ciphers = high
smtp_tls_mandatory_exclude_ciphers =
smtpd_tls_ciphers = high
smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK,
aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_exclude_ciphers =
tls_export_cipherlist =
aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH
tls_high_cipherlist = aNULL:-aNULL:HIGH:@STRENGTH
tls_low_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:LOW:+RC4:@STRENGTH
tls_medium_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH
tls_null_cipherlist = eNULL:!aNULL
tls_preempt_cipherlist = no
tls_session_ticket_cipher = aes-256-cbc
tlsproxy_tls_ciphers = $smtpd_tls_ciphers
tlsproxy_tls_exclude_ciphers = $smtpd_tls_exclude_ciphers
tlsproxy_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
tlsproxy_tls_mandatory_exclude_ciphers =
$smtpd_tls_mandatory_exclude_ciphers


If I try to connect to our MX using ECDHE-RSA-AES256-SHA this succeeds:

openssl s_client -cipher ECDHE-RSA-AES256-SHA -connect
mx31.harte-lyne.ca:25 -starttls smtp -CAfile
/usr/local/etc/pki/tls/certs/ca-bundle.crt

CONNECTED(00000003)
. . .
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 8146 bytes and written 383 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
250 SMTPUTF8
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
. . .

I do not understand what the problem is; or rather how to fix the
STARTTLS negotiation issue.

I point out that this problem is affects very few of our
correspondents (two at the moment) and both are located in the EU.

I would appreciate any guidance as to how to correct this issue
without running afoul of the PCI DSS.

Thanks,

--
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS and PCI requirements

Bastian Blank-3
On Thu, Jan 02, 2020 at 12:16:33PM -0500, James B. Byrne wrote:
> We recently were forced by our PCI compliance audit to change our
> permissible ciphers.  I speculate that this is the source of our
> problem.   Our revised cipher list is:

Don't, as long as you don't enforce encryption as well.

> I would appreciate any guidance as to how to correct this issue
> without running afoul of the PCI DSS.

Don't use mail to transport payment data, so PCI is not applicable.

Bastian

--
You can't evaluate a man by logic alone.
                -- McCoy, "I, Mudd", stardate 4513.3
Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS and PCI requirements

James B. Byrne


On Thu, January 2, 2020 12:35, Bastian Blank wrote:

> On Thu, Jan 02, 2020 at 12:16:33PM -0500, James B. Byrne wrote:
>> We recently were forced by our PCI compliance audit to change our
>> permissible ciphers.  I speculate that this is the source of our
>> problem.   Our revised cipher list is:
>
> Don't, as long as you don't enforce encryption as well.
>
>> I would appreciate any guidance as to how to correct this issue
>> without running afoul of the PCI DSS.
>
> Don't use mail to transport payment data, so PCI is not applicable.


This advice is not helpful.  It is not what we are sending but rather
what we are receiving.  We have no control over the information that
our clients send us.  PCI DSS exists to deal with this sort of thing.

--
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS and PCI requirements (postfix-3.3.4)

James B. Byrne
In reply to this post by James B. Byrne
The following are the settings in main.cf that have been changed
followed by the commented (#) default values:

postconf mail_version
mail_version = 3.3.4

postconf -n | grep smtp | grep tls

smtp_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt          
                            #smtp_tls_CAfile =

smtp_tls_cert_file =
/usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt                  
       #smtp_tls_cert_file =

smtp_tls_ciphers = high                                              
                            #smtp_tls_ciphers = medium

smtp_tls_exclude_ciphers = MD5, aDSS, SRP, PSK, aECDH, aDH, SEED,
IDEA, RC2,\ RC4, RC5, DES, 3DES   #smtp_tls_exclude_ciphers =

smtp_tls_key_file = /usr/local/etc/pki/tls/private/ca.harte-lyne.mx31.key
#smtp_tls_key_file = $smtp_tls_cert_file

smtp_tls_mandatory_ciphers = high                                    
                            #smtp_tls_mandatory_ciphers = medium

smtp_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1,
!SSLv3, !SSLv2
#smtp_tls_mandatory_protocols = !SSLv2, !SSLv3

smtp_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv3,
!SSLv2                            #smtp_tls_protocols = !SSLv2, !SSLv3

smtp_tls_security_level = dane                                        
                            #smtp_tls_security_level =

smtp_tls_session_cache_database = btree:/var/db/postfix/smtp_scache
#smtp_tls_session_cache_database =

smtp_tls_session_cache_timeout = 3600s
#smtp_tls_session_cache_timeout = 3600s

smtpd_starttls_timeout = ${stress?10}${stress:120}s
#smtpd_starttls_timeout = ${stress?{10}:{300}}s

smtpd_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt
#smtpd_tls_CAfile =

smtpd_tls_ask_ccert = no
#smtpd_tls_ask_ccert = no

smtpd_tls_auth_only = yes
#smtpd_tls_auth_only = no

smtpd_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
#smtpd_tls_cert_file =

smtpd_tls_ciphers = high
#smtpd_tls_ciphers = medium

smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
#smtpd_tls_dh1024_param_file =

smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK,
aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA
#smtpd_tls_exclude_ciphers =

smtpd_tls_fingerprint_digest = sha256                                
                            #smtpd_tls_fingerprint_digest = md5

smtpd_tls_key_file =
/usr/local/etc/pki/tls/private/ca.harte-lyne.mx31.key
#smtpd_tls_key_file = $smtpd_tls_cert_file

smtpd_tls_mandatory_ciphers = high
#smtpd_tls_mandatory_ciphers = medium

smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1,
!SSLv3, !SSLv2
#smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3

smtpd_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv3, !SSLv2
#smtpd_tls_protocols = !SSLv2, !SSLv3

smtpd_tls_received_header = yes
#smtpd_tls_received_header = no

smtpd_tls_security_level = may
#smtpd_tls_security_level =

smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_scache
#smtpd_tls_session_cache_database =

smtpd_tls_session_cache_timeout = 3600s
#smtpd_tls_session_cache_timeout = 3600s


--
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS and PCI requirements

Eero Volotinen-2
In reply to this post by James B. Byrne
You can't force encryption on smtp or your system fails with clients without ssl enabled.

Anyway, it's insane to receive PANs (credit card numbers) via email. Stop doing that.

Eero

On Thu, Jan 2, 2020 at 8:05 PM James B. Byrne <[hidden email]> wrote:


On Thu, January 2, 2020 12:35, Bastian Blank wrote:
> On Thu, Jan 02, 2020 at 12:16:33PM -0500, James B. Byrne wrote:
>> We recently were forced by our PCI compliance audit to change our
>> permissible ciphers.  I speculate that this is the source of our
>> problem.   Our revised cipher list is:
>
> Don't, as long as you don't enforce encryption as well.
>
>> I would appreciate any guidance as to how to correct this issue
>> without running afoul of the PCI DSS.
>
> Don't use mail to transport payment data, so PCI is not applicable.


This advice is not helpful.  It is not what we are sending but rather
what we are receiving.  We have no control over the information that
our clients send us.  PCI DSS exists to deal with this sort of thing.

--
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS and PCI requirements (postfix-3.3.4)

Eero Volotinen-2
In reply to this post by James B. Byrne
    smtpd_tls_security_level = may

With this, the Postfix SMTP server announces STARTTLS support to remote SMTP clients, but does not require that clients use TLS encryption.

Looks like there is plain text still enabled in your system? 

Eero


On Thu, Jan 2, 2020 at 8:11 PM James B. Byrne <[hidden email]> wrote:
The following are the settings in main.cf that have been changed
followed by the commented (#) default values:

postconf mail_version
mail_version = 3.3.4

postconf -n | grep smtp | grep tls

smtp_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt         
                            #smtp_tls_CAfile =

smtp_tls_cert_file =
/usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt                   
       #smtp_tls_cert_file =

smtp_tls_ciphers = high                                               
                            #smtp_tls_ciphers = medium

smtp_tls_exclude_ciphers = MD5, aDSS, SRP, PSK, aECDH, aDH, SEED,
IDEA, RC2,\ RC4, RC5, DES, 3DES   #smtp_tls_exclude_ciphers =

smtp_tls_key_file = /usr/local/etc/pki/tls/private/ca.harte-lyne.mx31.key
#smtp_tls_key_file = $smtp_tls_cert_file

smtp_tls_mandatory_ciphers = high                                     
                            #smtp_tls_mandatory_ciphers = medium

smtp_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1,
!SSLv3, !SSLv2
#smtp_tls_mandatory_protocols = !SSLv2, !SSLv3

smtp_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv3,
!SSLv2                            #smtp_tls_protocols = !SSLv2, !SSLv3

smtp_tls_security_level = dane                                       
                            #smtp_tls_security_level =

smtp_tls_session_cache_database = btree:/var/db/postfix/smtp_scache
#smtp_tls_session_cache_database =

smtp_tls_session_cache_timeout = 3600s
#smtp_tls_session_cache_timeout = 3600s

smtpd_starttls_timeout = ${stress?10}${stress:120}s
#smtpd_starttls_timeout = ${stress?{10}:{300}}s

smtpd_tls_CAfile = /usr/local/etc/pki/tls/certs/ca-bundle.crt
#smtpd_tls_CAfile =

smtpd_tls_ask_ccert = no
#smtpd_tls_ask_ccert = no

smtpd_tls_auth_only = yes
#smtpd_tls_auth_only = no

smtpd_tls_cert_file = /usr/local/etc/pki/tls/certs/ca.harte-lyne.mx31.crt
#smtpd_tls_cert_file =

smtpd_tls_ciphers = high
#smtpd_tls_ciphers = medium

smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
#smtpd_tls_dh1024_param_file =

smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK,
aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA
#smtpd_tls_exclude_ciphers =

smtpd_tls_fingerprint_digest = sha256                                 
                            #smtpd_tls_fingerprint_digest = md5

smtpd_tls_key_file =
/usr/local/etc/pki/tls/private/ca.harte-lyne.mx31.key
#smtpd_tls_key_file = $smtpd_tls_cert_file

smtpd_tls_mandatory_ciphers = high
#smtpd_tls_mandatory_ciphers = medium

smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1,
!SSLv3, !SSLv2
#smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3

smtpd_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv3, !SSLv2
#smtpd_tls_protocols = !SSLv2, !SSLv3

smtpd_tls_received_header = yes
#smtpd_tls_received_header = no

smtpd_tls_security_level = may
#smtpd_tls_security_level =

smtpd_tls_session_cache_database = btree:/var/db/postfix/smtpd_scache
#smtpd_tls_session_cache_database =

smtpd_tls_session_cache_timeout = 3600s
#smtpd_tls_session_cache_timeout = 3600s


--
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS and PCI requirements

Viktor Dukhovni
In reply to this post by James B. Byrne
On Thu, Jan 02, 2020 at 06:35:17PM +0100, Bastian Blank wrote:

> On Thu, Jan 02, 2020 at 12:16:33PM -0500, James B. Byrne wrote:
> > Our revised cipher list is:
>
> Don't, as long as you don't enforce encryption as well.
> Don't use mail to transport payment data, so PCI is not applicable.

The above sounds quite reasonable to me.

On Thu, Jan 02, 2020 at 12:16:33PM -0500, James B. Byrne wrote:

> Jan  2 11:32:20 mx31 postfix-p25/smtpd[55167]: connect from
> rockmx03.rockwool.com[195.191.109.227]
> Jan  2 11:32:20 mx31 postfix-p25/smtpd[55167]: SSL_accept error from
> rockmx03.rockwool.com[195.191.109.227]: -1

That seems to suggest that the client disconnected in the middle of the
TLS handshake, leaving no usable SSL-layer error reason.

> When I connect to the sender I see this:

There's little reason to expect to learn much by connecting to the
sending domain's MX hosts.

> New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA

The only think that's perhaps relevant is that TLSv1 was used
and not TLSv1.2, suggesting a rather dated inbound stack.

> 250 CHUNKING

The server runs Windows.

> We recently were forced by our PCI compliance audit to change our
> permissible ciphers.

It should be possible in many cases to talk some sense into the
auditors.  Was STARTTLS from the senders in question working before
the changes?

> # postconf | grep tls | grep cipher

[ Next time, "postconf -n" please. ]

> smtp_tls_ciphers = high
> smtp_tls_exclude_ciphers = MD5, aDSS, SRP, PSK, aECDH, aDH, SEED, IDEA, RC2, RC4, RC5, DES, 3DES
> smtp_tls_mandatory_ciphers = high

These don't affect inbound mail.

> smtpd_tls_ciphers = high
> smtpd_tls_mandatory_ciphers = high
> smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK,
>    aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA

The cipher exclusions above look rather haphazard.  Saner would be:

    smtpd_tls_exclude_ciphers = MD5, aDSS, kECDH, kDH, 3DES, RC4, SEED, IDEA, RC2, RC5

What protocol versions do you have enabled?  More likely the issue is
that you've disabled TLS 1.0.

> I would appreciate any guidance as to how to correct this issue
> without running afoul of the PCI DSS.

Leave TLS 1.0 enabled for now, it is adequately secure for opportunistic
TLS in SMTP.

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

Re: STARTTLS and PCI requirements

Viktor Dukhovni
In reply to this post by James B. Byrne
On Thu, Jan 02, 2020 at 12:55:54PM -0500, James B. Byrne wrote:

> > Don't use mail to transport payment data, so PCI is not applicable.
>
> This advice is not helpful.  It is not what we are sending but rather
> what we are receiving.  We have no control over the information that
> our clients send us.  PCI DSS exists to deal with this sort of thing.

When raising the floor on STARTTLS the result can be not greater
security, but otherwise avoidable use of cleartext.  See:

    https://tools.ietf.org/html/rfc7435#section-1.2

You get more security benefit from raising the ceiling, not the floor,
allowing the peer to negotiate the strongest available parameters.
Raising the floor is sometimes warranted, once *nobody* needs the weaker
options being excluded, but otherwise can be counter-productive.

Your system supports TLS 1.3, with modern ciphers, ... you're in good
shape.  Let the default settings work for you.

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

Re: STARTTLS and PCI requirements (postfix-3.3.4)

Viktor Dukhovni
In reply to this post by James B. Byrne
On Thu, Jan 02, 2020 at 01:02:51PM -0500, James B. Byrne wrote:

> The following are the settings in main.cf that have been changed
> followed by the commented (#) default values:
>
> postconf -n | grep smtp | grep tls

Whatever you did to post this, thoroughly mangled the output, but
amidst the carnage, I see:

> smtp_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv3, !SSLv2
> smtp_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv3, !SSLv2
>
> smtpd_tls_mandatory_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv3, !SSLv2
> smtpd_tls_protocols = TLSv1.3, TLSv1.2, !TLSv1.1, !TLSv1, !SSLv3, !SSLv2

The observed symptoms are with high probability caused by disabling TLSv1,
and not the random cipher tweaks.

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

Re: STARTTLS and PCI requirements

James B. Byrne
In reply to this post by Viktor Dukhovni


On Thu, January 2, 2020 13:16, Viktor Dukhovni wrote:

>
> What protocol versions do you have enabled?  More likely the issue is
> that you've disabled TLS 1.0.
>


You are correct. Disabling TLSv1 as we were instructed to do by the
PCI DSS audit, is the root cause of the problem.  This has been
corrected, or broken depending upon ones point of view. The haphazard
exclude list has been rendered more sane.

Now I need to see if the PCI people will consider TLSv1 a false
positive or exception.


Thank you all for the help.

Sincerely,

--
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:[hidden email]
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

Reply | Threaded
Open this post in threaded view
|

Server fingerprinting (CHUNKING)

Wietse Venema
In reply to this post by Viktor Dukhovni
Viktor Dukhovni:
> > 250 CHUNKING
>
> The server runs Windows.

Or Postfix, or Exim, or Gmail, ... (CHUNKING enables BDAT commands).
A better discriminant may be "BINARYMIME".

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: STARTTLS and PCI requirements

Jaroslaw Rafa
In reply to this post by Eero Volotinen-2
Dnia  2.01.2020 o godz. 20:09:41 Eero Volotinen pisze:
>
> Anyway, it's insane to receive PANs (credit card numbers) via email. Stop
> doing that.

Sending this type of information via e-mail is acceptable only when the
e-mail is E2E encrypted (eg. using PGP). Don't rely on transport level
encryption alone.

Maybe you can try to agree with your senders on using PGP?
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: Server fingerprinting (CHUNKING)

Viktor Dukhovni
In reply to this post by Wietse Venema
> On Jan 2, 2020, at 4:04 PM, Wietse Venema <[hidden email]> wrote:
>
> Viktor Dukhovni:
>>> 250 CHUNKING
>>
>> The server runs Windows.
>
> Or Postfix, or Exim, or Gmail, ... (CHUNKING enables BDAT commands).
> A better discriminant may be "BINARYMIME".

Yes, I know, but this one really does run Windows, and CHUNKING was
a hint in that direction... :-)  The quality of the signal is indeed
decaying as CHUNKING becomes more widely implemented.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Server fingerprinting (CHUNKING)

Wietse Venema
Viktor Dukhovni:

> > On Jan 2, 2020, at 4:04 PM, Wietse Venema <[hidden email]> wrote:
> >
> > Viktor Dukhovni:
> >>> 250 CHUNKING
> >>
> >> The server runs Windows.
> >
> > Or Postfix, or Exim, or Gmail, ... (CHUNKING enables BDAT commands).
> > A better discriminant may be "BINARYMIME".
>
> Yes, I know, but this one really does run Windows, and CHUNKING was
> a hint in that direction... :-)  The quality of the signal is indeed
> decaying as CHUNKING becomes more widely implemented.

BINARYMIME requires CHUNKING, consider it a signal upgrade.

        Wietse