Data Integrity

Do you want your transport line to be encrypted? Do you want data integrity and confidentiality? If you believe that the physical connection can be tampered with, you can consider encrypting all transmissions by using the secure socket layer (SSL) encryption technology. However, because adding encryption to your transmission affects your connection performance, if you do not have any transport security issues, you should transmit unencrypted.

Figure 6-1 Data Integrity Decision Tree

Using the Secure Socket Layer

JServer's CORBA and EJB implementations rely on the Secure Socket Layer (SSL) for data integrity and authentication. SSL is a secure networking protocol, originally defined by Netscape Communications, Inc. Oracle8i JServer supports SSL over the IIOP protocol used for the ORB.

When a connection is requested between a client and the server, the SSL layer within both parties negotiate during the connection handshake to verify if the connection is allowed. The connection is verified at several levels:

1. The SSL version on both the client and the server must agree for the transport to be guaranteed for data integrity.

2. If server-side authentication with certificates is requested, the certificates provided by the server are verified by the client at the SSL layer. This means that the server is guaranteed to be itself. That is, it is not a third party pretending to be the server.

3. If client-side authentication with certificates is requested, the certificates provided by the client are verified at the SSL layer. The server receives the client's certificates for authentication or authorization of the client.

   Note: Normally, client-side authentication means only that the server verifies that the client is not an impersonator and is trusted. However, when you specify SSL_CLIENT_AUTH in JServer, you are requesting both server-side and client-side authentication.

The SSL layer performs authentication between the peers. After the handshake, you can be assured that the peers are authenticated to be who they say they are. You can perform additional tests on their certificate chain to authorize that this user can access your application. See "Authorization" on how to go beyond authentication.

Note: If you decide to use SSL, your client must import the following JAR files: If your client uses JDK 1.1, import jssl-1_1.jar and javax-ssl-1_1.jar. If your client uses Java 2, import jssl-1_2.jar and javax-ssl-1_2.jar.

SSL Version Negotiation

SSL makes sure that both the client and server side agree on an SSL protocol version number. The values that you can specify are as follows:

• Undetermined: SSL_UNDETERMINED. This is the default setting.

• 3.0 with 2.0 Hello: This setting is not supported.

• 3.0: SSL_30.

• 2.0: This setting is not supported.

On the database, the default is "Undetermined". The database does not support 2.0 or 3.0 with 2.0 Hello. Thus, you can use only the Undetermined or 3.0 setting for the client.

• The server's version is set within the database SQLNET.ORA file, using the SSL_VERSION parameter. For example, SSL_VERSION = 3.0.

• For the client, you set the SSL client version number in the client's JNDI environment, as follows:

  environment.put("CLIENT_SSL_VERSION", ServiceCtx.SSL_30);
  

Table 6-1 shows which handshakes resolve to depending on SSL version settings on both the client and the server. The star sign "X" indicates cases where the handshake fails. Table 6-1 SSL Version Numbers

	Server Setting
Client Setting	Undetermined	3.0 W/2.0 Hello (not supported)	3.0	2.0 (not supported)
Undetermined	3.0	X	X	X
3.0 W/2.0 Hello (not supported)	X	X	X	X
3.0	3.0	X	3.0	X
2.0 (not supported)	X	X	X	X

---