JSSE ( Java Secure Socket Extension )
Data that travels across a network can easily be accessed by someone who is not the intended recipient. When the data includes private information, such as passwords and credit card numbers, steps must be taken to make the data unintelligible to unauthorized parties. It is also important to ensure the data has not been modified, either intentionally or unintentionally, during transport. The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols were designed to help protect the privacy and integrity of data while it is transferred across a network.The Java Secure Socket Extension (JSSE) enables secure Internet communications.Using JSSE, developers can provide for the secure passage of data between a client and a server running any application protocol, including HTTP, Telnet, NNTP, and FTP, over TCP/IP.JSSE is a security component of Java 6 and is based on the JCA ( Java Cryptographic Architecture) framework which is used by Web Logic Server .It provides framework and implementation of Java version of SSL and TLS protcols .JSSE was integrated with JDK1.4. It supplements the existing APIs - java.security and java.net with additional network socket classes , trust managers , key managers etc .
Downloading and Installing JSSE
->Since JSSE does not come with the Java 2 SDK, you must download it and integrate it with your current JDK installation. Download JSSE by going to http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-java-plat-419418.html#jsse-1.0.3_04-fcs-gl-oth-JPR and following the links at the bottom of the page. I suggest downloading both the software and documentation. Since JSSE is subject to export controls, you'll have to agree to these controls if you download JSSE from the U.S. or Canada.After downloading JSSE, you should have a file named jsse-1_0_2-do.zip. Unzip this file to produce a folder named jsse1.0.2.
->Within the jsse1.0.2 folder you'll find a lib directory and within the lib directory, you'll find the files jsse.jar, jcert.jar, and jnet.jar. Copy these files to the lib/ext subdirectory of your Java home directory. Use the program shown below to find your Java home directory. (It may not be where you think it is.) You should also copy these JAR files to the jre/lib/ext directory off of where the Java 2 SDK is installed.Test your JSSE installation by running the JSSETest program shown below. The ShowJavaHome program.
public class ShowJavaHome {
public static void main(String[] args) {
System.out.println(System.getProperty("java.home"));
}
}
import java.security.*;
public class JSSETest {
public static void main(String[] args) {
try {
Class.forName("com.sun.net.ssl.internal.ssl.Provider");
}catch(Exception e) {
System.out.println("JSSE is NOT installed correctly!");
System.exit(1);
}
System.out.println("JSSE is installed correctly!");
}
}
Features of JSSE:
->Its implemented in 100% pure Java.
->Provides API support to SSL 2.0 ,3.0 and TLS 1.0.
->Provides classes which can instantiate a secure channel ( e.g. SSLEngine, SSLSocket and SSLServerSocket )
->Provides support for SSL handshake
->SSL protocol, does its fantastic job of securing communication over the wire, with the help of multiple layers of protocols, above TCP(And After Application Layer).
->There are different versions and types of encryption and authentication algorithms out there. SSL can make use of, most of them out there. But a major point to note here is that, both the server and client must first agree on the same algorithm, that they are going to use in their communication.
->Always keep in mind that, although HTTP protocol is the protocol, which highly makes use of SSL, to secure communication. SSL is an application layer independent protocol.So you can use that with any application layer Protocol.As the client is the first person to begin the communication, the first step that the client does is to tell server, about the cipher suits and MAC(Message Authentication code, this is made in record Layer.Read Record Layer Protocol in SSL) hash algorithm's it supports.
->This is done by sending a CLIENT-HELLO message. The client's Hello message consists of the following contents.
>SSL version that the client supports In what order the client prefer the versions.
>The ciphersuits(Cryptographic Algo's) supported by the client Compression methods supported if any
>Random Number
->Keep in mind that, during the SSL initial handshake, nothing is encrypted. So anybody can sniff, and see whats going on. Encryption, starts only after the master secret (which will be used to encrypt and decrypt data as well as MAC calculation) is send by the client.
Client Hello message content in SSL/TLS
->SSL VERSION NUMBER : the client sends a list of ssl version it supports. And priority is given to the highest version it supports
->Random Data Number : Its made up of 32 bytes. 4 byte number made up from client's date & time plus 28 byte randomly generated number(this will be used with server's random value made of date & time for generating the "master secret", from which encryption key will be derived).
->SESSION ID: In order to enable client's resuming capabilities this session ID is included.
->CIPHER SUITS: RSA algorithm is used for the initial key exchange which will be done using public key cryptography. And SHA is used for MAC and hashing. And also sends the encrption algo's supported by the client like DES for example.
->Compression Algorithm: this will include compression algorithms details, if used. After the client has sent, its client-hello message, its the job of the server to send back a server-hello message. Which will contain the below information.
Server Hello message in SSL/TLS
->Version Number: Server selects an ssl version thats supported by both the server and the client, and is the highest version supported by both of them .
->Random Data: the server also generates a random value using the server's date and time plus a random number of 28bytes. Client will use this random value and its wn random value to generate the "master key".
->Sesssion ID: There are three possiblities, with regard to the session id. It all depends on the type of client-hello message. If the client requires to resume a previously created session, then both the client and server will use the same session ID. But, if the client is initiating a new session, the server will send a new session ID. Sometimes a null session ID is also used, where server will never support resuming the session, so no session id's are used at all.
->Cipher Suits: Similar to the version number selected by the server, the server will select the best cipher suite version supported by both of them.
->Certificate:The server also sends a certificate, which is signed and verified by a Certificate Authority, along with the public key(Content encrypted with public key can only be opened with a corresponding private key. In this case, only the server can unlock it because, the server has the private key for its public key).A certificate signed by a certificate authority(a trusted third party), consists the complete information about the company using that certificate. The certificate identity of
many well known certificate authority is made avialable to the web browser. Whenever a certificate is recieved by the client's browser, it is verified with the one it has from the certificate authority. So this proves that, that the server which claims, that it is "example.com" is infact correct.
>Server Key Exchange: this step is taken by the server, only when there is no public key shared along with the certificate. If this key is used, this will be used to encrypt the "Client Key Exchange Method"
>Client Certificate request: This is seldom used, because this is only used, when the client also needs to get authenticated, by a client certificate.
>Server Hello Done: this message from the server will tell the client, that the server has finished sending its hello message, and is waiting for a response from the client. Response from the client to server's hello message:
>Client Certificate: The client sends a client certificate back to the server. This step is only used when a client certificate is requested by the server(through the server hello message).
>Client Key Exchange: This message is only sent, after the client calculates, the premaster secret with the help of the random values of both the server and the client (Which was shared by both the server and the client through the hello message)."Clinoteent Key exchange" message, is sent by encrypting it with the server's public key, which was shared through the hello message. This message can only be decrypted with the server's private key. If successful, the server is authenticated.the client will also send the ssl protocol version once again along with the "client key exchange" method, so that the server can verify, this version with the previous one send, so as to prevent a man in the middle from changing the protocol version.
->Always keep in mind that, although HTTP protocol is the protocol, which highly makes use of SSL, to secure communication. SSL is an application layer independent protocol.So you can use that with any application layer Protocol.
->Provides support for cipher suit negotiation
->HTTPS protocol support
What is a Cipher Suite:
A cipher suite is a combimation of :
->Cryptographic parameters that define the security algorithm
->Key sizes used for authentication , key agreement , encryption and integrity protection.
Cipher suit examples :
- SSL_RSA_WITH_RC4_128_SHA
- SSL_RSA_WITH_RC4_128_MD5
- SSL_RSA_WITH_3DES_EDE_CBC_SHA
Please also be aware of the below changes in SSL implementation in 12c version
1. Certicom has been removed from WebLogic Server 12.1.1 and is no longer supported.
2. JSSE is the only SSL implementation that is supported in WebLogic Server 12.1.1.
The following configuration changes have been made to be consistent with this support:
The default for JSSEEnabled has been changed to true. Oracle recommends that you keep this value set to true.
-Dweblogic.ssl.JSSEEnabled=true|false
If JSSEEnabled is set to false, it will be ignored. That is, the MBean value will not be changed either in memory or the persisted config.xml file. WebLogic Server will continue to use JSSE, but will issue a warning.
Apps2Fusion Articles 