Guidelines on Securing Public Web Servers

version 1.0 is formally specified in the IETF RFC 2246,

26

 which was published in 1999 based 

in large part on SSL version 3.  For this document, SSL version 3 and TLS version 1 are 

essentially identical and will be discussed together.  Most major Internet components, such as 

Web browsers, now support the use of either SSL or TLS.  

The Transmission Control Protocol/Internet Protocol (TCP/IP) governs the transport and 

routing of data over the Internet.  Other protocols, such as the HTTP, Lightweight Directory 

Access Protocol (LDAP), or Internet Message Access Protocol (IMAP), run  on top of  

TCP/IP in that they all use TCP/IP to support typical application tasks, such as displaying Web 

pages or running e mail servers.  Thus, SSL/TLS can support more than just secure Web 

communications.  Figure 6.1 shows how SSL/TLS fits between the application and 

network/transport layers of the Internet protocol suite. 

Figure 7.1: SSL/TLS Location within the Internet Protocol Stack 

7.5.1 SSL/TLS 

Capabilities 

SSL/TLS provides the following capabilities to HTTP and other application layer protocols 

[SSL98]: 

Server Authentication

   SSL/TLS allows a Web client (user) to confirm a Web 

server's identity.  SSL/TLS enabled Web clients (e.g., Internet Explorer, Netscape, 

and Opera) can employ standard techniques of public key cryptography to check that 

a server's name and public key are contained in a valid certificate issued by a 

certificate authority (CA) listed in the client's list of trusted CAs. This confirmation 

might be important if the user, for example, is sending a credit card number over the 

network and wants to confirm the receiving server's identity.  

Client Authentication

   SSL/TLS allows a Web server to confirm a user's identity 

using the same techniques as those used for server authentication by reversing the 

roles.  SSL/TLS enabled Web server software can confirm that a client's certificate is

valid and was

issued by a CA listed in the server's list of trusted CAs. This 

confirmation might be important if the server, for example, is a bank that is sending 

confidential financial information to a customer and wants to confirm the recipient's 

identity.  

26

http://www.ietf.org/rfc/rfc2246.txt

54