Immediately after establishing a connection and before any data exchange has taken place, the SSL/TLS component performs a “security handshake” with the partner SSL/TLS component. This handshake is comprised of a series of public/private key encrypted messages that are used to negotiate the level of SSL/TLS to be implemented, verify the existence and content of digital certificates, and agree on the session encryption key and algorithms to be used for the secured connection.
Once the secure handshake completes successfully and the application chooses to start data exchange with its partner, the SSL/TLS component intercepts data from the application, performs the required encryption, and sends the encrypted message to the partner application. The partner application’s SSL/TLS component decrypts the data, performs the message authentication checks, and passes the data to the receiving application. As the encryption/decryption is performed after receipt of the data by the application process, no intermediate process (including TCP or IP layer tracing) has access to an unencrypted copy of the data.
HOW DOES AN APPLICATION IMPLEMENT SECURE SOCKETS?
Although secure sockets are widely used by Web servers, their benefit is applicable to any other TCP application that requires the additional security features provided.
The downside of secure sockets, when compared to IPSec-based security, is that the application must replace the existing TCP socket calls with a combination of SSL/TLS and TCP socket calls, plus have its logic changed to handle SSL/TLS related settings and error detection.
Standard TCP/IP socket calls are used to listen, connect, accept, and shut down a connection, but the SSL/TLS socket calls must be used to initialize the SSL/TLS environment, initialize secure sockets, and initiate the secure handshake. SSL/TLS socket calls must also be used to send and receive data on the connection so that the data is encrypted.
In addition to the basic socket and SSL/TLS communications, an application implementing secure sockets must implement logic to identify the repository for digital certificates and the certificates to be used. It must also be able to set run-time options to define the level(s) of SSL/TLS protocols and encryption algorithms to be negotiated and supported during the SSL/TLS handshake.
Figure 2 shows a simplified example of a sockets application that implements SSL/TLS communications.
DIGITAL CERTIFICATE REPOSITORIES