Such sockets are normal stream sockets, but they
add a layer of security protections over the underlying network transport
protocol, such as TCP. Those protections include:

Integrity Protection. SSL protects against
modification of messages by an active wiretapper.

Authentication. In most modes, SSL provides
peer authentication. Servers are usually authenticated,
and clients may be authenticated as requested by servers.

Confidentiality (Privacy Protection). In most
modes, SSL encrypts data being sent between client and server.
This protects the confidentiality of data, so that passive
wiretappers won't see sensitive data such as financial
information or personal information of many kinds.

These kinds of protection are specified by a "cipher suite", which
is a combination of cryptographic algorithms used by a given SSL connection.
During the negotiation process, the two endpoints must agree on
a ciphersuite that is available in both environments.
If there is no such suite in common, no SSL connection can
be established, and no data can be exchanged.

The cipher suite used is established by a negotiation process
called "handshaking". The goal of this
process is to create or rejoin a "session", which may protect many
connections over time. After handshaking has completed, you can access
session attributes by using the getSession method.
The initial handshake on this connection can be initiated in
one of three ways:

calling startHandshake which explicitly
begins handshakes, or

any attempt to read or write application data on
this socket causes an implicit handshake, or

a call to getSession tries to set up a session
if there is no currently valid session, and
an implicit handshake is done.

If handshaking fails for any reason, the SSLSocket
is closed, and no futher communications can be done.

There are two groups of cipher suites which you will need to know
about when managing cipher suites:

Supported cipher suites: all the suites which are
supported by the SSL implementation. This list is reported
using getSupportedCipherSuites.

Enabled cipher suites, which may be fewer
than the full set of supported suites. This group is
set using the setEnabledCipherSuites method, and
queried using the getEnabledCipherSuites method.
Initially, a default set of cipher suites will be enabled on
a new socket that represents the minimum suggested configuration.

Implementation defaults require that only cipher
suites which authenticate servers and provide confidentiality
be enabled by default.
Only if both sides explicitly agree to unauthenticated and/or
non-private (unencrypted) communications will such a ciphersuite be
selected.

When SSLSockets are first created, no handshaking
is done so that applications may first set their communication
preferences: what cipher suites to use, whether the socket should be
in client or server mode, etc.
However, security is always provided by the time that application data
is sent over the connection.

You may register to receive event notification of handshake
completion. This involves
the use of two additional classes. HandshakeCompletedEvent
objects are passed to HandshakeCompletedListener instances,
which are registered by users of this API.
SSLSockets are created by SSLSocketFactorys,
or by accepting a connection from a
SSLServerSocket.

A SSL socket may choose to operate in the client or server mode.
This will determine who begins the handshaking process, as well
as which messages should be sent by each party. However, each
connection must have one client and one server, or handshaking
will not progress properly.

getSupportedCipherSuites

Returns the names of the cipher suites which could be enabled for use
on this connection. Normally, only a subset of these will actually
be enabled by default, since this list may include cipher suites which
do not meet quality of service requirements for those defaults. Such
cipher suites are useful in specialized applications.

getEnabledCipherSuites

Returns the names of the SSL cipher suites which are currently enabled
for use on this connection. When an SSL socket is first created,
all enabled cipher suites support a minium quality of service. Thus,
in some environments this value might be empty.

There are several reasons why an enabled cipher suite might
not actually be used. For example: the server socket might
not have appropriate private keys available to it or the cipher
suite might be anonymous, precluding the use of client authentication,
while the server socket has been told to require that sort of
authentication.

setEnabledCipherSuites

Controls which particular cipher suites are enabled for use on
this connection. The cipher suites must have been listed by
getSupportedCipherSuites() as being supported. Even if a suite
has been enabled, it might never be used if no peer supports it,
or the requisite certificates (and private keys) are not available.

Parameters:

suites - Names of all the cipher suites to enable

Throws:

IllegalArgumentException - when one or more of the ciphers
named by the parameter is not supported, or when the
parameter is null.

getSession

Returns the SSL Session in use by this connection. These can
be long lived, and frequently correspond to an entire login session
for some user. The session specifies a particular cipher suite
which is being actively used by all connections in that session,
as well as the identities of the session's client and server.

This method will initiate the initial handshake if
necessary and then block until the handshake has been
established.

If an error occurs during the initial handshake, this method
returns an invalid session object which reports an invalid
cipher suite of "SSL_NULL_WITH_NULL_NULL".

startHandshake

Starts an SSL handshake on this connection. Common reasons include
a need to use new encryption keys, to change cipher suites, or to
initiate a new session. To force complete reauthentication, the
current session could be invalidated before starting this handshake.

If data has already been sent on the connection, it continues
to flow during this handshake. When the handshake completes, this
will be signaled with an event.
This method is synchronous for the initial handshake on a connection
and returns when the negotiated handshake is complete. Some
protocols may not support multiple handshakes on an existing socket
and may throw an IOException.

setWantClientAuth

public abstract void setWantClientAuth(boolean want)

Configures the socket to request client authentication, but
only if such a request is appropriate to the cipher suite
negotiated. This option is only useful
for sockets in the server mode.
Unlike setNeedClientAuth(boolean),
if the client chooses not to provide authentication information
about itself, the negotiations will continue.

The socket must be a server mode socket.

Parameters:

want - should be set to true if the clients should
try to authenticate themselves.
Setting this parameter to true overrides the current
setting of setNeedClientAuth(boolean).