TLS and Certificates

TLS works using digital certificates and a type of cryptography called public key encryption. Public key encryption works with two keys: the public key is available publicly, and the private key is stored on the server and kept secret. Anything that is encrypted using the public key can be decrypted only with the corresponding private key; this is the same concept described in the “DNSSEC” sidebar section in Chapter 10.

When using TLS, the digital certificate is the server’s public key and acts like an electronic driver’s license. It identifies the server or the web site you are connecting to. When you connect to an HTTPS web site, what your browser is doing is accepting the site’s digital certificate as evidence the site is who it says it is. Like driver’s licenses, certificates have an expiry period and are valid only for a fixed period, usually 12 months.

Each digital certificate can also contain a reference to a certificate authority. A CA is a mechanism that issues certificates and has a special certificate called a root certificatethat is then used to validate the server certificate’s veracity. To use the same license metaphor, the root certificate is like your state’s department of motor vehicles. It is the place people go to check that you have a valid license and that you are who you say you are. These root certificates are usually bundled with the clients you use to connect to servers; for example, your web browser will have a collection of root certificates from well-known CAs.

So, the basic flow for certificate-based encryption (in simple terms) is as follows:

1. Your client connects to a server and asks for the certificate.

2. The server presents its certificate.

3. The client checks for a reference to a root certificate.

4. The client uses the root certificate bundled with it to validate that your certificate is genuine.

5. If your client trusts the certificate, a connection is initiated and is encrypted between the client and server using the server’s public certificate.

There are four types of certificates that you need to know about, and there are pros and cons with using each type.

• Certificates issued by a commercial CA

• Certificates issued by a noncommercial CA

• Certificates issued by a self-managed CA

• Self-signed certificates

Certificates from Commercial Certificate Authorities

Certificates from commercial CAs are issued by popular providers such as VeriSign, Thawte, or Comodo. These certificates generally require regular payment, for example, yearly or biannually. The prices vary depending on the type and number of certificates. The root certificates of most commercial CAs are bundled with clients such as browsers, mail clients, and other tools that use SSL/TLS connections. Commercial CAs are usually regularly audited for security, and a certificate issued by them is generally assumed to be secure.

Certificates from Non-commercial Certificate Authorities

In addition to the commercial certificate providers are a small number of noncommercial providers. These providers don’t charge for their certificates, but correspondingly their root certificates are sometimes not bundled with many browsers. This means if you use these certificates for a web site or to secure a service like Simple Mail Transfer Protocol (SMTP) , your client will most likely warn you that the validity and security certificates can’t be determined.

If the CA’s root is not installed in the browser, the only way to overcome this is to manually add a noncommercial CA’s root certificate to the browser. If you have a lot of client browsers, this can add a lot of overhead and maintenance to your environment. In many cases, such as a web site, you don’t have access to the clients, and these errors may result in someone getting the message that the client cannot validate the certificate and hence not trust your web site. For example, this makes using noncommercial certificates for an e-commerce site problematic.

However, things have changed more recently. There has been a big push to encrypt the Internet in an effort to make the Internet more secure. One of the reasons for not using HTTPS on sites is that certificates are too expensive and noncommercial certificates are not widely supported, as we have mentioned. The Internet Security Research Group (ISRG) decided to create Let’s Encrypt to solve this problem.

Let’s Encrypt is a nonprofit organization dedicated to helping encrypt the Internet by providing a simple and automated mechanism for getting and installing TLS certificates. The Let’s Encrypt root CA is also bundled in a lot of modern browsers, which solves many of the issues faced by noncommercial CAs. You can find more information about Let’s Encrypt at https://letsencrypt.org/ .

An alternative way of getting noncommercial certificates is using CAcert. It provides free temporary certificates (like Let’s Encrypt) but also allows you to have longer certificates if you pass a “key of trust” that validates domain owners. For more information, see the CAcert web site and wiki: www.cacert.org/ and http://wiki.cacert.org/wiki/ .

Certificates from Self-Managed Certificate Authorities

You can also create and manage your own certificates. These certificates are issued by a certificate authority that you create and manage yourself. As a result, the certificates don’t cost any money, but they do have other issues. First, as it is your own CA, you can’t expect others to trust your certificates. This leads us to the second issue: usability. The root certificate of your CA is not bundled with clients and will never be. So if you want to install our root certificate, you will need to do so via software management (like Ansible or Puppet, discussed in Chapter 19).

Hence, when your web client attempts to validate certificates provided by your CA, for example, an error message is generated indicating that the client does not trust the CA. Other services may just refuse to connect altogether with a valid certificate. To overcome this error, you need to install your CA’s root certificate on the client. This is something you can do for clients you manage, for example, your internal desktops, but for others this isn’t feasible.

Self-Signed Certificates

Self-signed certificates don’t use a CA. They are signed by you and hence don’t cost any money either. Like certificates generated by a self-managed CA, they are not trusted and will generate a similar error message on your clients. Unlike those generated by a self-managed CA, you can’t remove this error by adding a root certificate because you have no root certificate to add to the client. Self-signed certificates are generally used only for testing and are rarely used in production environments.

Choosing a Certificate Type

If you want to buy a certificate for a long period of time, the best certificates to use are those issued by commercial CAs. The key issue here is cost. A certificate from a commercial CA can cost hundreds of dollars a year. This is a considerable expense just to secure your e-mail or your business marketing site. As a result, if you don’t want the expense of buying certificates, we recommend a Let’s Encrypt certificate.

If we choose a commercial certificate, we will need to create the private key and a certificate signing request (CSR). We show that next.

Creating Certificates for TLS

As you’ve discovered, for TLS to work we need two certificates: a server certificate and the root certificate from a CA (either a commercial CA, a noncommercial CA, or your own CA). Let’s start by generating our first server certificate. This first step is generating a server key and a CSR. We would take these steps whether we were generating a certificate from a commercial or a self-managed CA.

The process creates our private key and a CSR. This CSR is then submitted to a CA, in our case our own CA, but also to a commercial CA. It is this signing process that allows a client to confirm the identity of a server certificate.

In Listing 11-6, we generate a key and the request using the openssl command that is part of the OpenSSL application. The OpenSSL application is an open source SSL implementation that allows Linux and other operating systems to encrypt and secure applications using SSL.

Listing 11-6. Generating a Server Key and Request

$ openssl genpkey -algorithm RSA -out www.example.com.key -pkeyopt rsa_keygen_bits:2048
.........................................................................+++
.................+++

In Listing 11-6 we’ve used the openssl command to generate a private key using the RSA cipher. The key is 2,048 bits long, which is the current standard for the Internet but can be higher if you want. The issue is that some CAs will not support larger key lengths.

We pass the -algorithm option to tell the openssl command to use the RSA cipher, and the -out option tells the openssl command where to write the key, here to the www.example.com.key file. We pass the bit size to openssl via –pkeyopt rsa_keygen_bits:2048.

Next we want to generate a CSR. It is this that we would give to the CA for signing. This is generated from our private key we just generated. This way we do not have to give anyone our private key in order to get our certificate. While the private key is precious and needs to be secured, the CSR is public and doesn’t need such restrictions. We create a CSR as shown in Listing 11-7.

Listing 11-7. Generating the CSR

$ openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:AU
State or Province Name (full name) []:Victoria
Locality Name (eg, city) [Default City]:Melbourne
Organization Name (eg, company) [Default Company Ltd]:Example Inc
Organizational Unit Name (eg, section) []:IT
Common Name (eg, your name or your server's hostname) []:www.example.com
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

During the request creation process, you will be prompted for some information about your new certificate. If you don’t want to answer a specific query, you can type Enter to skip the field. You will be prompted for the two-letter country code, for example, US for the United States, GB for Great Britain, and AU for Australia.

You will also be prompted for the state, municipality, and name of your organization and optionally an organizational unit in your organization. This data will be displayed in your certificate when a client or user queries it. It’s a good idea to be specific and accurate here—especially if you are submitting your CSR to be signed by a commercial CA.

Next, and most important, we need to specify the common name of the certificate. This must be the exact hostname of the server that is going to use the certificate. If you specify an incorrect hostname, you will get an error about a mismatch between the server and certificate name. In this case, we specify mail.example.com, which is the fully qualified hostname of the e-mail server.

Then specify the e-mail address of the contact for the certificate , in this case [email protected].

Last, you are prompted for some extra attributes for the certificate. You don’t need to worry about these, and you can type Enter to skip the fields.

This process will leave you with two files: www.example.com.key and www.example.com.csr . We will keep these two files, as we’ll need them later in this process.

The next step in the process is signing the CSR with a CA. If you’re going to create your own CA, see the next section, “Creating Your Own Certificate Authority.”

Otherwise, you need to provide the contents of the www.example.com.csr file that you would provide to your commercial CA, and it will then deliver a certificate to you. Your commercial CA will provide instructions as to how to provide your CSR file. Usually, you would cut and paste the contents of the CSR into a web page and submit it. The CA would then sign it and notify you when a signed certificate was available to download.

In the next chapter we are going to show you how you can create another certificate and use it in your Postfix installation.

Creating Your Own Certificate Authority

Creating your own CA is an easy task. First, you create a directory to hold your CA and some subdirectories inside that directory. CentOS stores all OpenSSL files in the /etc/pki directory. Ubuntu uses /etc/ssl. In this example, we’re going to put our CA in the /etc/pki directory on our CentOS host. The following directories should already exist:

$ sudo mkdir /etc/pki/CA
$ sudo mkdir /etc/pki/CA/{private,newcerts,crl,certs}
$ sudo chown –R root:root /etc/pki/CA
$ sudo chmod 0700 /etc/pki/CA/private

The private directory will hold the CA’s private key, and the newcerts directory will contain a copy of each certificate the CA will sign. We also ensure the root user owns all the directories, and we secure the private directory so that only the root user can access it.

Next, you need to create a database to hold details of your signed certificates.

$ echo '01' | sudo tee /etc/pki/CA/serial
$ sudo touch /etc/pki/CA/index.txt

The serial file tracks the last serial number of certificates issued through this CA, starting with the number 01. Each certificate issued by the CA has a unique serial number.

The index.txt file will contain a list of the certificates currently being managed by this CA. Next to each certificate will be a letter indicating the status of that certificate.

• R: Revoked

• E: Expired

• V: Valid

OpenSSL has a configuration file that controls defaults and CA settings. There is a template file available on most distributions. This file, called openssl.cnf, is located in the /etc/pki/tls/ directory on CentOS distributions and in the /etc/ssl/ directory on Ubuntu.

If you are using a nonstandard directory for your CA or have some other settings, you can make a copy of this file and edit it in your CA directory. To do this, find the section in the configuration file that starts with the following:

[ CA_default ]

In the following example, we change the configuration option called dir. If we wanted to change the openssl command to read CA information from the current directory, we would do the following:

dir = .

This tells OpenSSL to look in the current directory for directories and files needed to configure and sign certificates. For CentOS, this is already set to /etc/pki/CA. Ubuntu has this set to ./demoCA. This means when you sign a certificate, you must change your working directory to the CA directory, in our case, /etc/pki/CA.

Now you need to create a self-signed certificate and a private key for your CA.

$ cd /etc/pki/CA
$ sudo openssl req -new -x509 -newkey rsa:4096 -keyout private/cakey.pem 
   -out certs/cacert.pem -days 3650 
   -subj '/C=AU/ST=Victoria/L=Melbourne/O=Example Inc/OU=IT/CN=ca.example.com/[email protected]/'
Generating a 4096 bit RSA private key
...................................++
..................................................................................................................................................++
writing new private key to 'private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----

First, as we mentioned, we change our working directory to /etc/pki/CA. Next, we’re creating a key, this one also RSA and 4,096 bits long. We store that key in the /etc/pki/CA/private/cakey.pem file. We’re also creating the certificate as self-signed because we don’t have another CA to sign it. We specify the age of the certificate as 3,650 days (or 10 years). We have specified some other options: -x509, which indicates the certificate is self-signed, and -extensions v3_ca, which specifies that we’re creating a CA certificate. The last option, -subj, allows us to answer the attributes we add to the certificate subject.

You’ll be prompted for a passphrase or password for your CA private key. Choose a good password and remember it. You’ll need this password every time you create a new certificate.

As you can see, the CA is made up of a private key and a public certificate. You now have your own CA and can use it to sign certificates.

Signing Your Certificate with Your Certificate Authority

Now that you’ve created your CA, you can use it to sign your certificate request. In our case, the CA is on the same host that we have created our CSR requests. You would normally need to copy the CSR file to the CA host. This takes your CSR and signs it with your CA and outputs a signed certificate. In Listing 11-8, we’ve signed our CSR.

Listing 11-8. Signing Our Certificate Request

$ cd /etc/pki/CA
$ sudo openssl ca -out /root/www.example.com.cert -infiles /root/www.example.com.csr
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Aug 21 02:05:11 2016 GMT
            Not After : Aug 21 02:05:11 2017 GMT
        Subject:
            countryName               = AU
            stateOrProvinceName       = Victoria
            organizationName          = Example Inc
            organizationalUnitName    = IT
            commonName                = www.example.com
            emailAddress              = [email protected]
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                3E:37:13:CB:D3:84:58:9D:47:73:89:A6:80:12:DD:90:FE:C7:06:4B
            X509v3 Authority Key Identifier:
                keyid:54:57:27:C4:82:CA:C2:97:CE:5E:C7:64:A8:99:D3:A8:D1:1E:EC:77

Certificate is to be certified until Aug 21 02:05:11 2017 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

In Listing 11-8, we’ve used the ca option to sign our request. The -out option specifies the signed certificate we’re going to output, and the -infiles option specifies the CSR we want to sign (we’ve assumed our CSR file is in the /root directory).

You will be prompted for the passphrase you created for the CA’s private key, then the details of your certificate will be displayed, and finally you will be prompted to sign the certificate and write its details to the CA’s database. Answer y for yes to both questions.

At the end of the process, you will have a signed certificate, a private key, and a certificate request all located in the /root directory. Your certificate is valid for one year (you can override this period using the -days option to specify a different validity period).

You can examine the details of your certificate using the openssl command.

$ openssl x509 -in /root/www.example.com.cert -noout -text -purpose | more

Remember, to avoid your clients indicating that your certificates are not trusted, you must install your root certificate in the relevant client, for example, the user’s browser! The CAcert site has instructions for installing its root certificate into a variety of clients at http://wiki.cacert.org/FAQ/BrowserClients . To install your certificate, replace its certificate with yours in the instructions.

Configuration

Squid is provided by the squid package. Install it via sudo yum install squid on CentOS or sudo aptitude install squid on Ubuntu. Both distributions use the same configuration file for Squid, which is /etc/squid/squid.conf. Because this file can contain sensitive information (e.g., passwords), you cannot even view it without using sudo.

The default configuration file on Ubuntu is well commented, so we won’t go into great detail about most options. The squid.conf file on CentOS has been striped to the recommended minimum settings. We will show you how to configure which address and port Squid should listen on and how to configure it so your users are actually permitted to access the Web via the cache.

Squid listens on port 3128 on all network interfaces by default, though port 8080 is used commonly as well. The directive to modify the port in the configuration file is http_port. This directive allows you to specify a port number or an address and port number combination.

If you want Squid to listen on multiple addresses and ports, you can add more http_port directives.

Because we’re setting up Squid on the gateway host, we don’t want it to listen for connections on all interfaces; users not on our local networks should not be able to access it. We thus need to add two http_port lines: one for the wireless network address range and one for the wired range.

http_port 192.168.0.254:3128
http_port 192.168.1.254:3128

Next, we need to tell Squid which ranges of IP addresses are allowed to connect to it and access web sites. Squid uses access control lists (ACLs) for this. For each network range you want to control, you need to define an ACL. You then create rules that control access for each ACL. The configuration file contains a few basic ACLs, which we’ve included in Listing 11-9.

Listing 11-9. ACL Definitions

acl all src 0.0.0.0/0.0.0.0
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8

The acl directive tells Squid the rest of the line is an ACL definition. Next, we give the ACL a label so we can refer to it later. Then we specify the ACL type we’re creating. Squid supports many types, but we’ll be using only src, dst, and port, which control whether we’re dealing with source addresses, destination addresses, or port numbers. Finally, we define the source, destination, or port using a string. To get a full list of ACL types, you can read through the ACL section on the Squid web site at www.squid-cache.org/Versions/v2/2.6/cfgman/acl.html .

In our case, we’ve defined an ACL called all that encompasses all Internet addresses. The next ACL allows us to refer to all traffic originating on the local network interface as localhost. The third does the same but for traffic to the local network interface.

Let’s add in some ACLs for our network addresses. We can add these directly under the line that defines to_localhost.

acl wired src 192.168.0.0/255.255.255.0
acl wireless src 192.168.1.0/255.255.255.0

We’ve defined two new ACLs, one for the wired network range and one for the wireless range. We could have combined them by simply specifying the same label for both ACLs. However, giving them different names means we can give them different levels of access to the Web, should we want to.

Another configuration option that might be useful is to set the time you want to allow access from any particular network or zone.

acl wireless_hours time M T W T F 8:30-17:30

Squid contains an ACL called Safe_ports that contains commonly used ports for web and FTP traffic. This way, you can control which ports on remote servers you want local users to be able to connect to. If a site you need to access runs on a nonstandard port, you can add the port number to the Safe_ports ACL and so permit browsers to connect to it.

acl Safe_ports port 80  # http
acl Safe_ports port 21     # ftp
acl Safe_ports port 443 # https

Now that we have defined all the ACLs we need, we can complete our configuration by defining access rules for these ACLs. Squid uses the http_access directive to determine whether a given ACL is allowed to use the cache. This directive has two parameters, an action and an ACL . These directives are processed in order, and processing stops when a rule matches.

The first rule prevents browsers from connecting to ports we haven’t explicitly listed in the Safe_ports ACL.

http_access deny !Safe_ports

Next, localhost is permitted to connect, and all other connections are rejected.

http_access allow localhost
http_access deny all

If no http_access rule matches, the opposite of the last seen action is applied. This is why it’s important to always leave http_access deny all in place as the final rule; it means Squid will deny access unless it encounters a rule to allow access.

We should insert our new rules in between, as shown in Listing 11-10.

Listing 11-10. Granting Access for Our Networks

http_access allow localhost
http_access allow wired
http_access allow wireless wireless_hours
http_access deny all

We are going to add some logging to help track down any issues with our configuration. To do this, we add the access_log directive. Logs will be written to /var/log/squid.

access_log daemon:/var/log/squid/access.log squid

This is will give us some logging details for our access logs like this example:

1471953526.429    934 192.168.0.1 TCP_MISS/200 10265 GET http://blahblah.com/ - HIER_DIRECT/64.207.180.61 text/html
1471953526.961    493 192.168.0.1 TCP_MISS/200 19834 GET http://blahblah.com/blah.jpg - HIER_DIRECT/64.207.180.61 image/jpeg
...
1471953633.942    389 192.168.0.1 TCP_REFRESH_UNMODIFIED/304 305 GET http://blahblah.com/ - HIER_DIRECT/64.207.180.61 –

In this example of our access log, you can see that we first get the resource we are after, and then we can see a subsequent request returns a 304 unmodified status.

Finally, we can change the directory on the disk that Squid uses to store its cached objects using the cache_dir directive. This is commented out, which means it will use the built-in default, as follows:

# cache_dir ufs /var/spool/squid 100 16 256

The preceding line tells Squid to store cache objects under the /var/spool/squid directory in ufs format. It will store a maximum of 100Mb of objects; after that, older objects will be expired from the cache and replaced by newer ones. The final two numbers control how many subdirectories Squid will create in the main cache directory. In this case, it will create 16 main subdirectories, each containing another 256 subdirectories.

This subdirectory schema came about because most filesystems are quite slow at accessing directories containing a large number of files . For example, if each of the Squid subdirectories contained about 100 cached files, the total number of files in the cache would exceed 400,000. If they were all stored in a single directory, each time one of these files was requested by a browser, the host would need to search through up to 400,000 entries in the directory inode to find out where the data it needs is stored. By subdividing the cache, the number of inodes that need to be searched for any given file is much smaller, resulting in less performance degradation as the cache grows.

Since disk space is generally cheaper than bandwidth, we’ll allow our cache to grow bigger.

cache_dir ufs /var/spool/squid 2000 16 256

We save the configuration file and start Squid. On CentOS, we should create the startup links via systemctl first.

$ sudo systemctl enable squid

We can now start Squid via sudo systemctl start squid on CentOS or restart it on Ubuntu via sudo service squid restart. On CentOS, the cache directory we specified will be created when Squid first starts. This already happened on Ubuntu, when we installed the package.

Client Configuration

All that is left for us to do is configure the web browser to use the proxy. In Chrome , we choose Settings ➤ Network ➤ Change proxy settings. On this Apple Mac host, we can configure the proxy service as shown in Figure 11-21 for http://-only traffic.

Figure 11-21. Setting a proxy server in Chrome

We could configure the traffic for https:// also if we so choose to. We then close the network and Chrome settings and visit our favorite web site. We can verify that the proxy is being used by looking at the Squid access logs.

Transparency

If you don’t want to make your users change their proxy settings in order to use the Squid cache, you can run Squid as a transparent proxy instead. A transparent proxyis one that has all outbound web traffic redirected to it via firewalling rules. Browsers accessing the Web don’t know they’re using a cache, and you don’t need to explicitly configure any web browsers to use it.

To turn our current configuration into a transparent proxy, we have to make two small changes to the configuration file. For each http_port directive, we need to add the option transparent.

http_port 192.168.0.254:3128 transparent
http_port 192.168.1.254:3128 transparent

After restarting Squid, we add firewall rules on the gateway host. These rules should intercept all connections to remote web sites and redirect them to our proxy instead. We want to change the destination address and port number on packets before the gateway sends them out to the Internet. This is a form of network address translation (NAT), and it is done by Netfilter in the NAT table. The command firewall-cmd can be used for this again.

To change the destination address of a packet, we need to create a DNAT target and mangle the HTTP traffic outbound. First make sure that we masquerade our connection. Then we forward traffic coming in to the firewall on port 80 to be redirected to port 3128 where Squid will be waiting.

$ sudo firewall-cmd --permanent --zone=public --add-masquerade
$ sudo firewall-cmd --permanent --zone=public --add-forward-port=port=80:proto=tcp:toport=3128:to_addr=192.168.0.254
$ sudo firewall-cmd --reload

We then reload the firewall to make the changes permanent.