Part 1: Protocol selection
Here at Delinea we have a wide range of recommended security best practices for our customers, and one of the first things we recommend is setting up SSL, or Secure Socket Layer, for Secret Server.
Setting up SSL is fairly trivial once an SSL certificate is obtained. Once it’s set up, SSL provides a few different security layers. The first security layer is that web traffic is encrypted between the client (such as a browser) and the server. This prevents eavesdroppers from seeing data communicated between the client and server. The second is providing confidence that the client is communicating with the server it believes it is communicating with, which mitigates Man in the Middle attacks.
There is a lot that can be done to enhance the protection provided by SSL, and the first step is understanding the SSL protocol versions and features.
SSL and the version negotiation
SSL is commonly used interchangeably for SSL and TLS, or Transport Layer Security. TLS is SSL’s successor. There are different versions of TLS and SSL, and each version supports different features.
When a client establishes a connection with a server, the first step is a negotiation, where the client and server have to agree on what protocol version to use. The negotiation between client and server usually starts with the most secure option and progresses to least secure. Both the client and server have the right to refuse a protocol version, and they go down the list until an agreement can be made.
A key reason for this negotiation is it provides the ability to remove old and untrustworthy versions of SSL or TLS. If a vulnerability were ever to be discovered in one of the versions, servers and clients can be updated to refuse communication through that version. Likewise, new protocols can be added to a client’s or server’s list of supported options. Because a server could support a newer protocol version than the client browser supports, the version negotiation is needed to settle on a version that is supported by both sides.
Disable insecure versions: SSL 2.0 and 3.0
SSL 2.0 is widely considered broken, and unsafe for secure communication regardless of the strength of the digital certificate. Most clients will refuse to use SSL 2.0 for this very reason. Just in case, it’s a good idea to disable SSL 2.0 from the server-side where Secret Server is installed to proactively stop clients from using an old version of SSL.
Fortunately, Windows Server 2012 and 2012 R2 already disable SSL 2.0, so there is no action to take there, but if you use other versions of Windows Server, such as 2008 and 2008 R2, you will have to disable SSL 2.0 manually.
Disabling SSL 2.0 is easy enough for those older platforms. Microsoft has a support article available on their site under KB 187498 that walks through the process and provides a tool to automate the change.
On October 14th, 2014, Google announced a vulnerability for SSL 3.0 called POODLE, which outlines a design flaw of SSL 3.0. It is strongly recommended that SSL 3.0 be disabled by following the same instructions for disabling SSL 2.0. SSL 3.0 by default is enabled for all versions of Windows today.
Enable secure versions: TLS 1.1 and 1.2
As we mentioned above, TLS offers better security than SSL, with TLS 1.2 offering the best. TLS 1.2 offers support for authenticated ciphers, such as AES-GCM, and an improved pseudorandom function to rely on SHA256.
Windows Server 2012 and 2012 R2 offer both of these protocols by default, so there is nothing that needs to be done to enable them.
Windows Server 2008 R2 supports these protocols, but they must be turned on manually. Microsoft’s KB 235030 explains a more detailed way to enable these protocols. The steps are this:
- Create a registry key
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSchannelProtocolsTLS 1.1 - Under the new TLS 1.1 key, create a Client subkey and Server subkey.
- Create a 32-bit DWORD in both the Client and Server subkey called “Enabled” and set its value to 1.
- Create a 32-bit DWORD in both the Client and Server subkey called “DisabledByDefault” and set its value to 0.
- Repeat this process for TLS 1.2 by substituting “TLS 1.1” with “TLS 1.2” in the first step.
- Reboot the server.
Unfortunately, for Windows Server 2008 and older, TLS 1.1 and 1.2 are not available at all. In this case, we recommend upgrading the operating system. Another option is to use a reverse proxy that does support TLS 1.1 and 1.2, either hardware or software, to offload the SSL responsibility from the server to the reverse proxy.
Wrap up
Our takeaways are:
- There is no practical reason for SSL 2.0 to be enabled anymore. Disabling it ensures unsecure clients don’t attempt to use it.
- SSL 3.0 should not be used anymore due to the POODLE attack.
- Enabling TLS 1.1 and 1.2 offers more robust security than SSL.
- Windows Server 2012 and 2012 R2 already come configured with SSL 2.0 disabled and TLS 1.1 and 1.2 enabled out of the box.
What’s next?
A key component to SSL is the cryptographic algorithms underneath the covers. These algorithms make up the cipher suite. The cipher suites accepted during the negotiation step above have a big impact on security. This can be improved by disabling weaker cipher suites and setting up a preference for the more secure suites. Check back next week for more details!
This post was updated on October 14th, 2014 to recommend disabling SSL 3.0 after the POODLE flaw was announced.
Read All Parts:
SSL: Beyond the Basics Part 1
SSL: Beyond the Basics Part 2: Ciphers
SSL: Beyond the Basics Part 3: Certificates
SSL: Beyond the Basics Part 4: Strict Transport Security
What does cybersecurity like this cost? Not as much as you think
