NIST 800-44 Version 2 Guidelines on Securing Public Web Servers
NIST 800-44 Version 2 Guidelines on Securing Public Web Servers
NIST 800-44 Version 2 Guidelines on Securing Public Web Servers
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
GUIDELINES ON SECURING PUBLIC WEB SERVERS<br />
server software can c<strong>on</strong>firm that a client’s certificate is valid and was issued by a CA listed in the<br />
server’s list of trusted CAs. 52 This c<strong>on</strong>firmati<strong>on</strong> might be important if the server, for example, is a<br />
bank that is sending c<strong>on</strong>fidential financial informati<strong>on</strong> to a customer and wants to c<strong>on</strong>firm the<br />
recipient’s identity. 53 If client authenticati<strong>on</strong> is to be performed, server authenticati<strong>on</strong> must also be<br />
performed.<br />
Communicati<strong>on</strong> Encrypti<strong>on</strong>—SSL/TLS can encrypt most of the informati<strong>on</strong> being transmitted<br />
between a <strong>Web</strong> browser (client) and a <strong>Web</strong> server or even between two <strong>Web</strong> servers. With an<br />
appropriate encrypti<strong>on</strong> algorithm, SSL/TLS provides a high degree of c<strong>on</strong>fidentiality. In additi<strong>on</strong>, all<br />
data sent over an encrypted SSL/TLS c<strong>on</strong>necti<strong>on</strong> is protected with a mechanism for detecting<br />
tampering; that is, for automatically determining if the data has been altered in transit.<br />
7.5.2 Weaknesses of SSL/TLS<br />
Several limitati<strong>on</strong>s are inherent with SSL/TLS. Packets are encrypted at the TCP layer, so IP layer<br />
informati<strong>on</strong> is not encrypted. Although this protects the <strong>Web</strong> data being transmitted, a pers<strong>on</strong> m<strong>on</strong>itoring<br />
an SSL/TLS sessi<strong>on</strong> can determine both the sender and receiver via the unencrypted IP address<br />
informati<strong>on</strong>. In additi<strong>on</strong>, SSL/TLS <strong>on</strong>ly protects data while it is being transmitted, not when it is stored at<br />
either endpoint. Thus, the data is still vulnerable while in storage (e.g., a credit card database) unless<br />
additi<strong>on</strong>al safeguards are taken at the endpoints.<br />
If SSL/TLS is implemented or used incorrectly, the communicati<strong>on</strong>s intended to be protected may be<br />
vulnerable to a “man in the middle” attack. This occurs when a malicious entity intercepts all<br />
communicati<strong>on</strong> between the <strong>Web</strong> client and the <strong>Web</strong> server with which the client is attempting to<br />
establish an SSL/TLS c<strong>on</strong>necti<strong>on</strong>. The attacker intercepts the legitimate keys that are passed back and<br />
forth during the SSL/TLS handshake (see Secti<strong>on</strong> 7.5.3) and substitutes the attacker’s keys, making it<br />
appear to the <strong>Web</strong> client that the attacker is the <strong>Web</strong> server and to the <strong>Web</strong> server that the attacker is the<br />
<strong>Web</strong> client [SSL98]. If SSL/TLS is implemented and used properly, it is not susceptible to man-in-themiddle<br />
attacks.<br />
The encrypted informati<strong>on</strong> exchanged at the beginning of the SSL/TLS handshake is actually encrypted<br />
with the malicious entity’s public key or private key, rather than the <strong>Web</strong> client’s or <strong>Web</strong> server’s real<br />
keys. The attacker program ends up establishing <strong>on</strong>e set of sessi<strong>on</strong> keys for use with the real <strong>Web</strong> server,<br />
and a different set of sessi<strong>on</strong> keys for use with the <strong>Web</strong> client. This allows the attacker program not <strong>on</strong>ly<br />
to read all the data that flows between the <strong>Web</strong> client and the real <strong>Web</strong> server but also to change the data<br />
without being detected. This threat can be mitigated if clients rely up<strong>on</strong> server certificates issued by<br />
trusted CAs or <strong>on</strong> self-signed certificates obtained by secure mechanisms. Presentati<strong>on</strong> of a self-signed<br />
certificate may be an indicati<strong>on</strong> that a man-in-the-middle attack is underway. Browsers may perform<br />
some checks automatically, but they cannot be relied up<strong>on</strong> in all instances.<br />
Even without performing a man-in-the-middle attack, attackers may attempt to trick users into accessing<br />
an invalid <strong>Web</strong> site. There are several possible methods for attack, including—<br />
Presenting a self-signed certificate unknown to the user and getting the user to accept it as legitimate.<br />
Although the <strong>Web</strong> browser can be c<strong>on</strong>figured to display a warning when a self-signed certificate is<br />
52<br />
53<br />
<strong>Servers</strong> and clients use different types of certificates for authenticati<strong>on</strong>; specifically, clients have to be authenticated using a<br />
signature certificate. See Secti<strong>on</strong> 7.5.3 for additi<strong>on</strong>al informati<strong>on</strong>.<br />
Client authenticati<strong>on</strong> performed by SSL/TLS is rarely used for public <strong>Web</strong> servers because of the logistics involved in<br />
providing client certificates to users and having them installed correctly for use by <strong>Web</strong> browsers.<br />
7-4