![]() |
||||||||||||||
| Article Index - Product Contact Details | ||||||||||||||
|
||||||||||||||
|
||||||||||||||
|
FOR Installation and configuration is easy. AGAINST Nothing. VERDICT A highly scalable solution to the problem of processing large numbers of requests for secure web server connections. The growing demand for secure connections to web servers has led to a huge growth in secure socket layer (SSL) traffic. Because it uses public-key cryptography, negotiating an SSL connection requires a lot of resources to perform the exchange of session keys - a process that is usually called the SSL handshake. This can place a heavy load on your valuable web servers and lead to large web server farms being necessary. The Ingrian i100 is designed to solve this problem by taking care of the SSL negotiation itself and thus offloading that task from the web server - it can perform 740 SSL handshakes per second. The i100 is housed in a 1U rack-mountable chassis and has 40Gb of disk storage and 1Gb RAM. This storage is used for caching web content, logs and keeping track of up to 16,000 concurrent SSL connections and their associated session keys. The front panel has nine LED status lamps, the on-off switch, and a serial configuration port. On the rear panel there are two 10/100Mbits/sec Ethernet interfaces, and these may be used to connect the i100 in two possible ways. The first method is to connect the i100, typically between two load-balancers, so that all web traffic flows through it. Alternatively, it may be connected to a load-balancer that is configured to direct only SSL traffic through the i100. Multiple i100s may be stacked in conjunction with load-balancers to increase throughput and provide redundancy. When extra i100s are added, it is simple to replicate certificates and configuration from an existing unit, so scalability is easily achieved. Some sites require that no clear text is transmitted even on their internal networks, and this is supported by the i100, which can optionally communicate with the back-end web servers using SSL. Even in this case the i100 offers an advantage because the web servers still offload the processor-intensive SSL handshakes with users' web browsers to the i100. Meanwhile the users' SSL traffic travels via a resumed previously negotiated SSL session between the i100 and the web server. However, in this scenario, the web servers still have to encrypt all outgoing traffic and so the benefits are not as great as when clear text is allowed on internal networks. The i100 caches SSL sessions so that they can be easily resumed, but it also times them out after two hours to avoid the risk of using the same session key for too long. Using the i100 to front-end all SSL connections means that the back-end web servers see only SSL connections coming from the i100. Therefore, the web server does not know the IP address of the requesting web browser. In some applications, this information is important, so the i100 adds an additional http header containing the IP address of the client web browser. There is much more to the i100 than just SSL acceleration. It also manages secure connections. For example, when it tries to establish a secure connection, a web browser sends a list of supported encryption algorithms or ciphers, as the SSL standard allows several different implementations. The i100 enables a security administrator to specify the order in which the ciphers are selected and to disallow certain ciphers that he or she deems to be insufficiently secure. It's not just secure http traffic that benefits, the i100 can accelerate any protocol over SSL. This includes IMAP and POP mail protocols. The i100 can also act as a certificate authority (CA) for public key infrastructure (PKI). Every secure web site must have a site certificate to allow authenticated SSL connections to the outside world. When using the i100, it is not necessary to use a public CA, such as VeriSign, to issue certificates for each web server, as it can provide certificate management even for multiple web sites. When setting up an SSL connection to a back-end web server, the i100 behaves like a web browser. So the back-end web server must present a certificate to authenticate itself to the i100. The i100 can issue such certificates, so it is not necessary to use a public CA to do this. However, a public CA must still be used to authenticate the i100 gateway to the outside world but this costs less than obtaining certificates for every web server. Another feature is caching of all secure static content, such as banners, buttons and navigation frames. This relieves the back-end web server of the task of delivering this static content every time it is requested. If the back-end server does not deliver an http Expires header, the i100 uses a heuristic method based on the http Last-Modified header to determine how long to cache the object. Caching is highly configurable, so that administrators can override the caching policy indicated by the back-end web server if they believe that policy to be incorrect. The i100 maintains extensive logs. The Activity Log provides the information needed for performance tuning and analyzing any errors. An Audit Log is necessary in any security device and, with the i100, this log records details of all connections and also administrator activity. It can be most useful in identifying the source of any hacking or denial-of-service attacks, and analyzing what an attacker actually did. The i100 manages its own backups, which must themselves be protected by keys and encryption because they may contain sensitive information such as user accounts and certificates. Backups may also be used to replicate user accounts, certificates and an i100's configuration to another i100. The i100's administration interface is
available to a dumb terminal emulator or via the easy-to-use web browser
interface. Configuration is easy and straightforward, and the management of
a number of i100s is simple and quick. Web site performance is enhanced
greatly, not only for SSL transactions but, if desired, also for all http
traffic because of the caching. The i100 can reduce the number of real
back-end web servers required dramatically and save its own cost many times
over. Additional cost savings come in the form of reduced management time
required to administer fewer actual web servers. |
||||||||||||||
|
||||||||||||||
|
SC On-Line |
||||||||||||||
| Copyright © 2001 West Coast Publishing. All rights reserved. |