Web Security

Technical Note

The paper covers various security aspects of Crystal Point's web product line. General topics covered are remote host access via the Internet, Java security, SSL and the HTTPS tunneling protocol in the AppView product.

Mainframe systems, with their ability to process huge amounts of data consistently and reliably, continue to be essential to the success of many organizations.  The mission-critical applications that run on these systems typically include customer service, order entry, credit card processing and securities trading.

The Internet, with its familiar web interface and worldwide accessibility, has made electronic communication and commerce available to everyone.  Crystal Point, as the leader in providing access to NonStop systems and others through its OutsideView terminal emulation software, now provides the best of both worlds through a new Java-based web-to-host solution.

The Internet offers great benefits and presents many security challenges as well. The key advantage of the Internet is that it provides almost universal connectivity throughout the world. The disadvantage is that not all Internet participants are good citizens.  With this in mind most corporations have some form of security architecture to control access to or from the Internet.

We will cover using Crystal Point’s web products on internal intranets and for external access via the Internet.

Deployment issues:

Since the web products intrinsically supply a terminal session to a specified host, a prerequisite is that the user be able to access the web server that is hosting the web page that allows access to the mainframe system. Your first line of defense is the web server, if the web server is open access to everyone then everyone who has a browser will be able to invoke the host access client and your security depends on the build in security of the mainframe.

In the web server environment there are many tactics and options that can be used to limit access to the mainframe client. Some of them are:

• Require client side digital certificates for browser access to the web server.
• Implement sign in security and access control lists to access the host connection page.
• Accept connections only from known IP addresses or a range of IP addresses in on the Intranet.
• Require a valid network logon for the client workstation (Intranet).

These methods vary by the type of web server that you use to host Crystal Point’s host access applications. It is suggested that you consult documentation for your web server and available security application notes.

On an Intranet Crystal Point’s downloadable Java web products can also be used via a file server share or locally installed on the workstation, avoiding the use of an intranet web server and it security issues.

Java Security:

Crystal Point web products are 100% pure Java code. The Java environment was designed from the start to have strong security for both local and remote code though the sandbox concept. The essence of the sandbox model is that local code is trusted to have full access to vital system resources (such as the file system) while downloaded remote code (an applet) is not trusted and can access only the limited resources provided inside the sandbox.

These Java applets are digitally signed using a software certificate from a known Certificate Authority.  This certificate allows these applets to be recognized as trusted code by the Java virtual machine on the end users workstation. When the end user first loads Crystal Point’s Java code, a dialog box comes up and gives them an option to approve the use of code. Since the boot process is sometimes in two stages (depending on circuit security) they may receive this message twice if they don’t check the box to always trust code from Crystal Point (recommend).

Proxies and SSL:

One of the major strengths of Crystal Point’s products is the ability to deploy applications via the Internet to remote users, customers and partners. The major obstacles to remote access are firewalls and proxy servers.

A firewall can be viewed as a combined hardware/software system that links two isolated networks, usually a private network and the Internet.  A firewall polices the traffic between the two networks, blocking access from the Internet to the private network, while providing Internet access to internal computers.  For software applications proxy servers do this kind of policing.

The TCP/IP protocol, which is used for communications on the Internet, allows connections to about 65000 ports on any machine. Firewalls typically have a rule set that allows only certain ports to be accessed from the Internet side of the firewall.  A typical example is a web server behind a firewall, which uses port 80 for the standard web protocol http and port 443 for secure (SSL) http or https. Other specific ports on the system may be enabled for FTP file transfer, file-sharing services or other services.  All other ports will be blocked disallowing unauthorized access by strangers on the Internet.  In this manner, a firewall limits connections to the known, authorized services that we want to offer to the outside world.

Web proxy servers perform three basic tasks.

1. Proxy/relay web traffic through the exterior and interior firewall access points.
2. Cache repetitive web requests to reduce load on the Internet link.
3. Control which web sites that internal users are allowed to access (optional).

The proxy server must also handle a HTTPS request for you to visit a secure Web site on the Internet.  However, there is one significant difference between a proxy server processing HTTP requests and HTTPS requests.  For HTTP requests, the proxy server is able to parse the communication content and exercise a lot more discretion on policing the traffic, including dropping the connection at the appropriate time (a proxy server always assumes HTTP connections are non-persistent).

On the other hand, the proxy server will not be able to decipher HTTPS connections because of encryption.  It has no choice but to relay the data intact and cannot drop the connection unless initiated by the client and/or server.   Again, this is because the proxy server assumes the subsequent communication will not be readable.  The ability to create a persistent connection that is free of the interference of the proxy server is what we want to exploit here.

The solution is use a secure connection (SSL) that the proxy server knows it cannot cache for reuse. Note most HTTPS proxy servers will only tunnel SSL through port 443.  This requires that the host connection address be a different address than the web server hosting our connectivity application. More on that later, but note that sites that authorize access on a server-by-server basis will require separate authorization for the web server and the host security proxy server.

Among the most time-consuming and computationally expensive operations performed during an SSL transaction are the initial exchange of a shared secret and the negotiation of a bulk-encryption protocol. This exchange usually takes place immediately following the establishment of each TCP connection, and is the primary cause of server CPU load when using SSL. To reduce the number of times that this exchange must be performed, SSL includes a feature called “Session ID Re-use.” When a client and server establish an SSL connection for the first time, that connection is assigned what is known as a Session Identifier, or “Session ID.” During subsequent connections, the client can ask the server to re-use the same Session ID.

By using the persistent connection feature of HTTPS connectivity via a proxy server, the vast majority of your remote clients are able to call home via the Internet.

There are still some problems primarily with Microsoft Proxy server.

If the following message is received when attempting to communicate with a remote host:

Proxy authentication method not supported:
HTTP/1.1 407 Proxy authentication required
Proxy-Authenticate: NTLM

This message indicates that the Proxy server has been configured for NTLM authentication, which is a proprietary Microsoft protocol.  NTLM is the highest form of client side authentication for which Proxy server 2.0 can be configured and may have been selected by the network administrator without consideration of other applications to be run on the network.

Crystal Point’s web products support the basic authentication protocol for web proxy servers that require client side authentication to access the Internet. Only a couple of Microsoft TCP/IP applications (Internet Explorer and the WinSock Proxy Client) conform to the NTLM protocol when used with the Proxy Server. There are other Microsoft applications that also require the basic authentication protocol setting for the proxy server.

One method to workaround this issue is to add an applet parameter <param name=”retryWithoutHTTPProxy” value =  “true”> to the host session html file.  This will cause the client to retry the call as a normal network connection. The organization may use a proxy for caching/network performance and permit outbound data calls through the firewall.  It is also possible that the user may already have the WinSock Proxy client installed (which is the other Microsoft application that understands the proprietary NTLM authentication protocol).

If this method is not successful, the end user will need to coordinate with their network administrator to implement any of the following solutions or actions:

1. Install and configure the WinSock proxy client on the users workstation.
2. If access for browsers to the Internet is not a concern in the organization, configure the proxy server with anonymous security for outbound connections.
3. Configure the Proxy Server for both basic and NTLM client authentication. The Internet explorer client will automatically use NTLM. Third party applications will then be able to traverse the Proxy using the basic authentication method. If additional security is required the user should be instructed not to use their personal network login/password.  Another login/password identity for the proxy which is valid for Internet access should be used.
4. Install another independent Proxy that is configured for anonymous service and point the users of OutsideViewWEB or AppView clients to this proxy server.
5. Check the control panel on the computer to determine if the WinSock Proxy (WSP) client is installed on the system. If so turn off the proxy settings in Internet Explorer so that both IE and the OutsideViewWEB or AppView client will use WSP for outside communications.  Another alternative is to leave IE’s proxy settings on and put the destination host/encryption gateway address into the exclusions box under advanced proxy settings.
6. If your network architecture permits workstations to communicate to the firewall. The network administrator can add a rule that permits the clients to talk with the destination host/encryption gateway. In this case, the address of the host must be entered in IE’s exclusions box under advanced proxy settings, so that the client will bypass the proxy server when calling this host system. This address should be different from the web server that serves up the OutsideViewWEB or AppView client application.

Corporate Firewall Proxy

Now that we have gotten the remote client's traffic out onto the Internet so that it can connect to our location, let’s go through the mechanics of getting it though our firewall.

Here’s the scenario that we will discuss:

1. Client is accessing our web server to get access to the client software, which is automatically downloaded and cached on the client’s workstation.
2. The HTML page that loads the client has a connection address of the security proxy that will handle the incoming connection request. In our previous discussions this must be a connection request on port 443, the normal SSL port for HTTPS traffic.
3. If the web server is already using SSL for it’s own purposes, then the external connection address for the security proxy will have to be a different IP address.

The next slide shows a high availability DMZ (de-militarized zone) configuration that can support a vast number of users. Our example shows the following components:

1. Load balancer/health monitoring (Big-IP) front end.
2. Exterior Firewalls
3. Server Farm (bastion servers)
4. Interior Firewall
5. Host

The entire purpose of a DMZ firewall is to insure that no device on the internal corporate network can be directly accessed from the Internet . A hacker who wants to access the corporate network has to break two firewalls and a bastion server to get access.

 In the diagram we show the basic data flow. The sequence is as follows:

1. The user initiates a connection to the web server for the host access web page.  As previously discussed, this access can be authenticated through several methods including a username/password challenge.  The URL used for this access resolves to the IP address of the Big IP load balancer.
2. This load balancer checks the health of the web server farm to know if any web servers are out of service.  It then redirects the request to the least busy operational server, which for this example is the top web server at 204.201.168.202.
3. The firewall takes the address 204.201.168.202 and via a previously configured rule translates it to 192.168.1.55, which is its address of the network card that is hooked to the exterior firewall.
4. The applet tag on the web page downloads the small bootstrap applet which checks the local cache and downloads any missing code.
5. The client make a Internet call to the Security Proxy  (204.201.168.201) which is again intercepted by the “BIG-IP” device to route it to the best available proxy server which for this example is the bottom proxy server at 204.201.168.205, port 443.
6. The firewall takes the address 204.201.168.205 and via a previously configured rule translates it to 192.168.1.56 and port 2000 so that it doesn’t interfere with the normal https service on port 443.
7. The proxy server then goes through the process of identifying the client side certificate and negotiates a secure circuit. It then calls the host though the network connection that is hooked to the interior firewall.
8. The interior firewall then checks if the host IP address is permitted, the right port or service on the host is being invoked and if the originator is an allowed IP address.

Depending on the security needs of organization you may have either a simpler or more complex setup. As you can see a great deal of coordination is needed for complex security configurations.

Another configuration item is the SSL session timeout that may be enforced by the load balancer/health monitoring software. Web servers generally timeout inactive SSL circuits to free up resources, in our case the host circuit are always active, so SSL timeout to the proxy server should be disabled.

HTTPS Tunneling

The AppView product from Crystal Point Inc. has an additional secure transport, HTTPS tunneling.  This architecture takes advantage of the SSL capabilities of client browsers and the web server to achieve secure transport with no changes to existing network structures.  If HTTP(s) tunneling is selected for the session, the AppView applet will forward data targeted for the host to its local browser.  The browser will encapsulate this data as an HTTP packet and encrypt it through SSL (HTTPS).  This data packet can easily traverse any intervening web proxies and firewalls since it is a  known protocol using a known port (443).  Once the packet arrives at the web server, it is decrypted and forwarded to a tunneling servelet.  This tunneling servelet is included with AppView and can be executed within most servelet runners (e.g., New Atlanta or Tomcat).  The tunneling servelet then sends to data to the host application via a standard telnet terminal session.

Since web-standard security can be achieved with no changes to network structures, HTTPS tunneling is rapidly becoming the protocol of choice for secure Internet communications via client and server side firewalls.  The tunneling servelet can also be installed at a web server residing on the host system (e.g., ITP or WebSphere) if end-to-end encryption is required.

Some of this advantages of this technology are:

1. If the user's browser can communicate with your web site via HTTPS then the host connection/tunnel will also work.
2. Host access may be more easily coordinated with the security personnel.  No additional ports have to be opened in the exterior firewalls or web proxies as the default HTTPS web access ports are used.
3. Access is easier from the client workstation. The browser is responsible for proxy traversal and, in the case of IE, can handle proxy servers that require “NTLM” login, etc.
4. Access controls for the web server can automatically be applied to further enhance security. (Client side certificates, etc.)
5. Any infrastructure enhancements for security on the web server/client can be automatically supported. (smart cards, access tokens, etc).

Tunneling makes heavy use of HTTPS, therefore some web server tuning may need consideration.