NIST 800-44 Version 2 Guidelines on Securing Public Web Servers

More documents

Recommendations

Info

GUIDELINES ON SECURING PUBLIC WEB SERVERS 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. 52 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. 53 If client authentication is to be performed, server authentication must also be performed. 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 if 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 an SSL/TLS session can determine both the sender and receiver via the unencrypted IP address information. In addition, SSL/TLS only protects data while it is being transmitted, not when it is stored at either endpoint. Thus, the data is still vulnerable while in storage (e.g., a credit card database) unless additional safeguards are taken at the endpoints. If SSL/TLS is implemented or used incorrectly, the communications intended to be protected may be vulnerable to a “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 establish an SSL/TLS connection. The attacker intercepts the legitimate keys that are passed back and forth during the SSL/TLS handshake (see Section 7.5.3) and 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]. If SSL/TLS is implemented and used properly, it is not susceptible to man-in-themiddle attacks. 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. This threat can be mitigated if clients rely upon server certificates issued by trusted CAs or on 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. Browsers may perform some checks automatically, but they cannot be relied upon in all instances. Even without performing a man-in-the-middle attack, attackers may attempt to trick users into accessing an invalid Web site. There are several possible methods for attack, including— Presenting a self-signed certificate unknown to the user and getting the user to accept it as legitimate. Although the Web browser can be configured to display a warning when a self-signed certificate is 52 53 Servers and clients use different types of certificates for authentication; specifically, clients have to be authenticated using a signature certificate. See Section 7.5.3 for additional information. Client authentication performed by SSL/TLS is rarely used for public Web servers because of the logistics involved in providing client certificates to users and having them installed correctly for use by Web browsers. 7-4
GUIDELINES ON SECURING PUBLIC WEB SERVERS presented, organizations that rely on self-signed certificates might instruct users to ignore such warnings. Exploiting vulnerabilities in a Web browser so that the Web site appears to be valid to an untrained user Taking advantage of a cross-site scripting vulnerability on a legitimate Web site. The Web browser will be accessing two different sites, but it will appear to the user that only the legitimate site is being accessed. Taking advantage of the certificate approval process to receive a valid certificate and apply it to the attacker’s own site. By using a valid certificate on what appears to be a valid site, the certificate will validate, and the user would have to somehow realize that the site being accessed is malicious. SSL spoofing attacks can occur without requiring any user intervention. As a proof of concept in 2005, the Shmoo Group registered an internationalized domain name that looked similar to a valid site when displayed in a browser. The SSL certificate matched the internationalized domain name of the Web site, so no user warning occurred. In the address bar, the URL appeared almost identical to that of the original spoofed Web site [NVD06]. Users can prevent less sophisticated attacks by confirming the validity of a certificate 54 before relying on the security of an SSL/TLS session and rejecting certificates for which the browser presents warnings. 55 Browsers perform some checks automatically, but they 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, whereas 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 keys used for rapid encryption, decryption, and tamper detection during the session that follows. The handshake also allows the client to authenticate itself to the server. The exact programmatic details of the messages exchanged during the SSL/TLS handshake are beyond the scope of this document. However, the basic steps involved can be summarized as follows [SSL98]: 1. “The client sends the server the client’s SSL/TLS version number, cipher settings, randomly generated data, and other information the server needs to communicate with the client using SSL/TLS.” 2. “The server sends the client the server’s SSL/TLS version number, cipher settings, randomly generated data, and other information the client needs to communicate with the server over SSL/TLS. The server also sends its own certificate and, if the client is requesting a server resource that requires client authentication, requests the client’s certificate.” 54 55 Checking a certificate using most Web browsers involves clicking on a padlock icon in the lower right-hand corner of the browser (this icon will only appear when accessing an SSL/TLS-protected resource). When organizations use self-signed certificates and instruct users to accept them, it may encourage users to do so with potentially malicious certificates. 7-5
Page 1 and 2:
Special Publication 800</st
Page 3 and 4:
GUIDELINES ON SECURING PUBLIC WEB S
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26: GUIDELINES ON SECURING PUBLIC WEB S
Page 75: GUIDELINES ON SECURING PUBLIC WEB S
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
show all

NIST 800-44 Version 2 Guidelines on Securing Public Web Servers

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?