Chapter 13. PKI and Encryption Protocols

This short chapter wraps up the rest of the encryption concepts you need to know for the Security+ exam. You need to understand public key infrastructures and have the ability to explain what is entailed when a secure connection is made, for example to a secure e-commerce web server. There is an entire system involved with public key infrastructures, from the users to servers, encryption methods, and much more. It’s a big topic that can be confusing due to how many and what variety of keys are used. Take it slow, and reread the section if necessary. Several protocols use public key infrastructures as well, many of which you have probably heard of, such as S/MIME, SSL, SSH, and so on. Keep in mind that the security protocols discussed in this section are intertwined with the concepts of a public key infrastructure.

Foundation Topics: Public Key Infrastructure

A public key infrastructure (PKI) is an entire system of hardware and software, policies and procedures, and people. It is used to create, distribute, manage, store, and revoke digital certificates. If you have connected to a secure website in the past, you have been a part of a PKI! But a PKI can be used for other things as well, such as secure e-mail transmissions and secure connections to remote computers and remote networks. The PKI is all encompassing: It includes users, client computers, servers, services, and most of all, encryption. Don’t confuse PKI with public key encryption. Though they are related, PKI is a way of accomplishing public key encryption, but not all public key encryption schemes are PKI. PKI creates asymmetric key pairs, a public key and a private key: The private key is kept secret whereas the public key can be distributed. If the key pair is generated at a server, it is considered to be centralized, and the public key is distributed as needed. If the key pair is generated at a local computer, it is considered to be decentralized, and the keys are not distributed, instead they are used by that local system. An example of public key usage would be a certificate obtained by a web browser during an encrypted session with an e-commerce website. An example of private key usage would be when a user needs to encrypt the digital signature of a private e-mail. The difference is the level of confidentiality. The public key certificate obtained by the web browser is public and might be obtained by thousands of individuals. The private key used to encrypt the e-mail is not to be shared with anyone.

In a nutshell, public key infrastructures are set up in such a way so as to bind public keys with user identities. This is usually done through the use of certificates that are distributed by a certificate authority. Less commonly it is done by means of a web of trust.

Let’s go ahead and describe these concepts in a little more detail.

Certificates

Certificates are digitally signed electronic documents that bind a public key with a user identity. The identity information might include a person’s name and organization, or other details relevant to the user the certificate is to be issued to. Most certificates are based off of the X.509 standard, which is a common PKI standard developed by the ITU-T that often incorporates the single sign-on authentication method. This way, a recipient of a single X.509 certificate will have access to multiple resources, possibly in multiple locations. Although difficult, X.509 certificates that use MD5 and SHA-1 hashes can be compromised. For organizations worried about extremely resourceful hackers, a more powerful hashing algorithm such as SHA-2 should be implemented with the certificate. X.509 is the core of the PKIX, which is the IETF’s Public Key Infrastructure (X.509) working group. Components of an X.509 certificate include the following:

• Owners (users) information including their public key

• Certificate authority information including their name, digital signature, serial number, issue and expiration date, and version.

Certificate Authorities

A certificate authority (CA) is the entity (usually a server) that issues certificates to users. In a PKI system that uses a CA, the CA is known as a trusted third party. Most PKI systems use a CA. The CA is also responsible for verifying the identity of the recipient of the certificate. An example of a technology that uses certificates would be secure websites. If you opened your browser and connected to a secure site, the browser would first check the certificate that comes from Verisign or another similar company, it would validate the certificate. You (the user) and the website are the two parties attempting to communicate. The CA is a third party that negotiates the security of the connection between you and the website. For a user to obtain a certificate from a CA, the user must present two items of information: The first is proof of the user’s identity; the second is a public key. This public key is then matched to the CA’s private key and if successful, the certificate is granted to the user.

A basic example of this would be if you connect to www.paypal.com. When connecting to this website it automatically redirects you to https://www.paypal.com, which is secured by way of a Verisign-issued certificate. You know you have been redirected to a secure site because the browser will have various indicators. For instance, Internet Explorer 7 shows a padlock in the locked position and the address field will has a green background. Similarly, Firefox shows a green background behind the website owner name. These examples are shown in Figures 13-1 and 13-2. The certificate information is shown in the address field, so only the top areas of the browser windows are shown.

Figure 13-1. Example of a Secure Connection, Shown in Internet Explorer

Figure 13-2. Example of a Secure Connection, Shown in Firefox

These are examples of SSL certificates. If you were to click on the green area of the address field in Firefox, it would display a drop-down information window that shows the name of the website and the issuer of the certificate. From there, you could click the More Information button, which tells you additional privacy and historical information, plus technical details. Finally, if you were to click the View Certificate button, the default General tab and the Details tab would show more details of the certificate, as shown in Figure 13-3.

Figure 13-3. Details of a Typical Verisign Certificate

You can see that the certificate gets a super-long hexadecimal serial number and shows when the certificate was originally issued and when it expires, among other information. You can also note that the certificate has been fingerprinted with a SHA1 and a MD5 hash, enabling you or the website (or issuer) to verify the integrity of the certificate. If for some reason the certificate cannot be verified by any of the parties, and the issuer confirms this, then the issuer would need to revoke it and place it in the certificate revocation list (CRL).

Recipients can use one or more certificates. Certificate mapping defines how many certificates are associated with a particular recipient. If an individual certificate is mapped to a recipient, it is known as a one-to-one mapping. If multiple certificates are mapped to a recipient, it is known as many-to-one mapping. Multiple certificates might be used if the recipient requires multiple secure (and separate) communications channels.

In some cases, a registration authority (RA) is used to verify requests for certificates. If the request is deemed valid, the RA informs the CA to issue the certificate. An RA might also be used if the organization deals with several CAs. In this case, the RA is at the top of a hierarchical structure and verifies the identity of the user. An RA isn’t necessary in a PKI, but if you are centrally storing certificates, a CA is necessary.

Certificate authorities aren’t just for the rich and famous (for example, Paypal using Verisign as the issuer). You can have a CA, too! Lab 13-2 in the “Hands-On Labs” section shows how to do this on a Windows Server 2003 when implementing an L2TP VPN; more on L2TP later in this chapter. Of course, a server’s built-in certificates are not necessarily secure. If you were to implement this technology in a secure environment in your organization, you would probably want to obtain proper certificates from a trusted source to use with the Windows server.

Certificate authorities can be subverted through the use of social engineering. If a person were to pose as a legitimate company and managed to obtain certificates from a trusted source, those certificates would appear to be valid certificates and could cause widespread damage due to connections made by unsuspecting users. That is, until the certificates are revoked. This happens sometimes, but the CA issuer will usually find out quickly and take steps to mitigate the problem, including revoking the certificate(s) and notifying any involved parties of the incident.

The certificate revocation list (CRL) is a list of certificates no longer valid or have been revoked by the issuer. There are two possible states of revocation: revoked, which is when a certificate has been irreversibly revoked and cannot be used again, and hold, which is used to temporarily invalidate a certificate. Reasons for revoking a certificate include the compromising or theft of a certificate or entire CA, unspecified certificates, superseded certificates, held certificates, and key or encryption compromise. The CRL is published periodically, usually every 24 hours. This enables users of an issuer’s certificates to find out if a certificate is valid or not. CRLs, like the certificates themselves, carry digital signatures to prevent DoS and spoofing attacks; the CRL is digitally signed by the CA.

Certificate keys can also be held in escrow. Key escrow is when certificate keys are held in the case that third parties such as government or other organizations need access to encrypted communications.

When installing a certificate authority to a Windows Server, you can set up a recovery agent for lost or corrupted keys. To do this, you would need Windows Server 2003 Enterprise and need to set up an Enterprise level CA. In this configuration, the certificates (or private keys) are archived at the CA. If a Key Recovery Agent has been configured, lost, or corrupted, keys can be restored. It’s important to use some type of software that can archive and restore keys in the case of an incident or disaster.

Another way to avoid single points of failure, such as a single CA, is to organize certificate authorities in a hierarchical manner. At the top of the tree is a root CA; underneath are subordinate CAs that offer redundancy. Though certificate authority exclusivity is common, it is not the only type of architecture used to bind public keys to users. In some cases, a centralized model for certificates is not required or desired.

Single-Sided and Dual-Sided Certificates

Most communication sessions, such as secure web sessions, use single-sided certificates. This is when the server validates itself to recipients of the certificate, for example users who are accessing the website. In these types of scenarios, users does not need to validate their own identity. This would be resource-intensive, especially for a secure web server that might have thousands of concurrent connections.

Sometimes, an organization might choose to have the server and the user validate their identities. This would be using a dual-sided certificate; it works well when a limited amount of computers and sessions are involved. When more computers are added to the mix, the amount of resources necessary might be a strain on the issuing CA.

Web of Trust

A web of trust is a decentralized trust model that addresses issues associated with the public authentication of public keys common to CA-based PKIs. It is considered peer-to-peer in that there is no root CA; instead, self-signed certificates are used that have been attested to by third parties. Users can decide what certificates they want to trust and can share those trusted certificates with others, making the web of trust grow larger. This model can also interoperate with standard CA architectures inherent to PKI. The more people that show trust of a certificate, the higher the chance that it is legitimate. This model is used by PGP, which enables users to start their own web of trust, self-publishing their own public key information.

Security Protocols

You can use a variety of security protocols to allow for more secure connections to other systems and networks. But the question is: What should be secured when connecting to other computers? I like to break it down into four categories:

• E-mail and other communications—This can be accomplished with the use of S/MIME or PGP.

• E-commerce and web logins—This can be brought about with the aid of protocols such as SSL and TLS.

• Direct connections to other computers—This can be done with a protocol such as SSH.

• Virtual connections to remote networks—This can be achieved with virtual private networks and protocols such as PPTP and L2TP.

Each of these scenarios builds on the concepts we leaned in the previous PKI section. Let’s define each of these scenarios and the security protocols used in more depth.

S/MIME

Originally developed by RSA Security, Secure/Multipurpose Internet Mail Extensions (S/MIME) is an IETF standard that provides cryptographic security for electronic messaging such as e-mail. It is used for authentication, message integrity, and nonrepudiation of origin. Most e-mail clients have S/MIME functionality built-in.

S/MIME relies on PKI and the obtaining and validating of certificates from a CA, namely X.509v3 certificates. Is also relies on digital signatures when attempting to establish nonrepudiation. S/MIME enables users to send both encrypted and digitally signed e-mail messages.

S/MIME can be implemented in Outlook by first obtaining a certificate known as a Digital ID, publishing the certificate within Outlook, and then modifying the settings for Outlook, as shown in Figure 13-4.

Figure 13-4. S/MIME Settings in Outlook

One of the issues with S/MIME is that it will encrypt not only messages but also any malware that found its way into the message. This could compromise systems between the sender and receiver. To defeat this, scan messages at a network gateway that has a copy of the private keys used with SMIME. Do this after decryption. If an e-mail program stores an S/MIME encrypted message and the private key used for encryption/decryption is lost, deleted, or corrupted, the message cannot be decrypted.

SSL/TLS

Secure Sockets Layer (SSL) and its successor Transport Layer Security (TLS) are cryptographic protocols that provide secure Internet communications such as web browsing, instant messaging, e-mail, and VoIP. These protocols rely on a PKI for the obtaining and validating of certificates.

Many people refer to the secure connections they make to websites as SSL, but in actuality some of these will be TLS. The last version of SSL, version 3, was released in 1996. TLS is a more secure solution; version 1 of TLS supersedes SSLv3. As of August 2008, the latest version of TLS is 1.2. However, they work in much the same manner. Two types of keys are required when any two computers attempt to communicate with the SSL or TLS protocols: A public key and a session key. Asymmetric encryption is used to encrypt and share session keys, and symmetric encryption is used to encrypt the session data. A recovery key will be necessary if any data is lost in an SSL/TLS session. SSL and TLS encrypt segments of network connections that start at the Transport Layer of the OSI model. The actual encryption occurs at the Session Layer. In general, SSL/TLS is known as an Application Layer protocol.

HTTPS, which stands for Hypertext Transfer Protocol Secure, is a combination of HTTP and either SSL or TLS. Web servers that enable HTTPS inbound connections must have inbound port 443 open. This is common for e-commerce. If you connect to an online shopping portal such as Amazon, your credit card transactions should be protected by HTTPS, and you should see the protocol within the address bar of your browser when you enter a secure area of the website.

HTTPS should not be confused with Secure HTTP (SHTTP). SHTTP is an alternative to HTTPS that works in much the same way. Because SHTTP was neglected by Microsoft, Netscape, and others in the 1990s, and because SHTTP encrypts only Application-Layer messages, HTTPS became the widely used standard. HTTPS can encrypt all data passed between the client and the server including data passing through Layer 3.

SSH

Secure Shell (SSH) is a protocol that can create a secure channel between two computers or network devices, enabling one computer or device to remotely control the other. Designed as a replacement for Telnet, it is commonly used on Linux and Unix systems, and nowadays also has widespread on Windows clients. It depends on public key cryptography to authenticate remote computers. One computer (the one to be controlled) will run the SSH daemon, while the other computer will run the SSH client and make secure connections to the first computer (which is known as a server), as long as a certificate can be obtained and validated.

Computers that run the SSH daemon have inbound port 22 open. If a proper SSH connection is made, files can also be transferred securely using SFTP (Secure File Transfer Protocol) or SCP (Secure Copy Protocol). Tunneling is also supported.

Vulnerabilities to SSH 1 and 1.5 such as the unauthorized insertion of content, the forwarding of client authentications to other servers (daemons), and integer overflow, precipitated the development of SSH 2.0, which is incompatible with SSH version 1. Improvements to SSH 2.0 include usage of the Diffie-Hellman key exchange and integrity checking with message authentication codes (MAC).

PPTP, L2TP, and IPsec

Virtual private networks (VPN) were developed to enable quick, secure, remote connections using the inherent capacity of the Internet. They were also developed to take advantage of faster Internet connections such as cable, DSL, and so on but still work with dial-up connections. The issue with VPNs is how to secure those connections. Basically, there are two common protocols used to do so: PPTP and L2TP (with the aid of IPsec).

PPTP

The Point-to-Point Tunneling Protocol (PPTP) is a protocol used in VPNs. It encapsulates PPP packets, ultimately sending encrypted traffic. PPP by itself is useful for dial-up connections but is not suitable for a VPN by itself without a protocol such as PPTP. Servers and other devices running the PPTP protocol and accepting incoming VPN connections need to have inbound port 1723 open.

Because the authentication protocol MSCHAPv1 is considered inherently insecure, and MSCHAP-v2 is vulnerable to dictionary attacks, PPTP is deemed to be vulnerable. These authentication vulnerabilities can be dismissed if PPTP is used with an authentication method such as EAP-TLS. This relies on the existence of a PKI for the client and server computers. If this infrastructure is not readily available, PEAP can be used instead, as long as the computers are running the Windows Vista operating system or newer. Otherwise, L2TP with IPsec or other tunneling protocols are recommended for environments in which session and data security are of paramount importance.

L2TP

The Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol used to connect VPNs. In essence, it creates an unencrypted tunnel if used by itself (which would be unwise). It does not include confidentiality or encryption on its own, but when paired with a security protocol such as IPsec is considered a formidable tunneling protocol.

Its starting point is based off of the Layer 2 Forwarding Protocol (L2F) and PPTP. The latest version is L2TPv3, which has improved encapsulation and increased security features. Servers and other devices accepting incoming VPN connections need to have inbound port 1701 open.

When installed on a Windows Server, it uses a PKI. Valid certificates need to be downloaded to clients before they can make a VPN connection to the server. Security must be configured on the server and the client side. Generally, the IPsec protocol is used to accomplish the secure connection within the L2TP tunnel.

IPsec

Internet Protocol Security (IPsec) authenticates and encrypts IP packets, effectively securing communications between the computers and devices that use this protocol. IPsec operates at the Network Layer of the OSI model. It differs from SSH, SSL, and TLS in that it is the only protocol that does not operate within the upper layers of the OSI model. It can negotiate cryptographic keys and establish mutual authentication. IPsec is made up of three other protocols that perform its functions, including:

• Security association (SA)—This is the establishment of secure connections and shared security information, using either certificates or cryptographic keys. It is set up most often through the Internet Key Exchange (IKE) or via Kerberized Internet Negotiation of Keys. The IKE can select varying levels of security protocols for the computers in a connection, which can differ in a VPN due to the dissimilar computers (with disparate protocols) that might attempt to connect to it.

• Authentication header (AH)—This offers integrity and authentication. The authentication information is a keyed hash based on all of the bytes in the packet. It can be used with the Encapsulating Security Payload (ESP) protocol. It can protect against replay attacks by employing sliding window protocols, which put limits on the total amount of packets that can be transceived in a given timeframe but ultimately enables an unlimited number of packets to be communicated using fixed-size sequence numbers.

• Encapsulating Security Payload (ESP)—This provides integrity, confidentiality, and authenticity of packets. Protected data is encapsulated and encrypted.

IPsec uses algorithms such as SHA1 for integrity and authenticity, which hashes the packets of data; afterward the hash is encrypted. It also uses Triple DES and AES for confidentiality.

Exam Preparation Tasks: Review Key Topics

Review the most important topics in the chapter, noted with the Key Topics icon in the outer margin of the page. Table 13-1 lists a reference of these key topics and the page numbers on which each is found.

Table 13-1. Key Topics for Chapter 13

Define Key Terms

Define the following key terms from this chapter, and check your answers in the glossary:

Public Key Infrastructure,

certificates,

certificate authority,

one-to-one mapping,

many-to-one mapping,

certificate revocation list (CRL),

X.509,

key escrow,

web of trust,

S/MIME,

Secure Sockets Layer (SSL),

Transport Layer Security (TLS),

Secure Shell (SSH),

Point-to-Point Tunneling Protocol (PPTP),

Layer 2 Tunneling Protocol (L2TP),

Internet Protocol Security (IPsec)

Hands-On Labs

Complete the following written step-by-step scenarios. After you finish (or if you do not have adequate equipment to complete the scenario), watch the corresponding video solutions on the DVD.

If you have additional questions, feel free to post them at my website: www.davidlprowse.com in the Ask Dave forum. (Free registration is required to post on the website.)

Equipment Needed

• Computer with Internet access and the Firefox web browser

• Windows Server 2003

• SuSE9 Linux installed on a computer or within a VM

• Windows client computer (preferably Windows XP) with Nmap installed and Putty downloaded (and extracted if necessary). Putty can be downloaded from: www.chiark.greenend.org.uk/~sgtatham/putty/download.html.

Lab 13-1: A Basic Example of PKI

In this lab, you view a public key infrastructure (PKI) certificate after connecting to a secure website. The steps are as follows:

Step 1. Access a Windows client computer.

Step 2. Open Firefox,

Step 3. Type the following URL into the address field: www.paypal.com.

Note the address automatically changes to https://www.paypal.com, with “https” indicating a secure connection with either the SSL or TLS encryption protocol. This allows for the secure, encrypted transmission of the e-mail address and password when logging in to the PayPal website.

A. Hover the mouse pointer over the green area of the address bar to find out the issuer of the certificate; in this case it is Verisign, Inc.

Step 4. Click where the domain name is listed in the address field. (This has the green background.)

Step 5. Click the More Information button. Examine the results.

Step 6. Click the View Certificate button. Examine the results. This is where the details of the certificate can be found including whom the issuer (CA) of the certificate is, its expiration date, and any hashing that was performed on the certificate to ensure integrity.

Step 7. Click the Details tab. Examine the results. Attempt to export the details of the certificate.

Watch the solution video in the “Hands-On Scenarios” section of the DVD.

Lab 13-2: Configuring an L2TP-Based VPN with Windows Server 2003

In this lab, you configure an L2TP-based VPN with a Windows Server 2003 and Windows client. This is an in-depth lab that will take some time to complete. Also, it’s easy to make a mistake or forget a small detail. In some cases, the entire lab will need to be restarted to work properly.

The steps are as follows:

Step 1. Install a Certificate Authority on the server.

Even if your client is already set up to make L2TP connections (see step 4 for more), and you have a basic VPN server working, you would get a 781 error when attempting to connect. This is because your client requires an encryption certificate. The client must get that certificate from the server (or some other authority). Let’s install and configure the Certificate Authority on the Windows Server 2003 computer now so that it can dispense certificates to clients:

A. Go to the Windows Server 2003 computer.

B. Click the Start button and select Control Panel.

C. Launch Add/Remove Programs.

D. Select Add/Remove Windows Components.

E. Click the Certificate Services check box to select it. A pop-up window opens; click Yes.

F. Click Next.

G. When asked what type of Certificate Authority you will be installing, choose the default option, Enterprise root CA. Then click Next.

H. In the Common Name for This CA field, type test. Leave the rest of the information as is, and click Next.

I. Leave the Certificate Database Settings window as is and click Next.

J. A pop-up window might ask you about IIS, which needs to be stopped during the installation of the CA. Click OK. The installation of the CA will begin.

K. If you are asked for the CD, you can get the necessary information from X:i386 (where X is the letter of your disc drive). This could be from the Windows Server 2003 disc, the Service Pack disc, or the Server 2003 disc with slipstreamed service pack, it depends on your setup.

L. Click Finish. The Certificate Authority is now installed. You should see it within your Administrative Tools. A restart is not normally necessary, but might be a good idea, especially if you have a lot of other services running on the server.

Step 2. Configure the Certificate Authority (CA) on the server.

Now you need to set up the CA to hand out certificates automatically and turn on the IP Security policy:

A. First, though, set up an MMC if you have not already and add the Certificate Authority snap-in (for the local computer) and the Default Domain Policy. (Select the Group Policy Object editor snap-in, Browse, and then Default Domain Policy.)

B. Set up the server to hand out certificates automatically:

i. In the MMC, click the Default Domain Policy entry, select Computer Configuration, choose Windows Settings, click Security Settings, select Public Key Policies, and choose Automatic Certificate Request Settings.

ii. Right-click the Automatic Certificate Request Settings entry, select New, and then select Automatic Certificate Request.

iii. A wizard is launched. Click Next.

iv. When asked what type of auto certificate template you want to install, select Computer. Then click Next.

v. Click Finish. You should see a certificate template called Computer on the right side window pane in the MMC.

vi. Save the MMC.

C. Turn on the IP Security Policy.

i. Within the MMC expand the following options in the left window pane: Default Domain Policy > Computer Configuration > Windows Settings > Security Settings. Click once on IP Security Policies on Active Directory.

ii. This should bring up three policies on the right side. None of these are yet assigned.

iii. Right-click the Secure Server (require Security) option and select Assign. This should assign the security policy allowing clients to connect.

iv. Save the MMC and close it.

Step 3. Configure MS-CHAP on the client.

Let’s configure your client to connect to the VPN server using a more complex level of authentication—username and password verification. This will be MS-CHAP II:

A. Go to the Windows XP computer.

B. Right-click My Network Places and select Properties to find your VPN adapter. If it is not there, create a new one, and point it toward your existing VPN server.

C. Right-click the VPN adapter and select Properties.

D. Click the Security tab and select Advanced (Custom Settings).

E. Click the Settings button. This opens the Advanced Security Settings dialog box.

F. Make sure that Require encryption is selected in the Data encryption drop-down list and that the Microsoft CHAP (MS-CHAP) and Microsoft CHAP Version 2 (MS-CHAP v2) checkboxes are selected. MS-CHAPII is already accepted by the server. MS-CHAPII will now be your challenge authentication scheme; it will work automatically.

Step 4. Configure L2TP and IPsec on the client:

Connect through L2TP as opposed to PPTP. L2TP is a more secure way of connecting than PPTP when L2TP is used with IPsec:

A. Click OK to close the Advanced Security Settings dialog box.

B. In the VPN Properties window, click the Networking tab.

C. Open the Type of VPN: Drop-Down List and choose L2TP IPsec VPN.

D. Click OK to close the VPN Properties window.

Step 5. Install a certificate on the client.

In some cases, you have to connect through a custom-made MMC, but in this scenario you retain your certificate within the browser:

A. Go to the Windows XP computer.

B. Open Internet Explorer and, in the address bar, type http://servername/certsrv (where servername is the actual hostname of your server). A web page with information opens.

C. Click the Request a Certificate link.

D. On the next screen, click User Certificate.

E. On the User Certificate – Identifying Information screen click Submit.

F. Click Yes in the pop-up window(s) that appears.

G. The browser should talk to the server and retrieve a certificate. Choose to install it now by clicking the Install this Certificate link.

H. Click Yes in the pop-up window that appears to add the certificate to the store. You’ll be informed that the certificate has been installed.

Step 6. Make the new VPN connection.

Now you can connect from your client to the server through the VPN connection using L2TP and MS-CHAP II. Connect to the VPN the way you normally would by double-clicking the VPN adapter and logging in with your username and password. There you have it!

Watch the solution video in the “Hands-On Scenarios” section of the DVD.

Lab 13-3: Making an SSH Connection

In this lab, you install SSH and allows the SSH daemon on a SuSE 9 Linux computer to be later remotely accessed and controlled by a Windows XP computer or other Windows client. The steps are as follows:

Step 1. Access the SuSE9 Linux computer and open the Shell – Konsole.

Step 2. Because this version of Linux already has SSH installed by default, verify that it is running by typing the following command:

/etc/init.d/sshd start

That should start the SSH daemon, if it weren’t started already.

Step 3. Access the Windows client computer, open the Command Prompt, and navigate to the Nmap folder.

Step 4. Type the following command: nmap –sS [IPAddress] where IPAddress is the IP address of the Linux computer. Actually, any port scanner will do; in the video we use Nmap as the example.

This should discern the services that are running on the Linux computer. Port 22 should be open at this point indicating that SSH is running.

Step 5. Return to the Linux computer.

Step 6. Download and run OpenSSH. Even though I just demonstrated how to start SSH in Linux, I’d like to show how to download OpenSSH in the case that you don’t have SSH built in to your version of Linux. It is a common type of SSH that technicians should know how to use:

A. Open the web browser.

B. Access the following link: ftp://ftp5/usa.openbsd.org/pub/OpenBSD/OpenSSH/portable/.

If the link doesn’t work, try running a search with the query OpenSSH download.

C. Double-click the openssh-5.1p1.tar.gz file and select Save As.

D. Save it where you want. The root is fine.

E. Decompress and extract the contents of the file:

i. In the command-line, type Dir and locate the file.

ii. Now type tar xvzf openssh-5.1p1.tar.gz to extract and decompress the contents.

iii. Run a Dir again to see the new folder that was extracted.

F. Run OpenSSH:

i. Change to the new folder by typing cd openssh-5.1p1.

ii. Type sshd to start up the OpenSSH program.

Step 7. Access the Windows client computer.

Step 8. Download Putty if you haven’t done so already.

Step 9. Locate the putty.exe download within Windows Explorer, and double-click it to run it. This should bring up the PuTTY Configuration window.

Step 10. Type the IP address of the Linux computer, and click the Open button to connect and have a lot of fun!

Step 11. At the PuTTY command-line window displayed, log in as the root account of the Linux computer. If you have a password, be sure to type it correctly.

Step 12. Run various commands to examine the remote Linux computer such as ifconfig, cd, dir, and so on.

Step 13. Access the Windows Command Prompt and run the netstat –an command. View the connection to the remote Linux computer. You should see a session with port 22 used on the remote computer.

Watch the solution video in the “Hands-On Scenarios” section of the DVD.

View Recommended Resources

• Microsoft TechNet: Configuring the Key Recovery Agent Certificate: http://technet.microsoft.com/en-us/library/cc780525%28WS.10%29.aspx

Answer Review Questions

Answer the following review questions. You can find the answers at the end of this chapter.

1. Which of the following does not apply to an x.509 certificate?

A. Certificate version

B. The Issuer of the certificate

C. Public key information

D. Owner’s symmetric key

2. What two items are included in a digital certificate? (Select the two best answers.)

A. User’s private key

B. Certificate Authority’s digital signature

C. The user’s public key

D. Certificate Authority’s IP address

3. Rick has a local computer that uses software to generate and store key pairs. What type of PKI implementation is this?

A. Distributed key

B. Centralized

C. Hub and spoke

D. Decentralized

4. Which of the following is usually used with L2TP?

A. IPsec

B. SSH

C. PHP

D. SHA

5. What ensures that a CRL is authentic and has not been modified?

A. The CRL can be accessed by anyone.

B. The CRL is digitally signed by the CA.

C. The CRL is always authentic.

D. The CRL is encrypted by the CA.

6. Which of the following encryption concepts is PKI based on?

A. Asymmetric

B. Symmetric

C. Elliptical curve

D. Quantum

7. You are in charge of PKI certificates. What should you implement so that stolen certificates cannot be used?

A. CRL

B. CAD

C. CA

D. CRT

8. Which of the following are certificate-based authentication mapping schemes? (Select the two best answers.)

A. One to-many mapping

B. One-to-one mapping

C. Many-to-many mapping

D. Many-to-one mapping

9. Which of the following network protocols sends data between two computers while using a secure channel?

A. SSH

B. SMTP

C. SNMP

D. P2P

10. Which of the following protocols uses port 443?

A. SFTP

B. HTTPS

C. SSHTP

D. SSLP

11. Which of the following protocols creates an unencrypted tunnel?

A. L2TP

B. PPTP

C. IPsec

D. VPN

12. In a public key infrastructure setup, which of the following should be used to encrypt the signature of an e-mail?

A. Private key

B. Public key

C. Shared key

D. Hash

13. Two computers are attempting to communicate with the SSL protocol. Which two types of keys will be used? (Select the two best answers.)

A. Recovery key

B. Session key

C. Public key

D. Key card

14. Which layer of the OSI model does IPsec operate at?

A. Data Link

B. Network

C. Transport

D. Application

15. Which layer of the OSI model is where SSL provides encryption?

A. Network

B. Transport

C. Session

D. Application

16. Which of the following details one of the primary benefits of using S/MIME?

A. S/MIME expedites the delivery of e-mail messages.

B. S/MIME enables users to send e-mail messages with a return receipt.

C. S/MIME enables users to send both encrypted and digitally signed e-mail messages.

D. S/MIME enables users to send anonymous e-mail messages.

17. What should you do to make sure that a compromised PKI key cannot be used again?

A. Renew the key.

B. Reconfigure the key.

C. Revoke the key.

D. Create a new key.

18. Which of the following statements is correct about IPsec authentication headers?

A. The authentication information is a keyed hash based on half of the bytes in the packet.

B. The authentication information is a keyed hash based on all the bytes in the packet.

C. The authentication information hash will remain the same even if the bytes change on transfer.

D. The authentication header cannot be used in combination with the IP Encapsulating Security Payload.

19. Which of the following protocols is not used to create a VPN tunnel and not used to encrypt VPN tunnels?

A. PPTP

B. L2TP

C. PPP

D. IPsec

20. Which of the following answers are not part of IPsec? (Select the two best answers.)

A. TKIP

B. Key exchange

C. AES

D. Authentication header

Answers and Explanations

1. D. In x.509, the owner does not use a symmetric key. All the other answers apply to x.509.

2. B and C. A digital certificate will include the Certificate Authority’s (CA) digital signature and the user’s public key. A user’s private key should be kept private and should not be within the digital certificate. The IP address of the CA should have been known to the user’s computer before obtaining the certificate.

3. D. When creating key pairs, PKI has two methods: centralized and decentralized. Centralized is when keys are generated at a central server and are transmitted to hosts. Decentralized is when keys are generated and stored on a local computer system for use by that system.

4. A. IPsec is usually used with L2TP. SSH is a more secure way of connecting to remote computers. PHP is a type of language commonly used on the web. SHA is a type of hashing algorithm.

5. B. Certificate revocation lists or CRLs are digitally signed by the certificate authority for security purposes. If a certificate is compromised, it will be revoked and placed on the CRL. CRLs are later generated and published periodically.

6. A. The public key infrastructure, or PKI, is based on the asymmetric encryption concept. Symmetric, elliptical curve, and quantum cryptography are all different encryption schemes that PKI is not associated with.

7. A. You should implement a certificate revocation list or CRL so that stolen certificates, or otherwise revoked or held certificates, cannot be used.

8. B and D. When dealing with certificate authentication, asymmetric systems use one-to-one mappings and many-to-one mappings.

9. A. SSH, or the secure Shell, enables two computers to send data via a secure channel. SMTP is the Simple Mail Transfer Protocol that deals with e-mail. SNMP is the Simple Network Management Protocol that enables the monitoring of remote systems. P2P is the abbreviated version of peer-to-peer network.

10. B. Port 443 is used by HTTPS, which implements TLS/SSL for security. SFTP is the Secure File Transfer Program. There are no protocols named SSHTP and SSLP.

11. A. In Virtual Private Networks (VPN), Layer Two Tunneling Protocol (L2TP) creates an unencrypted tunnel between two IP addresses. It is usually used with IPsec to encrypt the data transfer. PPTP is the Point-to-Point Tunneling Protocol that includes encryption.

12. A. A private key should be used to encrypt the signature of an e-mail in an asymmetric system such as PKI. Public keys and shared keys should never be used to encrypt this type of information. A hash is not used to encrypt in this fashion; it is used to verify the integrity of the message.

13. B and C. In an SSL session, a session key and a public key are used. A recovery key is not necessary unless data has been lost. A key card would be used as a physical device to gain access to a building or server room.

14. B. IPsec is a dual mode, end-to-end security scheme that operates at Layer 3, the Network Layer of the OSI model, also known as the Internet Layer within the Internet Protocol Suite. It is often used with L2TP for VPN tunneling among other protocols.

15. C. SSL, or the Secure Sockets Layer, and its successor Transport Layer Security (TLS) encrypt segments of network connections that start at the Transport Layer. The actual encryption is done at the Session Layer, and the protocol is known as an Application Layer protocol.

16. C. S/MIME enables users to send both encrypted and digitally signed e-mail messages enabling a higher level of e-mail security. It does not make the delivery of e-mail any faster nor does it have anything to do with return receipts. Return receipts are usually controlled by the SMTP server. Anonymous e-mail messages would be considered spam, completely insecure, and something that a security administrator wants to reduce, and certainly does not want their users to implement.

17. C. Key revocation is the proper way to approach the problem of a compromised PKI key. The revoked key will then be listed in the CRL (Certificate Revocation List).

18. B. The only statement that is true is that the authentication information is a keyed hash that is based on all the bytes in the packet. A hash will not remain the same if the bytes change on transfer; a new hash will be created for the authentication header (AH). The authentication header can be used in combination with the Encapsulating Security Payload (ESP).

19. C. PPP, or point-to-point protocol, does not provide security and is not used to create VPN connections. You will see PPP used in dial-up connections, and it is an underlying protocol used by L2TP, PPTP, and IPsec, which are all used in VPN connections.

20. A and C. IPsec contains (or uses) a key exchange (either Internet Key Exchange or Kerberized Internet Negotiation of Keys) and an authentication header (in addition to many other components). TKIP and AES are other encryption protocols.