Deploying Eclipse in IT

Posted by Documentation Tue, 09 Mar 2010 09:36:00 GMT

Integration of the HOB Windows Terminal Server clients HOBLink JWT and the 3270 client HOBLink J-Term in Eclipse

Originally, Eclipse was used in the development environment, i.e., as an application program for the development of software for the programming language Java. As the successor to IBM Visual Age for Java 4.0, the source code for Eclipse was released by IBM on 7 November 2001. On 2 February 2004, the Eclipse consortium, lead by IBM, decided to found the legally independent Eclipse Foundation, which since then has been responsible for the development of Eclipse. Eclipse is Open Source software and can be downloaded free of charge.

Due to its expansibility, Eclipse is also used for many other development tasks. There are many extensions from both open source and commercial providers.
Up to and including Version 2.1, Eclipse was designed as an IDE. Since Version 3.0, Eclipse is only the core that loads the individual plug-ins, which themselves supply the actual functionality. Eclipse and the plug-ins are completely implemented in Java. SWT is used to create the graphical user interface. For the display of the GUI components, SWT, similarly to AWT, uses the native GUI components of the corresponding operating system. The plug-ins can be installed either by downloading them directly from an update server or simply by unpacking them.

Increasingly more enterprises are deploying Java products and more and more often using Eclipse as the framework on the workstation computer due to the advantages thereof. A very popular and widely used application for deployment with Eclipse is Lotus Notes from IBM. With the Lotus Expeditor, the GUIs for Lotus Notes can be created and integrated on the basis of Eclipse (RCP, Rich Client Platform). Eclipse is itself written in Java and can therefore be used on any platform and on any client operating system.

The use of Eclipse as the framework on the workstation computers in an enterprise brings with it the following advantages:

  • A uniform base for the use of any application program as a Java plug-in in heterogeneous client environments

  • Very open and flexible design of the client’s GUI

  • All application programs used as plug-ins can be easily given a uniform display format

  • Standardized software interfaces allow the deployed plug-ins to be linked with each other, e.g., for data exchange, etc.
  • The integration of the individual application programs into the Eclipse framework simplifies the rollout to the work areas and, as a result, also the administrative work.

A disadvantage of this design is the fact that desired applications are not always available as Eclipse plug-ins. Early on, HOB recognized the need of enterprises for applications as Eclipse plug-ins and thus offers two important client applications as plug-ins for Eclipse:

HOBLink J-Term, the first and most performant 3270 emulations in Java
HOBLink JWT, the RDP client for Microsoft Terminal Server in Java

Both products are in use at well-known corporations. HOB has placed great importance on the providing the Eclipse plug-in versions with the same scope of functions as the native versions.
The “look and feel” and the performance range of the native versions and the Eclipse plug-in versions from HOB are absolutely identical. A user who has previously worked with a native version and switches to the Eclipse plug-in version can work with this version just as before.

For further information, please see:

25 February 2010

Klaus Weinbrenner



Posted in | no comments |

Migration from an IPsec to an SSL Solution

Posted by Documentation Mon, 15 Feb 2010 12:19:00 GMT


VPN’s (Virtual Private Networks) used to be created with the IPSec protocol (Internet Protocol Security). Newer solutions are based on SSL (Secure Sockets Layer). SSL-based solutions can be used in the same way as IPSec solutions; with SSL, however, there are also solutions that are principally different than IPSec solutions.

 In this article the differences between SSL and IPSec, and the advantages of SSL over IPSec, will be discussed.  This article deals exclusively with solutions for remote access from laptops or PCs. In gateway-to-gateway connections, which for instance are used for connections to branch offices, using SSL doesn’t make sense, so IPSec continues to be used in such scenarios. Also, devices such as the Apple iPhone or other cell phones with Microsoft Windows mobile as a standard have an embedded IPSec client. The advantages of SSL don’t apply here; therefore it doesn’t make sense in this case to replace IPSec with SSL. 

This article is organized into the following sections:

  1. Where SSL can be used, but IPSec doesn’t work
  2. System Architectures with IPSec or SSL
  3. Compression with IPSec or SSL
  4. Streaming with IPSec or SSL


1.       Where SSL can be used, but IPSec doesn’t work

Only Access over TCP Port 80 and 443 is possible

In the Internet environment such as in companies, hotels, or Wi-Fi Hotspots firewalls are used regularly as a form of protection from the public Internet. Since access to the protected areas should be possible, predominantly for the web-browser users, access over the HTTP TCP port  80 and the HTTPS TCP port  443 is allowed.  If there is nothing else configured in the firewall, IPSec definitely cannot be used.


Proxies within Company Networks for Access to the Public Internet

Proxies are used in many companies and organizations to regulate access to the public Internet. The protocol Socks 4/5 and HTTP are then utilized. Conventional browsers support access through such proxies. Microsoft ISA Server or Squid (Open-Source) are examples of proxies that are used. It could be required within the proxies that a user or a device must be authenticated before access to the public Internet is allowed. Different options can be used for the authentication: Username/Password, NTLM (NT LAN Manager) or Kerberos. It is possible within such proxies to check the incoming websites (HTTP/HTML) for viruses. With the appropriate constructive characteristics it is also possible to receive arbitrary data through the virus checker. Viruses are not received from the Web-Browser, but from the SSL Clients instead. Such proxies generally cannot be used with IPSec, only with TCP or SSL is access possible.


SSL over the HTTP TCP Port 80

There are installations, commonly found in hotels, where only port  80 is open and not the HTTPS/SSL-port  443. It is, in principle, possible to pass SSL data through port  80 so that access with the web browser (over SSL clients) is possible.


Costs for Hotel Internet Access

It has been reported that in many hotels there are different price models for Internet access. There is complimentary or low cost access over the TCP port  80 / 443 (where SSL can be used), but if one wants to use IPSec, then another, more expensive, price model must be chosen.


Low Cost Network Components

When a user is at home and wants to set up a VPN connection on the central network, then as a rule a standard DSL connection should be used. A DSL router is then used and it typically does the NAT (Network Address Translation). It has been reported that such DSL routers often cannot use IPSec, often not even with NAT-Traversal. 


2.        System Architectures with IPSec or SSL 

System Architecture with IPSec

IPSec solutions are usually set up so that a driver is installed on the client.  This driver installation creates a so-called virtual adapter in the system. Typically, the IP address used for communication with applications on the central servers comes from the central IT administration. The driver in the system intercepts all (or the relevant) IP packets, encodes them and then sends them over the IPSec tunnel to the server. Packets from the server travel the opposite path. There are also IPSec solutions with compression. 

Driver Problems

Modern operating systems are designed so that a faulty program doesn’t cause the operating system to crash nor disturb nor damage other programs. This is attained by allowing only the operating system to carry out critical actions such as input/output or memory management. If programs need such actions, they jump over the APIs (Application Programming Interface) in the operating system, the operating system checks whether the action can be carried out faultlessly and then the operating system carries out the critical actions for the application. 

Now, however, an operating system can’t always do everything alone; therefore drivers are used to extend the operating system. Drivers, in principle, are allowed to perform all actions, even the critical and dangerous ones. This is necessary because, otherwise, the applications would only be able to do what the standard operating system is designed to do. 

Several problems arise from these circumstances. One being, faulty drivers can cause the entire operating system to crash; with Windows one speaks of a “blue screen” event. Often data is lost by a system crash and it causes a big disturbance for the user, because he is not able to work for quite a long time (at least for as long as it takes for the system to reboot). 

There are specific interfaces in the operating system for drivers. Operating systems are constantly being further developed, so that these interfaces must always be changed. That mainly means that for every operating system version a specific driver is needed, which doesn’t work anymore with a newer version of the operating system. With normal applications this problem doesn’t exist because the OS manufacturers see to it while developing new versions that the interfaces to these applications (APIs) are maintained at a consistent level.     

Qualified developers are needed for the development of drivers and these are hard to find.  In comparison to normal applications, drivers are more difficult and more expensive to develop, debug and to test. 

In conclusion, it is to be said that the prevailing number of operating system crashes (“blue screen”) are not just errors from the operating system, but instead from the driver.

Microsoft, in Windows XP, introduced the function Windows Error Reporting (WER). This enables Online Crash Analysis (OCA) to be done. When Windows crashes with a blue screen event, than a small core-dump is generated and, after the user is prompted and agrees, this is sent to Microsoft. Microsoft was at the time quite amazed at the many core dumps they then received, the large amount of which was unexpected. As the received core dumps were analyzed, Microsoft discovered that faulty drivers were responsible for 85% of the errors, the small percentage remaining were actual Windows kernel problems. If there were fewer drivers in the system, then there would be correspondingly less annoyances and problems.

Full Network Access over SSL

With some SSL solutions there is also full network access over SSL, analogous to solutions with IPSec. In standard solutions a driver is installed on the client’s operating system, analogous to IPSec. HOB RD VPN PPP Tunnel, a new technique that is patent registered, has full network access without a driver, without administrator rights and completely without an installation on the client. The PPP Tunnel solution within HOB RD VPN is browser-based. 

Because with this solution everything is installed on the central server and nothing on the client, software updates are much easier to implement and constitute considerable cost savings. 

Access from the Client’s Web Browser over an SSL VPN to the Central Web Server   

One of the first and basic functions of SSL VPNs was to make access only via the client’s web browser. When a user wants access, he authenticates himself first on the SSL gateway and then he is granted access to all web servers in the central network. This access can be restricted if necessary by the configuration of the SSL VPNs; the user can then only access predetermined web servers. The communication between the client (web browser) and the VPN gateway is SSL encoded (HTTPS). For communication between the VPN gateway and the internal web servers, normal HTTP is used or, when needed, SSL can also be used. One speaks then of client-side SSL. 

This function sounds relatively simple; however it is expensive because all links in the web pages of the VPN gateway must be converted. This is principally possible for:

  • HTML
  • CSS
  • Javascript, jscript
  • Ajax 

However, there are restrictions and some general problems with websites with the following content:

  • ActiveX
  • Flash
  • Silverlight
  • Java


In addition, files can be exchanged in both directions with the central office over the browser. Not all SSL VPNs command these costly procedures for the conversion of web pages or for the exchange of files. With HOB RD VPN this function is called Web Server Gate. The exchange of files is called Web File Access.  

On the one hand, only web applications are predominantly developed or used in many companies, on the other hand only the normal web browser is needed on the client. For this reason, this form of access over SSL VPNs is often used. With IPSec VPNs there are no comparable functions. 

Redirection from the TCP Data Stream to the localhost

One of the basic functions of SSL-VPNs is the following: on the client a small proxy is started which was previously downloaded as a Java applet or an ActiveX  control from the SSL-VPN. Now the user can start on the client the desired applications. These then connect over the localhost to the local proxy and then to the corresponding server. To do this, of course, the application has to be configured differently.
The local proxy encrypts the data with SSL and sends it to the VPN gateway. The VPN gateway unpacks the data and sends it to the desired target or server. At HOB this function is called the Universal Client, elsewhere one speaks of port-forwarding. This function has certain limitations and only works when the client application establishes a TCP connection to the server; the other way around, a TCP connection can be made when the server wants to establish one to the client. UDP also cannot be used.
There are also problems when in the TCP data IP addresses are transmitted, as happens, for example, with FTP or RDP. Also in SIP and RTP IP addresses are transmitted in the data packets, but here the communications go over UDP and redirection over the localhost is, in principal, not possible.
When working with a local proxy, the Session Directory cannot be used with RDP for the Windows Terminal Server, because the RDP data stream is being redirected over the local proxy.
With HOB RD VPN, SSL is done directly in the RDP Java Remote Desktop Client HOBLink JWT and in the WebSecureProxy, so that the Session Directory function is also supported here, as opposed to solutions using local proxies and redirection over a localhost.
In many cases, the function with local proxies and redirection over a localhost is sufficient, yet it does not provide complete network access. However, in many cases complete network access is not at all desired.

3.        Compression with IPSec or SSL

In many IPSec solutions compression is incorporated, but after different methods, most of them deflate. 

With IPSec the packets are individually compressed, if a dictionary is used, it must be reset with each packet. This happens because IPSec is a connectionless protocol. This means packets can get lost, packets can arrive out of order, or they can arrive at the recipient with the wrong Checksum and then be rejected. Packets are also rejected from routes in the transmission network if the network is overloaded; this is a normal occurrence and is accordingly taken into consideration by all IP stacks. 

IPSec does not notice if a packet does not arrive at the recipient, these problems are handled at a higher layer, e.g., in the TCP stack. Due to the fact that with IPSec the dictionary is reset with every packet, the compression is less effective. Packets are mostly small with IPSec, MTU = Maximum Transmission Unit or MRU = Maximum Receive Unit is for example, with PPP RFC 1661 1,500 Bytes. With such small packets good compression is not possible. In the meantime, there are Gigabit Ethernet jumbo packets, up to 16,000 bytes, with these, better compression is possible, but, with WAN such large packets currently cannot be exchanged.

Compression with SSL

 SSL is connection-oriented and thus efficient compression can be used. Web browsers have a good command of compression methods such as zLib. The data is given in the HTTP header. The web browser doesn’t send compressed data itself; actually the packets from the web browser to the web server are typically quite small. But the web server (or an SSL gateway with the function Web Server Gate) can compress the response with zLib and thereby the corresponding web pages are loaded faster. 

Compression with zLib is built into HOB RD VPN Web Server Gate.  Web pages can be compressed even if the original web server sends the data uncompressed. 

With SSL the shared cipher suite is negotiated through a suitable method, which means deciding which encoding algorithms are used. 

The company Netscape originally invented SSL and had intended that while negotiating the cipher suite, a compression algorithm could also be negotiated. For this reason, HOB built this functionality into the corresponding SSL suite so that compression could also be used. This works, however, only when HOB SSL Suite is used on the client as well as on the VPN gateway. There are no other known companies, aside from HOB, that do compression on the SSL level. 

If with HOB RD VPN the PPP Tunnel with compression is deployed, Windows Explorer data, for example, is exchanged, and an effective compression takes place. In practice it was observed that the data stream was compressed sometimes down to 20%. The data exchange then goes much faster, just as with a virtually five times faster line. 

4.        Streaming with IPSec or SSL   

Applications like video or audio use streaming, i.e., a continuous data stream is sent. A special case of streaming is real time, such as VoIP (Voice over IP). In order to understand the suitability of IPSec or SSL for streaming, we must first look at the basics. 

Transmission Error

If data can be transmitted, then physical effects can cause this data to be falsified. That is the reason that checksums are built into the data packets. The transmitter generates the checksum and the recipient checks whether the checksums are still correct; if not, the data packet is rejected. The recipient does not have any other possibility, as the return address in the data packet could have also been falsified and therefore the recipient cannot inform the sender. 

Overruns in Routers

The Internet protocol, IP, is connectionless. Let’s assume that we have a router with 2 data lines connected, one fast line 1 and one slow line 2. If the router begins now with the packets in the quick succession from line 1 that should be redirected to line 2; the router cannot redirect the packets so fast over the slower line 2. A solution to this problem is that the router caches these packets and then sends them delayed. But the memory of the router is limited and therefore the router rejects data packets when it has received more than it can redirect.

The UDP Protocol  

The UDP protocol (User Datagram Protocol) is very simple. A transmitter sends packets, if the packets arrive at the receiver then it is good, if not, nothing further happens. Nothing is built in the UDP protocol for the transmitter to notice that the sent data packet did not arrive. 

The TCP Protocol  

The TCP protocol (Transmission Control Protocol) is connection-oriented and complex. With TCP it is guaranteed that all data packets that an application sends intact, complete, and in the correct order will arrive at the recipient.  

Simply described, it functions like this:  When the IP stack of a computer sends a TCP packet, the recipient must send an acknowledgement within a certain amount of time (a fraction of a second). If the sending IP Stack doesn’t receive an acknowledgement, because the sent packet is lost, the recipient doesn’t exist anymore, or the acknowledgement was lost, then he sends the packet again. If after a certain number of repetitions still no acknowledgement is received, then the IP stack reports this error to the application. 

Suitability of UDP or TCP for Streaming

For streaming, specifically for real time, normally UDP, not TCP, is used. If now and then a packet is lost by streaming, it is not a big problem. If however, like with TCP through the repetitions of packets, streaming doesn’t continuously function, then there will be a certain problem. 

Suitability of IPSec or SSL for Streaming

IPSec is connectionless like UDP; packets from the IPSec layer are not repeated, and therefore well-suited for streaming.  SSL is based on TCP. It is constructively built so that all packets must arrive intact, complete and in the correct order at the recipient, otherwise the cryptography of SSL doesn’t work.  

SSL is less suitable for streaming. A way out of this problem is to build an encoded UDP connection parallel to SSL and then dispatch the streaming data in this way when it is possible. This is exactly built in the HOB VoIP solution, HOBPhone. 

Practical Experience

Streaming over IPSec works well.  Streaming over SSL usually works just as well, because transmission errors are seldom seen these days. 

Klaus Brandstätter, CEO, HOB Inc.


Penny Orwick, Guy Smith
ISBN-13: 978-0-7356-2374-3
ISBN-10: 0-7356-2374-0

02.05.09 KB
04.05.09 KB
12.06.09 KB


Posted in | no comments |

HOB RD VPN and SSL Accelerator Cards

Posted by Documentation Fri, 12 Sep 2008 14:41:00 GMT

HOB RD VPN is a remote access solution based on SSL. The SSL part is quite old, it was first developed for the 3270 data stream to securely access IBM mainframes. Later it was extended to support RDP, then HTTPS for the HOB Web Server Gate and, finally, for tunneling of PPP. The SSL part of HOB RD VPN also has the product name HOBLink Secure. We believe when HOB started the development of its SSL solution, the popular OpenSSL was not yet available.

So over time there was the question at HOB: Should we support SSL Accelerator Cards?

First I have to mention that we at HOB work with the latest servers from leading vendors. We always buy the models with the highest clock speed. The HOB development people should not waste their time working (meaning compiling and debugging) on slow machines.

We acquired some SSL Accelerator Cards as test equipment and got them working. These cards were connected to the PCI bus of an x86 system.

But the results of tests we made were quite disappointing: When calculating the asymmetric RSA key, the SSL Accelerator Cards gave some advantage over the solution in pure software. But the symmetric encryption algorithms, mainly the currently most widely used AES algorithm, did not give an advantage over the software solution. Also, one or more cards were even slower compared to the pure software solution.

The asymmetric RSA key is calculated only once, at session start. The key found may also be re-used between two partners having one or multiple SSL connections between them. So processing of symmetric encryption is far more important compared to the calculation of the asymmetric RSA key.

We believe the reason for not getting more speed out of the SSL Accelerator Cards is the following: The CPU, when an SSL Accelerator Card is used, still has something to do: it has to send all the data down the bus, then the card will process, and afterwards the data is sent over the bus again. Whether there are cards which directly access the main memory is something I don't know.

The HOB SSL suite contains all major encryption algorithms including AES with a 256-bit key length. The HOB SSL also contains, as an option, compression. Netscape defined the original SSL protocol, and in the handshake they already put in parameters for compression. So HOB included compression, but we do not know of any other vendor who included compression as well. Tests have shown, for compression there are about as many CPU resources used as compared to symmetric encryption. But the SSL Accelerator Cards do not include compression. We have seen hardware that does compression. But, when comparing the compression ratio with software solutions, the hardware compression does not compare well. The reason for that is, that in compression algorithms there is some fine-tuning possible in software. Doing the same in hardware would be too complicated. So we found out compression should be done in software as well.

At HOB, we have successfully tested the WebSecureProxy, the SSL gateway, with 10,000 simultaneous sessions; both on Windows and Linux, and using an x86 CPU on mid-size servers. No SSL Accelerator Card was necessary to reach 10,000 simultaneous SSL sessions. Each of the sessions was run with simulated RDP traffic where the user neither permanently sends nor permanently receives data from the server.

We believe, on big machines, even more than 10,000 simultaneous sessions are possible - without an SSL Accelerator Card. And HOB RD VPN supports clustering as well.

The HOB WebSecureProxy was designed with heavy loads in mind, and it can keep any number of CPUs busy without giving delay to the users.

The HOB SSL encryption routines have been examined by the BSI, the German Bundesamt für Sicherheit in der Informationstechnik. The HOB SSL encryption routines got certified under Common Criteria. In the course of this certification, HOB made a large number of compatibility tests with other SSL solutions.

If the HOB customers would use SSL Accelerator Cards, there would be extra cost for the cards. Also, as hardware can break, our customers would need spare parts.

With the HOB solution, especially with the Unix-based OpenSource operating system HOB SCS, when there is a hardware problem you go to the nearest PC dealer, get a server out of the box, install the software and the problem is fixed.

I believe today we get a lot of processing power out of modern CPUs. These CPUs have many cores today. So spending money for fast CPUs is better compared to spending money for SSL Accelerator Cards.

12.09.08 Klaus Brandstätter

Posted in | no comments |

tp://')) %>
Powered by typo