Doubling the Handshake
The Secure Socket Layer (SSL) uses certificates as part of the handshake between the client and server. When the client connects to the server, they exchange a series of messages that do much more than just authenticate each other. Transaction Control Protocol (TCP) uses a handshake to begin and end a streaming conversation between the two host computers (see my earlier article "Writing a C-based Client/Server" for more details). SSL adds many more messages on top of TCP's simple handshake.
During the SSL handshake, the client and server perform several steps. These steps check and cross check so that the connection is as secure as technically feasible (see Figure 2). The first steps ("Hello") make sure that the client and server are using the same language. Secure sockets come in several flavors: SSL 2.0, PCT 1.0 (merged with SSL 2.0 to form SSL 3.0), SSL 3.0 (most commonly used in secure links), and TLS 1.0 (Transport Layer Security, the next secure technology).
Figure 2 Simplified SSL handshake.
The client can send its own certificate in the first part of the handshaking dialogue. After exchanging the Hello messages, the client and server exchange public keys and begin the negotiation process. During this process, they select the ciphers and secret keys.
After the two hosts complete the handshake, they switch to using the faster, more reliable symmetric ciphers. The programs then send and receive messages as usual.
One implementation of SSL/TLS is OpenSSL. The way the client and server interface is very simple, once both programs complete the secure channel. In fact, the only change between regular socket programming and secure socket programming is the initial overhead and the new send()/recv() library calls. You can easily convert many C socket programs with a search-and-replace.