|
|
Overview of an SSL Application
Table of Contents | Previous
| Next
| Index
SSL and related APIs allow compliant applications to configure sockets for authenticated, tamper-proof, and encrypted communications. This chapter introduces some of the basic SSL functions. Chapter 2, "Getting Started With SSL" illustrates their use in sample client and server applications.
An SSL application typically includes five parts:
Initialization Configuration Communication Functions Used by Callbacks Cleanup
Although the details differ somewhat for client and server applications, the concepts and many of the functions are the same for both.
WARNING:
Some of the SSL header files provided as part of NSS 2.0 include both public
APIs documented in the NSS 2.0 documentation set and private APIs intended
for internal use by the NSS implementation of SSL. You should use only the SSL
APIs (and related certificate, key, and PKCS #11 APIs) that are described in this
document, the SSL Reference. Other APIs that may be exposed in the header
files are not supported for application use.
Initialization includes setting up configuration files, setting global defaults, and setting up callback functions. Functions used in the initialization part of an application can include the following:
SSL peers frequently reconnect after a relatively short time has passed. To avoid the overhead of repeating the full SSL handshake in situations like this, the SSL protocol supports the use of a session cache, which retains information about each connection, such as the master secret generated during the SSL handshake, for a predetermined length of time. If SSL can locate the information about a previous connection in the local session cache, it can reestablish the connection much more quickly than it can without the connection information.
By default, SSL allocates one session cache. This default cache is called the client session ID cache, (also known as the client session cache, or simply the client cache). The client cache is used for all sessions where the program handshakes as an SSL client. It is not configurable. You can initialize the client cache with the function SSL_ClearSessionCache.
If an application will use SSL sockets that handshake as a server, you must specifically create and configure a server cache, using either SSL_ConfigServerSessionIDCache or SSL_ConfigMPServerSIDCache. The server cache is used for all sessions where the program handshakes as an SSL server.
The configuration portion of an SSL-enabled application always begins by opening a new socket and then importing the new socket into the SSL environment:
Configuration functions control the configuration of an individual socket.
Callbacks and helper functions allow you to specify such things as how authentication is accomplished, and what happens if it fails.
At this point the application has set up the socket to communicate securely. For simple encrypted and authenticated communications, no further calls to SSL functions are required. A variety of additional SSL functions are available, however. These can be used, for example, when interrupting and restarting socket communications or when the application needs to change socket parameters.
Communication between SSL sockets always begins with the SSL handshake. The handshake occurs automatically the first time communication is requested with a socket read/write or send/receive call. It is also possible to force the handshake explicitly with SSL_ForceHandshake or repeat it explicitly with SSL_RedoHandshake.
Once the SSL sockets have been configured, authentication and encryption happen automatically whenever you use the communication functions from the NSPR library.
A server application typically uses these functions to establish a connection:
PR_Bind PR_Listen PR_Accept PR_GetSockName
A client application typically uses these functions to establish a connection:
PR_GetHostByName
PR_EnumerateHostEnt
PR_Connect
PR_GetConnectStatus
Functions that can be used by both clients and servers during communication include the following:
PR_Send or PR_Write
PR_Read or PR_Recv
PR_GetError
PR_GetPeerName
PR_Sleep
PR_Malloc
PR_Free
PR_Poll
PR_Now (see prtime.h for declaration)
PR_IntervalToMilliseconds
PR_MillisecondsToInterval
PR_Shutdown
PR_Close
SSL_InvalidateSession
An SSL application typically provides one or more callback functions that are called by the SSL or PKCS #11 library code under certain circumstances. Numerous functions provided by the NSS libraries are useful for such application callback functions, including these:
CERT_CheckCertValidTimes
CERT_GetDefaultCertDB
CERT_DestroyCertificate
CERT_DupCertificate
CERT_FindCertByName
CERT_FreeNicknames
CERT_GetCertNicknames
CERT_VerifyCertName
CERT_VerifyCertNow
PK11_FindCertFromNickname
PK11_FindKeyByAnyCert
PK11_SetPasswordFunc
PL_strcpy
PL_strdup
PL_strfree
PL_strlen
SSL_PeerCertificate
SSL_RevealURL
SSL_RevealPinArg
This portion of an SSL-enabled application consists primarily of closing the socket and freeing memory. After these tasks have been performed, call NSS_Shutdown to close the certificate and key databases opened by NSS_Init, and PR_Cleanup to coordinate a graceful shutdown of NSPR.
Table of Contents | Previous
| Next
| Index
Last Updated: 01/17/00 16:36:25
|