Re: Verisign Problem with smtp tls
Viktor Dukhovni wrote: On Sat, Dec 28, 2013 at 05:56:41PM +0100, Michael Str?der wrote: http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html#rfc.section.1.2 This is why I am working to implement and standardize SMTP with DANE TLS. DANE itself does not help. It just shifts the trust anchor problem. DNSSEC secures the MX lookups. For the record: While indeed SMTP with DANE TLS relies on DNSSEC to secure the MX lookup, it also critically relies on DANE for two additional pieces of information: - Downgrade resistant STARTTLS support signalling. Without this MITM attackers simply suppress STARTTLS and the sender proceeds in cleartext. This entirely depends on the fallback configuration of the sender. Proceeding with clear-text communication also happens with DANE/TLSA if the sender is configured to send the message in any case. - TLS support signalling is combined with signalling that the peer can be authenticated and all the key material needed to perform authentication. Nothing really new. The key material has to be authenticated anyway by validating against some trust anchor. Sending MTAs run unattended with no user to click OK. They must not routinely fail due to Goedel's theorem for CA bundles (any set of trusted CAs is either insecure or incomplete). - Since it is already agreed that DNSSEC must be trusted to protect the MX records, eliminating the CA bundle from the picture reduces risk AND improves reliability to the point where peer authentication with SMTP becomes usable. It is NOT usable with CA bundles. Blaming CA bundles is somewhat right. But just using another data format/transport is not a solution to the trust problem. If DANE/TLSA gets ever widely adopted you will see the very same discussions about how to reliably establish trust. Time will tell. And in the light of recent news I'd rather vote against having a U.S. centric DNS trusted root key. but I am not obligated to provide a comprehensive justification in response to every trollish one liner, the above will have to do. Uuuhuuh. Just writing lengthy blog articles is not helpful either to analyse trust problems not to speak of inventing a real solution. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature
Re: Verisign Problem with smtp tls
On Sat, Jan 04, 2014 at 07:58:20PM +0100, Michael Str?der wrote: While indeed SMTP with DANE TLS relies on DNSSEC to secure the MX lookup, it also critically relies on DANE for two additional pieces of information: - Downgrade resistant STARTTLS support signalling. Without this MITM attackers simply suppress STARTTLS and the sender proceeds in cleartext. This entirely depends on the fallback configuration of the sender. Proceeding with clear-text communication also happens with DANE/TLSA if the sender is configured to send the message in any case. I'll keep this short, avoiding the need for EDNS0 replies. You appear to still not have read (at least section 2, but ideally the whole draft): http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html#rfc.section.2 Until you have, and unless you have detailed substantive comments, this branch of the thread is mere pontification. DANE for SMTP comes with a *required* fallback model. If you have substantive comments, the DANE WG list is likely a better forum. A substantive comment that argues that DANE adds nothing new to SMTP would begin by explaining in detail how SMTP to MX TLS security is possible without DNS data integrity (thus making it possible to not trust the root zone signature or any additional trust-anchors for critical peer domains). -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign Problem with smtp tls
On Sat, Jan 4, 2014 at 2:42 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: ... A substantive comment that argues that DANE adds nothing new to SMTP would begin by explaining in detail how SMTP to MX TLS security is possible without DNS data integrity (thus making it possible to not trust the root zone signature or any additional trust-anchors for critical peer domains). Bingo! DNS cannot be trusted. Pushing keys and configuration into DNS is just moving the key distribution problem around. Consider: 10 of the 13 dns roots are controlled by the US. You probably can't even form a quorum and get a good answer with colluding enemies. And good luck getting an authoritative response from a non-US server. Practice diversification techniques like continuity and perspectives. Limit or remove trust as its nearly meaningless in the context of security. (Some say trust is what is used when there's no security controls to place). Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign Problem with smtp tls
On Sat, Jan 04, 2014 at 03:11:16PM -0500, Jeffrey Walton wrote: ... A substantive comment that argues that DANE adds nothing new to SMTP would begin by explaining in detail how SMTP to MX TLS security is possible without DNS data integrity (thus making it possible to not trust the root zone signature or any additional trust-anchors for critical peer domains). Bingo! DNS cannot be trusted. Pushing keys and configuration into DNS is just moving the key distribution problem around. If anyone else thinks that DANE for SMTP is obviously wrong, do us all a favour and carefully read the draft, then give it some thought. Then consider how you would practically improve SMTP transport security. Once you've read the draft, explain how to secure SMTP to MX without relying on DNSSEC. Then criticize trusting DNSSEC if you think it still makes sense. I will not respond to further critiques pointing out obvious problems with DANE for SMTP. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign Problem with smtp tls
Viktor Dukhovni wrote: With SMTP, PKIX certificate verification is pointless without explicit per-destination configuration: http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html#rfc.section.1.2 This is why I am working to implement and standardize SMTP with DANE TLS. DANE itself does not help. It just shifts the trust anchor problem. DNSSEC secures the MX lookups. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature
Re: Verisign Problem with smtp tls
On Sat, Dec 28, 2013 at 05:56:41PM +0100, Michael Str?der wrote: http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html#rfc.section.1.2 This is why I am working to implement and standardize SMTP with DANE TLS. DANE itself does not help. It just shifts the trust anchor problem. DNSSEC secures the MX lookups. For the record: While indeed SMTP with DANE TLS relies on DNSSEC to secure the MX lookup, it also critically relies on DANE for two additional pieces of information: - Downgrade resistant STARTTLS support signalling. Without this MITM attackers simply suppress STARTTLS and the sender proceeds in cleartext. - TLS support signalling is combined with signalling that the peer can be authenticated and all the key material needed to perform authentication. Sending MTAs run unattended with no user to click OK. They must not routinely fail due to Goedel's theorem for CA bundles (any set of trusted CAs is either insecure or incomplete). - Since it is already agreed that DNSSEC must be trusted to protect the MX records, eliminating the CA bundle from the picture reduces risk AND improves reliability to the point where peer authentication with SMTP becomes usable. It is NOT usable with CA bundles. There are more good reasons why DANE is required as part secure SMTP TLS, but I am not obligated to provide a comprehensive justification in response to every trollish one liner, the above will have to do. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign Problem with smtp tls
On 12/27/2013 03:39 PM, Viktor Dukhovni wrote: There's your problem! This server (likely Exchange 2003) has a broken implementation of 3DES CBC padding (search Postfix users archives for my posts on the subject), and your cipher list is either long enough to cause it to not see RC4-SHA and RC4-MD5 or you've disabled RC4 (directly, or by only enabling HIGH grade ciphers). Exchange 2003 servers can't do better than RC4-SHA. Thanks very much for your help Viktor. I was able to specify the RC4-MD5 cipher and it works. I am using Qmail with the John Simpson patch set by the way. There is a control file (tlsclientcipher) which John had not documented but is there. After some discussion with another qmail user, he told me about it and sure enough it works. Any suggestions for what ciphers to put in the list besides RC4-MD5? -- Bob Wooldridge Blog: http://kc0dxf.net/blog
Re: Verisign Problem with smtp tls
|SMTP TLS, but I am not obligated to provide a comprehensive |justification in response to every trollish one liner, the above Luckily there is the UDPish EDNS0 extension from RFC 2671 as in The default is 1280 (RFC 2671, 4.5.1.). The minimum is 1024 (RFC 3226, 3.; note: not 1220!). The maximum is 65000. Have a nice weekend --steffen ---BeginMessage--- On Sat, Dec 28, 2013 at 05:56:41PM +0100, Michael Str?der wrote: http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html#rfc.section.1.2 This is why I am working to implement and standardize SMTP with DANE TLS. DANE itself does not help. It just shifts the trust anchor problem. DNSSEC secures the MX lookups. For the record: While indeed SMTP with DANE TLS relies on DNSSEC to secure the MX lookup, it also critically relies on DANE for two additional pieces of information: - Downgrade resistant STARTTLS support signalling. Without this MITM attackers simply suppress STARTTLS and the sender proceeds in cleartext. - TLS support signalling is combined with signalling that the peer can be authenticated and all the key material needed to perform authentication. Sending MTAs run unattended with no user to click OK. They must not routinely fail due to Goedel's theorem for CA bundles (any set of trusted CAs is either insecure or incomplete). - Since it is already agreed that DNSSEC must be trusted to protect the MX records, eliminating the CA bundle from the picture reduces risk AND improves reliability to the point where peer authentication with SMTP becomes usable. It is NOT usable with CA bundles. There are more good reasons why DANE is required as part secure SMTP TLS, but I am not obligated to provide a comprehensive justification in response to every trollish one liner, the above will have to do. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org ---End Message---
Re: Verisign Problem with smtp tls
On Sat, Dec 28, 2013 at 12:23:21PM -0600, Bobber wrote: Thanks very much for your help Viktor. I was able to specify the RC4-MD5 cipher and it works. I am using Qmail with the John Simpson patch set by the way. There is a control file (tlsclientcipher) which John had not documented but is there. After some discussion with another qmail user, he told me about it and sure enough it works. Does this modify the ciphers used for all connections, or just for the server in question? Any suggestions for what ciphers to put in the list besides RC4-MD5? If you read my previous responses on this thread, you'll notice I recommended: aRSA+AES128+kEECDH:aRSA+AES128+kEDH:aRSA+AES128+kRSA:RC4-SHA:@STRENGTH as a compact OpenSSL cipherlist that inter-operates with Exchange and yet yields AES with forward-secrecy whenever possible. If you're not authenticating the SMTP server (almost nobody is), you can allow both anonymous and ECDSA ciphers without bloating the list too much: aNULL:-aNULL:AES128+kEECDH:AES128+kEDH:AES128+kRSA:RC4-SHA this prefers aNULL, since you don't check the certs anyway. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign Problem with smtp tls
On 12/28/2013 12:51 PM, Viktor Dukhovni wrote: Does this modify the ciphers used for all connections, or just for the server in question? All connections. Any suggestions for what ciphers to put in the list besides RC4-MD5? If you read my previous responses on this thread, you'll notice I recommended: aRSA+AES128+kEECDH:aRSA+AES128+kEDH:aRSA+AES128+kRSA:RC4-SHA:@STRENGTH as a compact OpenSSL cipherlist that inter-operates with Exchange and yet yields AES with forward-secrecy whenever possible. If you're not authenticating the SMTP server (almost nobody is), you can allow both anonymous and ECDSA ciphers without bloating the list too much: aNULL:-aNULL:AES128+kEECDH:AES128+kEDH:AES128+kRSA:RC4-SHA this prefers aNULL, since you don't check the certs anyway. Good point, thanks for these suggestions. I will try both and see how it goes. -- Bob Wooldridge Blog: http://kc0dxf.net/blog
Re: Verisign Problem with smtp tls
On Sat, Dec 28, 2013 at 12:58:58PM -0600, Bobber wrote: Does this modify the ciphers used for all connections, or just for the server in question? All connections. In that case I would go for the second cipherlist, though still compact, it is a superset of the first and will interoperate with more peer systems. aNULL:-aNULL:AES128+kEECDH:AES128+kEDH:AES128+kRSA:RC4-SHA this prefers aNULL, since you don't check the certs anyway. Assuming of course that qmail can handle aNULL ciphers. If not, use: !aNULL:AES128+kEECDH:AES128+kEDH:AES128+kRSA:RC4-SHA which is 16 ciphers in total and includes RC4-SHA as a last resort. I am not aware of any SMTP servers that support TLS, but offer neither AES128 nor RC4-SHA. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Verisign Problem with smtp tls
I recently upgraded my companies' mail server to 64 Debian Wheezy. I am using the Openssl package which is version 1.0.1e-2. I am having problems when trying to send a message to one of our business partners. The SMTP session appears to shut down and it appears that my server is rejecting their certificate. Here is the openssl command I am giving to diagnose the problem and it's output. Can anyone suggest a solution? It appears to me that I may be lacking an intermediary certificate. How do I fix this if this is the case? openssl s_client -CApath /etc/ssl/certs/ -crlf -starttls smtp -connect mail.thelawrencegroup.com:25 CONNECTED(0003) depth=1 C = US, O = VeriSign, Inc., OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)05, CN = VeriSign Class 3 Secure Server CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=US/ST=Missouri/L=Saint Louis/O=The Lawrence Group/OU=IT/OU=Terms of use at www.verisign.com/rpa (c)05/CN=mail.thelawrencegroup.com i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)05/CN=VeriSign Class 3 Secure Server CA 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)05/CN=VeriSign Class 3 Secure Server CA i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority --- Server certificate -BEGIN CERTIFICATE- MIIFRTCCBC2gAwIBAgIQN9yAwL+UVDUkrxwUKIvOGTANBgkqhkiG9w0BAQUFADCB sDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEqMCgGA1UEAxMh VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBMB4XDTA1MTIxNTAwMDAw MFoXDTA4MTIyMTIzNTk1OVowgbkxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhNaXNz b3VyaTEUMBIGA1UEBxQLU2FpbnQgTG91aXMxGzAZBgNVBAoUElRoZSBMYXdyZW5j ZSBHcm91cDELMAkGA1UECxQCSVQxMzAxBgNVBAsUKlRlcm1zIG9mIHVzZSBhdCB3 d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEiMCAGA1UEAxQZbWFpbC50aGVsYXdy ZW5jZWdyb3VwLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAsHXWtCB1 OyKpgnuBF+Yis9msWrTOboMO50vYVPndtW1ILmY7hGy5glCLV6W2hu0ReUfTJHNd jV4m4a9pGu8nNEYajQALQuMB/9FwNmV24ZksQ/GkFyGKywvcsDNUrP1bsX+DmISW Jzc5sNRkw9JO7tuZ9Hs0KRSmxCS5Ozm/SGcCAwEAAaOCAdIwggHOMAkGA1UdEwQC MAAwCwYDVR0PBAQDAgWgMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9TVlJTZWN1 cmUtY3JsLnZlcmlzaWduLmNvbS9TVlJTZWN1cmUyMDA1LmNybDBEBgNVHSAEPTA7 MDkGC2CGSAGG+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMB8GA1Ud IwQYMBaAFG/sr6DdiqTv9SoQZy0/VYK81+8lMHkGCCsGAQUFBwEBBG0wazAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AudmVyaXNpZ24uY29tMEMGCCsGAQUFBzAChjdo dHRwOi8vU1ZSU2VjdXJlLWFpYS52ZXJpc2lnbi5jb20vU1ZSU2VjdXJlMjAwNS1h aWEuY2VyMG0GCCsGAQUFBwEMBGEwX6FdoFswWTBXMFUWCWltYWdlL2dpZjAhMB8w BwYFKw4DAhoEFI/l0xqGrI2Oa8PPgGrUSBgsexkuMCUWI2h0dHA6Ly9sb2dvLnZl cmlzaWduLmNvbS92c2xvZ28uZ2lmMA0GCSqGSIb3DQEBBQUAA4IBAQBAdNBhhrjm oVuYe5z7aHCBWB6Y3bl0UwIeuNNRCjwtbIBcFO1UPchr8NBuX8DI4Bw/Ek3PhQQL b/3IUFFn7uXfs8jO3R3NJUzMo1jDajhzBV9dE0aOuvYzuHdqws/rUm0uOUAmR1ob 50rZ/kTcCGemrvrzwf/bxLP2fbcAlaqHhvyxbsUPrX4cAc1DdqPTdMUxKSCYSBSq WiamaopkD5I5dv/116qF1VVyGtKYduZ+7cC/EPwvnFYJa8P/LhKbnA2xkVMf2pHE OJOSu//PAPLg/bOxHCh8Yurgyxgv5Dn1UtgTep5RSmrYac+EV3akkOuwzBPl2h8c dbImJ5QeqOFu -END CERTIFICATE- subject=/C=US/ST=Missouri/L=Saint Louis/O=The Lawrence Group/OU=IT/OU=Terms of use at www.verisign.com/rpa (c)05/CN=mail.thelawrencegroup.com issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)05/CN=VeriSign Class 3 Secure Server CA --- No client certificate CA names sent --- SSL handshake has read 3180 bytes and written 545 bytes --- New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Server public key is 1024 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher: DES-CBC3-SHA Session-ID: 4B17CCB1A39FEAE5E1682BE3F44E70362A2247CD6F6F9E0195D64323602C Session-ID-ctx: Master-Key: 4F89ADCC6069F833996E892E09D270497A36FAF8B26C8F246130D35FC431BA56C11EC2793ABFDECCC6342B583C311A92 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1388170612 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- 250 OK -- Bob Wooldridge bob...@kc0dxf.net Blog: http://kc0dxf.net/blog/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign Problem with smtp tls
On Fri, Dec 27, 2013 at 12:59:11PM -0600, Bobber wrote: I recently upgraded my companies' mail server to 64 Debian Wheezy. I am using the Openssl package which is version 1.0.1e-2. I am having problems when trying to send a message to one of our business partners. The SMTP session appears to shut down and it appears that my server is rejecting their certificate. Here is the openssl command I am giving to diagnose the problem and it's output. Can anyone suggest a solution? It appears to me that I may be lacking an intermediary certificate. How do I fix this if this is the case? openssl s_client -CApath /etc/ssl/certs/ -crlf -starttls smtp -connect mail.thelawrencegroup.com:25 The posttls-finger(1) utility, included with Postfix 2.11 snapshot source code, does a much better job of mail server TLS diagnostics. Their certificate is expired. Your MTA really ought to log the error reason. Consider a better MTA! :-) $ posttls-finger [mail.thelawrencegroup.com] posttls-finger: Connected to mail.thelawrencegroup.com[206.16.127.29]:25 posttls-finger: 220 mail.thelawrencegroup.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 ready at Fri, 27 Dec 2013 13:13:52 -0600 posttls-finger: EHLO amnesiac.example posttls-finger: 250-mail.thelawrencegroup.com Hello [192.0.2.1] posttls-finger: 250-TURN posttls-finger: 250-SIZE posttls-finger: 250-ETRN posttls-finger: 250-PIPELINING posttls-finger: 250-DSN posttls-finger: 250-ENHANCEDSTATUSCODES posttls-finger: 250-8bitmime posttls-finger: 250-BINARYMIME posttls-finger: 250-CHUNKING posttls-finger: 250-VRFY posttls-finger: 250-TLS posttls-finger: 250-STARTTLS posttls-finger: 250-X-EXPS GSSAPI NTLM LOGIN posttls-finger: 250-X-EXPS=LOGIN posttls-finger: 250-AUTH GSSAPI NTLM LOGIN posttls-finger: 250-AUTH=LOGIN posttls-finger: 250-X-LINK2STATE posttls-finger: 250-XEXCH50 posttls-finger: 250 OK posttls-finger: STARTTLS posttls-finger: 220 2.0.0 SMTP server ready posttls-finger: mail.thelawrencegroup.com[206.16.127.29]:25 Matched CommonName mail.thelawrencegroup.com posttls-finger: server certificate verification failed for mail.thelawrencegroup.com[206.16.127.29]:25: certificate has expired posttls-finger: mail.thelawrencegroup.com[206.16.127.29]:25: subject_CN=mail.thelawrencegroup.com, issuer_CN=VeriSign Class 3 Secure Server CA, fingerprint=58:83:F8:69:1B:45:53:BA:21:36:19:01:B4:C9:7A:A9:54:62:79:57, pkey_fingerprint=84:43:0D:55:D9:F8:D3:C5:59:D3:9D:33:42:B3:2E:A4:9B:FE:96:4D posttls-finger: Untrusted TLS connection established to mail.thelawrencegroup.com[206.16.127.29]:25: unknown with cipher RC4-MD5 (128/128 bits) posttls-finger: EHLO amnesiac.example posttls-finger: 250-mail.thelawrencegroup.com Hello [192.0.2.1] posttls-finger: 250-TURN posttls-finger: 250-SIZE posttls-finger: 250-ETRN posttls-finger: 250-PIPELINING posttls-finger: 250-DSN posttls-finger: 250-ENHANCEDSTATUSCODES posttls-finger: 250-8bitmime posttls-finger: 250-BINARYMIME posttls-finger: 250-CHUNKING posttls-finger: 250-VRFY posttls-finger: 250-X-EXPS GSSAPI NTLM LOGIN posttls-finger: 250-X-EXPS=LOGIN posttls-finger: 250-AUTH GSSAPI NTLM LOGIN posttls-finger: 250-AUTH=LOGIN posttls-finger: 250-X-LINK2STATE posttls-finger: 250-XEXCH50 posttls-finger: 250 OK posttls-finger: QUIT posttls-finger: 221 2.0.0 mail.thelawrencegroup.com Service closing transmission channel -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign Problem with smtp tls
On 12/27/2013 01:29 PM, Viktor Dukhovni wrote: On Fri, Dec 27, 2013 at 12:59:11PM -0600, Bobber wrote: I recently upgraded my companies' mail server to 64 Debian Wheezy. I am using the Openssl package which is version 1.0.1e-2. I am having problems when trying to send a message to one of our business partners. The SMTP session appears to shut down and it appears that my server is rejecting their certificate. Here is the openssl command I am giving to diagnose the problem and it's output. Can anyone suggest a solution? It appears to me that I may be lacking an intermediary certificate. How do I fix this if this is the case? openssl s_client -CApath /etc/ssl/certs/ -crlf -starttls smtp -connect mail.thelawrencegroup.com:25 The posttls-finger(1) utility, included with Postfix 2.11 snapshot source code, does a much better job of mail server TLS diagnostics. Their certificate is expired. Your MTA really ought to log the error reason. Consider a better MTA! :-) I don't see anywhere that it says expired other than this utility. How can I verify that it is really expired? These guys do business with lots of other people but have not noticed anything except with us. The openssl error code 20 indicates an improper intermediate CA from what I can find. Also using this site indicates no problem: http://www.checktls.com/testreceiver.html Is there another way to verify the expiration? $ posttls-finger [mail.thelawrencegroup.com] posttls-finger: Connected to mail.thelawrencegroup.com[206.16.127.29]:25 posttls-finger: 220 mail.thelawrencegroup.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 ready at Fri, 27 Dec 2013 13:13:52 -0600 posttls-finger: EHLO amnesiac.example posttls-finger: 250-mail.thelawrencegroup.com Hello [192.0.2.1] posttls-finger: 250-TURN posttls-finger: 250-SIZE posttls-finger: 250-ETRN posttls-finger: 250-PIPELINING posttls-finger: 250-DSN posttls-finger: 250-ENHANCEDSTATUSCODES posttls-finger: 250-8bitmime posttls-finger: 250-BINARYMIME posttls-finger: 250-CHUNKING posttls-finger: 250-VRFY posttls-finger: 250-TLS posttls-finger: 250-STARTTLS posttls-finger: 250-X-EXPS GSSAPI NTLM LOGIN posttls-finger: 250-X-EXPS=LOGIN posttls-finger: 250-AUTH GSSAPI NTLM LOGIN posttls-finger: 250-AUTH=LOGIN posttls-finger: 250-X-LINK2STATE posttls-finger: 250-XEXCH50 posttls-finger: 250 OK posttls-finger: STARTTLS posttls-finger: 220 2.0.0 SMTP server ready posttls-finger: mail.thelawrencegroup.com[206.16.127.29]:25 Matched CommonName mail.thelawrencegroup.com posttls-finger: server certificate verification failed for mail.thelawrencegroup.com[206.16.127.29]:25: certificate has expired posttls-finger: mail.thelawrencegroup.com[206.16.127.29]:25: subject_CN=mail.thelawrencegroup.com, issuer_CN=VeriSign Class 3 Secure Server CA, fingerprint=58:83:F8:69:1B:45:53:BA:21:36:19:01:B4:C9:7A:A9:54:62:79:57, pkey_fingerprint=84:43:0D:55:D9:F8:D3:C5:59:D3:9D:33:42:B3:2E:A4:9B:FE:96:4D posttls-finger: Untrusted TLS connection established to mail.thelawrencegroup.com[206.16.127.29]:25: unknown with cipher RC4-MD5 (128/128 bits) posttls-finger: EHLO amnesiac.example posttls-finger: 250-mail.thelawrencegroup.com Hello [192.0.2.1] posttls-finger: 250-TURN posttls-finger: 250-SIZE posttls-finger: 250-ETRN posttls-finger: 250-PIPELINING posttls-finger: 250-DSN posttls-finger: 250-ENHANCEDSTATUSCODES posttls-finger: 250-8bitmime posttls-finger: 250-BINARYMIME posttls-finger: 250-CHUNKING posttls-finger: 250-VRFY posttls-finger: 250-X-EXPS GSSAPI NTLM LOGIN posttls-finger: 250-X-EXPS=LOGIN posttls-finger: 250-AUTH GSSAPI NTLM LOGIN posttls-finger: 250-AUTH=LOGIN posttls-finger: 250-X-LINK2STATE posttls-finger: 250-XEXCH50 posttls-finger: 250 OK posttls-finger: QUIT posttls-finger: 221 2.0.0 mail.thelawrencegroup.com Service closing transmission channel -- Bob Wooldridge bob...@kc0dxf.net Blog: http://kc0dxf.net/blog/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign Problem with smtp tls
i am not following this in any detail, but if you look at the certificate you included in your original email it expired in 2008. just look at it with openssl -text -in some file sorry if i'm jumping into something i've misunderstood, andrew On Fri, Dec 27, 2013 at 01:47:47PM -0600, Bobber wrote: On 12/27/2013 01:29 PM, Viktor Dukhovni wrote: On Fri, Dec 27, 2013 at 12:59:11PM -0600, Bobber wrote: I recently upgraded my companies' mail server to 64 Debian Wheezy. I am using the Openssl package which is version 1.0.1e-2. I am having problems when trying to send a message to one of our business partners. The SMTP session appears to shut down and it appears that my server is rejecting their certificate. Here is the openssl command I am giving to diagnose the problem and it's output. Can anyone suggest a solution? It appears to me that I may be lacking an intermediary certificate. How do I fix this if this is the case? openssl s_client -CApath /etc/ssl/certs/ -crlf -starttls smtp -connect mail.thelawrencegroup.com:25 The posttls-finger(1) utility, included with Postfix 2.11 snapshot source code, does a much better job of mail server TLS diagnostics. Their certificate is expired. Your MTA really ought to log the error reason. Consider a better MTA! :-) I don't see anywhere that it says expired other than this utility. How can I verify that it is really expired? These guys do business with lots of other people but have not noticed anything except with us. The openssl error code 20 indicates an improper intermediate CA from what I can find. Also using this site indicates no problem: http://www.checktls.com/testreceiver.html Is there another way to verify the expiration? $ posttls-finger [mail.thelawrencegroup.com] posttls-finger: Connected to mail.thelawrencegroup.com[206.16.127.29]:25 posttls-finger: 220 mail.thelawrencegroup.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 ready at Fri, 27 Dec 2013 13:13:52 -0600 posttls-finger: EHLO amnesiac.example posttls-finger: 250-mail.thelawrencegroup.com Hello [192.0.2.1] posttls-finger: 250-TURN posttls-finger: 250-SIZE posttls-finger: 250-ETRN posttls-finger: 250-PIPELINING posttls-finger: 250-DSN posttls-finger: 250-ENHANCEDSTATUSCODES posttls-finger: 250-8bitmime posttls-finger: 250-BINARYMIME posttls-finger: 250-CHUNKING posttls-finger: 250-VRFY posttls-finger: 250-TLS posttls-finger: 250-STARTTLS posttls-finger: 250-X-EXPS GSSAPI NTLM LOGIN posttls-finger: 250-X-EXPS=LOGIN posttls-finger: 250-AUTH GSSAPI NTLM LOGIN posttls-finger: 250-AUTH=LOGIN posttls-finger: 250-X-LINK2STATE posttls-finger: 250-XEXCH50 posttls-finger: 250 OK posttls-finger: STARTTLS posttls-finger: 220 2.0.0 SMTP server ready posttls-finger: mail.thelawrencegroup.com[206.16.127.29]:25 Matched CommonName mail.thelawrencegroup.com posttls-finger: server certificate verification failed for mail.thelawrencegroup.com[206.16.127.29]:25: certificate has expired posttls-finger: mail.thelawrencegroup.com[206.16.127.29]:25: subject_CN=mail.thelawrencegroup.com, issuer_CN=VeriSign Class 3 Secure Server CA, fingerprint=58:83:F8:69:1B:45:53:BA:21:36:19:01:B4:C9:7A:A9:54:62:79:57, pkey_fingerprint=84:43:0D:55:D9:F8:D3:C5:59:D3:9D:33:42:B3:2E:A4:9B:FE:96:4D posttls-finger: Untrusted TLS connection established to mail.thelawrencegroup.com[206.16.127.29]:25: unknown with cipher RC4-MD5 (128/128 bits) posttls-finger: EHLO amnesiac.example posttls-finger: 250-mail.thelawrencegroup.com Hello [192.0.2.1] posttls-finger: 250-TURN posttls-finger: 250-SIZE posttls-finger: 250-ETRN posttls-finger: 250-PIPELINING posttls-finger: 250-DSN posttls-finger: 250-ENHANCEDSTATUSCODES posttls-finger: 250-8bitmime posttls-finger: 250-BINARYMIME posttls-finger: 250-CHUNKING posttls-finger: 250-VRFY posttls-finger: 250-X-EXPS GSSAPI NTLM LOGIN posttls-finger: 250-X-EXPS=LOGIN posttls-finger: 250-AUTH GSSAPI NTLM LOGIN posttls-finger: 250-AUTH=LOGIN posttls-finger: 250-X-LINK2STATE posttls-finger: 250-XEXCH50 posttls-finger: 250 OK posttls-finger: QUIT posttls-finger: 221 2.0.0 mail.thelawrencegroup.com Service closing transmission channel -- Bob Wooldridge bob...@kc0dxf.net Blog: http://kc0dxf.net/blog/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project
Re: Verisign Problem with smtp tls
On 12/27/2013 01:53 PM, andrew cooke wrote: i am not following this in any detail, but if you look at the certificate you included in your original email it expired in 2008. just look at it with openssl -text -in some file Ok, that's good. Thanks. sorry if i'm jumping into something i've misunderstood, andrew -- Bob Wooldridge bob...@kc0dxf.net Blog: http://kc0dxf.net/blog/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign Problem with smtp tls
Hey there...
On 2013-12-27, at 2:47 PM, Bobber wrote:
On 12/27/2013 01:29 PM, Viktor Dukhovni wrote:
On Fri, Dec 27, 2013 at 12:59:11PM -0600, Bobber wrote:
I recently upgraded my companies' mail server to 64 Debian Wheezy. I
am using the Openssl package which is version 1.0.1e-2.
I am having problems when trying to send a message to one of our
business partners. The SMTP session appears to shut down and it
appears that my server is rejecting their certificate.
Here is the openssl command I am giving to diagnose the problem and
it's output. Can anyone suggest a solution? It appears to me that
I may be lacking an intermediary certificate. How do I fix this if
this is the case?
openssl s_client -CApath /etc/ssl/certs/ -crlf -starttls smtp
-connect mail.thelawrencegroup.com:25
The posttls-finger(1) utility, included with Postfix 2.11 snapshot
source code, does a much better job of mail server TLS diagnostics.
Their certificate is expired. Your MTA really ought to log the
error reason. Consider a better MTA! :-)
I don't see anywhere that it says expired other than this utility. How can I
verify that it is really expired? These guys do business with lots of other
people but have not noticed anything except with us. The openssl error code
20 indicates an improper intermediate CA from what I can find. Also using
this site indicates no problem: http://www.checktls.com/testreceiver.html
Is there another way to verify the expiration?
Grabbing the certificate using the command line that you posted:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
37:dc:80:c0:bf:94:54:35:24:af:1c:14:28:8b:ce:19
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of
use at https://www.verisign.com/rpa (c)05, CN=VeriSign Class 3 Secure Server CA
Validity
Not Before: Dec 15 00:00:00 2005 GMT
Not After : Dec 21 23:59:59 2008 GMT
Subject: C=US, ST=Missouri, L=Saint Louis, O=The Lawrence Group, OU=IT,
OU=Terms of use at www.verisign.com/rpa (c)05, CN=mail.thelawrencegroup.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:b0:75:d6:b4:20:75:3b:22:a9:82:7b:81:17:e6:
22:b3:d9:ac:5a:b4:ce:6e:83:0e:e7:4b:d8:54:f9:
dd:b5:6d:48:2e:66:3b:84:6c:b9:82:50:8b:57:a5:
b6:86:ed:11:79:47:d3:24:73:5d:8d:5e:26:e1:af:
69:1a:ef:27:34:46:1a:8d:00:0b:42:e3:01:ff:d1:
70:36:65:76:e1:99:2c:43:f1:a4:17:21:8a:cb:0b:
dc:b0:33:54:ac:fd:5b:b1:7f:83:98:84:96:27:37:
39:b0:d4:64:c3:d2:4e:ee:db:99:f4:7b:34:29:14:
a6:c4:24:b9:3b:39:bf:48:67
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 CRL Distribution Points:
URI:http://SVRSecure-crl.verisign.com/SVRSecure2005.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.113733.1.7.23.3
CPS: https://www.verisign.com/rpa
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Authority Key Identifier:
keyid:6F:EC:AF:A0:DD:8A:A4:EF:F5:2A:10:67:2D:3F:55:82:BC:D7:EF:25
Authority Information Access:
OCSP - URI:http://ocsp.verisign.com
CA Issuers -
URI:http://SVRSecure-aia.verisign.com/SVRSecure2005-aia.cer
1.3.6.1.5.5.7.1.12:
0_.].[0Y0W0U..image/gif0!0.0...+..k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
Signature Algorithm: sha1WithRSAEncryption
40:74:d0:61:86:b8:e6:a1:5b:98:7b:9c:fb:68:70:81:58:1e:
98:dd:b9:74:53:02:1e:b8:d3:51:0a:3c:2d:6c:80:5c:14:ed:
54:3d:c8:6b:f0:d0:6e:5f:c0:c8:e0:1c:3f:12:4d:cf:85:04:
0b:6f:fd:c8:50:51:67:ee:e5:df:b3:c8:ce:dd:1d:cd:25:4c:
cc:a3:58:c3:6a:38:73:05:5f:5d:13:46:8e:ba:f6:33:b8:77:
6a:c2:cf:eb:52:6d:2e:39:40:26:47:5a:1b:e7:4a:d9:fe:44:
dc:08:67:a6:ae:fa:f3:c1:ff:db:c4:b3:f6:7d:b7:00:95:aa:
87:86:fc:b1:6e:c5:0f:ad:7e:1c:01:cd:43:76:a3:d3:74:c5:
31:29:20:98:48:14:aa:5a:26:a6:6a:8a:64:0f:92:39:76:ff:
f5:d7:aa:85:d5:55:72:1a:d2:98:76:e6:7e:ed:c0:bf:10:fc:
2f:9c:56:09:6b:c3:ff:2e:12:9b:9c:0d:b1:91:53:1f:da:91:
c4:38:93:92:bb:ff:cf:00:f2:e0:fd:b3:b1:1c:28:7c:62:ea:
e0:cb:18:2f:e4:39:f5:52:d8:13:7a:9e:51:4a:6a:d8:69:cf:
84:57:76:a4:90:eb:b0:cc:13:e5:da:1f:1c:75:b2:26:27:94:
1e:a8:e1:6e
You will notice that the Not After line does, in fact, indicate that their
Re: Verisign Problem with smtp tls
On 12/27/2013 01:54 PM, andrew cooke wrote: On Fri, Dec 27, 2013 at 04:53:41PM -0300, Andrew Cooke wrote: i am not following this in any detail, but if you look at the certificate you included in your original email it expired in 2008. just look at it with openssl -text -in some file openssl x509 -text -in some file Yes, thanks Andrew, I got it. I see that it is expired. I am still a bit baffled. I upgraded my mail server just a couple of weeks ago from Debian Squeeze. Everything was fine before then. Is there a different check involved in the latest openssl? -- Bob Wooldridge bob...@kc0dxf.net Blog: http://kc0dxf.net/blog/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign Problem with smtp tls
Bobber bob...@kc0dxf.net wrote on 12/27/2013 02:47:47 PM: I don't see anywhere that it says expired other than this utility. How can I verify that it is really expired? In case you don't trust your openssl install, here is an easy approach using windows: 1. Select everything between -BEGIN CERTIFICATE- and -END CERTIFICATE- 2. Paste into a notepad. Delete the at the beginning of each line. 3. Save the file, say as test.txt. 4. From the file manager, change the extension to test.cer -- the cer means certificate. 5. Double click on the file. It will bring up a lot of information about the certificate. -- Dr. Robert Woody GBS Cybersecurity Weaver Privacy IT Security Architect Cell: 301-524-8138 -- The naked truth of it is, I have no shirt. -- William Shakespeare, Love's Labour's Lost inline: 19941128.gif
Re: Verisign Problem with smtp tls
On Fri, Dec 27, 2013 at 02:54:55PM -0500, Patrick Patterson wrote: Why does no-one else notice? Probably because you've got your server set to actually validate TLS certs, as opposed to most of the world that doesn't. :) With SMTP, PKIX certificate verification is pointless without explicit per-destination configuration: http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html#rfc.section.1.2 This is why I am working to implement and standardize SMTP with DANE TLS. The OP has not explained whether the destination in question has been specifically selected for TLS authentication, or whether TLS authentication is attempted with all destinations that do STATTLS. Most businesses that do mandatory SMTP TLS for compliance reasons protect only against passive attacks (don't send in the clear). Configuration of pre-DANE authenticated SMTP TLS is too difficult. The OP might want to configure his MTA to only require TLS encryption when sending to the site in question, without authentication. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign Problem with smtp tls
On Fri, Dec 27, 2013 at 02:07:56PM -0600, Bobber wrote: Yes, thanks Andrew, I got it. I see that it is expired. I am still a bit baffled. I upgraded my mail server just a couple of weeks ago from Debian Squeeze. Everything was fine before then. Is there a different check involved in the latest openssl? You're posting to the wrong forum. The problem is not OpenSSL, rather you have an updated release of your MTA. (Is it Exim or Postfix? Go to the corresponding mailing list). OpenSSL performs whatever certificate verification your MTA asks for. Perhaps your Debian software upgrade modified your MTA configuration, or your new MTA is not backwards compatible in its TLS support (this would rule out Postfix, which is). -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign Problem with smtp tls
On 12/27/2013 02:22 PM, Viktor Dukhovni wrote: You're posting to the wrong forum. The problem is not OpenSSL, rather you have an updated release of your MTA. (Is it Exim or Postfix? Go to the corresponding mailing list). OpenSSL performs whatever certificate verification your MTA asks for. Perhaps your Debian software upgrade modified your MTA configuration, or your new MTA is not backwards compatible in its TLS support (this would rule out Postfix, which is). Here is output from the swaks command line tool. You can see at the end that it is the remote server which is closing the connection and not my MTA: swaks -tls --from r...@edm-inc.com --to nosuchu...@thelawrencegroup.com --server mail.thelawrencegroup.com === Trying mail.thelawrencegroup.com:25... === Connected to mail.thelawrencegroup.com. - 220 mail.thelawrencegroup.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 ready at Fri, 27 Dec 2013 15:22:54 -0600 - EHLO mail.edm-inc.com - 250-mail.thelawrencegroup.com Hello [68.143.19.38] - 250-TURN - 250-SIZE - 250-ETRN - 250-PIPELINING - 250-DSN - 250-ENHANCEDSTATUSCODES - 250-8bitmime - 250-BINARYMIME - 250-CHUNKING - 250-VRFY - 250-TLS - 250-STARTTLS - 250-X-EXPS GSSAPI NTLM LOGIN - 250-X-EXPS=LOGIN - 250-AUTH GSSAPI NTLM LOGIN - 250-AUTH=LOGIN - 250-X-LINK2STATE - 250-XEXCH50 - 250 OK - STARTTLS - 220 2.0.0 SMTP server ready === TLS started w/ cipher DES-CBC3-SHA === TLS peer subject DN=/C=US/ST=Missouri/L=Saint Louis/O=The Lawrence Group/OU=IT/OU=Terms of use at www.verisign.com/rpa (c)05/CN=mail.thelawrencegroup.com ~ EHLO mail.edm-inc.com ~ 250-mail.thelawrencegroup.com Hello [68.143.19.38] ~ 250-TURN ~ 250-SIZE ~ 250-ETRN ~ 250-PIPELINING ~ 250-DSN ~ 250-ENHANCEDSTATUSCODES ~ 250-8bitmime ~ 250-BINARYMIME ~ 250-CHUNKING ~ 250-VRFY ~ 250-X-EXPS GSSAPI NTLM LOGIN ~ 250-X-EXPS=LOGIN ~ 250-AUTH GSSAPI NTLM LOGIN ~ 250-AUTH=LOGIN ~ 250-X-LINK2STATE ~ 250-XEXCH50 ~ 250 OK ~ MAIL FROM:r...@edm-inc.com *** Remote host closed connection unexpectedly. -- Bob Wooldridge Blog: http://kc0dxf.net/blog
Re: Verisign Problem with smtp tls
On Fri, Dec 27, 2013 at 03:28:46PM -0600, Bobber wrote: === TLS started w/ cipher DES-CBC3-SHA === TLS peer subject DN=/C=US/ST=Missouri/L=Saint Louis/O=The Lawrence Group/OU=IT/OU=Terms of use at www.verisign.com/rpa (c)05/CN=mail.thelawrencegroup.com There's your problem! This server (likely Exchange 2003) has a broken implementation of 3DES CBC padding (search Postfix users archives for my posts on the subject), and your cipher list is either long enough to cause it to not see RC4-SHA and RC4-MD5 or you've disabled RC4 (directly, or by only enabling HIGH grade ciphers). Exchange 2003 servers can't do better than RC4-SHA. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign Problem with smtp tls
On 12/27/2013 03:39 PM, Viktor Dukhovni wrote: On Fri, Dec 27, 2013 at 03:28:46PM -0600, Bobber wrote: === TLS started w/ cipher DES-CBC3-SHA === TLS peer subject DN=/C=US/ST=Missouri/L=Saint Louis/O=The Lawrence Group/OU=IT/OU=Terms of use at www.verisign.com/rpa (c)05/CN=mail.thelawrencegroup.com There's your problem! This server (likely Exchange 2003) has a broken implementation of 3DES CBC padding (search Postfix users archives for my posts on the subject), and your cipher list is either long enough to cause it to not see RC4-SHA and RC4-MD5 or you've disabled RC4 (directly, or by only enabling HIGH grade ciphers). Does Micro$oft have a fix for this? -- Bob Wooldridge Blog: http://kc0dxf.net/blog
Re: Verisign Problem with smtp tls
On Fri, Dec 27, 2013 at 09:39:52PM +, Viktor Dukhovni wrote: On Fri, Dec 27, 2013 at 03:28:46PM -0600, Bobber wrote: === TLS started w/ cipher DES-CBC3-SHA === TLS peer subject DN=/C=US/ST=Missouri/L=Saint Louis/O=The Lawrence Group/OU=IT/OU=Terms of use at www.verisign.com/rpa (c)05/CN=mail.thelawrencegroup.com There's your problem! This server (likely Exchange 2003) has a broken implementation of 3DES CBC padding (search Postfix users archives for my posts on the subject), and your cipher list is either long enough to cause it to not see RC4-SHA and RC4-MD5 or you've disabled RC4 (directly, or by only enabling HIGH grade ciphers). Exchange 2003 servers can't do better than RC4-SHA. Confirmed, this server has the Exchange 2003 cipher-count limit problem. When RC4-SHA and RC4-MD5 are too low on the cipher-list, TLS breaks. If your MTA allows you configure a custom set of cipher suites for a given set of destinations, then configure this set of cipher suites for mail sent to Exchange 2003 machines (cipherlist setting for Postfix transport, Exim router, Sendmail mailer, etc): aRSA+AES128+kEECDH:aRSA+AES128+kEDH:aRSA+AES128+kRSA:RC4-SHA:@STRENGTH This cipherlist allows for the possibility of eventual upgrades that yield AES128 support, but otherwise falls back to RC4-SHA. The list if matching ciphers is well short of the 64 limit. In OpenSSL 1.0.1e it comes to: $ openssl ciphers -v \ 'aRSA+AES128+kEECDH:aRSA+AES128+kEDH:aRSA+AES128+kRSA:RC4-SHA:@STRENGTH' ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHASSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verisign Problem with smtp tls
On Fri, Dec 27, 2013 at 04:11:40PM -0600, Bobber wrote: TLS started w/ cipher DES-CBC3-SHA There's your problem! This server (likely Exchange 2003) has a broken implementation of 3DES CBC padding (search Postfix users archives for my posts on the subject), and your cipher list is either long enough to cause it to not see RC4-SHA and RC4-MD5 or you've disabled RC4 (directly, or by only enabling HIGH grade ciphers). Does Micro$oft have a fix for this? They did, in 2007, but the software in question is no longer supported and AFAIK the hotfix is no longer available. The domain in question is running abandon-ware. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
