This is my first entry on this weblog. I would be basically writing on SAAJ and Webservices (webservices security in particular, and anything that interests me on webservices in general). The most recent release of SAAJ and Webservices Security are part of Java Webservices Developers pack, version 2.0 which can be downloaded from here. SAAJ is now also a project on and can be accessed  here.

To begin with I wanted to put a writeup on SSL. I gave a presentation based on this writeup to my team sometime back.

What is SSL?

SSL defines a mechanism by which two endpoints exchange data in an encrypted format, such that the data exchanged offers the following characteristics:

Security: A third part, or an eavesdropper, cannot interpret the data being conveyed.

Integrity: The data received by the recipient matches that sent by the sender.

Identity: The server receiving the data is always positively identified; optionally an identity can be asserted for the client as well.

SSL operates in a layered fashion in two components. At the topmost level is the handshake protocol, which operates atop a record protocol. Both of these ride the TCP transport.

What does SSL provide?

SSL is intended to provide an encrypted means of data exchange betweena client and a server; most typically, a web browser and a web server.

As part of the handshake sequence, the server is required to identify itself via a server certificate. The inability of the server to offer such an identity causes the session setup to fail. During the handshake, protocol preferences are exchanged, and single secret session key is used via a symmetric key algorithm to encrypt and decrypt data sent across the wire. Session keys are discarded at the session's conclusion.

Point to point security:

SSL is declared to be a point to point protocol. This means that the security SSL provides is limited to the two immediate endpoints involved in the exchange of data; for example the web browser and the web server. The presence of security beyond the destination web server can not be asserted. There exists the potential for a security problem at any point downstream of the server, since the data it receives could be in clear text, and possibly could be re-transmitted to other servers that may or maynot have a public Internet presence. The ability to assert secure communication across the span of the entire application is termed “end-to-end” security, and SSL was never designed to provide this type of security gurantee.

Why do we need SSL?

The HTTP or Hypertext Transfer Protocol is the centerpiece of our current web technology. If data flows across the Internet to accomplish anything of interest, it finds its way through HTTP. This is a simple protocol capable of transmitting lots of data in a short time but with one slight drawback. Everything across HTTP is transmitted in plaintext.

Data is open to Inspection

Cleartext data flowing between browser and web server is ripe for third-party inspection for a variety of possible uses, not limited to the compromise of user-sensitive data. Other mechanisms available to a third-party eavesdropper on cleartext HTTP transmissions include the ability to make inferences about the structure of a site, and use that information as a basis on which to construct spoofing, redirections, or malformed URI attacks.

SSL eliminates the possibility of third-party examination of cleartext data by using a single shared secret key, with a symmetric key algorithm to encrypt and decrypt data on both ends of the data transaction during a session.

Inability to establish participant identities

HTTP provides no mechanism to validate that the server for which the data is intended is actually the server to which the data is delivered. Redirection attacks cause the data or websites to be spoofed or simulated on other servers without the user's knowledge.

SSL attempts to overcome this problem by mandating the use of server side certificates to assert a specific identity for a given server. The server certificate contains information about the common name of the server, which the browser can use to compare with the server requested in the client-supplied URL. If they don't match, the user can be warned and then be allowed to determine if the submission should proceed.

No gurantee of data integrity

HTTP does not pay much attention to the size, nature, stucture or type of data being transferred. As a result there is no way to validate that the data sent by one end made it to the other.

SSL addresses this problem by incorporating Message Authetication Code (MAC) in each encrypted message. A MAC is constructed by performing a hash function on the source data. The MAC value is added to the message structure that holds the data, which is then encrypted and sent to its destination. Upon receipt and decryption by the reciepient, the message data and MAC are extracted, and the same hash function is performed on the data block. The result of the reciepient hash is compared against the MAC, and if the two values match, the reciepint may conclude that the message was undisturbed in transit.

How does SSL work ?

SSL is a basket of encryption and identification technologies bundled together in a single protocol. Public-key algorithms are used to establish a secure mechanism for validation and key exchange, while a symmetric algorithm encrypts data via a shared secret sesion key. Hashing functions provide a mechanism for message integrity. The exchange of this data is covered in two layers, known as the SSL handshake protocol and the SSL record protocol. Initial protocol parameters are established at the server connection time, during the handshake protocol.

Handshake Protocol overview

The cryptographic parameters of the session state are produced by the SSL handshake protocol, which operates on top of SSL record layer. When a SSL client and a serevr start communicating, they agee on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public key encryption techniques to generate shared secrets. These processes are performed in the handshake protocol which can be summarized as follows:

  1. From the client, a CLIENT HELLO message is sent. With this initial message, the client sends its preliminary information including the protocol version, randomly generated data(ClientHello.Random),a list of cipher suites supported in decreasing order of preference and compression methods that can be imlpemented.

  2. In response, the server sends s SERVER HELLO message. The values set by the server are the protocol parameters that are set for tuis session. The server sends:

    • Protocol version

    • Session identifier – unique for a new communication session or reused from a previous session.

    • Randomly generated data – ServerHello.Random

    • Cipher suite selected by the server.

    • Compression method.

  3. The server sends its own cerificate for the client to verify.

  4. The server optionally sends a SERVER KEY EXCHANGE message.

  5. The server optionally sends a CERTIFICATE REQUEST message for client identification.

  6. The SEREVR HELLO DONE message is sent by the server to indicate the end of server hello and associated messages. After sending this message the server will wait for client response.

    Upon receipt of the server hello done message, the client should verify that the server provided a valid certificate if required and check that the hello parameters are acceptable.

  7. The client responds with a certificate if one was requested, or issues a NO CERTIFICATE alert if none is available.

  8. The client then sends a CLIENT KEY EXCHANGE message. The particular contents of this depends on the type of public key algorithm selected, but it basically contains a 48 byte PREMASTER SECRET encrpted using the public key of the server.

  9. If the client has sent a signing certificate, it will then send a CERTIFICATE VERIFY message to the server to perform certificate validation.

  10. The client now sends s CHANGE CIPHER SPEC message, indicating that the selected or pending cipher is ready to be used for subsequent communication.

  11. The client then sends FINISHED within the now current cipher algorithm, and indicates its completion of the handshake protocol.

  12. The server, in response sends its own corresponding CHANGE CIPHER SPEC and now encrypted FINISHED message to the client, concluding the handshake sequence.

  13. Secured commonucation commences.

Master secret and key generation

When RSA is used for server authentication and key exchange, a 48 byte pre_master_secret is generated by the client, encrypted under the server's public key, and sent to the server. The server uses its private key to decrypt the pre_master_secret. Both parties then convert the premaster secret into master secret as:

master_secret = MD5(pre_master_secret + SHA('A' + premaster_secret +

ClientHello.Random + ServerHello.Random)) +

MD5(pre_master_secret + SHA('BB' + premaster_secret +

ClientHello.Random + ServerHello.Random)) +

MD5(pre_master_secret + SHA('CCC' + premaster_secret +

ClientHello.Random + ServerHello.Random))

The master secret is hashed into a sequence of secure bytes, which are assigned to the MAC secrets and keys. Cipher specs different client write MAC secret, server write MAC secret, a client write key and a server write key. When generating the keys and MAC secrets, the master key is used as an entropy source, and the random values provide encrypted salt material.

The SSL record protocol

Once the SSL handshake protocol is completed, the record protocol steps in to mediate the flow of encrypted data across the connection. The protocol takes the session key established during the handshake, and begins encrypting the outbound data or decrypting the inbound data, as appropriate.

The SSL record protocol establishes the framework under which handshake and data messages are exchanged between the participants in an SSL communication. Each SSL record consists of not more than 2\^14 bytes of data known as SSLPlaintext record.

The SSLPLaintext record incorporates a structure defining the version of the protocol in use, the content of the data in the record, the length of the data, and the data itself. This record structure is then used throughout the communication merely by providing one of following four content types:

  • CHANGE_CIPHER_SPEC – Changing the cipher used for communication

  • ALERT – Indication of an error condition

  • HANDSHAKE – Negotiation of an SSL session

  • APPLICATION_DATA – Data in an existing SSL session

The algorithms used/supported for identification and key exchange:

  • RSA

  • Diffie-Hellman key exchange


RSA is the most popular algorithm.

The symmetric key algorithms used/supported:

DES, Triple DES, RC4

Hashing algorithms:



Man..this blog rocks!! Really a informative piece on SSL.

Posted by kodham on January 23, 2007 at 10:18 AM IST #

Post a Comment:
  • HTML Syntax: NOT allowed



« April 2014

No bookmarks in folder