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 java.net 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
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
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
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 overview
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:
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.
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:
identifier – unique for a new communication session or reused
from a previous session.
generated data – ServerHello.Random
selected by the server.
sends its own cerificate for the client to verify.
optionally sends a SERVER KEY EXCHANGE message.
optionally sends a CERTIFICATE REQUEST message for client
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.
responds with a certificate if one was requested, or issues a NO
CERTIFICATE alert if none is available.
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.
If the client
has sent a signing certificate, it will then send a CERTIFICATE
VERIFY message to the server to perform certificate validation.
now sends s CHANGE CIPHER SPEC message, indicating that the selected
or pending cipher is ready to be used for subsequent communication.
then sends FINISHED within the now current cipher algorithm, and
indicates its completion of the handshake protocol.
in response sends its own corresponding CHANGE CIPHER SPEC and now
encrypted FINISHED message to the client, concluding the handshake
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' +
MD5(pre_master_secret + SHA('BB' +
MD5(pre_master_secret + SHA('CCC' +
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
The SSL record protocol
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
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
HANDSHAKE – Negotiation of an
APPLICATION_DATA – Data in an
existing SSL session
The algorithms used/supported for
identification and key exchange:
RSA is the most popular algorithm.
The symmetric key algorithms
DES, Triple DES, RC4