Re-digging this up. Our FTP servers won't start when using this cipher configuration. Are you running Pure FTP on your setups?
Hello,
Is the affected system running cPanel 64? If so, note that as of cPanel 64, PureFTPd no longer supports the TLSv1 security protocol. Here's a user-submitted value for Pure-FTPd on another thread:
Code:
HIGH:!SSLv2:!ADH:!DES:!3DES:!aNULL:!eNULL:!NULLWe are running cPanel 62.0.21, using pure-ftp and running this FTP cipher with no problems:
HIGH:!aNULL:!eNULL:!PSK:!RC4:!MD5:!TLSv1:!SSLv2:!SSLv3
Passes SSLLabs tests with A-, but haven't had a PCI scan recently. No problems with FTP starting or logging in. The only weak cipher found is TLS_RSA_WITH_3DES_EDE_CBC_SHA and needs to be disabled. I think we need to add :!3DES: but haven't tested it yet...
HIGH:!aNULL:!eNULL:!PSK:!RC4:!MD5:!TLSv1:!SSLv2:!SSLv3
Passes SSLLabs tests with A-, but haven't had a PCI scan recently. No problems with FTP starting or logging in. The only weak cipher found is TLS_RSA_WITH_3DES_EDE_CBC_SHA and needs to be disabled. I think we need to add :!3DES: but haven't tested it yet...
Pure FTP is working with: AES128+EECDH:AES128+EDH:!SSLv2:!SSLv3:!3DES
For cpanel web service configuration, I have:
HIGH:!aNULL:!eNULL:!PSK:!RC4:!MD5:!DES
SSLv23:!SSLv2:!SSLv3:!TLSv1:!TLSv1_1
Failing on port 2083, 2087, and 2096:
TLSv1_2 : ECDHE-RSA-DES-CBC3-SHA
TLSv1_2 : EDH-RSA-DES-CBC3-SHA
TLSv1_2 : DES-CBC3-SHA
And, the server I'm testing with is running: CENTOS 7.3 x86_64, cPanel & WHM 64.0 (build 12)
For cpanel web service configuration, I have:
HIGH:!aNULL:!eNULL:!PSK:!RC4:!MD5:!DES
SSLv23:!SSLv2:!SSLv3:!TLSv1:!TLSv1_1
Failing on port 2083, 2087, and 2096:
TLSv1_2 : ECDHE-RSA-DES-CBC3-SHA
TLSv1_2 : EDH-RSA-DES-CBC3-SHA
TLSv1_2 : DES-CBC3-SHA
And, the server I'm testing with is running: CENTOS 7.3 x86_64, cPanel & WHM 64.0 (build 12)
Last edited:
Ok, here is the latest:
PCI Compliant Settings:
Dovecot
SSL Cipher List: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSL Protocols: TLSv1.2
EXIM
Options for OpenSSL: Default
SSL/TLS Cipher Suite List: Default
This will require a mitigation document and will be good until June 2018.
The down side is this breaks some Windows 7 machines using Outlook 2016 with the ssl3_get_client_hello error.
Working solution:
Dovecot
SSL Cipher List: AES128+EECDH:AES128+EDH
SSL Protocols: !SSLv2 !SSLv3
EXIM
Options for OpenSSL: +no_sslv2 +no_sslv3
SSL/TLS Cipher Suite List: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS
This works fine, but throws up a lot of PCI compliance errors. I believe all of them can still be mitigated at this point, but this configuration will not work after June 2018. This is ALMOST PCI complaint, which is too bad.
Windows 7 and Outlook 2016 issues with ssl3_get_client_hello appear to be random, not all machines have the problem. This is not patchable via the patch kb3140245. I have several patched clients that still can't get Outlook 2016 to work under the PCI Complaint configuration.
At this point, I don't believe there is a work around for the Outlook issue that is PCI complaint. Some stuff was posted in other threads here, but they were a bit drastic, some turning on SSLv3 with is way outside PCI compliance. What we really need is a patch for Windows 7 and Outlook 2016 that work. My guess is that Outlook is looking at compliant systems for TLSv1, not finding it and attempting to downgrade to SSLv3, but there are no ciphers, so it bombs.
As always, still working on this...
PCI Compliant Settings:
Dovecot
SSL Cipher List: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSL Protocols: TLSv1.2
EXIM
Options for OpenSSL: Default
SSL/TLS Cipher Suite List: Default
This will require a mitigation document and will be good until June 2018.
The down side is this breaks some Windows 7 machines using Outlook 2016 with the ssl3_get_client_hello error.
Working solution:
Dovecot
SSL Cipher List: AES128+EECDH:AES128+EDH
SSL Protocols: !SSLv2 !SSLv3
EXIM
Options for OpenSSL: +no_sslv2 +no_sslv3
SSL/TLS Cipher Suite List: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS
This works fine, but throws up a lot of PCI compliance errors. I believe all of them can still be mitigated at this point, but this configuration will not work after June 2018. This is ALMOST PCI complaint, which is too bad.
Windows 7 and Outlook 2016 issues with ssl3_get_client_hello appear to be random, not all machines have the problem. This is not patchable via the patch kb3140245. I have several patched clients that still can't get Outlook 2016 to work under the PCI Complaint configuration.
At this point, I don't believe there is a work around for the Outlook issue that is PCI complaint. Some stuff was posted in other threads here, but they were a bit drastic, some turning on SSLv3 with is way outside PCI compliance. What we really need is a patch for Windows 7 and Outlook 2016 that work. My guess is that Outlook is looking at compliant systems for TLSv1, not finding it and attempting to downgrade to SSLv3, but there are no ciphers, so it bombs.
As always, still working on this...
Just an update on DOVECOT. Currently Dovecot needs:
SSL Protocols set to TLSv1.2 !TLSv1.1 !TLSv1 !SSLv3 !SSLv2
To be fully complaint on June 30th on a CENTOS 6 & 7 machine. CENTOS 5 shouldn't work at all.
To work with Outlook 2016 on many Windows 7 systems, Dovecot needs this:
TLSv1.2 TLSv1.1 TLSv1 !SSLv3 !SSLv2
This is NOT PCI complaint, but does allow people to check their mail.
My current Windows 7 machine using Outlook 2016 with all of the current updates can not IMAP mail with the PCI Complaint settings. I've installed (KB3140245) and done the REGEDIT to make TLS default to not off. my.kualo.com/knowledgebase/33_windows---configuring-email/1403_how-to-enable-tls-v1.1v1.2-for-windows-78-and-outlook-200720102013.html
Come June 30th, I can not current become PCI complaint and also maintain my customer (or get my own mail with Outlook)
All of the other TLSv1 and TLSv1.1 should be off without any issues. Some FTP programs are going to freak out, but that can usually be resolved.
SSL Protocols set to TLSv1.2 !TLSv1.1 !TLSv1 !SSLv3 !SSLv2
To be fully complaint on June 30th on a CENTOS 6 & 7 machine. CENTOS 5 shouldn't work at all.
To work with Outlook 2016 on many Windows 7 systems, Dovecot needs this:
TLSv1.2 TLSv1.1 TLSv1 !SSLv3 !SSLv2
This is NOT PCI complaint, but does allow people to check their mail.
My current Windows 7 machine using Outlook 2016 with all of the current updates can not IMAP mail with the PCI Complaint settings. I've installed (KB3140245) and done the REGEDIT to make TLS default to not off. my.kualo.com/knowledgebase/33_windows---configuring-email/1403_how-to-enable-tls-v1.1v1.2-for-windows-78-and-outlook-200720102013.html
Come June 30th, I can not current become PCI complaint and also maintain my customer (or get my own mail with Outlook)
All of the other TLSv1 and TLSv1.1 should be off without any issues. Some FTP programs are going to freak out, but that can usually be resolved.
Last edited by a moderator:
I'm trying to wrap my head around this, with an easy summary.
And I'm doing this from the command-line because it's easier to script and run across multiple servers than logging into each individual WHM.
For Exim
In the file - /etc/exim.conf.localopts - it needs to contain the two lines:
openssl_options= +no_sslv2 +no_sslv3 +no_tlsv1 +no_tlsv1_1
tls_require_ciphers=ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
Then rebuild exim.conf and restart:
/scripts/buildeximconf
/scripts/restartsrv_exim
For Dovecot
In the file - /var/cpanel/conf/dovecot/main - it needs to contain the line:
ssl_protocols: "TLSv1.2 !TLSv1.1 !TLSv1 !SSLv3 !SSLv2"
Then rebuild dovecot configuration
/scripts/builddovecotconf
/scripts/restartsrv_dovecot
For cPanel/WHM/Webmail services
In the file - /var/cpanel/conf/cpsrvd/main - it needs to contain:
---
SSLCipherList: HIGH:!aNULL:!eNULL:!PSK:!RC4:!MD5:!DES
SSLVersion: SSLv23:!SSLv2:!SSLv3:!TLSv1:!TLSv1_1
VERSION: '1.2'
Then restart cpsrvd
/scripts/restartsrv_cpsrvd
Is all of this correct?
That leaves FTP (PureFTPd) and Web (Apache). What should those ciphersuites and SSL versions be set to?
And I'm doing this from the command-line because it's easier to script and run across multiple servers than logging into each individual WHM.
For Exim
In the file - /etc/exim.conf.localopts - it needs to contain the two lines:
openssl_options= +no_sslv2 +no_sslv3 +no_tlsv1 +no_tlsv1_1
tls_require_ciphers=ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
Then rebuild exim.conf and restart:
/scripts/buildeximconf
/scripts/restartsrv_exim
For Dovecot
In the file - /var/cpanel/conf/dovecot/main - it needs to contain the line:
ssl_protocols: "TLSv1.2 !TLSv1.1 !TLSv1 !SSLv3 !SSLv2"
Then rebuild dovecot configuration
/scripts/builddovecotconf
/scripts/restartsrv_dovecot
For cPanel/WHM/Webmail services
In the file - /var/cpanel/conf/cpsrvd/main - it needs to contain:
---
SSLCipherList: HIGH:!aNULL:!eNULL:!PSK:!RC4:!MD5:!DES
SSLVersion: SSLv23:!SSLv2:!SSLv3:!TLSv1:!TLSv1_1
VERSION: '1.2'
Then restart cpsrvd
/scripts/restartsrv_cpsrvd
Is all of this correct?
That leaves FTP (PureFTPd) and Web (Apache). What should those ciphersuites and SSL versions be set to?
For Apache, we're running: All -SSLv2 -SSLv3 -TLSv1 and ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:!DSS
The current default, TLSv1.2 should work as well.
For FTP: AES128+EECDH:AES128+EDH:!SSLv2:!SSLv3:!3DES
Separately, for our Windows 7 clients, this worked with outlook 2016/365: teamnetworks.net/blog/4832/enabling-tls-1-2-on-windows-7-complete-instruction/
We did have to manually run the registry update file which is in a zip in one of the links in the artucle, the Microsoft fix it didn't work, but once the registry changes were imported, only needed to restart outlook, not even the computer.
Last edited by a moderator:
Thanks for this.
For Apache, would just setting:
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
be enough to disable everything except for TLSv1.2?
For Pure-FTPd, I think I found using:
TLSCipherSuite EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SSLv2:!SSLv3
would disable everything except for TLSv1.2.
But I suspect there are different ways to accomplish all of this.
That's disappointing. You would think that by now, Microsoft would have released a patch that actually does everything that it needs to to enable TLSv1.2. Maybe they'll release something in July to really patch this, since PCI is advising to run only TLSv1.2 after June 30th.
To get on my soapbox a bit, I've been completely disheartened by all of this. The amount of end users that are still relying on old email clients and old software is just... mind boggling. Nobody cares about security. The whole Let's Encrypt and certificates for everyone, it's just stupid. Nobody cares enough to keep their applications and operating systems up to date and secure, what good is a free certificate going to do? Everybody is saying "I want everything to be secure... but I don't want to have to change anything." ... I've kind of reached a breaking point.
I've found a Windows 7 and Outlook 2016 fix for TLS 1.2 that has worked on a bunch of machines. TLS12-Enable.reg, which can be found here. This is TechNet for Exchange Servers, but the reg fix works.
SSL Protocols for Dovecot can be set to: TLSv1.2 !TLSv1.1 !TLSv1 !SSLv3 !SSLv2
Anyone with issues can run the regedit and it usually fixes the issue with Outlook 2016. Due to other issues, I don't like 2012,13.
For EXIM, the default works in v72.0.5
For Apache, the default SSL/TLS Protocols work fine. (TLSv1.2)
SSL Protocols for Dovecot can be set to: TLSv1.2 !TLSv1.1 !TLSv1 !SSLv3 !SSLv2
Anyone with issues can run the regedit and it usually fixes the issue with Outlook 2016. Due to other issues, I don't like 2012,13.
For EXIM, the default works in v72.0.5
For Apache, the default SSL/TLS Protocols work fine. (TLSv1.2)
I don't suppose Microsoft has posted that .reg file any where on their microsoft.com website for users to trust a download from?
What's the point of the patch, if you still have to cobble together a .reg file yourself? This is Microsoft intelligence at it's best right here.
What's the point of the patch, if you still have to cobble together a .reg file yourself? This is Microsoft intelligence at it's best right here.
On - https://blogs.technet.microsoft.com/exchange/2018/04/02/exchange-server-tls-guidance-part-2-enabling-tls-1-2-and-identifying-clients-not-using-it ?
I see where that link gives instructions on how to create your own TLS12-Enable.reg file. But I don't see where a TLS12-Enable.reg file can be downloaded directly.
Or perhaps I'm missing something obvious.
I see where that link gives instructions on how to create your own TLS12-Enable.reg file. But I don't see where a TLS12-Enable.reg file can be downloaded directly.
Or perhaps I'm missing something obvious.
Sorry, grab the text in the grey square and paste it into a regedit.reg file you created empty. I'm not sure they actually provide reg files because most virus scanners freak if you try to download one.
NOTE: I can't even attach one here, they are so dangerous...
NOTE: I can't even attach one here, they are so dangerous...
OK, was just making sure I wasn't missing it. I think they are giving everyday Windows users a lot of credit if they believe they can copy and paste that into a .reg file and run the .reg file.
But yea, I do agree about potential virus and malware spreading this way.
Of course... this is all the more reason... why wasn't this step included in the patch that they released but apparently nobody got?
I'm not a Microsoft fan, so my opinion is going to be biased. But what's the logic behind "here's a patch... it won't help you because you're still going to have to edit your registry, but we made a patch so that you ... can be aware that you have to edit the registry?"
But yea, I do agree about potential virus and malware spreading this way.
Of course... this is all the more reason... why wasn't this step included in the patch that they released but apparently nobody got?
I'm not a Microsoft fan, so my opinion is going to be biased. But what's the logic behind "here's a patch... it won't help you because you're still going to have to edit your registry, but we made a patch so that you ... can be aware that you have to edit the registry?"
To be technical, the site is for support people, they don't expect normal users to be browsing TechNet. I can assure you that this was not included in any official update, I've done them all. They are just leaving us hanging.
What I've done is I've created the .reg file and put it in my dropbox. I send the drop box link to people and tell them to download it and double click on it. It is really the best we can do.
What I've done is I've created the .reg file and put it in my dropbox. I send the drop box link to people and tell them to download it and double click on it. It is really the best we can do.
