Transport Layer Security Done Right

Transport Layer Security Done Right

Michael Schneider
by Michael Schneider
time to read: 12 minutes

Transport Layer Security (TLS) and its predecessor Secure Sockets Layer (SSL) are encryption protocols to ensure secure communication on the internet. TLS is most often used to encrypt communication between websites using HTTP but it can used with POP3, SMTP, IMAP, XMPP or FTP. The level of security of such a connection depends on protocols, settings and cipher suites. When establishing a TLS connection the systems involved in it will negotiate the cipher suite and the protocol to use. In the TLS configuration, the protocols and cipher suites are defined and determined, which ones are to be preferred.

Often during security checks we discover that the configuration of these systems does not meet the requirements for a secure connection. This labs describes the basics of a secure TLS configuration and shows how it can be checked for security.

TLS Configuration

The TLS configuration of a system is made up of three parts:

Depending on the operating system, the library or the application software, the configuration ends up looking different. The necessary adjustments can be made using configuration files, the Windows registry or a graphic user interface. The recommendations in this Labs are viable for most common solutions. An overview of TLS configurations in general can be found in the documes SSL/TLS Deployment Best Practices, written by Ivan Ristić.

There are five protocols concerned with TLS/SSL:

SSLv2 is insecure and should be deactivated immediately. SSLv3 has not been updated since 1996, is considered to be obsolete and was replaced by TLSv1.0 which went on to become the standard.

On October 14th, 2014, the vulnerability known as POODLE (CVE-2014-3566) was made public. It exploits an error in SSLv3 to extract information from an encrypted connection. The only effective mitigation is up to this point the deactivation of SSLv3.

TLSv1.2 should be used as the main protocol and be preferred to all other protocols. TLSv1.0 and TLSv1.1, however must remain supported for reasons of backwards compatibility.

Apart from the choice of protocol, the support or the disabling of functions is crucial for the secure operation of any TLS infrastructure. The function Client-Initiated Renegotiation should be deactivated because it makes a Denial of Service Attacke against TLS infrastructures much easier. In September 2012, security researchers Juliano Rizzo and Thai Duong published the attack known as CRIME (CVE-2012-4929) that enables the extraction of sensitive data such as a session cookie from a secure TLS connection. The countermeasure: Deactivating TLS compression.

When estabslishing a TLS connection between client and server, a session key for encryption of the communication based on a public key principle is being negotiated. If someone has recorded such a communication, including the handshake and later gains possession of the server’s private key, he can use the key to decrypt the communication. The function Forward Secrecy mitigates this attack by negotiating a one-time-only key that can’t be deducted from the server’s private key after the negotiation. Forward Secrecy requires deployment of the cipher suites of the key exchange named Diffie-Hellman (DHE-RSA, DHE-DSS)_ and Elliptic Curves based on Diffie Hellman ECDHE-RSA, ECDHE-ECDSA)

Cipher Suites

A cipher suite is the combination of algorithms used during the following stages:

A Cipher Suite Explained

The choice of cipher suite for a TLS connection has significant influence on the security of said connection. When establishing a connection between server and client, the cipher suite is being decided on. That is why it’s important that cipher suites are only supported by TLS infrastructure that fulfills certain security criteria. Only cipher suites should be deployed that have a key length of 128 Bit or more. All other cipher suites are to be disabled. This should include – for security reasons – Triple DES (3DES). Although 3DES has a key length of 168 Bit (3×56 Bit) but due to knowledge of Meet in the Middle attacks an effective key length of 112 Bit should be enforced.

In March 2013 a research team of Royal Holloway, TU Eindhoven and the University of Illinois at Chicago has discovered an attack against RC4 (CVE-2013-2566). Therefore ciphers based on RC4 are considered to be insecure and should therefore not be used anymore. In 2011, the use of RC4 was recommended as a mitigation for the BEAST Attack (CVE-2011-3389). All widely used web browsers have since been updated and thus, RC4 cipher can be deactivated.

Certificate

The certificate is a further component of a secure configuration. A certificate should include all hostnames and domains in the field Common Name (CN) or as Subject Alternative Name (SAN) and – in addition to that – should be signed by a trustworthy certificate agency. In order for a certificate to be checked for its validity, the certificate by the agency must be established and recognized as trusted by all clients that access the system (i.e. web browsers). When generating the certificate, additional attention needs to be paid to the length of the private key. It should be at least 2048 Bit long.

Computer Security Specialist Bruce Schneier published an article on the security of the algorithm SHA 1 and pointed out that the generation of collisions (generation of an identical hash with different originating values) with the use of adequate computing power has come entered the realm of the possible. He concludes that SHA2/SHA3 should be starting to replace SHA1. Microsoft and Google announced that certificates with SHA1 will be considered to be less trustworthy from now on. Therefore, SHA256 should be used.

TLS Configuration Checklist

The following checklist contains all the mentioned recommendations for a secure TLS configuration as of October 2014:

Check TLS configuration

A ELS configuration can be checked by various means. Qualys SSL Labs offers a SSL Server Test which keeps being adjusted to the most recent developments in the field of security. The test reads out the configuration and evaluates it based on Best Practices. The test’s big disadvantage is that only publicly available domains can be checked. The use of IP addresses is not allowed. Also, only tests using port tcp/443 are supported.

Alternatively, all the test’s steps can be done manually by using OpenSSL. Security researcher Jerome Smith has published a compilation of OpenSSL commands that can be used to check a TLS configuration. Using the command openssl s_client -ssl3 -connect <ip-address>:<port> an SSLv3 connection can be established and subsequently, information can be read out. The server in our example uses the insecure protocol SSLv3, the cipher suite DHE-RSA-AES256-SHA has been negotiated, the function TLS compression is being supported and a key with the length of 2014 Bit is being used. Even using nothing but this establishing of a connection as a basis, multiple vulnerabilities can be deducted.

[user@host ~] openssl s_client -ssl3 -connect <ip-address>:<port>
CONNECTED(00000003)
...
---
SSL handshake has read 1020 bytes and written 369 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
...
---
closed

In order to check the configuration of cipher suites, the command openssl s_client -cipher NULL,EXPORT,LOW,3DES,RC4 -connect <ip-address>:<port> can be used to check if the system is supporting weak cipher suites. The output below shows that this is indeed the case. There’s a connection using cipher suite EDH-RSA-DES-CBC3-SHA.

[user@host ~] openssl s_client -cipher NULL,EXPORT,LOW,3DES,RC4 -connect <ip-address>:<port>
CONNECTED(00000003)
...
---
SSL handshake has read 1167 bytes and written 434 bytes
---
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression

The manual analysis using OpenSSL commands is not very efficient. For example, if you want to figure out which ciphers are supported, a request for every single cipher has to be sent individually. This check just like many others can be performed automatically using any one of a number of tools that check TLS configurations. One of them is SSLyze that runs on Windows, Mac OSX and Linux. SSLyze can read all supported cipher suites and lists the status of functions such as Session Renegotiation or TLS Compression. 

PS C:\> .\sslyze.exe --regular <ip-address>:<port>
...
* Session Renegotiation:
  Client-initiated Renegotiations:   OK - Rejected
  Secure Renegotiation:              OK - Supported
* Deflate Compression:
  VULNERABLE - Server supports Deflate compression
...
* Certificate - Content:
  ...
  Signature Algorithm:               sha1WithRSAEncryption
  Key Size:                          1024 bit
  Exponent:                          65537 (0x10001)
...
* TLSV1 Cipher Suites:
  Preferred:
	DHE-RSA-AES256-SHA            DH-1024 bits   256 bits      HTTP 200 OK
  Accepted:
	DHE-RSA-AES256-SHA            DH-1024 bits   256 bits      HTTP 200 OK
	AES256-SHA                    -              256 bits      HTTP 200 OK
	DHE-RSA-AES128-SHA            DH-1024 bits   128 bits      HTTP 200 OK
	RC4-SHA                       -              128 bits      HTTP 200 OK
	RC4-MD5                       -              128 bits      HTTP 200 OK
	AES128-SHA                    -              128 bits      HTTP 200 OK
	EDH-RSA-DES-CBC3-SHA          DH-1024 bits   112 bits      HTTP 200 OK
	DES-CBC3-SHA                  -              112 bits      HTTP 200 OK

Unlike using Qualys SSL Server Test the received results have to be interpreted manually – at least partially – and categorized accordingly. In this example, we can identify the following:

SSLyze is, as opposed to Qualys SSL Server Test not limited to domain names and certain ports. IP addresses and random ports can be used. In addition to that, SSLyze supports the option STARTTLS and can therefore be used to check protocols like SMTP, POP3, IMAP, FTP, XMPP, LDAP or RDP.

Summary

The security of a TLS configuration hinges on the selection of the supported protocols, functions, cipher suites as well as a correctly issued certificate. The standard settings of an application usually don’t fulfill the requirements of a secure configuration. It’s well worth checking this configuration in order to make out vulnerabilities and implement fixes.

About the Author

Michael Schneider

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

Tags

Browser CVE Denial of Service Dienstleistung Exchange Exploit GitHub Google HTML HTTP Linux Mac Microsoft Qualys Request Research RSA Standard Talk Tool Trust University Windows

Are you interested in a Penetration Test?

Our experts will get in contact with you!

×
Reporting and Documenting

Reporting and Documenting

Michael Schneider

Introduction of CVSS v4.0

Introduction of CVSS v4.0

Michael Schneider

Rogue Device

Rogue Device

Michael Schneider

Windows LAPS

Windows LAPS

Michael Schneider

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here