05-18-2016
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.
This User Gave Thanks to agent.kgb For This Post:
6 More Discussions You Might Find Interesting
1. Programming
hi, I need to know how to lock a file. I used the following code, but after executing the program the file 'write.txt' remined empty, and I have no idea why.Maybe I'm not using the corresponding syntax for blocking a file. But I deleted then the blocking part and the problem persisted.
see to... (2 Replies)
Discussion started by: atticus
2 Replies
2. Solaris
df shows that the filesystem is filling up and the usage is 94%.
However when I actually traverse to the directory I du shows only about
10% of the space occupied!
Below is the output of df and du:
>>>df -kh
/cbmdata/00 470M 393M 29M 94% /cbmdata/00
>>>/cbmdata/00>... (3 Replies)
Discussion started by: zombiezparadize
3 Replies
3. AIX
Hi, I tried to do some research on this subject, but got nothing conclusive.
I have the following need:
I have different servers with AIX versions 3.2.5 through 4.3.2.
Some of them have two ASCI terminals connected.
I have a shell script that is executed by a user on the main console... (2 Replies)
Discussion started by: andrei_r20
2 Replies
4. AIX
Hello everyone,
Can anyone help me please. I want to disable SSH direct access for an AIX user.
For example, if I have USER1 and USER2. I want to disactivate direct access for USER2. The user must enter his login (USER1) and his password and then he can do su - USER2 .
Thanks, (3 Replies)
Discussion started by: adilyos
3 Replies
5. AIX
Hi,
I am planning to disable SNMP in our AIX LPARs. wanted to see by disabling in a test LPAR.
before that, I would like to check disabling this SNMP will impact any of our application or database in anyway. what kind of other software depends on these SNMP daemons ?
Can you please let me... (9 Replies)
Discussion started by: system.engineer
9 Replies
6. AIX
Hello,
We're working on securing the AIX environment. started with disabling unused services on AIX.
Below are the entries which are not commented on my test LPAR (even other LPARs).
ntalk dgram udp wait root /usr/sbin/talkd talkd
daytime stream tcp nowait root... (1 Reply)
Discussion started by: system.engineer
1 Replies
LEARN ABOUT MOJAVE
ssl_ctx_new
SSL_CTX_new(3SSL) OpenSSL SSL_CTX_new(3SSL)
NAME
SSL_CTX_new - create a new SSL_CTX object as framework for TLS/SSL enabled functions
SYNOPSIS
#include <openssl/ssl.h>
SSL_CTX *SSL_CTX_new(const SSL_METHOD *method);
DESCRIPTION
SSL_CTX_new() creates a new SSL_CTX object as framework to establish TLS/SSL enabled connections.
NOTES
The SSL_CTX object uses method as connection method. The methods exist in a generic type (for client and server use), a server only type,
and a client only type. method can be of the following types:
SSLv2_method(void), SSLv2_server_method(void), SSLv2_client_method(void)
A TLS/SSL connection established with these methods will only understand the SSLv2 protocol. A client will send out SSLv2 client hello
messages and will also indicate that it only understand SSLv2. A server will only understand SSLv2 client hello messages.
SSLv3_method(void), SSLv3_server_method(void), SSLv3_client_method(void)
A TLS/SSL connection established with these methods will only understand the SSLv3 protocol. A client will send out SSLv3 client hello
messages and will indicate that it only understands SSLv3. A server will only understand SSLv3 client hello messages. This especially
means, that it will not understand SSLv2 client hello messages which are widely used for compatibility reasons, see SSLv23_*_method().
TLSv1_method(void), TLSv1_server_method(void), TLSv1_client_method(void)
A TLS/SSL connection established with these methods will only understand the TLSv1 protocol. A client will send out TLSv1 client hello
messages and will indicate that it only understands TLSv1. A server will only understand TLSv1 client hello messages. This especially
means, that it will not understand SSLv2 client hello messages which are widely used for compatibility reasons, see SSLv23_*_method().
It will also not understand SSLv3 client hello messages.
SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
A TLS/SSL connection established with these methods will understand the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2
client hello messages and will indicate that it also understands SSLv3 and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1
client hello messages. This is the best choice when compatibility is a concern.
The list of protocols available can later be limited using the SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1 options of the
SSL_CTX_set_options() or SSL_set_options() functions. Using these options it is possible to choose e.g. SSLv23_server_method() and be able
to negotiate with all possible clients, but to only allow newer protocols like SSLv3 or TLSv1.
SSL_CTX_new() initializes the list of ciphers, the session cache setting, the callbacks, the keys and certificates, and the options to its
default values.
RETURN VALUES
The following return values can occur:
NULL
The creation of a new SSL_CTX object failed. Check the error stack to find out the reason.
Pointer to an SSL_CTX object
The return value points to an allocated SSL_CTX object.
SEE ALSO
SSL_CTX_free(3), SSL_accept(3), ssl(3), SSL_set_connect_state(3)
1.0.1e 2013-02-11 SSL_CTX_new(3SSL)