Understanding Internet Security - Implementing SSL/TLS Using Cryptography and PKI - page 5

responded with either what the client requested in document form or an error
indicating why it could not or did not give the client that document. Either
way, the socket would be closed after this. If the client wanted another docu-
ment, it would create another socket and request another document. Over the
years, HTTP has been refi ned quite a bit and optimized for bandwidth, speed,
and security features.
HTTP was also the primary motivator for SSL. Originally, SSL didn't stand
on its own; it was designed as an add-on to HTTP, called HTTPS. Although SSL
was subsequently decoupled from HTTP, some of its features were optimized
for HTTP, leaving it to be a bit of a square peg in a round hole in some other
contexts. Because HTTP and SSL go so well together, in this topic I motivate SSL
by developing an HTTP client and adding security features to it incrementally,
fi nally arriving at a working HTTP/SSL implementation.
Implementing an HTTP Client
Web browsers are complex because they need to parse and render HTML — and,
in most cases, render images, run Javascript, Flash, Java Applets and leave room
for new, as-yet-uninvented add-ons. However, a web client that only retrieves
a document from a server, such as the wget utility that comes standard with
most Unix distributions, is actually pretty simple. Most of the complexity is in
the socket handling itself — establishing the socket and sending and receiving
data over it.
Start with all of the includes that go along with socket communication — as
you can see, there are quite a few, shown in Listing 1-1.
Listing 1-1: “http.c” header includes
/**
* This test utility does simple (non-encrypted) HTTP.
*/
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#ifdef WIN32
#include <winsock2.h>
#include <windows.h>
#else
#include <netdb.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>
#endif