Can I get some clue on disabling SSLv1, v3 and TLS1.0 on AIX

Hi,

We've a requirement to disable the protocols SSLv3, SSL v2 and TLS 1.0.

And have TLS 1.2 enabled using AEAD (Authentication Encryption with Associated Data).

This is the only information i have,
I'm not sure how to proceed, was trying to find information using google.
Can you please help me understand

Is it related to OS (AIX), can this be implemented on OS level ?
or
is it related to Application ? Please let me know If you've already had a chance to work on these items before.

Please give me some idea. Thank you.

Those are broken cryptographic protocols used by applications with the need to secure the transmission transport part of the communication. Think of web services or mail services.
It is not at the OS level. It is at the application level. Therefore, if you are charged to disabled these old and broken versions of the TLS and SSL, you must learn what configuration must be changed to the application to prevent it from using it.

Thanks for the response Aia. If I understood correctly, As a AIX system admin we should not change anything on OS. Application/Middleware engineer supposed to work on this task (disabling these protocols)

Please correct me If am wrong. Then will plan accordingly. Please feel free to provide me any links/docs related to this if possible. I would appreciate.

Thank you.

Exactly. SSL is, basically, implemented as a (shared) library. Applications use from that library whatever they want to use. If they want to use insecure protocols they do it and if they are programmed correctly the don't do it. But from the POV of the library it is simply not its decision.

You can, of course, use some firewall software with stateful inspection and acting as a "transient SSL proxy", in which you could create rules to effectively forbid certain crypto-protocols.

This would be similar (and have similar consequences) to removing, say, "telnet" (the binary) from your system. If there would be a script using this "telnet" it would simply stop working. The applications using the protocols you forbid as outlined above would not be able to make any connection any more (and perhaps stop working, at least in this regard), but they wouldn't start working differently - for the same reason the script would not start to use "ssh" once "telnet" is not available any more.

One more word about these requests, because i got the same nonsense requested three times now: it is typically the request of someone not knowledgeable enough to be in either systems administration or programming, which is whe s/he ended up as "security advisor" and trying hard to make sure everybody else is getting done as little as the advisor himself.

These are the guys who want you to have 27-digits long passwords, containing no known words and at least 8 characters you can't enter from the keyboard, changing them every three days but do not write them down! I bet that in every office with such policies i can find at least one post-it note with the PW under some keyboard. And the number of post-its i will find will increase with the length and overall absurdity of these rules, so they won't increase but in fact decrease security.

I hope this helps.

bakunin

1 Like

Excellent rant there bakunin! I know exactly how you feel;0)

it depends...

if you install e.g. OpenSSL libraries on your server and every application on it uses your standard OpenSSL libraries, then it is your responsibility to patch them.

if your application has its own SSL stack, it is application owner's responsibility to patch it.

Example 1. You have AIX LPAR with LDAP-over-SSL connection to LDAP server. For LDAPS connection you must have IBM GSKit installed. GSKit implements SSL/TLS functions. It is a part of system software and you are responsible for patching it.

Example 2. You have AIX LPAR (without LDAPS). WebSphere Application Server runs on this LPAR. To provide SSL to WAS connections you installed GSKit upon request from WAS administrator. It is their (WAS team) responsibility to provide you with a newer version of GSKit to patch potential security problems and test it. It is your responsibility to install it, unless they have root rights.

Example 3. You installed Apache with mod_ssl for your internal documentation server. mod_ssl requires OpenSSL installation. It is your responsibility to update OpenSSL every time a new bug found there.

Example 4. You have an SAP installation. It has its own Java and SSL stack. It is responsibility of SAP administration team to check, test and update their SAP stack, if they have known security problems.

Example 5. You have an AIX LPAR with Tomcat. Tomcat uses Java, which was installed on AIX with default installation, but is administered by Tomcat administrators. You are responsible for updating Java and its SSL libraries on AIX LPAR, but Tomcat administrators are responsible for testing newer Java version with their application.

I have no idea, what you run on your LPARs, which teams are in your organization, how they work together, and so on. It can be rather complicated to decide, who is responsible for what.

1 Like

I got some idea and will make sure that all the necessary filesets/packges are up-to-date (if the app/middleware uses OS java/ssl etc). And will work with middelware/app team. Thanks bakunin, dukessd and agent.kgb. Appreciate your time.