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=<u...@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 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) > 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 = i...@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=i...@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=<u...@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
