I need to disable TLS v1.0
Per Trustwave:
TLS v1.0 violates PCI DSS and is
considered an automatic failing condition
I have the following line in SSL Cipher Suite:
ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-SSLv3:-EXP:!kEDH
-
Ok, still having many issues with mail. I'm seeing this TLSv1 : DHE-RSA-AES128-SHA, no idea where that cypher is being used, but it show up on several ports 110, 143, 465, 993, 995. 465 is also showing 15 TLSv1 cyphers. Fixed cPanel ports here: (Home >> Service Configuration >> cPanel Web Services Configuration) TLS/SSL Cipher List: ALL:!ADH:+HIGH:-MEDIUM:-LOW:-SSLv2:-EXP TLS/SSL Protocols: SSLv23:!SSLv2:!SSLv3:!TLSv1 FTP Server Configuration HIGH:!TLSv1:!SSLv2:!SSLv3:!ADH:!aNULL:!eNULL:!NULL Testing..... Dovecot AES128+EECDH:AES128+EDH This configuration does break Outlook 2007. Exim openssl_options +no_sslv2 +no_sslv3 +no_tlsv1 For Apache, I gave my cypher suite above, you can verify your cypher suite works with your install using this tool: 0 -
Using the above settings, I'm down to one final issue. The scanner is showing DHE-RSA-AES128-SHA on ports 110,143,993 & 995. So I've missed something on Dovecot. The rest of the system was secure and TLSv1 was removed. The downside is I had to stop testing because customers started to check mail after the long weekend and all of the XP and Outlook 2007 users were broken. Basically, the requirement to remove TLSv1 makes a large segment of customers unable to connect. Until large businesses such as Amazon start meeting this requirement or some media attention toward this problem is address, I doubt small businesses will be able to comply without alienating their customers. 0 -
Still an issue with RC4. Can't connect even over TLS from my email clients. If I remove !RC4, I can connect to POP and SMTP again. Really have no idea how to get around this at this point.
Testing..... Dovecot AES128+EECDH:AES128+EDH This configuration does break Outlook 2007.
Any suggestions for courier, this one still breaks it?0 -
Also, did they accept your mitigation plan on this one? 0 -
Any suggestions for courier, this one still breaks it?
Yes, for Dovecot or Courier, both will break Outlook 2007 as it doesn't support TLSv1.1. There is no way we can support Outlook 2007 or Microsoft XP and be PCI-DSS 3.1 complaint! On the Apache side, we can't support anything lower than Windows 7, with the service pack and IE 11. I'm telling you this is ugly.Also, did they accept your mitigation plan on this one?
I haven't submitted it yet. Seems like the plan is fairly simple. I don't see too much resistance from them. They are not PCI-DSS 3.1 complaint either! I'll be submitting in the next day or so.0 -
I'm trying with office 2013 and 365 on win 7_64 pro and ultimate, and it's breaking those as well. Looking through msdn to see if there is a fix or workaround for this. I think trustwave really jumped the gun on this one. 0 -
I'm trying with office 2013 and 365 on win 7_64 pro and ultimate, and it's breaking those as well. Looking through msdn to see if there is a fix or workaround for this. I think trustwave really jumped the gun on this one.
I had no users report issues with anything other than 2007. What operating system and version is your openssl. It has to support TLSv1.1 or TLSv1.2 or no one can connect.0 -
I had no users report issues with anything other than 2007. What operating system and version is your openssl. It has to support TLSv1.1 or TLSv1.2 or no one can connect.
CENTOS 6.6 x86_64, OpenSSL 1.0.1e-fips If I add +no_tlsv1 to my exim configuration, none of our email clients are able to send through the server.0 -
CENTOS 6.6 x86_64, OpenSSL 1.0.1e-fips If I add +no_tlsv1 to my exim configuration, none of our email clients are able to send through the server.
Strange, with 1.0.1e (same as I'm using) I didn't have any problems, but I didn't specifically test with Outloook other than 2007. I did see plenty of users sending mail. I personally just tested with Thunderbird. I'll run another test tonight after hours and see what happens.0 -
We're also seeing FTP incompatibility with the bundled FTP program included with Netbeans 8.0.2. Filezilla seems to work fine. Tried: HIGH:!TLSv1:!SSLv2:!SSLv3:!ADH:!aNULL:!eNULL:!NULL Server running most current version of Pure FTP. 0 -
Ok, these work for Dovecot and Outlook 2013 Updated: SSL Cipher List: ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4 SSL Protocols: !SSLv2 !SSLv3 Original SSL Cipher List: ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP SSL Protocols: !SSLv2 !SSLv3
This works for Exim: (From advanced editor)tls_require_ciphers: ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4 openssl_options: +no_sslv2 +no_sslv3 Original tls_require_ciphers: ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP openssl_options: +no_sslv2 +no_sslv3
Obviously I can't scan these with Trustwave on a weeknight, but the cipher suite should eliminate TLSv1. When I used the +no_tlsv1 option in EXIM it broke Outlook 2013. I need to further investigate, but these might work.0 -
We're also seeing FTP incompatibility with the bundled FTP program included with Netbeans 8.0.2. Filezilla seems to work fine. Tried: HIGH:!TLSv1:!SSLv2:!SSLv3:!ADH:!aNULL:!eNULL:!NULL Server running most current version of Pure FTP.
Did you already have the !SSLv3 in there? That broke a ton of programs when it was put in for Poodle.0 -
Did you already have the !SSLv3 in there? That broke a ton of programs when it was put in for Poodle.
Actually I don't think I did. I haven't heard anything from people using the server with !SSLv3 after removing !TLSv1 but I'll test some more.0 -
Yeah, !SSLv3 breaks a ton of programs. We had completely reverted to a previous cipher set on the other server. 0 -
I'm opening a ticket on this. Maybe cpanel has a solution for it. We're getting beat up over this from some of our partners, and from what I can see, Cpanel is completely incompatible with current PCI standards, assuming other vendors interpret cipher requirements the same way. 0 -
I'm opening a ticket on this. Maybe cpanel has a solution for it. We're getting beat up over this from some of our partners, and from what I can see, Cpanel is completely incompatible with current PCI standards, assuming other vendors interpret cipher requirements the same way.
Keep in mind that one one actually has to meet the current standards until June 2016 on existing systems. Trustwave jumped the gun by making it a PCI violation so soon, when no one can possibly meet the standard. cPanel can't really meet the standard either, since it would mean that, I'd guess, about 50% of customers would not be able to connect to their cPanel servers. Just making the POODLE changes killed most of the existing FTP software. TLSv1 changes are far more sweeping. Again, SSL connections would need Windows 7 and the latest IE11. Anything less would not be able to connect. That include OS X with Safari 5.1. Safari for Windows would also be toast, there is no version without TLSv1. So, I don't think this is really cPanel issue. It is an issue with the unrealistic expectations of the PCI people and Trustwave. Yes, we would all like to be super secure, but telling 50% of our customers they can't use our services isn't a solution.0 -
Anyone have sample "mitigation plan" answers for the questions that Trustwave is asking? Would sure save some time! Dear Sir or Madam: Please accept this as the Risk Mitigation and Migration Plan for PCI DSS 3.1 for . A description of where and how we are currently using SSL and/or early versions of TLS, how we intend to mitigate the risks with these technologies, and our migration plan are listed below. 1. Where are SSL/TLS 1.0 currently used in your environment? 2. How are you mitigating risks with SSL/TLS 1.0? 3. How are you monitoring for new vulnerabilities associated with SSL/TLS 1.0? 4. How are you ensuring that SSL/TLS 1.0 are not introduced into your cardholder data environment? (Meaning, how can you verify that new or upgraded systems connected to your cardholder data environment don't contain SSL/TLS 1.0?) 5. When will your migration plan from SSL/TLS1.0 be completed? 0 -
Keep in mind that one one actually has to meet the current standards until June 2016 on existing systems. Trustwave jumped the gun by making it a PCI violation so soon, when no one can possibly meet the standard. cPanel can't really meet the standard either, since it would mean that, I'd guess, about 50% of customers would not be able to connect to their cPanel servers. Just making the POODLE changes killed most of the existing FTP software. TLSv1 changes are far more sweeping. Again, SSL connections would need Windows 7 and the latest IE11. Anything less would not be able to connect. That include OS X with Safari 5.1. Safari for Windows would also be toast, there is no version without TLSv1. So, I don't think this is really cPanel issue. It is an issue with the unrealistic expectations of the PCI people and Trustwave. Yes, we would all like to be super secure, but telling 50% of our customers they can't use our services isn't a solution.
Yeah, I think we're going to go the risk plan route and revisit in about 6 - 9 months. The incompatibilities right now as so much that we wouldn't be able to effectively run our businesses.Anyone have sample "mitigation plan" answers for the questions that Trustwave is asking? Would sure save some time!
I'm wondering if just a generic, our software vendor is in the process of fully supporting the cipher requirements...0 -
I sure wish those that have already submitted this to Trustwave would share at least some of their language. Would really speed this up for me. - Scott 0 -
I sure wish those that have already submitted this to Trustwave would share at least some of their language. Would really speed this up for me. - Scott
I'll post here as soon as I get an answer on the risk plan.0 -
Still struggling... 28971 0 -
Still struggling... 28971
Cpanel isn't fixed. You need to update it. cPanel (Home >> Service Configuration >> cPanel Web Services Configuration) TLS/SSL Cipher List: ALL:!ADH:+HIGH:-MEDIUM:-LOW:-SSLv2:-EXP TLS/SSL Protocols: SSLv23:!SSLv2:!SSLv3:!TLSv1 Original TLS/SSL Cipher List: ALL:!ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP TLS/SSL Protocols: SSLv23:!SSLv2:!SSLv3 As for the plan, I haven't' got one approved yet. Still waiting. Edit: Put in a mitigation plan 9 days ago, still no approval or disapproval. No approval on my 'backport' disputes either. Trustwave seems to be very backed up! I'm guessing they messed up and now they have realized it. They did some updates to their system today at 7:00am, let see what they have changed.0 -
Risk Mitigation plan accepted by Trustwave. May 27th, 2015 Risk Mitigation and Migration Plan for Payment Card Industry Data Security Standard (PCI DSS) 3.1 Requirements c/o Trustwave 70 W. Madison St. Suite 1050 Chicago, IL 60602 Dear Sir or Madam: Please accept this as the Risk Mitigation and Migration Plan for PCI DSS 3.1 for . A description of where and how we are currently using SSL and/or early versions of TLS, how we intend to mitigate the risks with these technologies, and our migration plan are listed below. 1. Where are SSL/TLS 1.0 currently used in your environment? We are currently accepting TLSv1 connections on port 80 and 443 to support older browsers as many of our customers have not yet upgraded to PCI-DSS 3.1 compliant browsers. We are currently accepting TLSv1 connections on ports 110, 143, 993 and 995 for email logins from our customers who are not yet able to comply with PCI-DSS 3.1. 2. How are you mitigating risks with SSL/TLS 1.0? We are currently using TLSv1 to as a security control, but not to protect the confidentiality of the communication. We do not allow the transmission of customer data via email. We currently support TLSv1.1 and TLS1.2 and only HIGH encryption for those customers who are able to use these. Our default communication is set to use the best possible ciphers and protocols and only allowing downgrades for those customers unable to use the required level of communication. 3. How are you monitoring for new vulnerabilities associated with SSL/TLS 1.0? We are continuing our security scanning and should any new vulnerabilities in TLSv1 appear, we will be able to quickly react to prevent any additional risk. 4. How are you ensuring that SSL/TLS 1.0 are not introduced into your cardholder data environment? (Meaning, how can you verify that new or upgraded systems connected to your cardholder data environment don"t contain SSL/TLS 1.0?) TLSv1 is only currently in our website environment for the connivance of our customers. No new devices or system will be introduced that support TLSv1 and we are able to move to new TLS formats as soon as our customer base will support such a move. 5. When will your migration plan from SSL/TLS1.0 be completed? We expect to be fully migrated by March 2016 or earlier if our customer base is able to upgrade. Under current testing about half our customers are unable to communicate with us if we do not support TLSv1.
So basically, I told the truth, I can't upgrade my servers, its not me, its my customers who can't support their needs.0 -
I'm getting complaints from customers using chrome, with the message below. I do not want to effect ftp or email with any changes. Your connection to domainname.com is encrypted with obsolete cryptography. The connection uses TLS 1.0 The connection is using SHA256_CBC, with SHA1 for message authentication and ECDHE_RSA in the key exchange mechanism. The server is CENTOS 5.11 i686 standard " WHM 11.48.4 (build 4) # rpm -q --changelog openssl * Mon Apr 27 2015 Kai Engert 0.9.8e-34 If I set the TLS/SSL Protocols: SSLv23:!SSLv2:!SSLv3:!TLSv1 in cPanel Web Services Configuration then it does not appear to solve the issue but also cpanel becomes inaccessible and I have to do the fix mentioned by jestep earlier in this thread. My CENTOS 6.6 x86_64 xenpv " WHM 11.50.0 (build 9) server works fine. Any thoughts on what I may be doing wrong? 0 -
The server is CENTOS 5.11 i686 standard " WHM 11.48.4 (build 4)
CENTOS 5.11 with what OPENSSL and what Apache? None of my CENTOS 5 servers would support TLSv1.1 or TLSv1.2, I toss all of my 5 for 6.6 to get access to TLSv1.1 in case TLSv1 stopped being useable. You can check your server compatibility by using the SSL tester at0 -
CENTOS 5.11 with what OPENSSL and what Apache? None of my CENTOS 5 servers would support TLSv1.1 or TLSv1.2, I toss all of my 5 for 6.6 to get access to TLSv1.1 in case TLSv1 stopped being useable.
Apache/2.2.27 (Unix) mod_ssl/2.2.27 OpenSSL/0.9.8e-fips-rhel5. If there was an easy / safe upgrade from CentOS 5 to 6 I'd do that. I'm trying to avoid rebuilding or moving to a new server as I don't want customers to suffer. I'm slowly moving customers on to a different server. Some are not so easy as they require an old version of php. Protocols TLS 1.2 No TLS 1.1 No TLS 1.0 Yes SSL 3 No SSL 20 -
Apache/2.2.27 (Unix) mod_ssl/2.2.27 OpenSSL/0.9.8e-fips-rhel5. If there was an easy / safe upgrade from CentOS 5 to 6 I'd do that. I'm trying to avoid rebuilding or moving to a new server as I don't want customers to suffer. I'm slowly moving customers on to a different server. Some are not so easy as they require an old version of php.
Sorry to say that I don't see a choice. OpenSSL/0.9.8e-fips-rhel5 doesn't support TLSv1.1 and never will (that is my guess, I can't see them adding TLSv1.1) I was running the same version last year and saw no options except to upgrade. Also there are issues with with Apache 2.2, we really need to be running 2.4 now to support TLSv1.1. You can give up PCI Compliance and assume the risk of using TLSv1 or get a new server. If you upgrade (buy a new server and migrate) that uses CENTOS 6.6 with CloudLinux, then the server would support users selecting a different version of PHP without risk to the server and clients who are using the most current version by using CageFS. The older versions would NOT effect users PCI Compliance, since it isn't running in their cage. It would only effect users who were actually using the old version. That was the solution I picked. Obviously, this isn't urgent. You can upgrade between now and June of 2016 and still be compliant.0 -
Also there are issues with with Apache 2.2, we really need to be running 2.4 now to support TLSv1.1. You can give up PCI Compliance and assume the risk of using TLSv1 or get a new server. If you upgrade (buy a new server and migrate) that uses CENTOS 6.6 with CloudLinux, then the server would support users selecting a different version of PHP without risk to the server and clients who are using the most current version by using CageFS. The older versions would NOT effect users PCI Compliance, since it isn't running in their cage. It would only effect users who were actually using the old version. That was the solution I picked. Obviously, this isn't urgent. You can upgrade between now and June of 2016 and still be compliant.
Upgrading to 2.4 shouldn't be a problem. My long term plan is to that with CloudLinux etc. My biggest issue will be changes of IP. Way to many of my customers control the dns from their registrar etc. Thanks for your help.0
Please sign in to leave a comment.
Comments
119 comments