Java SSL Implementation
May 12, 1999
I’ve implemented a functioning subset of the Secure Sockets Layer
(SSL) protocol in pure Java with the ultimate goal of distributing a non-
proprietary version of SSL. To test whether this implementation
performs at a practical level, other project members have performed a
number of comparative performance tests and reported their results in a
Distributed applications, especially those that span wide area networks, require a level of authentication,
data integrity and data privacy only available through the sophisticated use of a combination of
cryptographic algorithms. Some applications use encrypted communication links, but many important
classes of applications--such as those that use the Internet--cannot depend on secure networks. For these
applications, there’s a requirement for a secure transport layer protocol that also delivers good performance
and ease of programming. The Secure Sockets Layer (SSL) protocol has proven its utility and flexibility
by providing robust security at the transport layer in distributed applications and, especially, in web
Programmers writing in C/C++ can download proven SSL implementations from the web for free. Among
the most prominent implementations is SSLeay, authored by Andrew Young , and SSLREF from
Netscape . For Java programmers, a number of commercially available pure Java implementations of
SSL exist, but their cost can be substantial and licensing policies restrictive [3,4]. Java programmers could
build their own JNI/SSLeay library, but this would sacrifice portability. There is at least one SSLeay-based
implementation available on the web for free, but requires modifications to the standard Java sockets
library source code in addition to restricting portability.
The initial project motivation was to provide a functioning, pure Java version of SSL so that secure,
distributed Java applications could be built using a standard protocol. To determine if such an
implementation would actually be practical in real world usage, we wanted to compare the performance of
the pure Java implementation to other implementation approaches. Specifically, we wanted to see if a
C/C++ implementation of SSL called from Java using JNI would provide better performance. We also
wanted to how the pure Java implementation performed with and without JIT compilation and under native
compilation. We would also like to benchmark all the Java implementations and runtime environments
against a C/C++ compiled implementation.
At this time, a pure Java version subset of the SSL protocol has been implemented. The two cipher suites
supported allow valid performance testing to take place. We were unable to implement a JNI version of
SSL in time, so no comparisons can be made between the two Java implementation approaches. Francois
Caen and Malcolm Haynes have reported in a separate document the results of their performance testing.
The next section introduces the SSL protocol from an architectural point of view. The following sections
discuss the design and implementation of our pure Java implementation, the results of our performance
tests and our conclusions.
2.1 SSL Architecture
SSLSSL ChangeApplicationSSL AlertHandshakeCipher SpecDataProtocolProtocolProtocolProtocol
SSL Record Layer
Figure 1. The SSL Record and Message Protocol Layers (Stallings ).
The SSL Architecture is defined as two layers that reside just above the transport in the TCP/IP protocol
stack. All SSL messages originate in one of the message protocol modules and pass through the SLL
Record Layer. The record layer handles physical record blocking and applies cryptographic
transformations. Taken together, the four modules in the upper SSL layer form the Message Protocol
Layer. All SSL input and output takes the form of messages defined by one of these four protocol modules.
The Handshake Protocol establishes the security characteristics of an SSL session. Handshake messages
negotiate the session’s cryptographic parameters and perform client/server authentication. The Change Cipher Spec Protocol is a one-message protocol used during the handshake negotiation. Its sole purpose is
to signal that the newly negotiated cipher suite is now in effect. SSL Alert messages report status between
communicating peers to indicate errors or normal connection termination. Application Data Protocol
messages contain user data protected according to the current cryptographic parameters.
The SSL Architecture does not specify any application programming interface. Each implementation is
free to devise its own interface allowing clients to send and receive SSL messages. Accordingly, SSL
implementations are not interchangeable from an application point of view.
SSL makes a distinction between sessions and connections. A connection is an actual TCP connection
between a client and server. The active connection initiator is always assigned the client role. On the other
hand, an SSL session is an agreed upon set of cryptographic and non-cryptographic parameters. When a
connection is initiated, the client can negotiate a new session or request that a previously negotiated session
be re-used. Thus, sessions can outlive the connection under which they were created. Also, multiple
connections can simultaneously participate in or use the same SSL session. Both the client and server
must cache sessions if they are going to be re-used. Session re-use allows an abbreviated handshake
protocol to be performed that avoids running the computationally intensive key exchange algorithm.
The SSL specification also allows client and server applications to re-negotiate a session’s parameters
anytime after the initial handshake completes. Application data messages may continue to flow during re-
negotiations. During any handshake negotiation, the client and server agree upon a cipher suite which
specifies a key exchange algorithm, a MAC algorithm and a cipher algorithm. The cryptographic
parameters generated under the cipher suite are known as the cipher spec. 2.1.1 SSL Record Layer
SSL Record Layer