Ssl overview, Ssl sections, Ssl handshake – HP Secure Key Manager User Manual

Page 164: 97 viewing the fips status server settings section, 77 fips status server settings section components

Advertising
background image

Figure 97 Viewing the FIPS Status Server Settings section

The following table describes the components of the FIPS Status Server Settings section.

Table 77 FIPS Status Server Settings section components

Component

Description

Enable FIPS Status

Server

Select this option to enable the FIPS Status Server on this device. This requires the

Security ACL.

Local IP

Select the IP addresses on which the FIPS Status Server is enabled on the SKM.

Local Port

Select the port on which the server status report is available. Default is 9081.

SSL overview

The SKM is designed to be able to establish Secure Sockets Layer (SSL) and Transport Layer Security (TLS)

connections with all applications and databases that make requests to the KMS Server. SSL and TLS are

the most widely deployed security protocols in network security. The following section provides a brief

overview of the SSL protocol so that you might better understand how to configure the SKM.
SSL is used to establish secure connections between two entities, such as a client application and a KMS

Server. In addition to securing connections, SSL is commonly used to authenticate a server to a client and

vice versa. The SSL protocol is composed of two phases: (1) establishing a secure connection using the

SSL handshake protocol, and (2) exchanging data over the secure connection.

SSL Handshake

The following steps describe a typical SSL handshake:

1.

The protocol is initiated by the requesting application using a client hello message. This message

includes a list of all the ciphers supported by the client application. The application also sends a

session ID that might refer to previously established sessions.

2.

The SKM responds with a server hello message, which includes the SKM’s certificate and the cipher

chosen by the SKM. Once the session is established, it is secured using the chosen cipher. The

message also contains a session ID.

3.

The application and the SKM then engage in a key exchange protocol. The result is a session key

that is then used for encrypting the entire session.
Once the SSL handshake is completed, the two sides begin exchanging application data, such

as cryptographic operations, data migration operations, and so on. All data is encrypted using

the negotiated session key.

SSL Session Resume

Because the SSL key exchange protocol is based on public key cryptography, it consumes significant

computing resources. To minimize the number of SSL handshakes, SSL provides a shortcut to a full key

exchange. Consider an application that has previously established a secure session with the SKM.

Both the application and the SKM already share a session–key. When the application reconnects to

the KMS Server, there is no need to renegotiate a session key. During the reconnection process the two

sides execute the SSL resume protocol, which bypasses the key exchange part of the SSL handshake.

The resumed session is encrypted using the previously negotiated session–key. Establishing a secure

connection using SSL resume is much faster than a full SSL handshake.

164

Using the Management Console

Advertising