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
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: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
|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 --- Begin Message --- 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 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
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
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
Is there any opportunity to set different cipher suits for different versions of TLS?
Hi, For example, I want to exclude wholly RC4 cipher suits for TLS 1.2/1.1 and leave them only for <=TLS 1.0 The reason is the same BEAST. But if we have only one string with cipher suits we can't do this because we need RC4 for TLS 1.0 and lower. --- Regards. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
