Other Applications of SSL - Implementing SSL/TLS Using Cryptography and PKI - page 544

form. I blame high-speed connections and graphics-capable displays for the
devolution of the once pure and beautiful Internet — now, you kids get off
my lawn.
Although NNTP is an older protocol whose use is not nearly as widespread
as it once was, it's useful as an example of an alternate means of initiating an
SSL connection. HTTPS requires that you completely set up the SSL connec-
tion before a single byte of HTTP traffi c can be sent. For this to be possible,
the client must notify the server in some way of its intent to start with an SSL
connection. HTTPS does this by assigning two separate ports to HTTP traffi c.
If the client wants a plaintext connection, it connects to port 80; if it wants SSL,
it connects to port 443.
This is problematic in two ways:
The use of multiple ports: If every protocol on the Internet needs two
ports, the number of available ports is cut in half. TCP only allocates
two bytes for the port number, which means that there are only 65,535
ports available to begin with.
Switching from plaintext to encrypted communication requires a
connection change: There's no provision in the TCP protocol for a con-
nection to start using a new port. This isn't as bad with HTTP as with
other protocols because HTTP is fundamentally stateless to begin with,
but even HTTP has problems as a result. You've undoubtedly loaded a
web page and have been presented with a security warning such as, “This
page contains both secure and nonsecure items. Do you want to display
the nonsecure items?” This happens when a web page is downloaded via
HTTPS but some of the links within it are listed as using HTTP.
NNTP, defi ned in 1986 by RFC 977, was a stateful protocol. This was the
only kind of protocol back in those days. The client software established a
connection to the server on port 119 and sent text commands back and forth
over this long-running socket connection. The socket itself would be held
open until the session was complete. You could — and people did — interact
with an NNTP server directly via telnet because the commands themselves
were human-readable text.
At fi rst, Usenet servers were provided by universities free of charge. Over
time, though, Usenet traffi c outgrew what could reasonably be provided for free,
so commercial Usenet servers began to spring up, and they needed to support
authentication to ensure that only paid-up users could send and receive. The
original specifi cation didn't provide for any means of client authentication, so
RFC 2980 standardized an AUTHINFO extension to NNTP that allowed a user
to provide a user name and password before issuing any commands.
Because you're reading a topic about SSL/TLS, you can probably immediately
spot the problem with this approach — NNTP is sent in the clear, with no provision