Strategies for Securing Web-centric Intranets

Francisco M. De La Vega

Web interfaces are now used in organizations for providing access to a variety of corporate information assets and databases within open standards TCP/IP-based internal networks, also referred to as Intranets. The security and resistance of this infrastructure to a variety of external and internal attacks are of crucial importance if the corporate Intranet is to fulfill its goals. The typical security tactics offered to corporations revolve around the implementation of barriers to isolate the internal resources from the Internet, where supposedly the security threats reside. Recently, I found this definition of Intranet security: "an enabling technology that allows industry to make use of Internet computing technology without the Internet making use of them." This view leaves out several important topics relevant to corporate information environments and limits the security problem to a firewall implementation issue, oblivious to internal threats.

The goal of this article is to provide an understanding of the security risks of Web information services, as well as the possible countermeasures current technology provides, from the standpoint of corporate Intranet design. As an implementation study case, I will refer to the security features of Netscape Suitespot servers throughout this discussion.

Major Threats to Intranet Security

Before Internet technology arrived to the enterprise, IS managers used to protect their infrastructure by "security through obscurity." The widespread use of TCP/IP protocol and the openness of its standard offers many avenues that users, system administrators and crackers can misuse or abuse. Many security breaches are accidental and arise through badly managed/configured systems. Furthermore, as many as 50% of the experienced intrusions are traced to on-board employees, capable of skipping any firewall protection. Even when referring to external attacks, a recent Computer Security Institute survey showed that about 20% of those occurred after firewall deployment. Therefore, a major effort to protect valuable servers on the corporate network and to authenticate all network transactions is necessary regardless of client location.

Unauthorized access, authorized users performing unauthorized functions, and unauthorized modification or deletion, are among the most common threats Web-based information systems may experience. Impersonation may result in unauthorized access, and eavesdropping can compromise the privacy of corporate communications. Finally, denial of service attacks can reduce the availability and acceptable level of service to users of this infrastructure.

The Security Process

Securing corporate information assets available through the Intranet needs the definition of a corporate security strategy. This strategy should be able to cope with the following technical requirements:

• Confidentiality - ensuring that data is not disclosed to unauthorized persons.

• Access control - ensuring that only those who are authorized to view or modify data can access that data.

• Integrity - ensuring that data has not been altered since it was originally created.

• Data origin authentication - providing proof of the source of the data.

• Nonrepudiation - ensuring that someone cannot deny involvement in an electronic transaction.

Authentication is the process whereby the identification information sent by the client software is checked against an authentication database and, if verified, credentials are issued by the authentication server to provide access to the desired application server. Credentials convey that a trusted entity has confirmed the identity and usually have an expiration date. Once identity is established, client and server should exchange credentials for mutual authentication (i.e., both client and server are authenticated). To preserve confidentiality through the transaction and avoid eavesdropping, a shared secret is generated between client and server, and this information is used as a secret encryption key to encode all data exchanged. This mechanism also enforces nonrepudiation due to the use of digital signatures.

Finally, the authorization database ensures that for each operation requested by the client, access control rules are enforced, and the user has privileges to perform the requested operation in the specified application server.

The Key to Intranet Security

There are many security strategies capable of enabling effective authentication, authorization, and confidential electronic transactions in Web-centric Intranets. The foundations of these strategies lie on cryptographic methodology as implemented by the current industry and Internet standards. To ensure that only authorized clients can access specific corporate information assets, a company must deploy an encryption infrastructure for privacy and digital signatures for client and server authentication within the organization.

There are many cryptographic methods that can be applied to the problem at hand. However, public key cryptography has been widely adopted as a standard for implementing strong authentication methods. RSA is the most widely used public key encryption algorithm. Developed by RSA Laboratories, RSA provides methods for encrypting data using public and private keys. RSA encryption is defined in PKCS-1, which is part of a set of public key cryptography standards. It is widely accepted that this algorithm is secure enough to withstand cryptoanalysis, provided a sufficient key length is used. Key lengths for Certificates typically range between 512 and 1024 bits.

Identification proof is provided as a public key cryptography (PKC) certificate, based in the International Telecommunications Union's X.509 standard. A certificate contains secure information that can be used to verify the identity of either a client or a server involved in a secure transaction. Among other items, the certifcate contains the name of the certified entity as well as its public cryptography key. This key can be used to encrypt data for the certificate owner or to verify the owner's digital signature, which can be generated by the entity's private key. To verify the authenticity of the public key, the certificate is digitally signed by a Certification Authority (CA), a trusted third party who vouches for the identity of the certificate owner. There is much more about PKC to be explained, but this should suffice as background for the following discussion; the reader is invited to review the suggested resources listed in the Information Resources sidebar for further insight.

Once authentication is established between client and server by mutual exchange of certificates and certificate verification, another cryptography method is commonly used to establish an encrypted information flow. Since public key cryptography, though effective, is computationally costly, a symmetric, or secret-key encryption algorithm is used to further encrypt the transaction - symmetric RSA, IDEA, Blowfish, and DES algorithms can be used here. A random number is generated by both parts and exchanged during initial handshake. This shared secret is used to generate private keys to encrypt the following transmission. The length of the private encryption keys can be between 40 and 56 bits for export software (a weak key, as demonstrated by recent challenges), and up to 1024 for military strength software. Normally, a session key of 128 bits is used, and some implementations allow for key renewal after a fixed amount of time, to resist brute force attacks.

Depending on the specific network application to be secured, there are a variety of implementations of the above scheme. For example, SSH (Secure SHell) Protocol has been proposed to protect remote logins, and currently an Internet draft has been submitted to IETF for scrutiny. PGP (Pretty Good Privacy) is a freeware application widely used by Internauts to sign and encrypt email messages. However, both applications are not widely supported by the industry, and interoperation outside organization's borders is difficult.

To protect Web-based transactions, NCSA proposed the S-HTTP (Secure-HTTP) standard. On the other hand, Netscape Communications has proposed the SSL (Secure Socket Layer) as a middleware to sit between TCP/IP protocol and the application layer. In principle any application running over TCP/IP can be protected through SSL. To protect email messages, industry is supporting S/MIME (Secure/Multimedia Internet Mail Extensions) proposed by RSA Laboratories over IETF's PEM (Protection Enhanced Mail). S/MIME uses X.509 certificates like SSL, thus providing a basis for implementing a coherent enterprise public key infrastructure.

I focus on this approach for the rest of the discussion. Please refer to the Information Resources for further details on the SSL protocol.

Server Security Implementation

SSL implementation in Netscape Suitespot servers requires the following steps:

• Generating a RSA key pair

• Requesting a Certificate to an appropriate local or root CA

• Installing the CA and newly issued certificates in the server database

• Activating SSL and restarting the server providing the private key passphrase in the server console

  If client certificates will be required to authenticate connecting clients, additional steps are required:

• Activating control access and configuring rules to require SSL Certificates instead of basic user/password authentication

• Installing the client certificate signing CA in the server database (if not done before)

First, an RSA key pair must be generated. This is done from the command line in the UNIX version using the sec-key utility program located at:

$NSHOME/bin/https/admin/bin/sec-key

During key generation a passphrase of at least 8 characters must be provided to protect the private key residing on the server's hard disk. Also, a random seed must be provided. This is usually done by typing at different speeds in the local keyboard (never use the auto-repeat feature of your keyboard). The key pair is stored at $NSHOME/https- serverID/ssl/ServerKey.db, where serverID is the internal name used for the test server (Enterprise server software can support multiple, multi-homed HTTP servers on the same machine). Listing 1 shows the terminal output from sec-key.

Once the key pair is generated, a certificate request must be constructed and sent to an appropriate CA. This is done through the HTML form shown in Figure 1. Necessary data includes information to generate the server's unique X.500 directory distinguished name. For example, the distinguished name for the server depicted in Figure 1 is:

cn=www.sadr.org.mx, ou=Genetica y Biologia Molecular,o=CINVESTAV, l=Zacatenco,  \
st=Distrito Federal, c=MX.(cn=common name, ou=organizational unit, o=organization, \
l=locality, st=state, c=country)

Contact information such as email and phone should be provided as well. Normally, the CA receives certificate requests either by email (as suggested in this example) or through a Web form. The certificate request must be generated by pressing OK in the form. The resulting PEM encrypted certificate request (see Listing 2) is sent via email, or should be copied and pasted on the appropriate CA request form. As an example, you can use Nortel Entrust's demo CA (available at http://www.entrust.com) to generate server and client certificates useful to test enable SSL. Entrust's demo certificates are received a few minutes later by email; a real CA would need further identification provided via other medium (fax, mail) to verify the requester's identity, and may need to run a security check on your data. The certificate can be received by mail (not very secure) or can be retrieved using a special URL provided by the CA via email.

The certificate is installed using the Install Certificate form invoked from the Encryption menu of the Enterprise server console (see Figure 2). Essentially, the PEM-encrypted certificate is cut and pasted into the provided window, the option "own certificate" is chosen, and its information is visually checked. It is also possible to install CA root certificates necessary for verification. About a dozen accepted CAs exist, and the server database already comes with most of the necessary CA's certificates.

After server certificate installation, SSL is enabled via the Encryption main menu. The HTTP server must be shut down and restarted in order for the change to take effect. Since the passphrase must be provided at start-up to activate the server's private key, the "On" or "Start" buttons in the server Web console will not work to restart the server - the system console must be used instead:

sadr% /usr/local/nshome/https-sadr/start
Key File Password:
startup: listening to 148.247.13.5, port 443 as nobody

Upon restart the server listens for SSL requests on port 443 instead of 80, normally requiring URLs using the https:// prefix. Starting the server from the console is a hassle especially after automatic, unintentional, or remote reboots of the system. However, it is not advised to build reboot scripts containing the passphrase to start the server - an unauthorized person with access to the local filesystem can steal and use the key pair.

Client Security Configuration

Although SSL enabling in the server side is enough to provide confidentiality (i.e., encrypted communication - the familiar blue line appearing at the top of the Web page) and server authentication, it is sometimes desirable for corporate Intranet design to authenticate the user retrieving a specific piece of information. This would enforce a stricter access policy to sensitive database tables, discussion threads, catalog entries, or some directory entry fields. This strategy would avoid unauthorized access by employees or hackers/old employees accessing from the outside who in some way or another have circumvented the firewall protection (e.g., connecting to an internal modem bank, using unexpected Internet access at some departments, using firewall tunnels or captured passwords).

This can be achieved by requiring client certificates for access control processing (see Figure 3). Client-side X.509 personal certificates should be requested from a local or external CA and installed into the Web browser's local database. Just as in the server certificate database, it can contain either personal certificates, bound to specific X.500 distinguished names, and CA certificates used for verifying the validity of server certificates received upon SSL connections (see Figure 4). In this case, authentication is based on location of the client workstation (i.e., the browser located in the user's workstation). To avoid possible abuse of the user's terminal by other users (who would be impersonating authorized users), the secret key can be protected by a passphrase that can be requested either once in a browsing session, at every new SSL transaction, or after a specified amount of time.

Key generation in the Netscape browser is triggered when presented to a form containing the <key> tag. A series of windows guides the user through the steps of key generation ("wizard" style), providing a random seed, and choosing between options. After the key pair is generated, the private key is stored encrypted in the local disk, and the public key is submitted to the CA server. The CA server (it can actually be a Requesting Authority intermediate server that will send the request to the appropriate CA) will ask for some personal information to construct the distinguished name of the user. The CA server will then perform a series of security checks and send a message to the security manager of the server for certification approval. If the certificate is approved, the user receives an email message with an appropriate URL to retrieve the binary form of the certificate using the Navigator. Before entering the certificate into the local database the user can check the certificate information and then accept it (see Figure 5). For demonstration purposes, you can again use the Entrust demo CA to request demo client-side certificates.

Netscape Navigator or Communicator recognizes only some CAs out of the box. If the certificate was produced by a local CA not trusted by an Internet root CA, a warning window discouraging the user from initiating SSL to the server appears. The user can then decide to accept this certificate for this time only, for all future transactions, or to terminate the current transaction. To avoid this, the user must load the CA certificate and any possible intermediate CA's certificates in a local database until the local (Intranet) root database is reached, to allow certificate verification. Also, the application server database must contain the CA issuing the client certificate. Finally, to allow the server to use client certificates in access control, a database of users with passwords should be created. Upon first connection to an SSL-protected Suitespot server, a one time password is requested of the user (additional to the private key passphrase), and thereafter a mapping is created between a user and a specific certificate. Mappings can be edited later.

Personal X.509 certificates can also be used in S/MIME secured mail, and the new mail tools included in the latest versions of Web browsers (e.g., Netscape Communicator) can use those for message signature or encryption, allowing secure mail transaction across the Internet.

Corporate Security Management

Clearly, large scale deployment of a corporate Public Key Infrastructure (PKI) is complex and involves dedicated security management effort, especially to deploy client-side certificates, and local CAs. In large firms with regional branches, delegation of CA may be necessary.

The central question that corporate users must answer, however, is the following: "Where do cryptographic keys come from and how does a business manage those keys effectively and securely to protect its information?" Thus, the corporate PKI must address the following key management concerns: