Cover V06, I06
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Listing 1
Listing 2
Sidebar 1


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.

The security process involves three major steps: identification, authentication, and authorization. Identification requires the user to present information to the client software to obtain credentials necessary for accessing application servers. The information presented can be one of the following: something you know and ideally no one else knows (e.g., a password or passphrase); something you have and that no one else has (e.g., a smart card or a token); or a physical proof of identity (e.g., a retina scan, thumb print, or unique DNA sequence). In current information technology, the former two possibilities can be readily implemented - the latter one falls into the realm of top-secret government agencies.

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)

Obviously, client browsers are required to possess an appropriate personal certificate installed in their local database for client authentication (discussed later). Because Suitespot servers are managed by a special administration HTTP server through Web forms, configuration is quite straightforward once the goal is understood. This configuration is essentially identical regardless of the server being configured (Enterprise, Catalog, NEWS/Collabra, Directory, etc.) or the implementation platform (various flavors of UNIX and Windows NT). To experiment with this software, you may want to obtain a 90-day evaluation version of Enterprise server through the Test-Drive program from Netscape's ftp site, if not available locally. Even though the following steps and figures are based on Netscape products, the basic concepts are similar for other servers, like Microsoft IIS.

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:


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:, 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 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, 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:

  • Key generation, backup, update, and revocation (this latter is especially important to revoke old employees' credentials).

  • Establishment and maintenance of trust relationships among security domain's CAs.

  • Scalability and affordability integrating other Intranet information resources like LDAP corporate directories.

  • Application integration and user transparency.

    The public PKI standards being worked out at IETF address this concerns, currently at the Internet draft level. Some vendors like Entrust and Netscape already have products, called certificate servers, using these specifications. A certificate server uses an internal RDBMS to control the many phases in the certificate issuing process, offering a Web-based interface to users and managers of the service.

    Intranet technology uses Internet open standards to provide interoperation and integration of diverse applications along the enterprise. A key application for Intranets is the corporate directory service allowing collection of all corporate users' personal information and preferences, including public key certificates. LDAP, a lightweight derivative of X.500's DAP protocol has been adopted recently by IETF (RFC status), and many vendors announced their adherence to the standard. In Suitespot v. 3.0 servers, LDAP services are used to recover user or server information. In this way, management of PKI by Netscape Certificate Server is supported by the Directory Server. Besides publishing newly generated certificates in the LDAP directory corresponding to the user/server's distinguished name, revocation lists are also published there and can be checked by other Intranet servers for current certificate validity.

    This model implements the security process depicted at the beginning of this discussion (see Figure 6). The operation of a certificate server, and in general, the management of a PKI within a corporate Intranet is a complex subject, with enough material for a separate article, but the necessity of implementing this management should be clear.

    Loose Ends

    Although PKI deployment within a corporation implements most of the security requirements of secure Intranets, there are still some attacks able to compromise the information architecture. This is especially true for denial of service (DoS) attacks. The SYN flooding attack exploits a basic feature of TCP/IP protocol and is difficult to remedy. Some available patches or configurations can be applied to reduce the susceptibility of corporate servers to these attacks, but the protection is not very effective for LAN connected (i.e., internal) attackers, and these patches are costly in memory requirements. Products that monitor for DoS attacks, or actually block them at the firewall level, are appearing. A redesign of some features of the TCP/IP protocol would be necessary to eliminate this risk.

    Also, a new possible man-in-the-middle attack has been demonstrated by researchers at Princeton University (see Information Resources), called Web Spoofing. In this attack, an attacker creates a shadow copy of the entire WWW by funneling through its server all access to the Web once a user has reached the attacker's machine. This attack circumvents standard SSL protection, and the users see the usual blue line in the browser window.

    All the standard system security, Web server, and TCP/IP protections apply here as well - unauthorized access to systems via remote logins of stolen UNIX passwords or abuse of CGI-bin scripts can compromise the deployed PKI. See the Information Resources sidebar for some useful security checklists. A PKI is ineffective if someone can steal a backup tape of the server! Encryption of the backup and tape protection are advised.

    Intranet infrastructure is not necessarily limited to behind the firewall networks. Sometimes the public Internet infrastructure is used to construct a cost-effective virtual Intranet providing access to regional corporate branches or mobile users. How to better protect the virtual Intranet outside firewall control? Some solutions exist for this goal, and they are based in encrypted point-to-point communication channels between Intranet sections. Banks use proprietary hardware encryptors with a secret-key technology to protect all the information flowing outside the Intranet toward clients or other offices' premises. CISCO announced a technology in partnership with Citylink to produce router-to-router encrypted channels. Software implementations that encrypt outside traffic at the firewall level are also being implemented (e.g., DataFellow's SSH Virtual LAN).

    Ultimately, the very Internet network protocol should provide the facilities for authentication and confidentiality of all Internet traffic at the protocol level. The new version of the IP protocol (IPng or v.6) provides special headers for packet origin authentication and encrypted payloads. While some of its features are still being worked out, we should be able to see working implementations of the secure protocol in a few years.

    About the Author

    Francisco M. De La Vega has been Assistant Professor and Head of the Computer Unit at the Department of Genetics and Molecular Biology of CINVESTAV, an academic research center located in Mexico City. He has been CINVESTAV's Webmaster since 1994, designer of a digital library, technical point of contact for the Mexican CERT on behalf of CINVESTAV, Solaris fan and system administrator, and private consultant on Internet/Intranet technology. In May 1997, he moved to California and is now a Senior Systems Consultant with Bluestone Consulting, Inc. He can be reached at:; email: