We will be closed Monday, September 1st in observance of the U.S. Labor Day holiday. More info »

Blog

  • SSL: Beyond the Basics

    Part 1: Protocol Selection

    Here at Thycotic 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 Unsecure Versions: SSL 2.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.

    SSL 3.0 is still considered safe for use and is supported by almost every major browser – even Internet Explorer 6 supports version 3.0. Therefore, there is little reason to have SSL 2.0 enabled and turning it off should not be a problem.

    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.

    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:

    1. Create a registry key
      HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSchannelProtocolsTLS 1.1
    2. Under the new TLS 1.1 key, create a Client subkey and Server subkey.
    3. Create a 32-bit DWORD in both the Client and Server subkey called “Enabled” and set its value to 1.
    4. Create a 32-bit DWORD in both the Client and Server subkey called “DisabledByDefault” and set its value to 0.
    5. Repeat this process for TLS 1.2 by substituting “TLS 1.1” with “TLS 1.2” in the first step.
    6. 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.

    Consider Disabling SSL 3.0

    SSL 3.0 is, for the most part, considered secure enough for use in production. However, it is on its way out due to a reliance on the weak MD5 hashing algorithm, among other factors. TLS 1.0 is the next step beyond SSL 3.0. All modern browsers support at least TLS 1.0, except, notably, Internet Explorer 6 on Windows XP, which does not support TLS at all.

    Perform an audit to determine if SSL 3.0 is needed for a server where Secret Server resides. If SSL 3.0 isn’t needed, disable it on the server-side in the same fashion that SSL 2.0 is disabled.

    Wrap up

    Our takeaways are:

    1. There is no practical reason for SSL 2.0 to be enabled anymore. Disabling it ensures unsecure clients don’t attempt to use it.
    2. SSL 3.0, while still considered acceptable, should at least be examined to determine if it is necessary, and removed if unnecessary.
    3. Enabling TLS 1.1 and 1.2 offers more robust security than SSL.
    4. 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 preference for the more secure suites. Check back next week for more details!

     

     

     

     

     

    Leave a reply →

Leave a reply

Cancel reply