Deprecation of TLS 1.0

Summary

PCI standards require that TLS 1.0 can no longer be used for secure communications. All web servers and clients must transition to TLS 1.1 or above.
Comodo will disable TLS 1.0 on our web properties on 12th June 2017. Our servers will refuse connections to servers using TLS 1.0 from that date
All partners using the Comodo API to order certificates should ensure that their API-calling systems support TLS 1.1 (or higher) by 12th June to avoid failed orders as TLS 1.0 will not be an available protocol on our servers by that date. If your website relies in any part on TLS 1.0, you are advised to disable it and transition to TLS 1.1 or above. Disabling TLS 1.0 support will help avoid future service interruptions and potential data loss.
Visitors and customers who attempt to connect to our websites with a browser which does not support TLS 1.1 or above will be automatically redirected to a help page which explains how to update their browser.

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

To ensure compliance with the PCI DSS standards, Comodo will disable support for TLS 1.0 on our web-facing systems on 12th June 2017.
All Comodo partners and customers are also encouraged to disable TLS 1.0 on their own web properties and transition to TLS 1.1 or above. The PCI regulations apply to anybody who accepts online payments by credit card.
Comodo API users must switch to TLS 1.1 or above to ensure that orders can be completed successfully.

Why should PCI standards affect API calls?

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.

What is the risk?

Among other weaknesses, TLS 1.0 is vulnerable to man-in-the-middle attacks, risking the integrity and authentication of data sent between a website and a browser. Disabling TLS 1.0 support on your server is sufficient to mitigate this issue.
Because Comodo will end support for TLS 1.0 on 12th June, all connections to our properties using the protocol will not be accepted. API users are therefore strongly encouraged to configure their servers to support TLS 1.1 or above well before this date.

What's a man-in-the-middle attack?

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.

How can I fix this issue?

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:

Web servers

Disabling TLS 1.0 support or CBC-mode ciphers with TLS 1.0 is sufficient to mitigate this issue.

How to disable SSL 3.0 on Apache, NGINX and IIS
How to check whether your website is vulnerable

Browsers

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:

https://www.comodo.com/e-commerce/ssl-certificates/tls-1-deprecation-browsers.php

How to disable TLS 1.0 and below on Apache, NGINX and IIS

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.

Apache

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.

apachectl configtest

sudo service apache2 restart

NGINX

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

IIS

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.

HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols

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.

How to check whether your website is vulnerable

Enter your website URL at: https://sslanalyzer.comodoca.com
On the results page, scroll down to the ‘Protocol Versions’ section.
Sites with TLS 1.0, SSL 3.0 and SSL 2.0 will be reported as ‘Vulnerable’