Java SSL Implementation and Performance

By Yvonne Lopez,2014-04-24 12:56
8 views 0
Java SSL Implementation and Performance

    Java SSL Implementation

    May 12, 1999

    Richard Cardone

    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

    separate document.

    1 Introduction

    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 [1], and SSLREF from

    Netscape [2]. 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 Background

    2.1 SSL Architecture

    SSL Architecture

    SSLSSL ChangeApplicationSSL AlertHandshakeCipher SpecDataProtocolProtocolProtocolProtocol

    SSL Record Layer



Figure 1. The SSL Record and Message Protocol Layers (Stallings [5]).

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




    Add MAC