Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Cannot Start TLS: handshake failure

4,393 views
Skip to first unread message

Tom

unread,
Apr 29, 2015, 6:57:33 PM4/29/15
to
I have a basic postfix setup that's been working fine for a long time, but recently, I've been seeing errors with a number of sites:

"Cannot start TLS: handshake failure"

Here are some specific sites where I'm seeing this issue:

SSL_connect error to mail.mlmatthews.com[23.25.38.217]
SSL_connect error to 108.247.226.220[108.247.226.220]
SSL_connect error to mail.txninc.com[216.167.201.250]

And so on.

I have minimal settings in my main.cf for smtp_tls_* settings - most of the settings are simply the defaults.

smtp_use_tls = yes
smtp_tls_security_level = may
smtp_tls_session_cache_timeout = 3600s
smtp_tls_CApath = <path>
smtp_tls_key_file = <key file>
smtp_tls_cert_file = <cert file>
smtp_tls_CAfile = <ca file>


And I've tried this, thinking that it could be an issue with the selected ciphers, but it makes no difference:

smtp_tls_exclude_ciphers = 3DES DES


2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: setting up TLS connection to mail.mlmatthews.com[23.25.38.217]:25
2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: mail.mlmatthews.com[23.25.38.217]:25: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH:!3DES:!DES"
2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: SSL_connect:before/connect initialization
2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: SSL_connect:SSLv2/v3 write client hello A
2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: SSL_connect error to mail.mlmatthews.com[23.25.38.217]:25: lost connection
2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: 3lcZT61sm7z5wjJ: to=<user @mlmatthews.com>, relay=mail.mlmatthews.com[23.25.38.217]:25, delay=8.8, delays=8.5/0.26/0.05/0, dsn=4.7.5, status=undeliverable-but-not-cached (Cannot start TLS: handshake failure)


Here's what I'm running:

postfix 3.1-20150421
CentOS release 6.6 (Final)
openssl-1.0.1e-30.el6.8.x86_64
openssl-devel-1.0.1e-30.el6.8.x86_64


Any suggestions about what is going on here? Did something recently change with either openssl or with MS Exchange? Many, although not all the servers where I see this happening are exchange servers, but I don't have enough data to say that's definitive.

Tom Johnson

unread,
Apr 29, 2015, 8:58:07 PM4/29/15
to
I have a basic postfix setup that's been working fine for a long time, but recently, I've been seeing errors with a number of sites: 

   "Cannot start TLS: handshake failure" 

Here are some specific sites where I'm seeing this issue: 

   SSL_connect error to 23.25.38.217 [23.25.38.217] 

   SSL_connect error to 108.247.226.220 [108.247.226.220] 
   SSL_connect error to 216.167.201.250 [216.167.201.250] 

Viktor Dukhovni

unread,
Apr 29, 2015, 10:42:12 PM4/29/15
to
On Wed, Apr 29, 2015 at 05:57:36PM -0700, Tom Johnson wrote:

> I have a basic postfix setup that's been working fine for a long time,
> but recently, I've been seeing errors with a number of sites:
>
> "Cannot start TLS: handshake failure"
>
> Here are some specific sites where I'm seeing this issue:
>
> SSL_connect error to 23.25.38.217 [23.25.38.217]
> SSL_connect error to 108.247.226.220 [108.247.226.220]
> SSL_connect error to 216.167.201.250 [216.167.201.250]
>
> And so on.
>
> I have minimal settings in my main.cf for smtp_tls_* settings - most of the settings are simply the defaults.
>
> smtp_use_tls = yes
> smtp_tls_security_level = may
> smtp_tls_session_cache_timeout = 3600s
> smtp_tls_CApath = <path>
> smtp_tls_CAfile = <ca file>

Fine, but you'll save a bit of CPU if you leave "smtp_tls_CApath" and
"smtp_tls_CAfile" empty.

> smtp_tls_key_file = <key file>
> smtp_tls_cert_file = <cert file>

And you're generally better off without client certs too.


> And I've tried this, thinking that it could be an issue with the selected ciphers, but it makes no difference:
>
> smtp_tls_exclude_ciphers = 3DES DES

The symptom with broken 3DES with Microsoft systems is not a
handshake failure.

> 2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: setting up TLS connection to mail.mlmatthews.com[23.25.38.217]:25
> 2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: mail.mlmatthews.com[23.25.38.217]:25: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH:!3DES:!DES"
> 2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: SSL_connect:before/connect initialization
> 2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: SSL_connect:SSLv2/v3 write client hello A
> 2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: SSL_connect error to mail.mlmatthews.com[23.25.38.217]:25: lost connection
> 2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: 3lcZT61sm7z5wjJ: to=<us...@mlmatthews.com>, relay=mail.mlmatthews.com[23.25.38.217]:25, delay=8.8, delays=8.5/0.26/0.05/0, dsn=4.7.5, status=undeliverable-but-not-cached (Cannot start TLS: handshake failure)
>

That's funny, the domain's MX host is different for me:

$ dig +short -t mx mlmatthews.com
10 mail.mailroute.net.

That aside, even with the "wrong" MX host, I still get successful
connections. Perhaps you're behind some sort of firewall that
proxies TLS and disconnects when it does not like the peer certificate:

$ posttls-finger -c -Ldebug "[mail.mlmatthews.com]"
posttls-finger: initializing the client-side TLS engine
posttls-finger: setting up TLS connection to mail.mlmatthews.com[23.25.38.217]:25
...
posttls-finger: SSL_connect:SSLv2/v3 write client hello A
posttls-finger: SSL_connect:SSLv3 read server hello A
...
posttls-finger: SSL_connect:SSLv3 read server certificate A
posttls-finger: SSL_connect:SSLv3 read server done A
posttls-finger: SSL_connect:SSLv3 write client key exchange A
posttls-finger: SSL_connect:SSLv3 write change cipher spec A
posttls-finger: SSL_connect:SSLv3 write finished A
posttls-finger: SSL_connect:SSLv3 flush data
posttls-finger: SSL_connect:SSLv3 read finished A
posttls-finger: server certificate verification failed for mail.mlmatthews.com[23.25.38.217]:25: certificate has expired
posttls-finger: mail.mlmatthews.com[23.25.38.217]:25: subject_CN=mail.mlmatthews.com, issuer_CN=Go Daddy Secure Certification Authority, fingerprint=84:E0:0C:BD:01:55:DF:38:7C:7E:CF:22:DC:AC:97:6A:3B:91:87:7B, pkey_fingerprint=D5:EE:32:D4:FF:7D:70:58:43:06:89:5A:85:8B:79:5B:6C:B4:3B:B4
posttls-finger: Untrusted TLS connection established to mail.mlmatthews.com[23.25.38.217]:25: TLSv1 with cipher RC4-MD5 (128/128 bits)

> Here's what I'm running:
>
> postfix 3.1-20150421
> CentOS release 6.6 (Final)
> openssl-1.0.1e-30.el6.8.x86_64
> openssl-devel-1.0.1e-30.el6.8.x86_64

I'm testing with Postfix 2.11 on NetBSD, but that should make little difference.

> Any suggestions about what is going on here? Did something recently change
> with either openssl or with MS Exchange? Many, although not all the
> servers where I see this happening are exchange servers, but I don't have
> enough data to say that's definitive.

Are you behind some sort of firewall? I'd look there first.

--
Viktor.

Tom Johnson

unread,
Apr 30, 2015, 11:28:51 PM4/30/15
to
On Apr 230, 2015, at 2:41:53 PM, Viktor Dukhovni wrote:


> And I've tried this, thinking that it could be an issue with the selected ciphers, \
> but it makes no difference:  
> smtp_tls_exclude_ciphers = 3DES DES 

The symptom with broken 3DES with Microsoft systems is not a
handshake failure.

Ok - I wasn't sure.  Thanks.



> 2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: setting up TLS \
> connection to mail.mlmatthews.com[23.25.38.217]:25  2015-04-29T22:36:51+0000 \
> server.domain.com postfix-gw/smtp[29844]: mail.mlmatthews.com[23.25.38.217]:25: TLS \
> cipher list "aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH:!3DES:!DES"  \
> 2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: \
> SSL_connect:before/connect initialization  2015-04-29T22:36:51+0000 \
> server.domain.com postfix-gw/smtp[29844]: SSL_connect:SSLv2/v3 write client hello A \
>  2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: SSL_connect \
> error to mail.mlmatthews.com[23.25.38.217]:25: lost connection  \
> 2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: 3lcZT61sm7z5wjJ: \
> to=<us...@mlmatthews.com>, relay=mail.mlmatthews.com[23.25.38.217]:25, delay=8.8, \
> delays=8.5/0.26/0.05/0, dsn=4.7.5, status=undeliverable-but-not-cached (Cannot \
> start TLS: handshake failure)  


Yes, that's what's strange.  I get the same result with posttls-finger.   

I've also tried this, which works fine:

# openssl s_client -starttls smtp -connect mail.mlmatthews.com:25
CONNECTED(00000003)
depth=3 L = ValiCert Validation Network, O = "ValiCert, Inc.", OU = ValiCert Class 2 Policy Validation Authority, CN = http://www.valicert.com/, emailAddress = in...@valicert.com
verify return:1
depth=2 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify return:1
depth=1 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certificates.godaddy.com/repository, CN = Go Daddy Secure Certification Authority, serialNumber = 07969287
verify return:1
depth=0 OU = Domain Control Validated, CN = mail.mlmatthews.com
verify error:num=10:certificate has expired
notAfter=Sep 25 19:32:03 2014 GMT
verify return:1
depth=0 OU = Domain Control Validated, CN = mail.mlmatthews.com
notAfter=Sep 25 19:32:03 2014 GMT
verify return:1
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=mail.mlmatthews.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
 2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=in...@valicert.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFWTCCBEGgAwIBAgIHK1wrGFsncjANBgkqhkiG9w0BAQUFADCByjELMAkGA1UE
BhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAY
BgNVBAoTEUdvRGFkZHkuY29tLCBJbmMuMTMwMQYDVQQLEypodHRwOi8vY2VydGlm
aWNhdGVzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkxMDAuBgNVBAMTJ0dvIERhZGR5
IFNlY3VyZSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTERMA8GA1UEBRMIMDc5Njky
ODcwHhcNMTMwOTI1MTkzMjAzWhcNMTQwOTI1MTkzMjAzWjBBMSEwHwYDVQQLExhE
b21haW4gQ29udHJvbCBWYWxpZGF0ZWQxHDAaBgNVBAMTE21haWwubWxtYXR0aGV3
cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1fkMJ8tvaMedT
ctSdrsNUNmkHcZvH3xiisdMF9WdHZKnsF49SS2y284KZicAKDQLvZQfaeiPNSLdn
ll9F4hoG22JGgs0E+FuRAbXw8yK1VjrH0j0dA526q3rtZGO8QjW//Mill5TN7PxZ
bLRGZOOMNMmQLRHiDDRLsq3nnckzRfnC03OhwuK7NE9i7xpcgeV/4wcPDAE3eENi
vCrZql8xGT5tlOQll+RGGAd329ghnr+01wK63PSfL6goeDCenVqEzhgbFnjy4K3c
pgySKyWTLp7LldzyeH+7qWWjZJ2zArX9h9/Imw4diPO+QOMMIKcsruLIxHa/+m8U
6xXL1sWbAgMBAAGjggHKMIIBxjAPBgNVHRMBAf8EBTADAQEAMB0GA1UdJQQWMBQG
CCsGAQUFBwMBBggrBgEFBQcDAjAOBgNVHQ8BAf8EBAMCBaAwMwYDVR0fBCwwKjAo
oCagJIYiaHR0cDovL2NybC5nb2RhZGR5LmNvbS9nZHMxLTk5LmNybDBTBgNVHSAE
TDBKMEgGC2CGSAGG/W0BBxcBMDkwNwYIKwYBBQUHAgEWK2h0dHA6Ly9jZXJ0aWZp
Y2F0ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeS8wgYAGCCsGAQUFBwEBBHQwcjAk
BggrBgEFBQcwAYYYaHR0cDovL29jc3AuZ29kYWRkeS5jb20vMEoGCCsGAQUFBzAC
hj5odHRwOi8vY2VydGlmaWNhdGVzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvZ2Rf
aW50ZXJtZWRpYXRlLmNydDAfBgNVHSMEGDAWgBT9rGEyk2xF1uLuhV+auud2mWjM
5zA3BgNVHREEMDAughNtYWlsLm1sbWF0dGhld3MuY29tghd3d3cubWFpbC5tbG1h
dHRoZXdzLmNvbTAdBgNVHQ4EFgQUWHj2irAGAh3dGoNbZjUKwdMdxEYwDQYJKoZI
hvcNAQEFBQADggEBAGm2AZqvn+McLK6D6NgQshxSqw9GgAIOgw2D5qkIm/yS1uol
Br8d4Bvw+nYUKS4HlwqI2krObhCzFphl9xoU8ppg7wBrOK6D6LSMfi5PNpoOm6kS
M0Vyf9huFPMNQgU53IFdNggdVKqfRjIrmt0B422IasaVaVRGAyzQvINia56yufNz
niPpdzYNJJtNnO0dKJHps7hYU4d+E2d4hTeGrnJNdqLlPw6H/flcw9YPjPqNCY2e
7/TxRy7427Hnp3C+++WAJYoZCGyIdcYbuMOB0COjzf6IAMPGsvz7gz0vkCHDqRGL
ojiaE2cyUihL67nURjtbfAVXPo36iXAJh8NRYPw=
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=mail.mlmatthews.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
---
No client certificate CA names sent
---
SSL handshake has read 4548 bytes and written 598 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
    Session-ID: 8D1D0000F63D423E90A40926E666976472A7C727295C3654ECE2E0CE2B93F23F
    Session-ID-ctx: 
    Master-Key: B2224FE9228F574FE74E035CB00716FAF1864325CC61A0CA7D707E50CB9587751F4B5D57BFC25D5A52C0D7867BC83E2C
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1430450783
    Timeout   : 300 (sec)
    Verify return code: 10 (certificate has expired)
---
250 OK


But postfix consistently gets those errors:

2015-04-29T22:36:51+0000 server.domain.com postfix-gw/smtp[29844]: 3lcZT61sm7z5wjJ: \
to=<us...@mlmatthews.com>, relay=mail.mlmatthews.com[23.25.38.217]:25, delay=8.8, \
delays=8.5/0.26/0.05/0, dsn=4.7.5, status=undeliverable-but-not-cached (Cannot \
start TLS: handshake failure)  
> Here's what I'm running: 
> 
> postfix 3.1-20150421 
> CentOS release 6.6 (Final) 
> openssl-1.0.1e-30.el6.8.x86_64 
> openssl-devel-1.0.1e-30.el6.8.x86_64 

I'm testing with Postfix 2.11 on NetBSD, but that should make little difference.

> Any suggestions about what is going on here?  Did something recently change
> with either openssl or with MS Exchange?  Many, although not all the
> servers where I see this happening are exchange servers, but I don't have
> enough data to say that's definitive.

Are you behind some sort of firewall?  I'd look there first.


Nope.  No firewall.  Nothing that should be touching any TLS traffic.

Any other ideas?  I'm grasping at straws here.

Tom


Viktor Dukhovni

unread,
May 1, 2015, 12:51:31 AM5/1/15
to
On Thu, Apr 30, 2015 at 08:28:21PM -0700, Tom Johnson wrote:

> > That aside, even with the "wrong" MX host, I still get successful
> > connections. Perhaps you're behind some sort of firewall that
> > proxies TLS and disconnects when it does not like the peer certificate:
> >
> > $ posttls-finger -c -Ldebug "[mail.mlmatthews.com]"
> > posttls-finger: Untrusted TLS connection established to \
> > mail.mlmatthews.com[23.25.38.217]:25: TLSv1 with cipher RC4-MD5 (128/128 bits)

Notice I that with posttls-finger I'm connecting with "RC4-MD5",
when I disable RC4, I get connection problems.

> Yes, that's what's strange. I get the same result with posttls-finger.

Same, as in success with RC4? Have you disabled RC4? Or otherwise
changed the cipher-suite or procotol controls? Post the output of:

$ postconf -n | grep '^smtp_tls'

> I've also tried this, which works fine:
>
> # openssl s_client -starttls smtp -connect mail.mlmatthews.com:25
> Cipher : RC4-SHA

RC4-SHA this time.

> But postfix consistently gets those errors:

Postfix offers more ciphers when the security level is "may". When
I explicitly set the "posttls-finger" security level to "may". I
see your symptoms:

$ posttls-finger -c -lmay -o 'tls_medium_cipherlist=ALL:+RC4:@STRENGTH' -Ldebug "[mail.mlmatthews.com]"
posttls-finger: initializing the client-side TLS engine
posttls-finger: setting up TLS connection to mail.mlmatthews.com[23.25.38.217]:25
posttls-finger: mail.mlmatthews.com[23.25.38.217]:25: TLS cipher list "ALL:+RC4:@STRENGTH:!eNULL"
posttls-finger: SSL_connect:before/connect initialization
posttls-finger: SSL_connect:SSLv2/v3 write client hello A
posttls-finger: SSL_connect error to mail.mlmatthews.com[23.25.38.217]:25: lost connection

This is indeed an Exchange 2003 server which only supports RC4 and
a broken 3DES, but you must have a sufficiently recent OpenSSL
version where even 3DES (re-rated at 112-bit) is not in the first
64 cipherlist elements, and so the handshake fails early.

For this server, you need a more "compact" cipherlist as a work-around.

smtp_tls_exclude_ciphers =
#
# Disable MD5, DSA, SRP and PSK, and the "exotic" fixed DH cipher suites.
#
MD5, SRP, PSK, aDSS, kECDH, kDH,
#
# Disable 256-bit ciphers, 128-bit is for now quite strong enough.
# Also disable the largely unused SEED, IDEA, RC2, RC5, ...
# leaving just AES128, CAMELLIA128, RC4 and 3DES.
#
AES256, CAMELLIA256, SEED, IDEA, RC2, RC5

This is does not noticeably impact the security of connections to
other sites, but enables communication with Exchange 2003 servers
(it is rather sad that folks are still using these), without having
to configure a separate policy for each such site.

--
Viktor.

Viktor Dukhovni

unread,
May 1, 2015, 3:02:28 AM5/1/15
to
On Fri, May 01, 2015 at 04:51:03AM +0000, Viktor Dukhovni wrote:

> For this server, you need a more "compact" cipherlist as a work-around.
>
> smtp_tls_exclude_ciphers =
> #
> # Disable MD5, DSA, SRP and PSK, and the "exotic" fixed DH cipher suites.
> #
> MD5, SRP, PSK, aDSS, kECDH, kDH,
> #
> # Disable 256-bit ciphers, 128-bit is for now quite strong enough.
> # Also disable the largely unused SEED, IDEA, RC2, RC5, ...
> # leaving just AES128, CAMELLIA128, RC4 and 3DES.
> #
> AES256, CAMELLIA256, SEED, IDEA, RC2, RC5

Following up, we don't (as yet) even need to disable AES256 or
CAMELLIA256. Until ChaCha20 and other new cipher-suites show up,
the following still leaves RC4 in the top 64, and does not disable
anything useful in practice:

smtp_tls_exclude_ciphers =
#
# Disable MD5, DSA, SRP and PSK, and the "exotic" fixed DH cipher suites.
#
MD5, SRP, PSK, aDSS, kECDH, kDH,
#
# Disable 256-bit ciphers, 128-bit is for now quite strong enough.
# Also disable the largely unused SEED, IDEA, RC2, RC5, ...
# leaving just AES128, CAMELLIA128, RC4 and 3DES.
#
SEED, IDEA, RC2, RC5

This even with OpenSSL "master", which has more cipher-suites than older releases:

$ openssl ciphers -v 'aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH:!kDH:!kECDH:!aDSS:!PSK:!SRP:!MD5:!SEED:!IDEA:!RC2:!RC5' | egrep -n 'RC4-SHA|DES-CBC3-SHA'
49:AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1
50:ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1
51:ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1
52:RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
53:AECDH-DES-CBC3-SHA SSLv3 Kx=ECDH Au=None Enc=3DES(168) Mac=SHA1
54:ADH-DES-CBC3-SHA SSLv3 Kx=DH Au=None Enc=3DES(168) Mac=SHA1
55:ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1
56:ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
57:DHE-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
58:DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1

So the above setting makes a rather sensible default exclusion
list, while we're still plagued with coddling Exchange 2003 servers.

--
Viktor.

Tom Johnson

unread,
May 1, 2015, 1:16:59 PM5/1/15
to
Viktor-

Thank you! This has indeed solved the problem. We will nudge these people to upgrade their mail server software, but I won't be holding my breath.

Tom

0 new messages