Posted by hob
Mon, 12 Nov 2007 13:10:00 GMT
The HOB WebSecureProxy is the security gateway for many organizations. It is used to access internal applications over the Internet.
The HOB WebSecureProxy is configured through one (and only one) XML configuration file. XML has the advantage that it is human readable. It is the proven way to simply exchange information between the administrator and the machine (computer).
There is a Java based configuration tool which is used to enter the necessary information.
But this XML configuration file can also be edited with every common text-based editor.
The XML configuration file can be viewed with Web Browsers and their built-in XML functionality, the hierarchy of the definitions can be seen.
We all know that sometimes administrators call all users of certain services and tell them they have to leave the application at a certain time because the configuration is going to be updated then and the application will have to be restarted.
The HOB WebSecureProxy can dynamically update its configuration by reading a new version of the XML configuration file.
This means, users that have logged on before the configuration update keep their old configuration until they log off.
Users who log on after the configuration update automatically get the new parameters.
The service is not interrupted.
The problem of users having a part of their configuration parameters from the old configuration, and the other part of their configuration comes from the new configuration does not exist.
Which techniques are used to enable this scenario?
In Windows the WebSecureProxy is the program IBIPGW08.
IBIPGW08 automatically gets notified when the XML configuration on disk (that was used when IBIPGW08 was started) is changed and then reads in the new parameters.
In Unix and Linux the WebSecureProxy is the program NBIPGW08.
When the XML configuration has been changed, the administrator can start a new instance of NBIFGW08.
The new instance of NBIPGW08 notifies the already running old NBIPGW08; the already running old NBIPGW08 closes its sockets which listen for incoming new connections.
Now the newly started NBIPGW08 can listen on the same ports again and users who log on from now on automatically get connected to the newly started NBIPGW08.
The already running old NBIPGW08 automatically exits when all users have logged off.
Security Risk of Applications Listening on Well-Known Ports
In Unix and Linux only applications running at superuser level can open the well-known ports.
The HOB WebSecureProxy normally listens on HTTPS port 443; this port is one of the well-known ports.
But for security reasons it is less critical when the WebSecureProxy NBIPGW08 runs on a normal user account.
To solve this problem, HOB has developed the listen-gateway NBIPGW12.
The listen-gateway NBIPGW12 is a small application which should run on superuser level and can then open the well-known ports.
The listen-gateway NBIPGW12 needs only little configuration, this can be given in the command line when NBIPGW12 is started.
The HOB WebSecureProxy NBIPGW08 now runs on a normal user account and creates a Unix Pipe (FIFO) to NBIPGW12.
NBIPGW08 over the FIFO sends encrypted commands to the listen-gateway NBIPGW12, such as open a port for listen.
The listen-gateway NBIPGW12 then opens said port for listen and forwards all incoming connection requests to NBIPGW08 over the FIFO.
In this way, NBIPGW08 does not need to run as superuser and still can open well-known ports.
no comments
Posted by hob
Mon, 10 Sep 2007 12:28:00 GMT
1. The Problem
On the serial ports of PCs, asynchronous communication is mostly used. This means, every piece of information, which is normally one byte with 7 or 8 bits of information, is sent individually. There are start-bits at the beginning of each character and there are stop-bits at the end of each character.
Information sent mostly contains multiple characters, forming a block.
The problem now is, that neither the hardware nor the software driver can know how many characters form such a block.
We discuss here how applications handle this type of traffic.
2. Applications We Have Seen
We have seen applications of other vendors and how they work. The have a buffer of a certain length, for example two kilobytes. They set a very short timeout and receive data in a
loop.
In Windows, ReadFile() is done, giving the buffer and its entire length.
The ReadFile() returns when either the entire buffer has been filled by the driver or when the timeout has elapsed.
Now in the loop, there is mostly no data received, and the ReadFile() returns after the short timeout saying it has received nothing.
So these applications constantly give a certain load to the machine they are running on. Another disadvantage of this technique is, that there is also a delay before the application gets the data that have been received, because the buffer normally does not get filled; there are just some bytes received.
This delay is theoretically half of the time of the timeout set.
3. HOB Approach for Receiving Data with the Serial Interface
In the HOB approach, the serial interface is set for no timeout, or a very long timeout. When data is received by the application, ReadFile() is started, giving a buffer of one byte length. Then the ReadFile() operation returns each and every time a single character has been received, and only then.
During times when no data is received over the serial line, this application does not consume any CPU cycles.
When data are received, CPU load is higher, since there is a context switch for every byte received.
When data are received, they can be immediately processed by the application without any delay.
no comments
Posted by hob
Mon, 10 Sep 2007 12:20:00 GMT
Today, many SSL-VPNs are used to access Webservers which are internal to a certain network, for example an enterprise or an organization.
In this way, the access is secure and authentication can be used.
When SSL-VPNs are used to access a Webserver, the HTTP datastream containing HTML, JavaScript, XML for Ajax, CSS or flash input data goes thru the SSL-VPN.
As the Webbrowser has to access the SSL-VPN over its TCP connections, and not the Webservers directly, the SSL-VPN checks the datastream and replaces links (URLs) by links to the SSL-VPN.
This is necessary, since normally the Webservers access directly from browsers in the internal network, and so the links in the Webpages point to the internal Webservers.
Now, as regards finding the links in the HTTP datastream, this is quite complicated, since links can be at different locations. There are also solutions where the link is dynamically built by the Webbrowser. This could be done, for example, by a JavaScript program. Also the JavaScript program could dynamically generate HTML pages containing additional links.
The JavaScript program runs in the browser on the client, and it may use variables which are only known to the browser, not to the SSL-VPN.
You can think of solutions where the SSL-VPN cannot find the link, and so is not able to replace the URL. This means, that these Webpages cannot be distributed over SSL-VPNs.
As this problem exists, what would be a possible solution to this problem?
A possible solution to this problem would be, that a so-called HOOK in the browser can be populated by a JavaScript function. The browser would send any URL, to which it wants to connect, over this HOOK. This HOOK could now check the URL, modify the URL if desired, or give a message-text preventing the browser from connecting to this URL but display the message-text to the user instead.
Of course, this HOOK, written in JavaScript, comes from a Webpage downloaded from the Webserver - or the SSL-VPN which sends this HOOK before sending the original Webpages from the Webserver.
These HOOKs may be nested, which would mean the browser calls several HOOKs one after the other until finally the browser uses the URL to connect to the server.
When HOOKs are nested, the one giving first should be the one which is processed as the last stage before the browser acctually makes the TCP connection.
When a JavaScript program registers a HOOK, it should get a handle in return. This handle would be needed if any JavaScript program wants to remove this instance of the HOOK later.
Modern browsers connect to a single Webserver with multiple TCP connections. There are also browsers which have tabs; each tab shows a single Webpage (made from multiple TCP connections) to the user.
So when a HOOK is set, this should be used for all TCP connections for a single browser tab.
The HOOK, which is programmed in JavaScript, has to be called by all TCP connections from the browser, i.e., from Java programs or Flash animation.
If this functionality is built into all Webbrowsers, SSL-VPNs can correctly distribute all Webpages, and SSL-VPNs would be less complicated compared to what they have to be today.
no comments | no trackbacks
