Security-Encrypted Transactions - Online Article

You can further enhance security on your intranet by encrypting  Web transactions. When you use an encryption facility, information  submitted by customers using Web fill-in forms-including usernames,  passwords, and other confidential information-can be transmitted  securely to and from the Web server.

There are a wide range of proposed or partially implemented encryption  solutions for the Web, but most are not ready for prime time.  Of the several proposed methods, only two have emerged in anything  like full-blown form. Let's look at the Secure HTTP (S-HTTP) and  Secure Socket Layer (SSL) protocols in this article. Unfortunately,  the two protocols are not compatible with each other. Worse, Web  browsers and servers that support one method don't support the  other, so you can reliably use one or the other only if you carefully  match your Web server and customers' browsers.

Secure HTTP (S-HTTP)

S-HTTP was developed by Enterprise Integration Technologies and  RSA Data Security, and the public S-HTTP standards are now managed  by CommerceNet, a nonprofit consortium conducting the first large-scale  market trial of technologies and business processes to support  electronic commerce over the Internet. (For general information  on CommerceNet, see  S-HTTP is a modified version of the current httpd protocol. It  supports

  • User and Web server authentication using  Digital Signatures and Signature Keys using both the RSA and MD5  algorithms.
  • Privacy of transactions, using several  different key-based encryption methods.
  • Generation of key certificates for server  authentication.

EIT has developed modified versions of the ncSA httpd server and  ncSA Mosaic (for UNIX and Microsoft Windows), which both support  S-HTTP transactions. Although the licensing terms allow for ncSA  to fold EIT's work into its free httpd server and Mosaic browsers,  there's been no public indication of ncSA's plans to do so. Meanwhile,  the CommerceNet secure ncSA httpd server and Mosaic browser are  available only to members of CommerceNet. You'll find information  about both packages, including full-text user manuals, at the  CommerceNet home page

Secure Sockets Layer (SSL)

S-HTTP seems to have been engulfed in the 1995 Netscape tidal  wave. Unwilling to wait for widely accepted httpd security standards  to evolve (as it was with HTML as well), Netscape Communications  Corporation developed its own SSL encryption mechanism. SSL occupies  a spot on the ISO seven-layer network reference below that of  the httpd protocol, which operates at the application layer. Rather  than developing a completely new protocol to replace httpd, SSL  sits between httpd and the underlying TCP/IP network protocols  and can intervene to create secure transactions. Netscape makes  the technical details of SSL publicly available. In addition,  C-language source code for a reference implementation of SSL is  freely available for noncommercial use.

The Netscape Navigator Web browser has built-in SSL support, as  does the Netscape Commerce Server; the Netscape Communications  Server does not support SSL. Given Netscape's share of the Web  browser market, it's hard to see how S-HTTP has much of a chance  at becoming widely available. With the exception of ncSA Mosaic,  most other Web browsers have-or have promised-SSL support. Some  of them are Spry's newer product, Internet in a Box, Mosaic in  a Box for Windows 95, and Release 2 of Microsoft's Internet Explorer  for Windows 95 and the Macintosh.

Even though a browser might support secure transactions using SSL or S-HTTP, no transactions are actually secure except those between the browser and a compatible Web server. Thus, using Netscape, for example, won't provide any security unless you're also   using the Netscape Commerce Server. It's also important to note that simply using a proxy service (that is, passing Web services through network firewalls) does not imply secure transactions unless both the proxy server and the destination server do.

As noted in the preceding section, the Netscape Commerce Server  supports the company's SSL security mechanism. Other packages  that support SSL include the Secure WebServer package from Open  Market, Inc., (,  which also supports S-HTTP, and IBM's Internet Connection Secure  Server, which runs under IBM's UNIX, AIX Version 4, and OS/2 Warp.  (Evaluation copies of Secure WebServer for several UNIX systems  are available at the Open Market Web site.)

Both Secure WebServer and Internet Connection Secure Server are  based on Terisa Systems, Inc.'s SecureWeb Client and Server Toolkit.  This package provides source code for developers building secure  Web servers and browsers. The Terisa Toolkit supports both SSL  and S-HTTP. For more information about the package, visit Terisa's  Web site at  Open Market's promotional announcements about Secure WebServer  state that the package supports secure transactions through Internet  firewalls, but no details on just how this works are provided.

The  Common Gateway Interface (CGI) and Intranet Security

CGI is the mechanism that stands behind all the wonderful, interactive  fill-in forms you'll want to put on your intranet. Your customers  might demand these kinds of intranet resources. CGI-BIN scripting  is susceptible to security problems, so do your scripting carefully  to avoid such problems.

You can minimize much of your risk of security breaches in CGI-BIN  scripting by focusing on one particular area: Include in your  scripts explicit code for dealing with unexpected user input.  The reason for this is simple: You should never trust any information  a user enters in a fill-in form. Just because, for instance, a  fill-in form asks for a user's name or e-mail address, there is  no guarantee that the user filling in the form won't put in incorrect  information. Customers make typographical errors, but probing  crackers, even those inside your organization, might intentionally  enter unexpected data in an attempt to break the script. Such  efforts can include UNIX shell meta-characters and other shell  constructs (such as the asterisk, the pipe, the back tick, the  dollar sign, and the semicolon) in an effort to get the script  to somehow give the user shell access. Others intentionally try  to overflow fixed program text buffers to see if the program can  be coaxed into overwriting the program's stack. To be secure,  your CGI-BIN scripts have to anticipate and deal safely with unexpected  input.

Other problems inherent with CGI-BIN scripts include

  • Calling outside programs, opening potential  security holes in the external program. The UNIX sendmail program  is a favorite cracker target.
  • Using server-side includes in scripts,  which dynamically generate HTML code. Make sure user input doesn't  include literal HTML markup that could call a server-side include  when your script runs.
  • Using SUID scripts are almost always dangerous,  whether or not in a CGI-BIN context.

Paul Phillips maintains a short but powerful list of CGI-BIN security  resources on the Web. Check out,  where you'll find a number of documents spelling out these and  other risks of CGI-BIN scripting. For an extensive list of general  CGI-related resources, go to Yahoo!'s CGI page, at

Your  Intranet and the Internet

Is your intranet accessible from the Internet? If so, all of the  security problems of the Internet are now your intranet's problems,  too. You can, however,  connect safely to the Internet and still protect your intranet.  You can even use the Internet as a means of letting remote sites  in your company access your intranet.

First, look at some Internet security basics.


It's a fact of Internet life that there are people out there who  want to break into other people's networks via the Internet. Reasons  vary from innocent curiosity to malicious cracking to business  and international espionage. At the same time, the value of the  Internet to organizations and businesses is so great that vendors  are rushing to fill the need for Internet security with Internet  firewalls. An Internet firewall is a device that sits between  your internal network and the outside Internet. Its purpose is  to limit access into and out of your network based on your organization's  access policy.

A firewall can be anything from a set of filtering rules set up  on the router between you and the Internet to an elaborate application  gateway consisting of one or more specially configured computers  that control access. Firewalls permit desired services coming  from the outside, such as Internet e-mail, to pass. In addition,  most firewalls now allow access to the World Wide Web from inside  the protected networks. The idea is to allow some services to  pass but to deny others. For example, you might be able to use  the Telnet utility to log into systems on the Internet, but users  on remote systems cannot use it to log into your local system  because of the firewall.

Here are a couple of good general Web resources about Internet  firewalls:

  • Marcus Ranum's Internet Firewalls Frequently  Asked Questions document at
  • Kathy Fulmer's annotated list of commercial  and freeware firewall packages (with many hyperlinks to firewall  vendor Web pages) at

If your company is also connected to the Internet, you'll want  to know how to make sure your intranet isn't generally accessible  to the outside world. You learned earlier in this article about  denying access to your Web server using hostname and IP address  authentication, but the fact that IP addresses can be easily spoofed  makes it essential that you not rely on this mechanism as your  only protection. You'll still want to rely on an Internet firewall  to protect your intranet, as well as all your other network assets.  Moreover, unless your corporate network is not connected to the  outside world at all, you'll want to ensure the security of your  other intranet services, including not only your Web servers,  but also your FTP, Gopher, Usenet news, WAIS, and other TCP/IP  network services.

Virtual Intranet

More and more companies with widely distributed offices, manufacturing  sites, and other facilities are turning to use the Internet to  replace private corporate networks connecting the sites. Such  a situation involves multiple connections to the Internet by the  company, with the use of the Internet itself as the backbone network  for the company. Although such an approach is fraught with security  risks, many organizations are using it for non-sensitive information  exchange within the company. Using a properly configured firewall,  companies can provide access to services inside one site's network  to users at another site. Still, however, the data that flows  across the Internet backbones between the corporate sites is usually  unencrypted, plain text data that Internet snoopers can easily  read. Standard firewalls don't help with this situation.

A number of firewall companies have recently developed Virtual  Private Network (VPN) capabilities. Essentially, VPN is an extension  of standard firewall capabilities to permit authenticated, encrypted  communications between sites over the Internet. That is, using  a VPN, users at a remote site can access sensitive data at another  site in a secure fashion over the Internet. All the data that  flows on the public Internet backbones is encrypted before it  leaves the local network and then decrypted when it arrives at  the other end of the connection.

The VPN is similar to a wide area network, or WAN, in that you  are connecting one or more smaller networks together. WANs, however,  typically utilize dedicated phone lines to communicate with each  other. Many T1 and T3 lines are used for this purpose daily all  over the world. This WAN setup can be quite secure because the  information flow is over private telephone networks, not a giant  chaotic network like the Internet.

WANs are not as prone to outages as VPNs are. That is because  the VPN is at the mercy of a) your Internet service provider,  and possibly b) your Internet service provider's Internet service  provider. If either of these two sites go down, you're in the  dark. That's a bad thing when you need to get at your corporate  database in Chicago for a meeting that started five minutes ago.

What VPNs do give you is secure communications over a relatively  cheap medium. Instead of paying hundreds or possibly thousands  of dollars per network drop site, plus the cost of WAN equipment  (which can get expensive), you simply pay for an Internet connection.  These can be had for as little as $125.00 per month. Granted you  won't get much bandwidth for that price, but it's a start. If  you are considering extending your corporate network, consider  VPNs too.

The most mature VPN product comes from Raptor Systems (,  part of the company's Eagle family of products, and others are  available from Checkpoint (  and Telecommerce (

About the Author:

No further information.


No comment yet. Be the first to post a comment.