When a browser communicates to a web server, the recommendation is to ensure the web site uses an encrypted connection - otherwise anyone can see all your private data. Although users are told to look for the padlock icon next to the web address, or make sure the web address begins with https://, many protocols that handle the encryption of that link are no longer considered secure.

If you are responsible for managing a server, or are responsible for ensuring browsers only communicate in a secure way, you need to ensure your systems are configured in a way that ensures the encrypted links really are secure.

What is at risk?

Web servers and browsers that allow encryption to be established using old and obsolete protocols put all the data transmitted over the network at risk. Browsers and servers often leave support enabled in case it is required, which removes the protections afforded by modern protocols.

Recommendations

• Disable support for SSLv2 and PCT on servers and browsers. These protocols are known insecure since 1995
• Disable support for SSLv3 on servers and browsers. This protocol is known insecure since 2006
• Disable support for TLS 1.0, or at least disable compression, on servers and browsers. This protocol is known exploitable since 2011. Further, no credit card handling system will be permitted to support this protocol in 2018.
• Disable support for weak ciphers, including DES, 3DES, RC4. These ciphers are known breakable.
• Ensure support for modern ciphers (AES), modes (GCM) and protocols (TLS 1.2)

What are the impacts to disabling protocols? Will this deny access to users?

All major browsers have supported the most modern of protocols since 2014, and have supported acceptable older protocols (such as TLS 1.1) for eight years or more. In short, if a browser does not support secure protocols, the system the user is coming from is very likely compromised, and should not be trusted to connect.

All trustworthy web server software has supported protocols almost as soon as they have been released. If a web site does not support modern or acceptable modern protocols (TLS 1.1 or TLS 1.2), then it is also likely that website itself cannot be trusted, and you should not be sharing data with that site.

How do I configure my webserver?

For Apache web servers, use the configuration lines below

SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS 

A Quick History of SSL/TLS

July 1994	SSLv1	Netscape Communications developed SSL (Secure Sockets Layer) to handle the encryption over a web browser/web server link. SSLv1 was in use internally within Netscape and reportedly cracked within the first 10 minutes of it being shown to MIT students. It was never released to the public.
Nov 1994	SSLv2	Version 2 of the SSL protocol suite, released by and a proprietary product of Netscape. Significant flaws discovered a few months after release. SSLv2 was officially withdrawn less than a year later.
Oct 1995	PCT 1.0	Microsoft release a competing standard to SSL named PCT (Private Communications Technology). Supported in Microsoft products only and the source of significant exploits over the years. It has not been supported in any browser since IE5, but is still supported by current versions of IIS.
Nov 1995	SSLv3	Released to address significant exploited SSLv2 and PCT flaws.
Jan 1999	TLS 1.0	International standard specification of the SSL/PCT security protocols, named TLS (Transport Layer Security). TLS 1.0 and SSLv3 are largely identical.
Apr 2006	TLS 1.1	Update to address potential flaws determined by researchers in TLS 1.0. These flaws were exploited by a global and devastating cyberattack named BEAST in 2011 (6 years after TLS 1.0 was superseded).
Apr 2008	TLS 1.2	Update to address potential flaws determined by researchers in TLS 1.1. These flaws have not been observed to be exploited (yet).
May 2013	Edward Snowdon	Whistleblower reveals state of insecurity across the internet, and how it is being actively exploited by (at least) NSA
Aug 2013	TLS 1.3	Work begins on an update to TLS 1.2 addressing, amongst other issues, weaknesses revealed by Snowdon
Late 2013/early 2014		Chrome, Safari, IE and Firefox all add support for TLS 1.2.
Oct 2015		A cyberattack named POODLE exploits flaws in SSLv3. 10% of all internet servers found vulnerable, despite flaws identified and corrected 15 years previously
Mar 2016		A cyberattack named DROWN exploits flaws in SSLv2. 33% of all internet servers found vulnerable, despite flaws identified and corrected 21 years previously
Jul 2016		PCI Council releases edict that a requirement of PCI-DSS compliance is that any site that handles credit card data must not support TLS 1.0 or lower.  Full compliance is required prior to July 2018.
Jul 2017		Paypal discontinues support for TLS 1.0 and TLS 1.1. All merchant connections can only use TLS 1.2. Consumer websites (eg www.paypal.com) will also be restricted to TLS 1.2 before end 2017.