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
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