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
-
I'm not sure of the risk of upgrading OPENSSL. I would put in a ticket and discuss it with cPanel before you decided. In my case, I looked at the upgrade and thought the risk was too high. Plus it isn't really a supported change, so who knows what could go wrong. A screwed up server is harder to migrate than one that is working. Migration is a pain, but it solves the problem. 0 -
You made these changes: (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 0 -
-
You made these changes: (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
no because that breaks whm i fixed the rc4 issue, i used mozilla's recommendations. as for cpanel i believe its the way the cert is generated because it's self signed. the original one i had needs to be regenerated, when their site is back up i'll try again.0 -
no because that breaks whm
This would only break WHM if your server doesn't support those changes. For a Apache 2.4 server that is running CENT OS 6.6, WHM works fine with those settings. Also Trustwave has come up with a new wrinkle: SSL Weak Encryption Algorithms: "Please note that this vulnerability CANNOT be disputed using a Risk Mitigation and Migration plan. This is a separate finding and must be treated as such." In other words, sure you can put in a mitigation plan to still allow you to use TLSv1, but we aren't going to allow you to use any TLSv1 protocols. Thus making the mitigation plan idea useless, since the idea was that we couldn't stop using TLSv1 because too many can not connect to our server. Now, they have approved my continued use of TLSv1, but will not approve or allow me to mitigate the use of TLSv1 protocols. The only hope is that they are only flagging 110, 143 and 995, so it is possible that a change to Dovecot that doesn't break Outlook 2007 might be a work around. I'm running a scan on that now.0 -
The original one i had needs to be regenerated, when their site is back up i'll try again.
I also needed to regenerate all of my SSL, which were about a year old from RapidSSL. All of them were using SHA1. There was no option at Namecheap to use any other method. Namecheap is now using SHA2 for certificates, so once regenerated, they seemed to work fine.0 -
Also Trustwave has come up with a new wrinkle: SSL Weak Encryption Algorithms: "Please note that this vulnerability CANNOT be disputed using a Risk Mitigation and Migration plan. This is a separate finding and must be treated as such." In other words, sure you can put in a mitigation plan to still allow you to use TLSv1, but we aren't going to allow you to use any TLSv1 protocols. Thus making the mitigation plan idea useless, since the idea was that we couldn't stop using TLSv1 because too many can not connect to our server. Now, they have approved my continued use of TLSv1, but will not approve or allow me to mitigate the use of TLSv1 protocols. The only hope is that they are only flagging 110, 143 and 995, so it is possible that a change to Dovecot that doesn't break Outlook 2007 might be a work around. I'm running a scan on that now.
I had this as well, but the only cipher that was showing under the evidence tab was RC4. Are you seeing others listed?0 -
Hello. I also had to pass a Trustwave PCI scan, and this is what I finally did, after hitting my head against the monitor. 1) Recompiled Apache in order to have the latest OpenSSL in place. 2) Changed the following settings in WHM: FOR APACHE (Service Configuration / Apache Configuration / Global Configuration): - SSL Cipher Suite: ALL:!ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-SSLv3:-TLSv1:-EXP - SSL/TLS Protocols: leave the PCI recommended or default setting. FOR DOVECOT: (Service Configuration / Mailserver Configuration): - SSL Cipher List: ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP:-TLSv1 That finally worked for me. Since this seems to be a very recurrent issue, let's have this post guys with the latest useful tips about Trustwave findings. Regards 0 -
Thanks for the post. Have you tested any email clients against that dovecot configuration? 0 -
Thanks for the post. Have you tested any email clients against that dovecot configuration?
No, sorry. Our mail service is not working on the same box. We only send out some system messages, nothing coming in really.0 -
I was able to pass with a mitigation document for the email ports with TLSv1 on with these settings: Dovecot SSLCipherSuite: HIGH:!aNULL:!eNULL:!PSK:!RC4:!MD5 Protocols: !SSLv2 !SSLv3 !TLSv1 Exim tls_require_ciphers ALL:!ADH:RC4+RSA:+HIGH:-MEDIUM:-LOW:-SSLv2:-EXP:!RC4 This configuration allows TLSv1, so it needs the mitigation documentation, but does not break Outlook 2007. 0 -
Thanks for the post. Have you tested any email clients against that dovecot configuration?
The "-TLSv1" will break ALL versions of Outlook. I tested with 2007 and 2013 and both were broken. The best we can hope for now is to remove the ciphers and allow Outlook to use TLSv1, then submit the mitigation document that allows us to continue using TLSv1. That results in a pass for Trustwave, for now.0 -
FOR APACHE (Service Configuration / Apache Configuration / Global Configuration): - SSL Cipher Suite: ALL:!ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-SSLv3:-TLSv1:-EXP - SSL/TLS Protocols: leave the PCI recommended or default setting.
I'm attempting to implement this for just one customer, utilizing their .htaccess file, which should work in theory, but I can't seem to get it working. In the customer's .htaccess file, I have:SSLCipherSuite ALL:!ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-SSLv3:-TLSv1:-EXP
However, when I run their site through the SSL checking at Qualys, it still shows the customer's site as using TLS v1.0. Any tips on this would be greatly appreciated. Also, if anyone has successfully submitted a "TLS v1.0 Mitigation" document to Trustwave and is willing to share what you put in there, that would be super helpful. - Scott0 -
Scott, Serra shared a mitigation plan earlier, hope this helps: 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 -
Scott, Serra shared a mitigation plan earlier, hope this helps:
I used the same document for two companies now, so I believe it is good.0 -
Serra, I was having the same issue you described running a CentOS 6.6, WHM 11.5 server. TrustWave scans passed, but unable to connect via Thunderbird 38.1 or Outlook 2013 on port 993. I ended up removing the !SSLv3 text from the SSL Cipher List under Service Configuration > Mailserver Configuration, while still using this format "!SSLv2 !SSLv3 !TLSv1" under SSL Protocols. I can get successful handshakes on tlv1_1 and tlsv1_2, but not tlsv1, ssl3 or ssl2 using the following via SSH: openssl s_client -connect myserver.com:993 -ssl3 Perhaps I'm mistaken, but removing SSLv3 from SSL Ciphers wasn't the right approach. Here is my current config: Service Configuration > Mailserver Configuration SSL Ciphers: HIGH:!aNULL:!eNULL:!PSK:!RC4:!MD5:!ADH:!EXPORT:!LOW SSL Protocols: !SSLv2 !SSLv3 !TLSv1 Service Configuration > Exim > Advanced Editor open_ssl_options = +no_sslv2 +no_sslv3 +no_tlsv1 Unsure yet if this will cause TrustWave to fail PCI Compliance. Waiting to see.... 0 -
Hello. I also had to pass a Trustwave PCI scan, and this is what I finally did, after hitting my head against the monitor. 1) Recompiled Apache in order to have the latest OpenSSL in place. 2) Changed the following settings in WHM: FOR APACHE (Service Configuration / Apache Configuration / Global Configuration): - SSL Cipher Suite: ALL:!ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-SSLv3:-TLSv1:-EXP - SSL/TLS Protocols: leave the PCI recommended or default setting. FOR DOVECOT: (Service Configuration / Mailserver Configuration): - SSL Cipher List: ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP:-TLSv1 That finally worked for me. Since this seems to be a very recurrent issue, let's have this post guys with the latest useful tips about Trustwave findings. Regards
We have just tried the Cipher Suite mentioned above (SSL Cipher Suite: ALL:!ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-SSLv3:-TLSv1:-EXP)....unfortunately that breaks all but TLS 1.2 for us (when checking with SSL Labs) - See attached.0 -
So this seems to have dropped off since August. Does anyone have any update on this? I know this is pretty much waiting for software vendors like MS and Apple to get on board just curious if anything has been heard. I have apache and FTP compliant currently just waiting on email. Any change I currently make breaks Outlook, IOS, webmails etc. 0 -
Same here. Just waiting for the stuff to hit the fan and this become an issue for people. Email is still an issue for me, I've remained compliant by getting an exception. However, Trustwave now wants me to do the exception each month! Right now, Outlook breaks with any compliant change I make. My Apache is also not compliant, turning off TLSv1 breaks a mess of browsers for SSL. We just need to sit on this until April or May when it starts to become a media issue. I've only seen one article on this in a tech blog that actually talked about the problem so far. 0 -
Here is an alternative approach, if your primary goal is just to get through the scan temporarily, while better solutions are developed: 1) Since customers that have SSL also must have a dedicated IP, you can use your firewall (such as CSF) to block all the ports they scan, except for port 443 (SSL). This way, you don't have to worry about what TLS version you run for email... because it appears you have no email server at all. In DNS, MX record is set to "mail.domain.tld" and that entry points to the main IP of the server, not the customer's IP. So, customers can still send/receive email... it is all done on the server's main IP, and not the customer's dedicated IP. 2) To get the website to pass, you will need one modification to Apache. Here are the steps: [LIST] - Create this file: /usr/local/apache/conf/userdata/ssl/2_4/username
- Put the following into that file: SSLCipherSuite ALL:!ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-SSLv3:!TLSv1:-EXP SSLProtocol All -SSLv2 -SSLv3 -TLSv1
- Rebuild Apache with: /scripts/rebuildhttpdconf
- Restart Apache with: /scripts/restartsrv_apache 3) After the scan is complete and passes, the customer can either be OK with losing some customers due to the above config blocking older browsers/computers... or they can have you reverse this procedure... until they fail again, in which case you can put it back for the next scan. Hope this helps. - Scott
0 -
Here is an alternative approach, if your primary goal is just to get through the scan temporarily, while better solutions are developed
That is a good work around. Right now, we only have to 'pass' once every three months to stay compliant, so that works well. I very much hope a permanent solution will be forthcoming. I just don't know what that will be. There doesn't seem to be any movement on this from big companies.0 -
Digging this back up. Anyone have a clue if Microsoft is going to do anything to make outlook compatible with TLS v1.1 or 1.2? I've found some manual instructions but not exactly convenient to do registry edits on a ton of computers not on a directory, nor is there any guarantee they don't get wiped out during an arbitrary office update. The heartbleed deadline is going to roll around really quick and I haven't heard any news that microsoft is going to do anything with outlook. 0 -
There has been zero movement on this since we started this thread about the issue. I suspect that Microsoft will have to come up with a solution OR the compliance date will need to be moved. I've always felt that as the deadline approaches, that some heat will be generated on this issue. Until then, we just sit and wonder what will happen because this is all clearly outside of our control. I've been reading anything dealing with the subject and I did see a blog about the issue that sort of rehashed what we've been discussing, but it was burred on a tech blog and never got front page status. 0 -
Security Metrics Pass Qualsys SSL Labs A+ with Robust Forward Secrecy Beast, Poodle (SSLv3/TLS), Crime, and Heartbleed mitigated server side Cpanel Web Services SSL Cipher List ALL:!ADH:+HIGH:-MEDIUM:-LOW:-SSLv2:-SSLv3:-TLSv1:-EXP:-RC4:-CBC TLS/SSL Protocols !SSLv2:!SSLv3:!TLSv1 Apache SSL Cipher Suite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK SSL/TLS Protocols ALL -SSLv2 -SSLv3 -TLSv1 +TLSv1.1 +TLSv1.2 0 -
TLS/SSL Protocols !SSLv2:!SSLv3:!TLSv1
That was really the first configuration we tested. Works perfect, passes all of the Trustwave tests and gets an A+ for Qualsys SSL Labs. Of course the down side is that no one with Outlook will be able to connect to the server. A large number of older android customers will not be able to use SSL, but beyond those two issues, it is perfect.0 -
Yea that is the downside. I had another one that was safer for legacy clients but once TLS 1.0 resulted in a PCI failure I had to scrap it. Hope my suggestion works for anyone in the same boat. :) 0 -
Yea that is the downside. I had another one that was safer for legacy clients but once TLS 1.0 resulted in a PCI failure I had to scrap it. Hope my suggestion works for anyone in the same boat. :)
You should be able to get an automatic deferment on removing TLSv1 until June of 2016.0 -
Cpanel Web Services SSL Cipher List ALL:!ADH:+HIGH:-MEDIUM:-LOW:-SSLv2:-SSLv3:-TLSv1:-EXP:-RC4:-CBC TLS/SSL Protocols !SSLv2:!SSLv3:!TLSv1
This causes Firefox to show a "ssl_error_no_cypher_overlap" error and refuse to proceed, while other browsers seem fine with it. Any ideas?0 -
They finally realized this was completely impossible and unrealistic. The date has been extended to June 2018. pcisecuritystandards.org/pdfs/15_12_18_SSL_Webinar_Press_Release_FINAL_%28002%29.pdf 0 -
They finally realized this was completely impossible and unrealistic. The date has been extended to June 2018. pcisecuritystandards.org/pdfs/15_12_18_SSL_Webinar_Press_Release_FINAL_%28002%29.pdf
Thanks for the update! What a relief.0
Please sign in to leave a comment.
Comments
119 comments