TLS v1.0 deadline by pci!

@wattie:
I also disabled TLS 1.0 and 1.1 now for apache. Next to that I changed the cipher Suite because I kept getting a lot of red entries with SSLlabs, while newer Cpanel installations by default do not.
So now I'm using the same cipher suite as cpanel does, not a single user complaining, enough older browsers (including IE11 for W7) supported and everything is black and green, no red anymore. :)

For mail it's way more difficult to disable it already now. Indeed older outlook versions like 2007 need an update to be able to work with SSL, otherwise people have to make registry entries which is not advisable to do for the average users. But I know a lot of users still using older e-mail clients like Outlook versions older then 2007, some with MAC issues and several also using Windows Live Mail. Which is also declared EOL and not supported anymore by MS, but still a lot of users still use it.

I didn't know about WinHTTP though that this would effect Windows 7.
Vista is EOL and End of support anyway like XP. But about the secure mail, just to be sure. Isn't it the client what defines that? Like Thunderbird is supporting tls 1.2 for example. When you install Thunderbird on Vista or W7 then TLS 1.2 is supported correct?
Anyway, for mail I can either stay with the old style plain text stuff like before to meet customers with old stuff, or let TLS 1.0 enabled for the time being. I won't force my customers.

@JohnyByk: As wattie says, same kind of handling, but then remove the -TLSv1 line from httpd-ssl.conf, copy to the /custombuild/custom/ap2/conf/extra directory.
Then restart Apache and TLS 1.0 is supported again.
 
@Ditto: I just had a look. Windows 7 supports TLS 1.1 and 1.2 by default. Was not enabled by default until juni 2016 when update KB3140245 was released.
So if people update their windows 7, there is no issue for Windows 7.
There might be issues for older outlook versions. You can patch Outlook 2007 either via windows update or registry entry's, but older ones have bad luck I guess.
 
Without the update it won't work.

Thunderbird and non-Microsoft clients are unaffected - they will work regardless of Windows version and its updates.
 
Richard G said:
@Ditto: I just had a look. Windows 7 supports TLS 1.1 and 1.2 by default. Was not enabled by default until juni 2016 when update KB3140245 was released.
So if people update their windows 7, there is no issue for Windows 7.
There might be issues for older outlook versions. You can patch Outlook 2007 either via windows update or registry entry's, but older ones have bad luck I guess.
Click to expand...

Thank you for the information. As I don't have Outlook 2007 it is hard for me to test. What is unclear for me, is if it is enough for Windows 7 users that have Outlook 2007 to apply all available from Windows updates, or if they need to manually apply edits to the registry? If all they need to do is to apply all the latest updates from Windows update, then they have no excuse and I will not disable TLS 1.0 in Dovecot. However if they manually need to edit the registry or manually download a patch that is not applied when running windows update, then I will need to enable TLS 1.0 in Dovecot.
 
I had a customer today I did a remote session with.

Windows 7 SP1 - Latest updates Installed
Office 2016

Would not work with TLS1.0 disabled. I also applied the registry patch through the "easy fix" and restarted.

I will spend more time on it next week, it does not appear to be a simple user didn't patch issue.

ditto said:
Thank you for the information. As I don't have Outlook 2007 it is hard for me to test. What is unclear for me, is if it is enough for Windows 7 users that have Outlook 2007 to apply all available from Windows updates, or if they need to manually apply edits to the registry? If all they need to do is to apply all the latest updates from Windows update, then they have no excuse and I will not disable TLS 1.0 in Dovecot. However if they manually need to edit the registry or manually download a patch that is not applied when running windows update, then I will need to enable TLS 1.0 in Dovecot.
Click to expand...
 
Richard G said:
@Ditto: I just had a look. Windows 7 supports TLS 1.1 and 1.2 by default. Was not enabled by default until juni 2016 when update KB3140245 was released.
So if people update their windows 7, there is no issue for Windows 7.
There might be issues for older outlook versions. You can patch Outlook 2007 either via windows update or registry entry's, but older ones have bad luck I guess.
Click to expand...

Richard,

It appears that while the 2016 patch added TLS 1.1 and TLS 1.2 support, the WINHTTP module forces TLS1.0 and when it gets a refusal it doesn't try the other versions. If anyone has a simple fix to the problem, I would turn off TLS 1.0 in a heartbeat on Dovecot.

Kevin
 
ditto said:
is if it is enough for Windows 7 users that have Outlook 2007 to apply all available from Windows updates,
Click to expand...
As far as I understood from the Microsoft page, that would unfortunately not be enough.
To apply this update, the DefaultSecureProtocols registry subkey must be added.
Click to expand...

kevinb said:
Would not work with TLS1.0 disabled. I also applied the registry patch through the "easy fix" and restarted.
Click to expand...
Indeed this has to be done and is also written on the KB3140245 page at the Microsoft site.

This is unfortunate. I hope Microsoft will soon come to their senses because W7 is supported untill 2020, so they should enable this by default without the need for manual registry changes.
As they can make registry changes via Windows Update anyway.

@Kevinb: As I read from the KB3140245 page, you can set the default by editting the registry setting. Defaulting to 1.2 would be 0x00000800, or you can add 1.1 and 1.2 by calculator.
However... this again is manual stuff, not an easy thing, unless you create a .reg file yourself for this.

IMHO Microsoft should drop 1.0 anyway.
 
Last edited:
smtalk said:
"./build rewrite_confs" is enough for that.
Click to expand...

It seems ./build rewrite_confs only update TLS version for Apache. It was needed to run ./build dovecot_conf to update TLS version in /etc/dovecot/conf/ssl.conf
 
Hi Everyone,

I ran into this issue myself on Windows 7 using Outlook 2010 and was able to resolve it. However, it does require manually editing the Windows Registry as Windows Update KB3140245 + Microsoft Easy Fix does not appear to create the required Protocol Keys.

*Use common sense when editing the registry. My situation may be different than yours.

Links:

1. Microsoft Page that describes the update (includes access to KB3140245 + Easy Fix patch):
Windows TLS Upgrade Overview

2. Microsoft Update Catalog for Direct Downloads of KB3140245 (may already be installed):
Windows Update KB3140245

3. TechNet Article that explains the overall process and additional Keys/DWORD values (32bit) that are needed:
Enable TLS 1.1 and TLS 1.2 on Windows 7

More than likely KB3140245 will automatically be installed - if not, it should be installed as per Microsoft. The TechNet article provides the registry Keys/DWORD values that are needed (which depends on the versions of TLS you want to enable - follow the article). The "Easy Fix" from Microsoft appears to create the first set of DWORD values, but I had to manually enter the new Protocol Keys as per the TechNet article (they credit Ivan from their comments).

Here is what I did. However, check that all other values from the TechNet article are in place. I only enabled TLS 1.1 + 1.2:

Code: 
Per the TechNet article, be sure to create the DisabledByDefault DWORD values and 
set them to 0 in both locations below. You may need to create the TLS 1.1, TLS 1.2 and Client keys:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client

I have attached a screenshot for how the TLS 1.1 Key appears in my registry. The TLS 1.2 should appear the same.

Once I made all the changes and rebooted, Outlook immediately connected and can send/receive without issues. This has worked for three clients thus far.

Good Luck!
 

Attachments

  • Win7-TLS-Protocol-Keys.jpg
    Win7-TLS-Protocol-Keys.jpg
    44 KB · Views: 44
Hi guys,

To the increasing number of complaints and support issues due to a very common OS and email client, we've reverted back to TLSv1 as the default.

But as there is a need for PCI complaince (where cannot do both at the same time), I've written this guide on how to change your SSL/TLS/cipher settings in dovecot:
https://help.directadmin.com/item.php?id=2072

Sorry for the confusion, hopefully this will strike more of a balance with everyone :)

John
 
Excellent option. While the move to TLS > 1.0 makes complete sense, I'm sure there are probably many users still using older versions of Windows + Outlook (I do myself).

It is a shame because there should be no reason why Microsoft cannot include the basic registry changes (mentioned in my post above) in an update or patch. The "Easy Fix" that they provide is 50% there, and could easily include the additional Protocol Keys that are required to resolve the issue.

Then again...a fix that completely resolves the problem (for software without monthly fees) would not encourage new sales for software with subscription based licensing.

$$$
 
That is exactly why we only disabled the TLS v1.0 by default for Apache which is a good thing, but waited with the change for Dovecot in the (maybe idle) hope dat Microsoft will fix this in a better way as they still support Windows 7 until 2020 which is still 2 years.

My gues is they again did or slow down this on purpose to push more users to W10.
 
That's indeed good news! Thank you!

Still, only in 2020, so over a bit more then a year. But it still is good news.
 
Some links with info en test.

Dovecot info
https://wiki2.dovecot.org/SSL/DovecotConfiguration

The FTP and SSH ports has default to weak DH and so on if testing also the dovecot port 110 and 143

Test here:
https://discovery.cryptosense.com/

Port 21 examples bad as some of these also for port 22:
Support for anonymous cipher suites
Trigger This service supports 11 anonymous cipher suites.
Context

Each cipher suite describes how server authentication is done. Anonymous cipher suites tell the client not to authenticate the server. They should thus not be used unless server authentication is not required, as is usually the case for SMTP servers

Weak cryptography
Support for RC4 cipher
Trigger The server supports a cipher suite containing the RC4 cipher.
Context

RC4 is a stream cipher in which significant weaknesses have been found. The use of this cipher in any protocol has been discouraged by ECRYPT as of 2014 (ECRYPT 2016 report).

In TLS, cipher suites using RC4 have been deprecated as of February 2015 (RFC 7465).
B
Warnings
Support for Triple DES cipher
Trigger The server supports a cipher suite containing the 3DES cipher.
Context

Three-key-3DES is a cipher with 168-bit keys but an effective key length of 112 bits because of a meet-in-the-middle attack. This is considered enough only for legacy. Furthermore, it has a 64-bit block size, which can be insufficient for some applications, for example because of birthday attacks (sweet32.info).
Click to expand...

Port 22:

SSH (port 22)
Show scan details
C
Weak cryptography
Diffie-Hellman group security
Trigger The server supports the "diffie-hellman-group1-sha1" algorithm.
Context

The "diffie-hellman-group1-sha1" key exchange algorithm uses the commonly-shared and 1024-bit Oakley Group 2 (RFC 4253).

For security, a 2048-bit group is reasonable although ECRYPT recommends a group size of at least 3072 bits (ECRYPT 2016 report). The use of commonly-shared 1024-bit groups such as Oakley group 2 is especially discouraged because of possible precomputation attacks (weakdh.org).

Diffie-Hellman is mainly used so that two machines can compute a shared secret and so benefit from forward secrecy.
Fix Log in to get remediation advice
Support for 3DES cipher
Trigger The server supports the 3DES cipher.
Context

Three-key-3DES is a cipher with 168-bit keys but an effective key length of 112 bits because of a meet-in-the-middle attack. This is considered enough only for legacy. Furthermore, it has a 64-bit block size, which can be insufficient for some applications, for example because of birthday attacks (sweet32.info).

In SSH, there seem to be no advantage to using 3DES over more secure and more supported ciphers.
Fix Log in to get remediation advice
B
Warnings
Support for Blowfish cipher
Trigger The server supports the Blowfish cipher.
Context

Blowfish is a block cipher with a 64-bit block size.

In SSH, Blowfish is used with 128-bit keys. However, its 64-bit block size, can be insufficient for some applications, for example because of birthday attacks (sweet32.info). There are also some cryptanalytic results on reduced-round versions (though no practical attacks). There seem to be no advantage to using it over more secure and more widely supported ciphers.
Fix Log in to get remediation advice
Support for CAST-128 cipher
Trigger The server supports the CAST-128 cipher.
Context

In SSH, CAST-128 is used with 128-bit keys. However, it has a 64-bit block size, which can be insufficient for some applications, for example because of birthday attacks (sweet32.info). There seem to be no advantage to using it over more secure and more widely supported ciphers.
Fix Log in to get remediation advice
Click to expand...
 
Last edited:
The following config will give you "C" score for ProFTPd:

TLSProtocol TLSv1.2
TLSCipherSuite HIGH:-ADH:-ECDH_anon_WITH_AES_128_CBC_SHA:-ECDH_anon_WITH_AES_256_CBC_SHA
Click to expand...

It will still complain about presence of RC4 and 3DES. Unfortunately I found no way to disable them. For example for RC4 I tried:

-ECDHE_RSA_WITH_RC4_128_SHA:-RSA_WITH_RC4_128_MD5:-RSA_WITH_RC4_128_SHA
Click to expand...

and even the aliases:

-RC4:-3DES
Click to expand...

but it's not working for me.
 
You must log in or register to reply here.
Back
Top