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

More documents

Recommendations

Info

GUIDELINES ON SECURING PUBLIC WEB SERVERS • Time value of data (if data is valuable but for only a short time period [e.g., days as opposed to years], then a weaker encryption algorithm could be used) • Threat to data (the higher the threat level, the stronger the required encryption) • Other protective measures that are in place and that may reduce the need for stronger encryption—for example, using protected methods of communications, such as dedicated circuits as opposed to the public Internet Required performance (higher performance requirements may require procurement of additional system resources, such as a hardware cryptographic accelerator, or may necessitate weaker encryption) System resources (fewer resources [e.g., process, memory] may necessitate weaker encryption) Import, export, or usage restrictions Encryption schemes supported by Web server application Encryption schemes supported by Web browsers of expected users. 7.5.5 Implementing SSL/TLS A digital signature is needed to implement SSL/TLS on a Web server. A certificate, which is the digital equivalent of an ID card, is used in conjunction with a public key encryption system. Certificates can be issued by trusted third parties, known as CAs, or can be self-signed. Organizational requirements determine which approach is used. Although the sequence of steps is not identical for all Web servers, the implementation of a third-party signed certificate for a Web server generally includes at least three steps: Generating and submitting a certificate-signing request (CSR) Picking up a signed SSL/TLS certificate from a CA Installing the certificate and configuring the Web server to use SSL/TLS for any specified resources. A CSR consists of three parts: certification request information, a signature algorithm identifier, and a digital signature over the certification request information. Web servers that are SSL/TLS enabled provide specific instructions for the generation of a CSR. There are two major types of CSRs. The most popular is the encoded Public Key Cryptography Standard (PKCS) #10, Certification Request Syntax Standard, which is used by newer Web servers [RSA00]. The other CSR type, based on the Privacy Enhanced Mail (PEM) specification, is called either PEM message header or Web site professional format. The use of this CSR is generally limited to older Web servers. Most Web servers generate PKCS #10-compliant CSRs similar to the sample CSR shown in Figure 7-2. A CSR provides not only additional information about a given entity, or a “challenge password” by which the entity may later request certificate revocation, but also attributes for inclusion in X.509 certificates [RSA00]. 7-8
GUIDELINES ON SECURING PUBLIC WEB SERVERS -----BEGIN CERTIFICATE REQUEST----- MIIBujCCASMCAQAwejELMAkGA1UEBhMCQ0ExEzARBgNVBAgTClRFc3QgU3RhdGUx ETAPBgNVBAcTCENvbG9yYWR0MRswGQYDVQQKExJDYW5hZGlhbiBUZXN0IE9yZy4x EjAQBgNVBAsTCU9VIE9mZmljZTESMBAGA1UEAxMJd3d3LmV4LmNhMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQD5PIij2FNa+Zfk1OHtptspcSBkfkfZ3jFxYA6ypo3+YbQ hO3PLTvNfQj9mhb0xWyvoNvL8Gnp1GUPgiw9GvRao603yHebgc2bioAKoTkWTmW+C8+Ka 42wMVrgcW32rNYmDnDWOSBWWR1L1j1YkQBK1nQnQzV3U/h0mr+ASE/nV7wIDAQABo AAwDQYJKoZIhvcNAQEEBQADgYEAAAhxY1dcw6P8cDEDG4UiwB0DOoQnFb3WYVl7d4 +6lfOtKfuL/Ep0blLWXQoVpOICF3gfAF6wcAbeg5MtiWwTwvXRtJ2jszsZbpOuIt0WU1+cCYi vxuTi18CQNQrsrD4s2ZJytkzDTAcz1Nmiuh93eqYw+kydUyRYlOMEIomNFIQ= -----END CERTIFICATE REQUEST----- Figure 7-2. Sample CSR Spelling and punctuation should be checked when information is provided during the CSR generation process. The URL that is supplied must exactly match the URL for which the certificate is used. SSL/TLS clients are configured to generate an error if the URLs do not match. In some instances, a user may acknowledge this error in an alert box and proceed. Once the CSR has been generated, the organization submits it to a CA. The CA’s role is to fulfill the CSR by authenticating the requesting entity and verifying the entity’s signature. If the request is valid, the CA constructs an X.509 certificate from the domain name (DN) and public key; the issuer name (more commonly referred to as the common name [CN]); and the CA’s choice of serial number, validity period, or signature algorithm. Upon receiving a submitted CSR, the CA must verify the CSR and create a signed X.509 certificate. At this point, most CAs will then alert the applicant by telephone, e-mail, etc., that the X.509 certificate is available. Once notified, applicants will be able to download their certificates through an SSL/TLS-protected Web-based interface. Figure 7-3 shows an X.509 certificate encoded in PEM format. Similar to the CSR, when supplying a certificate to a configuration wizard or even saving it to a hard drive, the lines “BEGIN CERTIFICATE” and “END CERTIFICATE” are vital. Without them, the Web server application will be unable to interpret the encoded contents of the certificate. 7-9
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:
Page 27 and 28:
Page 29 and 30: GUIDELINES ON SECURING PUBLIC WEB S
Page 79: GUIDELINES ON SECURING PUBLIC WEB S
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

Create successful ePaper yourself

Delete template?

Save as template?