The Payment Card Industry (PCI) Data Security Standard stipulates that the TLS 1.0 encryption protocol can no longer be used for secure communications. Any web servers which still support TLS 1.0 or below will fail the PCI standards and therefore will not be allowed to take credit card payments online. The PCI DSS standards can be read in full here: https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss
Comodo, along with every other web service provider, follows the PCI standards to keep our customer’s credit card details secure.
Of course, you don’t pass your credit card details when you call our APIs and you don’t provide credit card details when you take a free service from us, but we care about protecting data you supply when making a certificate application MORE than we care about protecting your credit card details, not less.
A theft or other interception of credit card details would be a ‘bad thing’™, but the credit card industry has fraud mitigation measures in place as well as the capacity to withstand a low level of fraud or other financial loss. The consequences of a loss of integrity of the secure channel protecting your certificate application details could be devastating for an individual site operator and their customers.
A well-placed hacker who has set up a 'man in the middle' server could theoretically recover data that would normally be encrypted. The most likely attack vector would be for the hacker to obtain the session cookies.
The 'Coffee shop' attack is an example of a 'man in the middle' attack (MITM). In this scenario, an attacker who is situated in the coffee shop would set up a laptop to broadcast a WiFi signal that looks the same as the coffee shop's WiFi. The victim then inadvertently connects to the attacker's WiFi instead of the coffee shop's WiFi. If the victim is using TLS 1.0 or below, all their internet traffic is now available to the attacker to intercept and record. This type of attack would usually be stopped if the connection was encrypted. However, with the vulnerabilities present in TLS 1.0, it would be theoretically possible to observer the data and/or spoof their own messages.
Web server operators should disable TLS 1.0 and below on their servers. Browser users should similarly use a browser with TLS 1.1 enabled. NIST guidelines for the selection, configuration and use of TLS are available here - http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf
The following articles contain advice to fix both web servers and browsers:
Disabling TLS 1.0 support or CBC-mode ciphers with TLS 1.0 is sufficient to mitigate this issue.
First and foremost, users should make sure they upgrade their browsers to the latest versions. Users should also ensure that TLS 1.1 is enabled and should disable TLS 1.0 and below. Users visiting our site with a vulnerable browser will be redirected to the following help page which explains how to upgrade their browser:
The most effective way to ensure your server is secure is to disable TLS 1.0 and below on your web-server. Please note, disabling TLS 1.0 on your website will most likely mean most XP/IE 6.0 users are no longer supported for secure sessions.
To disable TLS 1.0 on your Apache server you can configure it using the following.
SSLProtocol All -SSLv2 -SSLv3 -TLSv1
This will give you support for TLS 1.1 and TLS 1.2, but explicitly removes support for TLS 1.0 and below. Check the config and then restart Apache.
sudo service apache2 restart
To disable TLS 1.0 and below on your Apache server you can configure it using the following.
ssl_protocols TLSv1.1 TLSv1.2;
Similar to the Apache config above, you will get TLS 1.1+ support and no TLS 1.0 or SSL. You can check the config and restart.
sudo nginx -t
sudo service nginx restart
We strongly recommend that all users upgrade to Microsoft Internet Information Services (IIS) version 7.0 running on Microsoft Windows Server 2008. IIS 7.0
IIS requires some registry tweaks and a server reboot. Microsoft have a support article at https://support.microsoft.com/en-us/help/187498/how-to-disable-pct-1.0,-ssl-2.0,-ssl-3.0,-or-tls-1.0-in-internet-information-services which deals with this topic. All you need to do is modify/create a registry DWORD value.
In the protocols directory, you will most likely have an SSL 2.0 key already. Create keys called 'SSL 3.0' and ‘TLS 1.0’ alongside it if needed. Under those, create Server keys and inside them a DWORD value called ‘Enabled’ and assign it a value of 0.
Once that's done reboot the server for the changes to take effect.
Should you have any questions regarding the issuance of certificates with internal names, the status of existing certificates or if you require general advice with any of the points raised in this document, please contact your Comodo Account Manager or Comodo Support: