This blog was written by Tim Mullenbach. Tim is an Advisory Software Engineer at IBM Rochester. He has been a part of the IBM i sockets/SSL development team since 1995 and leading the team for the past eight years. He has worked on designing, implementing, and testing various socket and System SSL enhancements for the V4R2 through V7R1 releases.
Hopefully you noticed the recent messaging for IBM i 7.1 TR6 which included the statement “Latest industry standards of Transport Layer Security version 1.2 (TLSv1.2) and Transport Layer Security version 1.1 (TLSv1.1) protocols implemented.”
In my conversations with customers I find that many do not realize that TLS is the “new” name for SSL. And by new, I mean for the past 14 years. SSL stands for Secure Sockets Layer and was created by Netscape a long time ago. TLS stands for Transport Layer Security and was created/designed/defined by the Internet Engineering Task Force (IETF) in 1999. IETF standardized and improved the SSLv3 specification making TLSv1.0. While technically called TLSv1.0, many times the .0 was left off leaving TLSv1. Implementers assumed the next version would be TLSv2.0 since SSLv2 preceded SSLv3. No such luck – the next version was called TLSv1.1 with the one after that called TLSv1.2.
Unfortunately the vast majority of people still call the entire concept SSL. It can make for confusing conversations as people like me try to interpret what SSL means in any given context. In all likelihood it is both SSLv3 and TLSv1.0 being described by the use of SSL. A level of uncertainly always remains however due to a handful of applications that still only support the SSL protocol version known as SSLv3. And for the few of us that call it all TLS instead of SSL, we lump SSLv3 under the term TLS.
At this point you might be asking, “Thanks for the name game and history lesson, but what does new support mean to me and my business?”
IBM i and its precursors have supported TLSv1.0 (SSLv3 and SSLv2 too) at least back to V4R5 days. As of Feb 2013 with the release of IBM i 7.1 TR6, we have support for TLSv1.1, defined by RFC 4346 and TLSv1.2, defined by RFC 5246. Each successive version of the SSL/TLS protocol corrects issues found with the previous version and improves upon the state of the art. The latest version available should be used to obtain the highest level of security available for TLS/SSL.
There is a catch though, nothing can be simple. From 1999 to 2005 almost every application, work station, and intelligent device in the world had SSLv3/TLSv1.0 support built into it. The vast majority of those devices still work, perform business critical transactions, and have zero ability to be enhanced with newer TLS/SSL protocols. This significantly impacted and is still impacting the roll out of TLSv1.1. With TLSv1.2 defined so close to TLSv1.1, TLSv1.1 became a lost protocol version. TLSv1.2 adoption initially suffered for the same reasons. The difference is that TLSv1.2 is more of a game changer than TLSv1.1. Sure TLSv1.1 protects from additional attack vectors than the previous protocols did, but other workarounds existed to limp along without it.
So what is the big deal about TLSv1.2? Besides all of the incremental improvements, its big selling point is that it uses the SHA-2 hash algorithm instead of SHA-1 and/or MD5. This is important because of NIST 800-131a. You won't see SSL or TLS mentioned by name, yet when pieced together the recommendations lead to TLSv1.2. NIST is playing the prediction game – how long will things secure today remain secure? While you might have longer than the end of 2013 as predicted in that document, a wise security administrator would start transitioning to the new protocols and algorithms sooner rather than later.
The IBM i 7.1 TR6 enhancements make it easy enough to enable TLSv1.2 for your applications. That is only half the story, the easy half at that. Your communication partner also must support TLSv1.2 for it to be negotiated. This ability varies greatly by application and the peer devices themselves.
For years client applications had no incentive to add TLSv1.2 support since the servers didn't support the protocol. To make matters worse, a very small number of broken SSL implementations in the world fail when a client tries to negotiate TLSv1.2.
It would be a good idea to enable TLSv1.2 for all of your IBM i 7.1 servers. Then start work to enable TLSv1.2 in all of the client applications you have control over that connect to those servers. It could take years, but once all of your clients support TLSv1.2, that should become the only protocol supported by the server.
The IBM i 7.1 client applications you use should also have TLSv1.2 enabled after verifying the server at least tolerates TLSv1.2 being requested. Like with the server, once you know the server supports TLSv1.2, the older protocols should be disabled.
The unfortunate reality is that many applications must continue to support TLSv1.0 for years. Some peer devices have no upgrade path to get new SSL support so you wait for the device to be replaced.
Please read “How to use TLSv1.2 with System SSL on IBM i 7.1” on developerWorks for details on enabling TLSv1.2.
While overshadowed in the developerWorks article by TLSv1.2, the new application level cipher suite control is also very interesting. For the first time ever, you can control the ciphers supported for the various IBM applications on an individual basis. This means FTP, Telnet, and SMTP (client or server) can all use a different list of ciphers at the same time. Gone are the days of taking a sledgehammer to the Secure Sockets Layer cipher specification list (QSSLCSL) system value in order to get an individual application to pass a security scan.
This configuration option is available from the enhanced Digital Certificate Manager (DCM) application definition support. To locate this support, select ‘Manage Applications’ and then ‘Update application definition’ from the left hand panel in DCM. Once the application to update has been selected, the ‘Update Application Definition’ panel will display the new fields that can be updated. Use these fields to control both the ciphers and protocols used by the application. Refer to the panel help text for details on these configuration options as well as other additional System SSL properties now located on that panel.
Recent Comments