8/9/2019 WHICH SSL

http://slidepdf.com/reader/full/which-ssl 1/6

WHICH SSL/TLS PROTOCOL VERSIONS AND CIPHER SUITESSHOULD I USE?

Our customers d evelop and deploy p roducts t hat rely S SL/TLS to p rotect thecondentiality a nd integrity o f Web, VPN, e-mail, and other traffic. We are often askedhow to congure SSL/TLS libraries o n servers t o avoid any k nown s ecurityvulnerabilities, specically, regarding which protocol versions and cipher suites should beenabled. In this p ost we list new features i ntroduced in and vulnerabilities r esolved byeach new version of SSL/TLS, and describe how to select the most secure cipher suiteswhile maintaining backward compatibility. Certain SSL/TLS versions a nd cipher suiteswere recommended o r enabled b y de fault in the p ast for backward c ompatibility a nd

even security reasons; here, we hope to clarify current best practices.

Two c onguration p arameters a re c ritical when h ardening a n SSL/TLS-based s ervice:the allowed SSL/TLS versions, and the allowed cipher suites. These parameters sh ouldbe set according to best practices, but these are not always clear; plus, in the constantlyevolving world of security, yesterday’s b est recommendation for resolving one securityissue can become today’s vu lnerable conguration. In this p ost, we briey review thehistory of the different versions o f SSL and TLS, describe the most secure and m odern

cipher suites a vailable, and provide our recommendations f or both conguration settings.Don't forget to congure and update load balancers, reverse proxies, embedded devices,appliances, or other SSL/TLS servers a s w ell as t raditional servers. For example, due toa padding implementation bug, unpatched F5 and A10 devices a re vulnerable toPOODLE even when TLS is used [1] .

SSL/TLS Protocol VersionsSSL/TLS libraries and applications using them allow the administrator to restrict theversions o f SSL/TLS allowed, usually a s p art of the security h ardening conguration.Five versions o f SSL/TLS are widely su pported in library co de: SSL 2.0, SSL 3.0, TLS1.0, TLS 1.1, and TLS 1.2. All of these versions a re affected by a t least one securityissue requiring a workaround or special conguration to avoid, and the two earliestcontain s evere aws t hat cannot be worked around without breaking c ompatibility. Webriey describe the history of the different versions o f SSL/TLS and show how each canor cannot be s ecurely us ed today w hen correctly co ngured.

8/9/2019 WHICH SSL

http://slidepdf.com/reader/full/which-ssl 2/6

Protocol Action

SSL 2.0 Disable

SSL 3.0 Disable

TLS 1.0 Disable when possibleTLS 1.1 Enable

TLS 1.2 Enable

Recommended conguration for each version of SSL/TLS.

SSL 2.0 was r eleased in 1995. It contains a number of cryptanalytic d esign aws w hichcannot be worked around without breaking the protocol and could lead to the exposureor modication of condential data. SSL 2.0 should never be used on the modernInternet. When encountered today, SSL 2.0 is u sually e nabled as a result of an accidentor weak d efault conguration.Result: Disable S SL 2.0 without regard to backward compatibility.

SSL 3.0 was r eleased in 1996 as a full re-design. Google's POODLE attack leveragesbrowser scripting capabilities a nd the broken p adding implementation in SSL 3.0 tolaunch man-in-the-middle attacks, which could lead to the exposure or modication ofcondential data [2] . Two workarounds co uld allow SSL 3.0 to remain in use whileresolving POODLE:

1. Disable all CBC mode cipher suites w hen communicating with a n S SL 3.0 client;stream ciphers d o not use padding and are therefore not vulnerable. Unfortunately,the only non-CBC cipher widely su pported, RC4, is su sceptible to additionalsecurity issues of its own.

2. A new pseudo-cipher suite recently ad ded to TLS, TLS_FALLBACK_SCSV , helpsto detect downgrade attacks t o resist an attacker's a ttempts to force a victim todowngrade to SSL 3.0 [3] . As o f this w riting (early 2015), TLS_FALLBACK_SCSV isnot yet universally supported, and the clients that do support it are likely to supportTLS 1.0 anyway.

For the reasons st ated, we recommend disabling SSL 3.0 rather than relying on either ofthese w orkarounds.Up until 2014 m any p ublic se rvers co ntinued to s upport SSL 3.0 for backward

compatibility, despite its s upersession by T LS fteen years b eforehand. This t rade-off isnow unacceptable in light of the irreparable POODLE vulnerability. Disabling SSL 3.0

8/9/2019 WHICH SSL

http://slidepdf.com/reader/full/which-ssl 3/6

ensures t hat software cannot miscongured to use it, and that attackers cannot force aclient and server to downgrade to it.Result: Disable S SL 3.0 without regard to backward compatibility.

TLS 1.0 was r eleased in 1999 as a revision to SSL 3.0. Among the modications to theprotocol was a new padding scheme, and as a result TLS 1.0 is n ot vulnerable to thePOODLE attack when TLS padding is in use.However, TLS 1.0 is vulnerable to the BEAST attack , which leverages browser scriptingcapabilities a nd weaknesses i n the use of initialization vectors e mployed whenencrypting with a block ci pher in CBC mode [4] . BEAST can b e worked a round withoutbreaking the TLS 1.0 protocol in one of two ways:

1. Disable all CBC mode cipher suites; stream ciphers a re not vulnerable.

Unfortunately, the only n on-CBC cipher widely su pported, RC4, is su sceptible toadditional security issues of its own.

2. Modify TLS client and server libraries t o add a "tweak" to the way in which thesoftware communicates, called "insert empty fragments".

If TLS 1.0 must be supported, then we recommend ensuring that both the client andserver follow the "insert empty fragments" workaround, rather than switching to RC4.Many servers co ntinue to support TLS 1.0 for backward compatibility, as so me widely-

deployed software d oes n ot support later versions o f TLS (e.g., Windows XP, WindowsServer 2003, OpenSSL 0.9.8), while other software, including Mozilla Firefox, did notimplement TLS 1.1 until many years a fter its i ntroduction in 2006. TLS 1.0 users w howish to use workarounds r ather than discontinue support must be diligent in ensuringtheir TLS libraries a re up to date and properly co ngured. We recommend that usersinstead upgrade unless a specic b ackward compatibility issue precludes d isabling TLS1.0.Result: Disable TLS 1.0; re-enable if backward compatibility issues arise.

TLS 1.1 was r eleased in 2006 as a revision to TLS 1.0. Among the modications t o theprotocol is a new IV generation scheme; thus, TLS 1.1 is n ot susceptible to BEAST.While attacks have been successfully launched against specic TLS 1.1 features, suchas co mpression (CRIME) and renegotiation, workarounds e xist that do not breakprotocol compatibility. Note: these issues a ffect TLS 1.2 as w ell.TLS 1.1 users s hould be diligent in ensuring their TLS libraries a re up to date andproperly co ngured to e nable s ecurity workarounds a ccording to current best practices(e.g., disabling compression, and enabling the RFC 5746 renegotiation workaround).Result: Enable TLS 1.1.

8/9/2019 WHICH SSL

http://slidepdf.com/reader/full/which-ssl 4/6

TLS 1.2 was r eleased in 2008 as a revision to TLS 1.1. As of this w riting, it isunnecessary to upgrade from TLS 1.1 to 1.2 in response to any known, exploitablevulnerabilities, but TLS 1.2 introduces useful features such as h igher-performance GCM

cipher suites and a SHA-256 based pseudorandom function. GCM cipher suites also useprovide a uthenticated encryption, replacing TLS’s t raditional Encrypt-then-Authenticatescheme.TLS 1.2 users s hould be diligent in ensuring their TLS libraries a re up to date andproperly co ngured to e nable s ecurity workarounds a ccording to current best practices(e.g., disabling compression, and enabling the RFC 5746 renegotiation workaround).Result: Enable TLS 1.2.

Cipher SuitesThe SSL/TLS protocols w ere designed to be extensible and modular, allowing theserver/client authentication, key e xchange, encryption, and message integrity ( MAC)protocols t o be changed without replacing the entire protocol. The most recent ciphersuites u se R SA, ECDH, or ECDSA for authentication, ECDHE for key exchange, AES forencryption, and GCM for integrity, but a large number of older and backward-compatibility cipher suites also exist. We split the cipher suites into three categories:those that should always b e enabled for the best security p ossible, those that can be

enabled if desired for compability, and those that should always b e disabled due tosecurity weaknesses.

Recommended Cipher SuitesAdministrators s hould be sure to enable the following cipher suites.

ECDH/DH AES cipher suites. These newer cipher suites u se Elliptic-Curve DiffieHellman (ECDH) and Diffie-Hellman (DH) for key e xchange. Unlike o lder cipher suitesthat use static R SA based on the server's p ublic key for this purpose, passively-capturedECDH/DH traffic ca nnot be d ecrypted, even if the s erver's pr ivate ke y is co mpromisedlater. This feature is known as forward s ecrecy .

AES cipher suites. P lain AES cipher suites a re used by c lients t hat do not support

ECDH/DH cipher suites, or have them disabled.

8/9/2019 WHICH SSL

http://slidepdf.com/reader/full/which-ssl 5/6

8/9/2019 WHICH SSL

http://slidepdf.com/reader/full/which-ssl 6/6

Wi-Fi networks, with catastrophic r esults. While SSL/TLS is n ot vulnerable to orexploitable by the sa me techniques as W EP, the u nderlying weakness i n RC4nonetheless exists, and security researchers at Microsoft and other companies nowrecommend that it be d isabled [5] .This a dvice may be surprising to many IT professionals, as o ne of the immediaterecommendations t o the BEAST vulnerability just a few years a go was t o disable a llciphers e xcept RC4. However, current best practices st ate that RC4 itself should bedisabled.

FutureTLS 1.3 is, as o f this w riting, currently u nder development and makes m ore substantialchanges to the protocol than previous revisions; in fact, it is the most signicant revisionto the protocol since SSL 3.0. In a reversal from previous p ractice, many w eak o rbackward-compatibility features, such as RC4, compression, and static RSAauthentication, are proposed to be dropped from TLS 1.3. As T LS 1.3 is d eployed,administrators should implement support when possible. In particular, as clients andservers m igrate to TLS 1.3, many workarounds a nd hardening steps w ill no longer benecessary.