Apache 2 supports SSL / TLS: Step by step instructions (Part II)

Review Part I

Part II

In the first part of this series, you have been taught how to install, configure, and troubleshoot Apache 2.0 software that supports SSL / TLS. Now, part two will continue to discuss the issue of setting up the mod_ssl module to achieve the highest level of security and optimal performance. You will also be guided on how to create an internal Certification Authority and an SSL certificate based on the OpenSSL open source library.

Requirements set for mod_ssl

In Apache 2.0.52, there are more than 30 instructions that can be used to configure mod_ssl . A detailed description of all of these 30 instructions can be found in Apache's mod_ssl documentation . This section only focuses on setup requirements to improve the security and performance of SSL / TLS connections.

The list of these settings is shown in the following table:

Instruction Setting requirements or SSLEngine annotations Must be enabled, otherwise the server (or virtual client) will not use SSL / TLS to be enabled by SSLRequireSSL . Web content can be accessed via regular HTTP requests without requiring SSL / TLS. SSLProtocol

SSLProxyProtocol It is recommended to set the mode to use only TLS v1.0 and SSL v3.0. Most web browsers currently support both. So we can safely disable SSL v2.0. SSLCipherSuite

SSLProxyCipherSuite To create a strong encryption method, this parameter should be set to HIGH (> 168 bits) and MEDIUM (128 bits). LOW level (
HIGH: MEDIUM:! ANULL: + SHA1: + MD5: + HIGH: + MEDIUM

Note : The settings that support the encoder can be viewed as follows:

openssl ciphers -v 'HIGH: MEDIUM:! aNULL: + SHA1: + MD5: + HIGH: + MEDIUM' SSLOptions The "+ StrictRequire" option should be set, otherwise the "Satisfy Any" directive can force mod_ssl to allow Access web content even if SSL / TLS is not used. SSLRandomSeed To start Apache, install it to use fake random device (/ dev / urandom) and / or EGD (Entrophy Gathering Daemon). Before each new SSL connection is established, reconfigure it to use the pre-installed source, / dev / urandom or EGD. Do not use / dev / random in either case. Because / dev / random can only provide many entropy at a given time. SSLSessionCache To avoid repeating SSL handshakes for parallel HTTP requests (for example, when web browser loads multiple images over a period of time), SSL caching should be used. It will set up to use shared memory (SHM), or DBM. When this setting is "none", the execution of the web server can be significantly reduced. SSLSessionCacheTimeout This value describes the number of seconds seconds after the entry in SSLSessionCache expires. It should be set at least 300-600 seconds. However, real-time depends on the average user time spent on each visit to the web server. For example, if the average time is about 15 minutes, then the value should be set to at least 900 (15 minutes * 60 seconds). SSLVerifyClient

SSLProxyVerify When not using client or proxy identifiers, these options should be set to 'none'. Never put them in "optional_no_ca" mode. Because in contrast to PKI identifiers, where the client is identified, they must present the appropriate certificates. 'Optional' is sometimes used (depending on whether it is needed or not), however it may not work for all web browsers. SSLVerifyDepth

SSLProxyVerifyDepth Should be the largest number of intermediate CAs. For example, to get only self-signed certificates, set it to 0, for client certificates signed by Root CA, set to 1 . SSLProxyEngine should be disabled (set to disable), if SSL mechanism / TLS proxy cannot be used.

Table 1. Required settings for mod_ssl .

Our sample settings corresponding to the above instructions can be found in httpd.conf as follows:

SSLEngine on

SSLOptions + StrictRequire


SSLRequireSSL


SSLProtocol -all + TLSv1 + SSLv3
# Support only for strong cryptography
SSLCipherSuite HIGH: MEDIUM:! ANULL: + SHA1: + MD5: + HIGH: + MEDIUM
# Support for strong and export cryptography
# SSLCipherSuite HIGH: MEDIUM: EXP:! ANULL: + SHA1: + MD5: + HIGH: + MEDIUM: + EXP

SSLRandomSeed startup file: / dev / urandom 1024
SSL Randomization file: / dev / urandom 1024

SSLSessionCache shm: / usr / local / apache2 / logs / ssl_cache_shm
SSLSessionCacheTimeout 600

SSLVerify none
SSLProxyEngine off

In addition to the instructions on mod_ssl above, there are two other important parts in Apache modules ( mod_log_config and mod_set_envif ) that need to be installed according to the following table 2:

Instruction Required setting or commenting CustomLog To write SSL parameter information (minimum requirement: version of protocol and encoder selected) we should use the following values:

CustomLog logs / ssl_request_log
"% t% h% {HTTPS} x% {SSL_PROTOCOL} x% {SSL_CIPHER} x
% {SSL_CIPHER_USEKEYSIZE} x% {SSL_CLIENT_VERIFY} x
"% r"% b " Setenvif To be compatible with older versions of MS Internet Explorer with errors in the SSL execution section (eg problems with keep-alive functions, HTTP 1.1 on SSL, alerted scenes) close SSL on the connection end socket The following options should be set:

SetEnvIf User-Agent ". * MSIE. *"
nokeepalive ssl-unclean-shutdown
downgrade-1.0 force-response-1.0
The above option causes the web server to use HTTP / 1.1 or keep-alive connections and will not send SSL close attention when the web browser is MS Internet Explorer.

Table 2. Setting requirements for mod_log and mod_set_envif .

The sample configuration file (httpd.conf) shown in the previous lesson has included the above options, making it more convenient for readers.

Web server identifier

So far, we can configure and test SSL / TLS, but our web browser cannot check the identity of the web server. In the first lesson, we used a web server certificate created for testing purposes and did not contain the information required for real identity and commercial transactions.

In order for web browser to successfully identify the web server, we need to create an appropriate web server certificate, which should include:

1. Common key for web server
2. Effective date (start date and expiration date)
3. Support encryption algorithms
4. A separate set of names (DN), must include the full valid domain name of the web server, known as the common name (CN). However, there may be other components such as country (C), state (S), region (L), organization name (O), organizational unit name (OU) or more.
5. Number of certificate numbers
6. The X.509v3 attribute will tell the web browser about the type and usage of the certificate
7. URI of CRL distribution point (if exists)
8. URI of X.509v3 Certificate Policy (if exists)
9. The name and signature are verified by the certificate identifier (CA).

It is important to note that the common name attribute (CN) must be a fully qualified domain name on the web server. Otherwise the web browser will not be able to verify that the certificate belongs to the web server that is being used.

Web server certificate template (text style template) can be as follows:

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: O = Seccure, OU = Seccure Root CA
Validity Not Before:
Nov 28 01:00:20 2004 GMT
Not After: Nov 28 01:00:20 2005 GMT
Subject: O = Seccure, OU = Seccure Labs, CN = www.seccure.lab

Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bits)
Modulus (1024 bits):
00: 1: 19: c7: 38: f4: 89: 91: 27: a2: 1b: 1d: b6: 8d: 91:
48: 63: 0e: 3d: 0d: 2e: f8: 65: 45: 56: db: 98: 4d: 11: 21:
01: ac: 81: 8e: 3f: 64: 4a: 8a: 3f: 21: 15: ca: 49: 6e: 64:
5c: 5d: a2: ab: 5a: 48: cb: 2a: 9f: 0c: 02: b9: ff: 52: f6:
d9: 39: 6d: a3: 4a: 94: 41: f9: e9: ab: f0: 42: fb: 68: 9a:
4b: 53: 41: e7: 4f: b0: 2b: 02: d7: 92: a2: 2b: 02: a2: f9:
f1: 2d: 68: fa: 50: 01: 2f: 49: c1: 28: 2f: a8: c6: 6d: 6d:
ab: 1d: b9: bd: c9: 80: 63: f1: d6: 22: 19: de: 2d: 4a: 43:
50: 76: 79: 7e: a5: 5a: 75: af: 19
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA: FALSE
Netscape Cert Type:
SSL Server
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, Netscape Server Gated Crypto, Microsoft Server Gated Crypto
Netscape Comment:
OpenSSL Certificate for SSL Web Server
Signature Algorithm: sha1WithRSAEncryption
45: 30: 9d: 04: 0e: b7: 86: 9e: 61: a1: b0: 68: 2b: 44: 93: 1c: 57: 2a:
99: 42: bb: 16: b1: ab: f5: c0: d2: 33: 12: c8: d3: 1d: 2b: bb: 6b: 9a:
4c: c7: 53: bc: e4: 88: ef: 1e: c3: 37: ed: 53: 2c: 15: cf: b8: 90: df:
df: 4b: 34: b8: db: cc: 23: 77: 46: 06: 72: 9d: 43: 60: a8: a2: ed: 0a:
bb: 1a: a4: e8: 4e: three: 66: 93: 63: 74: 87: fd: 43: 48: b6: 93: a2: e3:
3d: da: 1b: 64: 46: 35: 88: b4: 4b: 22: e6: 3c: 84: 70: 5d: 88: dd: 64:
c2: 51: c2: d6: 59: 80: 87: bc: bd: 7f: e3: c1: 45: 7e: c0: 5f: 9c: ca:
e1: a1

The next example is based on some values ​​shown in Table 3. To create a correct certificate, you need to replace some of these values ​​with your company or organization name:

Description attribute Attribute Example Country code (2 characters) C C = PL State or province S S = mazowieckie Region L L = Warsaw Organization name O O = Seccure Organization unit OU OU = Seccure Labs Common name CN CN = www.seccure.lab

Table 3 .Example of a correct certificate

Should a password be used to protect it?

Before starting to create certificates, it's important to understand the meaning of the password (passphrase) in the certificate. Should the web server's private keys be encrypted? There are many opinions, including the idea that it is not recommended to protect the private key with a password. It is not only inconvenient but also creates a feeling of insecurity. Why? See the following points:

1. First, it requires entering the password after each restart of the web server. This is quite annoying if the system needs to reboot regularly (such as updating code, an electronic error or configuration changes, etc.).

2. If an intruder conquers and retrieves the private key on the web server, it means that the web server is compromised and the intruder has access to the web server's operating system in Root. In this case, the intruder can steal the password by installing a keylogger. And then, either destroy or restart the system to force the administrator to re-enter the password. The intruder can dump Apache's memory and find the web server's private key stored in a certain segment.

Therefore, improving the web server's private key encryption with passwords only helps protect them against children. As for the system vandalists, it is useless.

Create a web server certificate

In this section we can create web server certificates. Usually there are 3 types of certificates that we can use:

Self-signed certificate (self-signed certificate)

2. Certificate certified by CA (most)

3. The certificate is signed by the internal CA

The following section describes in detail how to create the above certificates. The end result of any method used will have only 2 files:

1. server.key - the web server's private key
2. server.crt - PEM encryption certificate including the web browser public key

Method 1 : Self-signed certificate (for testing purposes only)

This method is designed only to continue our testing process, or to use it in a small, close environment (such as at home or a small Intranets network). In order for the web browser to identify the web server the self-signed certificate must be installed in every web browser that needs to access that web server. This can be quite inconvenient.

The web server's public / private key pair and PEM self-signed encryption certificate can be created as follows:

openssl req
-new
-x509
-days 365
-sha1
-newkey rsa: 1024
-nodes
-keyout server.key
-out server.crt
-subj '/ O = Seccure / OU = Seccure Labs / CN = www.seccure.lab'

The above statements will create a new certificate (-new), named (-x509), which is valid for one year (-days 365), and will be signed by using the SHA1 algorithm (-sha1). The RSA private key is 1024 bits long (-newkey rsa: 10224), and does not need to be protected with a (-nodes) password. The certificate and the public / private key pair will be created in two files 'server.crt' and 'server.key'. The name of this area is 'Seccure Labs' and the full domain name is: www.seccure.lab .

After creating the above certificate, we need to distribute and install it in any web browser that can connect to the web server. Otherwise, when the web browser requires a connection, it will not be able to verify the identity of the web server. In a Windows environment, this is shown in Figure 1 below:

Apache 2 supports SSL / TLS: Step by step instructions (Part II) Picture 1

Method 2 : Certificate signed by CA

Creating a certificate request and signing it with a trusted CA (such as Versign, Thawte, RSA, etc.) is the most commonly used way to know if an SSL web server is included in the internet. Using this approach does not need to install the certificate in every web browser. Because most of them have a number of CA certificates from before they are installed.

Note that each certificate authority (CA) has different limits for distributing proper names, providing lengths for a key, international characters. Therefore, before creating certification requirements you need to make sure that your certification requirements are consistent with the specific requirements of CA. Should choose a CA whose signed certificates are installed in most web browsers (including: Thawte, Verisgn and some other firms .). Otherwise, the user's web browser may have problems verifying with the web server.

The process of obtaining a signed certificate by a trusted CA includes the following steps:

1. The first step is to create a public / private key pair (in server.key) and certificate request (in request.pem) as follows:

openssl req
-new
-sha1
-newkey rsa: 1024
-nodes
-keyout server.key
-out request.pem
-subj '/ O = Seccure / OU = Seccure Labs / CN = www.seccure.lab'

2. Now we have to send the certificate request to CA (in request.pem ). Then wait until it is signed and return to us the form of the certificate.

3. After receiving the certificate from the trusted CA , we must make sure that it has been encoded in PEM format and not TXT or DER. If you receive a certificate that does not encode PEM, you need to convert from any format received to PEM format.

The easiest way to check the format of the certificate is to view the certificate with a text editor. Depending on which editor we have one of the following formats (the file name extension is indicated in double quotes):

- PEM, Base64 encoded X.509 format (* .crt, * .pem, * .cer)

----- BEGIN CERTIFICATE -----
MIICdzCCAeCgAwIBAgIBATANBgkqhkiG9w0BAQUFADAsMRAwDgYDVQQKEwdTZWNj
dXJlMRgwFgYDVQQLEw9TZWNjdXJlIFJvb3QgQ0EwHhcNMDQxMTI4MDEwMDIwWhcN
.
ou0Kuxqk6E66ZpNjdIf9Q0i2k6LjPdobZEY1iLRLIuY8hHBdiN1kwlHC1lmAh7y9
f + PBRX7AX5zK4aE =
----- END CERTIFICATE -----

- TXT + PEM format (* .crt, * .cer, * .pem, * .txt)

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: O = Seccure, OU = Seccure Root CA
.
RSA Public Key: (1024 bits)
Modulus (1024 bits):
00: 1: 19: c7: 38: f4: 89: 91: 27: a2: 1b: 1d: b6: 8d: 91:
.
X509v3 extensions:
X509v3 Basic Constraints:
CA: FALSE
.
----- BEGIN CERTIFICATE -----
MIICdzCCAeCgAwIBAgIBATANBgkqhkiG9w0BAQUFADAsMRAwDgYDVQQKEwdTZWNj
dXJlMRgwFgYDVQQLEw9TZWNjdXJlIFJvb3QgQ0EwHhcNMDQxMTI4MDEwMDIwWhcN
.
ou0Kuxqk6E66ZpNjdIf9Q0i2k6LjPdobZEY1iLRLIuY8hHBdiN1kwlHC1lmAh7y9
f + PBRX7AX5zK4aE =
----- END CERTIFICATE -----

- If your certificate is received as TXT + PEM, here is the command to convert it to PEM:

openssl x509 -in signed_cert.pem -out server.crt

- DER, encoded binary encoded X.509 (* .der, * .crt, * .cer)

[non-text, binary representation]

- If your certificate is received as DER, the switch to PEM is:

openssl x509 -in signed_cert.der -inform DER -out server.crt

4. Verify and check the certificate

Before installing the certificate, we should check to see if the certificate is actually valid and can be used to authenticate the web server:

openssl verify -CAfile /path/to/trusted_ca.crt -purpose sslserver server.crt

Likewise, if it runs well, make sure that the certificate corresponds to the previously created web server's private key (the results of both statements are identical):

openssl x509 -noout -modulus -in server.crt | openssl sha1
openssl rsa -noout -modulus -in server.key | openssl sha1

( Also )