Using Encryption Techniques | Red Hat Fedora Linux 3 Bible

The previous sections told you how to lock the doors to your Fedora system to deny access to crackers. The best dead bolt lock, however, is useless if you are mugged in your own driveway and have your keys stolen. Likewise, the best computer security can be for naught if you are sending passwords and other critical data unprotected across the Internet.

A savvy cracker can use a tool called a protocol analyzer or a network sniffer to peek at the data flowing across a network and pick out passwords, credit card data, and other juicy bits of information. The cracker does this by breaking into a poorly protected system on the same network and running software, or by gaining physical access to the same network and plugging in his or her own equipment.

You can combat this sort of theft by using encryption. The two main types of encryption in use today are symmetric cryptography and public-key cryptography.

Symmetric cryptography

Symmetric cryptography, also called private-key cryptography, uses a single key to both encrypt and decrypt a message. This method is generally inappropriate for securing data that will be used by a third party, due to the complexity of secure key exchange. Symmetric cryptography is generally useful for encrypting data for one’s own purposes.

A classic use of symmetric cryptography is for a personal password vault. Anyone who has been using the Internet for any amount of time has accumulated a quantity of user names and passwords for accessing various sites and resources. A personal password vault lets you store this access information in an encrypted form. The end result is that you only have to remember one password to unlock all of your access information.

Until recently, the United States government was standardized on a symmetric encryption algorithm called DES (Data Encryption Standard) to secure important information. Because there is no direct way to crack DES encrypted data, to decrypt DES encrypted data without a password you would have to use an unimaginable amount of computing power to try to guess the password. This is also known as the brute force method of decryption.

As personal computing power has increased nearly exponentially, the DES algorithm has had to be retired. In its place, after a very long and interesting search, the United States. government has accepted the Rijndael algorithm as what it calls the AES (Advanced Encryption Standard). Although the AES algorithm is also subject to brute force attacks, it requires significantly more computing power to crack than the DES algorithm does.

For more information on AES, including a command line implementation of the algorithm, you can visit http://aescrypt.sourceforge.net/.

Public-key cryptography

Public-key cryptography does not suffer from key distribution problems, and that is why it is the preferred encryption method for secure Internet communication. This method uses two keys, one to encrypt the message and another to decrypt the message. The key used to encrypt the message is called the public key because it is made available for all to see. The key used to decrypt the message is the private key and is kept hidden. The entire process works like this:

Imagine that you want to send me a secure message using public-key encryption. Here is what we need:

I must have a public and private key pair. Depending on the circumstances, I may generate the keys myself (using special software) or obtain the keys from a key authority.
You want to send me a message, so you first look up my public key (or more accurately, the software you are using looks it up).
You encrypt the message with the public key. At this point, the message can only be decrypted with the private key (the public key cannot be used to decrypt the message).
I receive the message and use my private key to decrypt it.

Secure Socket Layer

A classic implementation of public-key cryptography is with secure sockets layer (SSL) communication. This is the technology that enables you to securely submit your credit card information to an online merchant. The elements of an SSL encrypted session are as follows:

SSL-enabled Web browser (Mozilla, Internet Explorer, Opera, Konquerer, etc.)
SSL-enabled Web server (Apache)
SSL certificate

To initiate an SSL session, a Web browser first makes contact with a Web server on port 443, also known as the HTTPS port (Hypertext Transport Protocol Secure). After a socket connection has been established between the two machines, the following occurs:

The server sends its SSL certificate to the browser.
The browser verifies the identity of the server through the SSL certificate.
The browser generates a symmetric encryption key.
The browser uses the SSL certificate to encrypt the symmetric encryption key.
The browser sends the encrypted key to the server.
The server decrypts the symmetric key with its private key counterpart of the public SSL certificate.
The browser and server can now encrypt and decrypt traffic based on a common knowledge of the symmetric key.

Secure data interchange can now occur.

Creating SSL Certificates

In order to create your own SSL certificate for secure HTTP data interchange, you must first have an SSL-capable Web server. The Apache Web server (httpd package), which comes with Fedora, is SSL-capable. Once you have a server ready to go, you should familiarize yourself with the important server-side components of an SSL certificate:

# ls -l /etc/httpd/conf  -rw-r--r--  1 root     root      36010 Jul 14 15:45 httpd.conf  lrwxrwxrwx  1 root     root      37 Aug 12 23:45 Makefile ->  ../../../usr/share/ssl/certs/Makefile  drwx------  2 root     root      4096 Aug 12 23:45 ssl.crl  drwx------  2 root     root      4096 Aug 12 23:45 ssl.crt  drwx------  2 root     root      4096 Jul 14 15:45 ssl.csr  drwx------  2 root     root      4096 Aug 12 23:45 ssl.key  drwx------  2 root     root      4096 Jul 14 15:45 ssl.prm      # ls -l /etc/httpd/conf.d/ssl.conf  -rw-r--r--  1 root     root      11140 Jul 14 15:45 ssl.conf

The /etc/httpd/conf and /etc/httpd/conf.d directories contains all of the components necessary to create your SSL certificate. Each component is defined as follows:

httpd.conf — Web server configuration file.
Makefile — Certificate building script.
ssl.crl — Certificate revocation list directory.
ssl.crt — SSL certificate directory.
ssl.csr — Certificate service request directory.
ssl.key — SSL certificate private key directory.
ssl.prm — SSL certificate parameters.
ssl.conf — Primary Web server SSL configuration file.

Now that you’re familiar with the basic components, take a look at the tools used to create SSL certificates:

# cd /etc/httpd/conf  # make  This makefile allows you to create:    o public/private key pairs    o SSL certificate signing requests (CSRs)    o self-signed SSL test certificates      To create a key pair, run "make SOMETHING.key".  To create a CSR, run "make SOMETHING.csr".  To create a test certificate, run "make SOMETHING.crt".  To create a key and a test certificate in one file, run "make  SOMETHING.pem".      To create a key for use with Apache, run "make genkey".  To create a CSR for use with Apache, run "make certreq".  To create a test certificate for use with Apache, run "make testcert".      Examples:    make server.key    make server.csr    make server.crt    make stunnel.pem    make genkey    make certreq    make testcert

The make command utilizes the Makefile to create SSL certificates. Without any arguments the make command simply prints the information listed above. The following defines each argument you can give to make:

make server.key — Creates generic public/private key pairs.
make server.csr — Generates a generic SSL certificate service request.
make server.crt — Generates a generic SSL test certificate.
make stunnel.pem — Generates a generic SSL test certificate, but puts the private key in the same file as the SSL test certificate.
make genkey — Same as make server.key except it places the key in the ssl.key directory.
make certreq — Same as make server.csr except it places the certificate service request in the ssl.csr directory.
make testcert — Same as make server.crt except it places the test certificate in the ssl.crt directory.

Using third-party certificate signers

In the real world, I know who you are because I recognize your face, your voice, and your mannerisms. On the Internet, I cannot see these things and must rely on a trusted third party to vouch for your identity. To ensure that a certificate is immutable, it has to be signed by a trusted third party when the certificate is issued and validated every time an end user taking advantage of your secure site loads it. The following is a list of the trusted third-party certificate signers:

GlobalSign — https://www.globalsign.net/
GeoTrust — https://www.geotrust.com/
VeriSign — https://www.verisign.com/
FreeSSL — http://www.freessl.com/
Thawte — http://www.thawte.com/
EnTrust — http://www.entrust.com/
ipsCA — http://www.ipsca.com/

COMODO Group — http://www.comodogroup.com/

Note

Because of the fluid nature of the certificate business, some of these companies may not be in business when you read this, while others may have come into existence. To get a more current list of certificate authorities, from your Mozilla Firefox browser select Edit ® Preferences. From the Preferences window that appears, select Advanced ® Manage Certificates. From the Certificate Manager window that appears, refer to the Authorities tab to see Certificate Authorities from which you have received certificates.

Each of these certificate authorities has gotten a chunk of cryptographic code embedded into nearly every Web browser in the world. This chunk of cryptographic code allows a Web browser to determine whether or not an SSL certificate is authentic. Without this validation, it would be trivial for crackers to generate their own certificates and dupe people into thinking they are giving sensitive information to a reputable source.

Certificates that are not validated are called self-signed certificates. If you come across a site that has not had its identity authenticated by a trusted third party, your Web browser will display a message similar to the one shown in Figure 14-3.

image from book
Figure 14-3: A pop-up window alerts you when a site is not authenticated.

This does not necessarily mean that you are encountering anything illegal, immoral, or fattening. Many sites opt to go with self-signed certificates, not because they are trying to pull a fast one on you, but because there may not be any reason to validate the true owner of the certificate and they do not want to pay the cost of getting a certificate validated. Some reasons for using a self-signed certificate include:

The Web site accepts no input — In this case, you as the end user, have nothing to worry about. There is no one trying to steal your information because you aren’t giving out any information. Most of the time this is done simply to secure the Web transmission from the server to you. The data in and of itself may not be sensitive, but, being a good netizen, the site has enabled you to secure the transmission to keep third parties from sniffing the traffic.
The Web site caters to a small clientele — If you run a Web site that has a very limited set of customers, such as an Application Service Provider, you can simply inform your users that you have no certificate signer and that they can browse the certificate information and validate it with you over the phone or in person.
Testing — It makes no sense to pay for an SSL certificate if you are only testing a new Web site or Web-based application. Use a self-signed certificate until you are ready to go live.

Creating a Certificate Service Request

To create a third-party validated SSL certificate, you must first start with a Certificate Service Request (CSR). To create a CSR, do the following on your Web server:

 # cd /etc/httpd/conf  # make certreq umask 77 ; \  /usr/bin/openssl genrsa -des3 1024 > /etc/httpd/conf/ssl.key/server.key   .   .   .

You will now be asked to enter a password to secure your private key. This password should be at least eight characters long, and should not be a dictionary word or contain numbers or punctuation. The characters you type will not appear on the screen, in order to prevent someone from shoulder surfing your password.

Enter pass phrase:

Enter the password once again to verify.

Verifying - Enter pass phrase:

The certificate generation process now begins.

At this point, it is time to start adding some identifying information to the certificate that the third-party source will later validate. Before you can do this, you must unlock the private key you just created. Do so by typing the password you typed above. Then enter information as you are prompted. An example of a session for adding information for your certificate is shown below:

Enter pass phrase for /etc/httpd/conf/ssl.key/server.key:  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) [GB]:US State or Province Name (full name) [Berkshire]: Connecticut Locality Name (eg, city) [Newbury]: Mystic Organization Name (eg, company) [My Company Ltd]:Acme Marina, Inc.  Organizational Unit Name (eg, section) []:InfoTech Common Name (eg, your name or your server's hostname)  []:www.acmemarina.com Email Address []: webmaster@acmemarina.com

To complete the process, you will be asked if you want to add any extra attributes to your certificate. Unless you have a reason to provide more information, you should simply press Enter at each of the following prompts to leave them blank.

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

Getting the CSR Signed

Once your CSR has been created, you need to send it to a signing authority for validation. The first step in this process is to select a signing authority. Each signing authority has different deals, prices and products. Check out each of the signing authorities listed in the “Using third- party certificate signers” section earlier in this chapter to determine which works best for you. The following are areas where signing authorities differ:

Credibility and stability
Pricing
Browser recognition
Warranties
Support
Certificate strength

After you have selected your certificate signer, you have to go through some validation steps. Each signer has a different method of validating identity and certificate information. Some require that you fax articles of incorporation, while others require a company officer be made available to talk to a validation operator. At some point in the process you will be asked to copy and paste the contents of the CSR you created into the signer’s Web form.

 # cd /etc/httpd/conf/ssl.csr # cat server.csr -----BEGIN CERTIFICATE REQUEST-----  MIIB6jCCAVMCAQAwgakxCzAJBgNVBAYTAlVTMRQwEgYDVQQIEwtDb25uZWN0aWN1  dDEPMA0GA1UEBxMGTXlzdGljMRowGAYDVQQKExFBY21lIE1hcmluYSwgSW5jLjER  MA8GA1UECxMISW5mb1RlY2gxGzAZBgNVBAMTEnd3dy5hY21lbWFyaW5hLmNvbTEn  MCUGCSqGSIb3DQEJARYYd2VibWFzdGVyQGFjbWVtYXJpbmEuY29tMIGfMA0GCSqG  SIb3DQEBAQUAA4GNADCBiQKBgQDcYH4pjMxKMldyXRmcoz8uBVOvwlNZHyRWw8ZG  u2eCbvgi6w4wXuHwaDuxbuDBmw//Y9DMI2MXg4wDq4xmPi35EsO1Ofw4ytZJn1yW  aU6cJVQro46OnXyaqXZOPiRCxUSnGRU+0nsqKGjf7LPpXv29S3QvMIBTYWzCkNnc  gWBwwwIDAQABoAAwDQYJKoZIhvcNAQEEBQADgYEANv6eJOaJZGzopNR5h2YkR9Wg  l8oBl3mgoPH60Sccw3pWsoW4qbOWq7on8dS/++QOCZWZI1gefgaSQMInKZ1II7Fs  YIwYBgpoPTMC4bp0ZZtURCyQWrKIDXQBXw7BlU/3A25nvkRY7vgNL9Nq+7681EJ8  W9AJ3PX4vb2+ynttcBI=  -----END CERTIFICATE REQUEST-----

You can use your mouse to copy and paste the CSR into the signer’s Web form.

After you have completed the information validation, paid for the signing, and answered all of the questions, you have completed most of the process. Within 48 to 72 hours you should receive an e-mail with your shiny new SSL certificate in it. The certificate will look similar to the following:

Copy and paste this certificate into an empty file called server.crt, which must reside in the /etc/httpd/conf/ssl.crt directory, and restart your Web server:

 # service httpd restart

Assuming your Web site was previously working fine, you can now view it in a secure fashion by placing an “s” after the http in the Web address. So if you previously viewed your Web site at http://www.acmemarina.com, you can now view it in a secure fashion by going to https://www.acmemarina.com.

Creating Self-Signed Certificates

Generating and running a self-signed SSL certificate is much easier than having a signed certificate. To generate a self-signed SSL certificate, do the following:

Remove the key and certificate that currently exist:

 # cd /etc/httpd/conf # rm ssl.key/server.key ssl.crt/server.crt

Create your own server key:
```
 # make genkey 
```

Create the self-signed certificate by typing the following:

 # make testcert umask 77 ; \  /usr/bin/openssl req -new -key /etc/httpd/conf/ssl.key/server.key       -x509 -days 365 -out /etc/httpd/conf/ssl.key/server.crt      .      .      .

At this point, it is time to start adding some identifying information to the certificate. Before you can do this, you must unlock the private key you just created. Do so by typing the password you typed earlier. Then follow this sample procedure:

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) [GB]:US State or Province Name (full name) [Berkshire]: Ohio Locality Name (eg, city) [Newbury]: Cincinnati Organization Name (eg, company) [My Company Ltd]:Industrial Press, Inc. Organizational Unit Name (eg, section) []:IT Common Name (eg, your name or your server's hostname)  []:www.industrialpressinc.com Email Address []: webmaster@industrialpressinc.com

The generation process above places all files in the proper place. All you need to do is restart your Web server and add https instead of http in front of your URL. Don’t forget, you’ll get a certificate validation message from your Web browser, which you can safely ignore.

Restarting your Web server

By now you’ve probably noticed that your Web server requires you to enter your certificate password every time it is started. This is to prevent someone from breaking into your server and stealing your private key. Should this happen, you are safe in the knowledge that the private key is a jumbled mess. The cracker will not be able to make use of it. Without such protection, a cracker could get your private key and easily masquerade as you, appearing to be legitimate in all cases.

If you just cannot stand having to enter a password every time your Web server starts, and are willing to accept the increased risk, you can remove the password encryption on your private key. Simply do the following:

 # cd /etc/httpd/conf/ssl.key # /usr/bin/openssl rsa -in server.key -out server.key

Troubleshooting your certificates

The following tips should help if you are having problems with your SSL certificate.

Only one SSL certificate per IP address is allowed. If you want to add more than one SSL-enabled Web site to your server, you must bind another IP address to the network interface.
Make sure the permission mask on the /etc/httpd/conf/ssl.* directories and their contents is 700 (rwx------).
Make sure you aren’t blocking port 443 on your Web server. All https requests come in on port 443. If you are blocking it, you will not be able to get secure pages.
The certificate only lasts for one year. When that year is up, you have to renew your certificate with your certificate authority. Each certificate authority has a different procedure for doing this; check the authority’s Web site for more details.
Make sure you have the mod_ssl package installed. If it is not installed, you will not be able to serve any SSL enabled traffic.

Exporting encryption technology

Before describing how to use the various encryption tools, I need to warn you about an unusual policy of the United States government. For many years, the United States government treated encryption technology like munitions. As a result, anyone wanting to export encryption technology had to get an export license from the Commerce Department. This applied not only to encryption software developed within the United States, but also to software obtained from other countries and then re-exported to another country (or even to the same country you got it from). Thus, if you installed encryption technology on your Linux system and then transported it out of the country, you were violating federal law! Furthermore, if you e-mailed encryption software to a friend in another country or let him or her download it from your server, you violated the law.

In January 2000, U.S. export laws relating to encryption software were relaxed considerably. However, often the U.S. Commerce Department’s Bureau of Export Administration requires a review of encryption products before they can be exported. U.S. companies are also still not allowed to export encryption technology to countries classified as supporting terrorism.

Using the Secure Shell package

The Secure Shell package (SSH) is a package that provides shell services similar to the rsh, rcp, and rlogin commands, but encrypts the network traffic. It uses private-key cryptography, so it is ideal for use with Internet-connected computers. The Fedora distribution contains the following client and server software packages for SSH: openssh, openssh-clients, and openssh-server packages.

Starting the SSH service

If you have installed the openssh-server software package, the SSH server is automatically configured to start. The SSH daemon is started from the /etc/init.d/sshd start-up script. To make sure the service is set up to start automatically, type the following (as root user):

 # chkconfig --list sshd  sshd    0:off    1:off   2:on   3:on   4:on   5:on   6:off

This shows that the sshd service is set to run in system states 2, 3, 4, and 5 (normal bootup states) and set to be off in all other states. You can turn on the SSH service, if it is off, for your default run state, by typing the following as root user:

 # chkconfig sshd on

This line turns on the SSH service when you enter run levels 2, 3, 4, or 5. To start the service immediately, type the following:

 # /etc/init.d/sshd start

Using the ssh, sftp, and scp commands

Three commands you can use with the SSH service are ssh, sftp, and scp. Remote users use the ssh command to login to your system securely. The scp command lets remote users copy files to and from a system. The sftp command provides a safe way to access FTP sites.

Like the normal remote shell services, secure shell looks in the /etc/hosts.equiv file and in a user’s .rhost file to determine whether it should allow a connection. It also looks in the ssh-specific files /etc/shosts.equiv and .shosts. Using the shosts.equiv and the .shosts files is preferable because it avoids granting access to the nonencrypted remote shell services. The /etc/shosts.equiv and .shosts files are functionally equivalent to the traditional hosts.equiv and .rhosts files, so the same instructions and rules apply.

Now you are ready to test the SSH service. From another computer on which SSH has been installed (or even from the same computer if another is not available), type the ssh command followed by a space and the name of the system you are connecting to. For example, to connect to the system ratbert.glaci.com, type:

 # ssh ratbert.glaci.com

If this is the first time ever you have logged in to that system using the ssh command, it will ask you to confirm that you really want to connect. Type yes and press Enter when it asks this:

The authenticity of host 'ratbert.glaci.com (199.170.177.18)' can't be  established.  RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.  Are you sure you want to continue connecting (yes/no)?

It should then prompt you for a user name and password in the normal way. The connection will then function like a normal telnet connection. The only difference is that the information is encrypted as it travels over the network. You should now also be able to use the ssh command to run remote commands from a shell on the remote system.

The scp command is similar to the rcp command for copying files to and from Linux systems. Here is an example of using the scp command to copy a file called memo from the home directory of the user named jake to the /tmp directory on a computer called maple:

 $ scp /home/jake/memo maple:/tmp jake@maple's password: ******** memo       100%|****************| 153 0:00

Enter the password for your user name (if a password is requested). If the password is accepted, the remote system indicates that the file has been copied successfully.

Similarly, the sftp command starts an interactive FTP session with an FTP server that supports SSH connections. Many security-conscious people prefer sftp to other ftp clients because it provides a secure connection between you and the remote host. Here’s an example:

 $ sftp ftp.handsonhistory.com  Connecting to ftp.handsonhistory.com  jake@ftp.handsonhistory.com's password: ******** sftp>

At this point you can begin an interactive FTP session. You can use get and put commands on files as you would using any FTP client, but with the comfort of knowing that you are working on a secure connection.

Tip

The sftp command, as with ssh and scp, requires that the SSH service be running on the server. If you can’t connect to a FTP server using sftp, the SSH service may not be available.

Using ssh, scp and sftp without passwords

For machines that you use a great deal, it is often helpful to set them up so that you do not have to use a password to log in. The following procedure shows you how to do that.

These steps will take you through setting up password-less authentication from one machine to another. In this example, the local user is named chuckw on a computer named host1. The remote user is also chuckw on a computer named host2.

Log in to the local computer (in this example, I log in as chuckw to host1).

Note
Only run step 2 once as local user on your local workstation. Do not run it again unless you lose your ssh keys. When configuring subsequent remote servers, skip right to step 3.
Type the following to generate the ssh key:
```
 $ ssh-keygen -t dsa 
```
Accept the defaults by pressing Enter at each request.
Type the following to copy the key to the remote server (replace chuckw with the remote user name and host2 with the remote host name):
```
 $ cd ~/.ssh $ scp id_dsa.pub chuckw@host2:/tmp chuckw@host2's password: ******* 
```
Type the following to add the ssh key to the remote-user’s authorization keys (the code should be on one line, not wrapped):
```
$ ssh chuck2@host2 'cat /tmp/id_dsa.pub >> /home/chuckw/.ssh/  authorized_keys2'
```
Note
The previous two steps will ask for passwords. This is okay.
Type the following to remove the key from the temporary directory:
```
 $ ssh chuckw@host2 rm /tmp/id_dsa.pub  
```

Note

The previous step should not ask for a password.

It is important to note that once you have this working, it will work regardless of how many times the IP address changes on your local computer. IP address has nothing to do with this form of authentication.