On 9/9/2013 4:09 PM, Reindl Harald wrote:

Am 09.09.2013 22:56, schrieb Darren Pilgrim:

...

I'm running Dovecot 2.2.5 and want to make it refuse SSLv2, SSLv3 and TLSv1.0. Clients will opportunistically use TLS 1.1 and 1.2, but now I want require they do so. Is it enough to set

ssl_cipher_list = HIGH:!SSLv2:!SSLv3:!TLSv1.0:!aNULL:!MD5 or are there additional settings I need to specify?

and what clients do you imagine to connect?

Thunderbird and a Webmail app.

on most widely used distributions you even have no openssl version supporting TLS 1.2 and so you lock them all out

OpenSSL 1.0.1 supports TLS 1.2. So does Windows 7/8 and MacOS X. Mozilla NSS 3.15 does 1.2.

FWIW, I was able to get it working with the following:

ssl_protocols = !SSLv2 !SSLv3 !TLSv1 ssl_cipher_list = ALL:HIGH:!SSLv2:!MEDIUM:!LOW:!EXP:!RC4:!MD5:!aNULL:@STRENGTH

The above disables SSLv2, v3 and TLSv1.0, leaving only TLSv1.1 with AES/Camellia/3DES and TLSv1.2 with AES/AES-GCM.

Dovecot lacks the ability to disable TLS 1.1 or 1.2. Adding support for specifying TLSv1.1 and TLSv1.2 in ssl_protocols looks pretty straight forward: add 0x08 and 0x10 to the enum in src/lib-ssl-iostream/iostream-openssl-common.c and expand the various tests to include the appropriate strings.

Would a user-submitted patch to add TLSv1.1 and TLSv1.2 support to ssl_protocols be appreciated?

On 9/11/2013 3:52 PM, Reindl Harald wrote:

and that is why i said most widely used does not

RHEL5: openssl-0.9.8e RHEL6: openssl-1.0.0 Fedora 17: openssl-1.0.0k Fedora 18: openssl-1.0.1e

RHEL with outdated software bundled? You don't say. ;)

Let's look at the rest of the world:

Firefox and Thunderbird currently ship with TLS 1.1/1.2 support, but not enabled by default. Mozilla is still working on automatic fallback to SSLv3/TLSv1.0. Firefox 24 supposedly has ability and will enable TLS 1.1 and 1.2 by default.

On Windows 7, 8, 2008R2 and 2012, the schannel libraries support TLS 1.1 and 1.2. Versions of IE, Office, IIS, Exchange, SQL Server et al dating to as early as 2010 or so use those schannel library versions. IE 11 should have TLS 1.1 and 1.2 enabled by default. One nice thing: IE 10 will report the TLS version in the page properties. For example, Google's front page gives "TLS 1.2, AES with 128 bit encryption (High); ECDH_P256 with 256 bit exchange".

With Apple, the SecureTransport libraries since 2011 or so supports TLS 1.1 and 1.2. That should include iOS 5 and 6 and OS X 10.6+. Version info is hard to find for Apple software, so my apologies if the version alignment isn't correct. Safari has TLS 1.1 and 1.2 enabled by default.

Other things that support TLS 1.1+:

• Google servers
• Facebook
• Twitter
• Cloudflare
• Chrome
• GnuTLS
• Java SSE

I'm not sure we can agree on what comprises the "most widely used" case or even at what point we can say TLS 1.1+ is "well supported"; but the above is at least a good start.

On Wed, 2013-09-11 at 15:46 -0700, Darren Pilgrim wrote:

...

on most widely used distributions you even have no openssl version supporting TLS 1.2 and so you lock them all out

OpenSSL 1.0.1 supports TLS 1.2. So does Windows 7/8 and MacOS X. Mozilla NSS 3.15 does 1.2.

FWIW, I was able to get it working with the following:

ssl_protocols = !SSLv2 !SSLv3 !TLSv1 ssl_cipher_list = ALL:HIGH:!SSLv2:!MEDIUM:!LOW:!EXP:!RC4:!MD5:!aNULL:@STRENGTH

The above disables SSLv2, v3 and TLSv1.0, leaving only TLSv1.1 with AES/Camellia/3DES and TLSv1.2 with AES/AES-GCM.

Dovecot lacks the ability to disable TLS 1.1 or 1.2. Adding support for specifying TLSv1.1 and TLSv1.2 in ssl_protocols looks pretty straight forward: add 0x08 and 0x10 to the enum in src/lib-ssl-iostream/iostream-openssl-common.c and expand the various tests to include the appropriate strings.

Would a user-submitted patch to add TLSv1.1 and TLSv1.2 support to ssl_protocols be appreciated?

Frankly I think your idea is crazy :) But if your in a closed network and known all clients, including mobiles and tablets etc will work with what you want, well, your network, your rules.

I'm always of the belief that if one person wants a feature, they might be the only vocal person, but they are never really alone, so post your patch, Timo can only either pull it in, or decline it, as for its useful for others, only time will tell, but not even god will help those who use it on a commercial network with paying customers - thats just plain professional suicide.

Cheers

Hi Patrick,

On Thu, 2013-09-12 at 09:23 +0200, Patrick Lists wrote:

Hi Noel,

On 09/12/2013 08:54 AM, Noel Butler wrote: [snip]

...

I'm always of the belief that if one person wants a feature, they might be the only vocal person, but they are never really alone, so post your patch, Timo can only either pull it in, or decline it, as for its useful for others, only time will tell, but not even god will help those who use it on a commercial network with paying customers - thats just plain professional suicide.

Unless it was clearly stated what the requirements are when they sign up. With NIST sleeping at the helm and the NSA having a field day it would not surprise me if businesses understand the importance of stronger encryption.

Yeah, but you wont have many customers, or keep them if you inflict that much pain, I'm well known for being pretty anal about security policies, but not even I would contemplate that on a commercial (isp/web-host) scale, on corporate LAN, there will also always be one who wont support it, and its likely going to be the CEO's mobile device hah.

Which reminds me, if the OP is interested in knowing how many and who wants it, they could always email the NSA ans GCHQ, if your American, Brittish, or your data traverses the US or UK, they I'm sure will have a record of who ;)

Cheers

-- CZlY6zU4Hd4O9ciGSQTwDs/l82IexuIWo4MUSMBVfeyXfdO/fDnk99mA0H3tVduiHm7RsdUtxO9wjiBrMM7BCgoTRdnqeax/3o1W0iXU29/B+vs/eHYH6O81yhe5mNe7SUuWStEdfEavy3ZqCCzOh2JNwbpO6iLXn8Q/Jc0qDM5SidAl0Rg7i8tYx+T2oD+y1UK8JB6pE=

Zitat von Hans Spaans hans@dailystuff.nl:

Patrick Lists schreef op 2013-09-12 09:23:

...

Hi Noel,

On 09/12/2013 08:54 AM, Noel Butler wrote: [snip]

...

I'm always of the belief that if one person wants a feature, they might be the only vocal person, but they are never really alone, so post your patch, Timo can only either pull it in, or decline it, as for its useful for others, only time will tell, but not even god will help those who use it on a commercial network with paying customers - thats just plain professional suicide.

Unless it was clearly stated what the requirements are when they sign up. With NIST sleeping at the helm and the NSA having a field day it would not surprise me if businesses understand the importance of stronger encryption.

Why not turn it around? Why not tell the paying customer he is using
an unencrypted connection or with options that are insecure. Parse
the logfiles and make an additional section on the website where
he/she can see from where he/she had a successful login and the
security level? Make it red for unencrypted, orange/amber for
insecure and green for a "secure" connection. Most people like to
have everything in the green and you give them a choice what to do.
Also the cost is almost nothing for doing this. You could even make
it a service for companies who get a weekly/monthly PDF with an
overview.

For now only Dovecot tells if it is a TLS-connection or not. Postfix
for example already tells if it is TLSv1 connection and the cipher.
If this could be extended then sysadmins have a way to make a
decision about the path to follow or to advise to management.

Hans

http://dovecot.2317879.n4.nabble.com/Patch-to-log-the-cipher-suite-used-for-...
??

Regards

Andreas

On 12.9.2013, at 1.46, Darren Pilgrim list_dovecot@bluerosetech.com wrote:

Would a user-submitted patch to add TLSv1.1 and TLSv1.2 support to ssl_protocols be appreciated?

v2.2.5 already has them.