Guidelines on Securing Public Web Servers

Communication Encryption

   SSL/TLS can encrypt most of the information being 

transmitted between a Web browser (client) and a Web server or even between two 

Web servers.  With an appropriate encryption algorithm SSL/TLS provides a high 

degree of confidentiality.  In addition, all data sent over an encrypted SSL/TLS 

connection is protected with a mechanism for detecting tampering   that is, for 

automatically determining whether the data has been altered in transit.   

7.5.2  Weaknesses of SSL/TLS 

Several limitations are inherent with SSL/TLS.  Packets are encrypted at the TCP layer so IP 

layer information is not encrypted.  Although this protects the Web data being transmitted, a 

person monitoring communications of an SSL/TLS session can determine both the sender and 

receiver via the unencrypted IP address information.  In addition, SSL/TLS protects only data 

while it is being transmitted.  It is not encrypted when stored at either end point.  Thus, the data 

is still vulnerable while in storage (e.g., a credit card database) unless additional safeguards are 

taken at the end points.   

SSL/TLS are also vulnerable to the  man in the middle  attack.  This occurs when a malicious 

entity intercepts all communication between the Web client and the Web server with which the 

client is attempting to communicate via SSL/TLS.  The attacker intercepts the legitimate keys 

that are passed back and forth during the SSL/TLS handshake (see Section 7.5.3), substitutes 

the attacker's keys making it appear to the Web client that the attacker is the Web server and to 

the Web server that the attacker is the Web client [SSL98].  

The encrypted information exchanged at the beginning of the SSL/TLS handshake is actually 

encrypted with the malicious entity's public key or private key, rather than the Web client's or 

Web server's real keys.  The attacker program ends up establishing one set of session keys for 

use with the real Web server, and a different set of session keys for use with the Web client.  

This allows the attacker program not only to read all the data that flows between the Web 

client and the real Web server, but also to change the data without being detected.  Therefore, it 

is extremely important for Web users to be educated in the dangers of this type of attack and 

that they be taught to confirm a certificate before relying on the security of an SSL/TLS 

session.

27

  This threat can be mitigated if clients rely upon server certificates issued by trusted 

CAs, or self signed certificates obtained by secure mechanisms.  Presentation of a self signed 

certificate may be an indication that a man in the middle attack is underway.  Recent browsers 

perform some checks automatically but cannot be relied upon in all instances.   

7.5.3  Example SSL/TLS Session 

The SSL/TLS protocols use a combination of public key and symmetric key encryption.  

Symmetric key encryption is much faster than public key encryption, while public key 

encryption

is better suited to provide authentication and establish symmetric keys. An 

SSL/TLS session always begins with an exchange of messages called the SSL/TLS 

handshake.  The handshake allows the server to authenticate itself to the client using public 

key techniques; this allows the client and the server to cooperate in the creation of symmetric 

27

 To check a certificate when using Microsoft Explorer, click on the yellow padlock icon in the lower right hand 

corner (this icon will only appear when accessing a SSL/TLS protected resource).  To check a certificate when using 

Netscape, click on the padlock icon in the lower right hand corner (this icon will only appear when accessing a 

SSL/TLS protected resource).   

55