Management QuickStart
SSL/TLS is one of the most popular technology that aims at, mainly through cryptography, securing communication between different networks. SSL provides a way for two parties to establish a session and transfer data over the session while ensuring privacy, confidentiality and integrity. All secure communications on the internet at this moment use this same technology (HTTPS). Some of the popular software applications that use SSL are VPNs and Web Browsers. For example, in client-server environment, an SSL link ensures that all data passed between the web server and browsers remain private and integral. SSLv2 and TLSv1 are the 2 versions of this protocol (SSLv1 was never publicly released). After TLSv1, SSL was renamed to TLS. Those protocols are standardized and described by RFCs.
Protocol:
TLSv1 is not safe. It has a few critical vulnerabilities and is rightly being decommissioned by a lot of popular vendors and product manufacturers. There have been major flaws found with TLSV1 protocol such as Beast. There were other factors too apart from the vulnerabilities that led to TLSv1 being marked as an obsolete technology. Since this is a flaw in the official definition and standardization of the protocol, the only option to fix this issue is to upgrade the version of SSL (now being called TLS) being used. Note that upgrading the protocol does not result in any difference in what SSL was intended to do (secure communication), an upgrade to the protocol simply means that the technology is patched for flaws that could compromise the security of the product using it.
High-level Action Plan:
- Disable TLSv1 on all systems. Should be used in no capability whatsoever.
- Upgrade to TLSv1.2 is recommended. TLSv1.1 can also be considered for a temporary basis. Have the appropriate teams (Ex: IT and Development) clearly informed and prepared for an upgrade.
- Connectivity to these systems using TLSv1 could be affected because of the upgrade. Ensure proper migration plan to avoid implications like unnecessary downtime.
- Run an audit to make sure that the upgrade was successful.
- In any case if an upgrade is not possible, it is recommended in the interest of security to turn off all SSL connectivity to the system (Ex: remote access VPNs, web page hosting over HTTPS).
Implementation:
Note: Only think about Implementation if you are in a situation where legacy hardware or software cannot be upgraded to support at least TLSv1.1
A lot of vendors who support TLSv1 should provide software patches that should help prevent protocol vulnerabilities. If any of these patches are present and can be implemented on a system that runs TLSv1, they should be done immediately. This would require extensive research of specific products and therefore there is no documentation on this site (except examples under IT or Dev Quickstart). General practices for good patch management should be followed. For example, the patches should be verified for genuineness and the patch should specifically solve problems with TLSv1. It should also be noted that patches will only work if both sides of a connection (client and server) have been patched.
High-level Action Plan:
- List down hardware or software that cannot be upgraded.
- Gather the respective teams responsible for administration and management of these devices or technology.
- Teams should be tasked with finding the patches and devising a plan to implement them ASAP.
- Consider any sort of verification process to audit these patches.
- Devise a long term plan to replace the hardware or software to support TLSv1.1 at the least.
Configuration:
TLSv1.2 offer a few options with configuration. Some of these are Cipher Suites, Key lengths, Hash Functions used by your CA to sign your keys. Keep in mind that the security of your system is only as strong as the weakest link in the chain. For example, a strong cipher alone does not guarantee good security. The keys and the certificates are just as important, as well as the hash functions and keys used by the Certification Authority (CA) to sign your keys. The parameters for these settings depend on the version of SSL/TLS that is being used and therefore great care must be taken in choosing the best combination of the above settings.
High-level Action Plan:
- Gather teams that are responsible for configuring TLSv1.2. Teams who take care of Cipher Suits, Key lengths, Hash Functions used by your CA to sign your keys, are very important.
- Have team research the best set of parameters to be configured to provide maximum security with TLSv1.2. These details can be found on this site under IT and Dev Quickstarts.
- Keep in mind interoperability with different devices that support TLSv1. The configurational changes should match on both the ends of any TLSv1.2 connections.
- Changes in configuration can be done on the fly on a lot of products. Take steps to ensure unnecessary downtime.
- If there are no changes possible on any devices, there are no alternatives to fixing security problems with TLSv1.