Is Your System Using Outdated and Insecure SSL/TLS Security Protocol Versions?

Safely sending data over the Internet is critical in this brave new world of widespread cybersecurity vulnerabilities.  When it comes to securely passing data from one system to another, a key requirement is to use encryption standards that are current and do not have widespread know flaws that can be exploited.

On IBM i versions V7R3 and V7R4, the following encryption protocol versions are supported (actual versions supported on your specific system is dependent upon system settings allowing their use):

  • TLS 1.3
  • TLS 1.2
  • TLS 1.1
  • TLS 1.0
  • SSL V3
  • SSL V2

When looking at the above list of currently supported protocols, what’s important to note is that “supported” does not implicitly mean “secure”.  This is illustrated by the fact that SSL V2, SSL V3, TLS 1.0, and TLS 1.1 now have known vulnerabilities and are therefore now considered insecure.  TLS versions 1.0 and 1.1 (also referred to as “early TLS”) were formally deprecated by the Internet Engineering Task Force (IETF) early in 2021, those older versions of the protocol were using cryptographic algorithms that were compromised by multiple attacks over the past several years, including BEAST, LUCKY 13, POODLE, and ROBOT, as both older TLS versions lack support for current and recommended cryptographic algorithms and mechanisms.  If your shop is supporting/handling credit card transactions then chances are you already know that the PCI Council announced way back in 2016 that SSL and TLS 1.0 could no longer be used for transmitting credit card data because they are no longer considered secure.

So, is there an “easy” way to determine if your IBM i environment is using any of the older protocols above that are no longer considered safe to use?  Well, as a matter of fact, there is!

IBM has embedded into the Licensed Internal Code(LIC) a very cool automated tool (a LIC macro of sorts) that can be turned-on and used to track all SSL/TLS connections that your system is involved with.  Turning this facility “on” is very easy to do and can be done in only a few minutes, and you do not need to bring your system down or halt production activity to do so.

To turn-on the LIC macro and have it start keeping track of all SSL/TLS protocols being used, simply follow these steps from inside the SST (System Service Tools) menus:

  1. Signon to SST using the STRSST command
  2. Take option #1 Start a service tool
  3. Take option #4 Display/Alter/Dump
  4. Take option #1 Display/Alter storage
  5. Take option #2 Licensed Internal Code (LIC) data
  6. Take option #14 Advanced analysis
  7. Page down until you see SSLCONFIG in the list and type a “1” beside it and hit <Enter> and you will see the screen below.
  8. In the Options field enter -connectionCounts:enable as shown below and hit <Enter> (if you get the error “Unrecognized option” then enter -sslconnectionCounts:enable instead and hit <Enter>).
  9. The screen below will now appear as a confirmation that you have turned the recording facility “on”.
  10. Now you can invoke another option to “display” SSL/TLS connection counts list by protocol version, simply enter -connectionCounts:display as shown below and hit <Enter> (if you get the error “Unrecognized option” then enter -sslconnectionCounts:display instead and hit <Enter>).
  11. The screen below will now appear and will give you an exact connection count by protocol. The first time that you display this screen right after turning the facility “on” it will most likely display all “0”s for counts as it just started tracking the connections.
  12. To turn the facility “off” after days/weeks of letting it run to capture all connection protocols being used, enter -connectionCounts:disable as shown below and hit <Enter> (if you get the error “Unrecognized option” then enter -sslconnectionCounts:disable instead and hit <Enter>).
  13. The screen below will now appear as a confirmation that you have turned the recording facility “off”.

Best practice is to let this MIC macro recording facility run for a considerable amount of time so it can track all secure connections that your system makes, we recommend a full week.  Running this connection count facility will not impede your system’s performance in any way so it’s safe to turn on and run anytime.  At the end of your desired analysis period, you can display the connection counts and see if you are using any of the compromised protocols that are no longer considered secure (e.g. SSLV2, SSLV3, TLSV1.0, or TLSV1.1) and then perform further analysis to discover the source of the older protocol connections (e.g. outdated vendor-provided software that needs updating).

Turning on this powerful system-level facility is easy and quick to do, and it will provide you with a simple way to determine if your system is using older protocols that are no longer secure and pose a substantial cybersecurity risk to your environment.

 

More from this month:

Leave a Comment

Your email address will not be published. Required fields are marked *