Sep 8 ’14
Transport Layer Security Version 1.2: Gaining Ultimate Security for Your IT Network With z/VSE
The article “Using OpenSSL to Strengthen the Security of Your z/VSE Environment and Communications” provided an overview of OpenSSL, how it was ported to z/VSE and how it’s exploited by the IPv6/VSe product from Barnard Software Inc. Here we discuss a special security flaw in the SHA-1 hash algorithm and show how Transport Layer Security (TLS) Version 1.2 overcomes this problem. It also examines how TLSv1.2 can be used in a z/VSE environment using OpenSSL.
Secure Hash Functions
First, let’s examine secure hash functions and how they’re used.
A hash function is a mathematical function that maps input data of almost any length to a fixed-length binary string. It’s important that this mapping is a one-way mapping; for example, there’s no way of reconstructing the original data from a given hash value, except systematically trying all kinds of input. Another important characteristic is that it’s very unlikely to find two different input strings with the same hash value. Therefore, hash values are often used to uniquely identify data and are sometimes also referred to as “message digests” or “fingerprints.” You can find more information about secure hash functions here.
There are two specific hash functions: SHA-1 and SHA-256. SHA stands for Secure Hash Algorithm.
SHA-1 was developed and published in the mid-90s by the U.S. National Security Agency (NSA). SHA-1 accepts any input data up to 264 bits (approximately 2 exabytes). This is a huge number, which, for example, would be equivalent to about 500,000 tape cartridges with a capacity of 4TB each. The hash value is always exactly 20 bytes long.
SHA-256 belongs to the family of SHA-2 algorithms that includes SHA-224, SHA-256, SHA-384 and SHA-512. It was published in 2001 by the U.S. National Institute of Standards and Technology (NIST) as a U.S. Federal Information Processing Standard (FIPS). SHA-256 accepts input data up to 2128 bits. The hash value always consists of exactly 32 bytes.
The Use of Hash Functions in the IT Industry
Before we discuss which hash function to use in your IT environment, here are some examples of how hash functions are used in computer environments:
• Storing the hash value of passwords. Almost every computer system provides logon security. Users type in their password when they sign on to the system. As passwords should never be stored in clear text in a computer system, they’re often stored as their hash values. When a password is entered on a terminal, its hash value is calculated and compared to the stored password hash for this user. Due to the nature of hash functions, it isn’t feasible to reversely calculate the password from a given hash.
• Ensuring data integrity. The stored hash value of a document or data backup can be used for detecting document modifications. The smallest change to a document will result in a completely different hash value. And by nature, it isn’t feasible to, for example, get back to the original hash value by adding further document modifications.
• Securing network connections. In Secure Sockets Layer (SSL)/TLS connections, the data sent over the line is hashed. This allows anyone who intercepts the connection to detect any data modifications.
All these applications strongly rely on the properties of hash functions: They’re easy to compute, but it’s infeasible to generate a document with a given hash, change a document without changing the hash and find two different messages with the same hash.
Attacks Against Hash Functions
Attacks against hash functions try to break at least one of their properties. The following two types of attacks have been publicly discussed in recent years.
The pre-image attack works by calculating up to 2160 SHA-1 hashes with randomly chosen input data. As the SHA-1 hash value consists of 160 bits (20 bytes), there are exactly 2160 different possible values and you will more than likely find two different input strings with the same hash value. However, doing this with the fastest available hardware today, this would take billions of years. In practice, if your list of password hashes would be compromised, attackers could use the pre-image attack to find a password for a given hash. This would give them access to your system.
The collision-attack is a bit cheaper. You need about 280 attempts to find two different input strings with the same SHA-1 hash value. However, this number is also quite far away from what you can do with today’s computers.
The SHA-1 Discussion
In 2005, a team of Chinese researchers published a paper describing a mathematical method to reduce the number of attempts for a collision-attack from 280 to 269. Even though 269 is still a huge number, this reduces the number of attempts by 211 (that is, 2,048). Yes, it doesn’t break SHA-1, but it’s at least a start and further research might again decrease this number in the near future. The original paper is available here. As SHA-256 produces hash values of 32 bytes (256 bits), the effort of breaking it is still magnitudes higher. So SHA-256 can be considered as being safe for today and the foreseeable future.
As computer security expert Bruce Schneier wrote in his blog post from February 2005, “Jon Callas, PGP’s CTO, put it best: ‘It’s time to walk, but not run, to the fire exits. You don’t see smoke, but the fire alarms have gone off.’ That’s basically what I said last August. It’s time for us all to migrate away from SHA-1.”
NIST Special Publication 800-131A
Based on this discussion, NIST already changed its recommendations. The NIST Special Publication 800-131A, dated January 2011 and titled “Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths” states that the use of the SHA-1 hash function is disallowed after December 31, 2013, except for non-digital signature applications. You can read the full document here. This has a direct impact on government customers and companies selling security products to governmental customers.
If you’re already supporting secure connections in your IT environment, you’re most likely using SSL or its successor TLS for secure Telnet, FTP and HTTPS. Most applications today support protocol versions up to TLS Version 1.0.
One of the basic properties of a secure SSL/TLS connection is the SSL cipher suite. A cipher suite consists of three parts:
• An algorithm for authenticating the two communication partners
• An algorithm for encrypting the data that goes over the line
• A hash algorithm to ensure data integrity.
Here, TLSv1.2 comes into play. Protocol versions up to TLSv.1.1 are using the SHA-1 algorithm or even older algorithms such as MD5. TLSv1.2 introduces new cipher suites using the SHA-256 algorithm and are therefore compliant with NIST 800-131A. TLSv1.2 is described in Internet Engineering Task Force (IETF) RFC 5246 at here.
TLSv1.2 in OpenSSL
In the past, the following three SSL cipher suites were the most secure ones available on z/VSE and either supported by TCP/IP for VSE/ESA or OpenSSL (available on z/VSE since z/VSE 5.1):
Besides using RSA for authenticating, all three cipher suites are using SHA-1 for hashing. The first one uses Triple-DES for encryption, the second one the more secure AES algorithm with 128 bits key length and the last one uses AES with a 256-bit key.
TLSv1.2 adds three cipher suites:
The first one only authenticates the communication partners and ensures data integrity, but in fact doesn’t encrypt any data. You wouldn’t normally use this cipher suite. The latter two use AES-128 and AES-256 for data encryption. All three use SHA-256 for hashing.
Usage Scenarios With z/VSE
Here are some examples of how to use TLSv1.2 in a z/VSE environment. This requires the IPv6/VSE product from Barnard Software Inc.:
• z/VSE e-business connectors. On z/VSE, you set up one of the SSL/TLS servers provided by IPv6/VSE (BSTTATLS or BSTTPRXY) to SSL-enable the VSE Connector Server. On a Java-enabled workstation, you use Java 7, which supports the TLSv1.2 cipher suites. This way you can enable any VSE Connector Client application for TLSv1.2. Our tests went well with VSE Navigator.
• FTP. If VSE is the server, you SSL-enable the BSTTFTPS FTP server for SSL via BSTTATLS/BSTTPRXY. On a Windows PC, you, for example, use the FileZilla FTP client, which supports TLSv1.2. In our tests, we used FileZilla client 184.108.40.206, but other free FTP clients, such as Core FTP LE and Total Commander, are also available.
If VSE is the client, you SSL-enable the BSTTFTPC FTP client for SSL. On a Linux platform, you use the VSFTPD server that supports TLSv1.2. In our tests, we used VSFTPD Version 3. Unfortunately, FileZilla server currently doesn’t support TLSv1.2. However, there are other freeware FTP servers such as Cerberus that support TLSv1.2.
• TN3270. For Telnet, it’s a bit difficult to find a TN3270 client that supports TLSv1.2. IBM Personal Communications V6.0, for example, doesn’t support TLSv1.2. However, you can use the free x3270 client, which internally uses OpenSSL.
• HTTPS. Mozilla Firefox supports TLSv1.2 with version 27; Google Chrome uses TLSv1.2 since version 30. This allows you to, for example, connect to BSTTATLS/BSTTPRXY for CICS web support.
TLSv1.2 provides enhanced security for your IT environment. NIST Special Publication 800-131A strongly encourages migration to TLSv1.2. Apply the PTFs shown in Figure 1 on your z/VSE system to take advantage of greater SSL/TLS security.