Hardware SSL vs. SSL Software - Network Security Hardware The Network Security Hardware Difference Hardware SSL Products Network Security News Network Security Hardware Resources Network Security Partners Harware SSL Products Support About our Network Security Hardware Solution
Hardware SSL vs. SSL Software - Network Security Hardware CONTACT US | SITE MAP
Britestream Network Security Hardware. Secure. Scalable. Simple
HOME :: THE BRITESTREAM DIFFERENCE :: Competing Methods
The SSL Challenge
Britestream: Architecture
Redefined
Competing Methods
A New Metric

Network Security Hardware Related Resources
Hardware SSL Solution Overview

Competing Network Security Methods

SSL Software 

The dominant method for network security today is software running on general-purpose servers. And while SSL software is easy to deploy, it comes with a number of drawbacks:

It cripples performance. Processing the complex encryption algorithms associated with security presents a heavy load to general-purpose computing SSL software platforms, which are notorious for crippling web server performance. In fact, it is quite common to see degradation in performance of two orders of magnitude when using SSL software.

It is unpredictable. Because throughput varies with the overall system load, the heavier the usage, the worse the results. So it’s impossible to set performance expectations.

It is difficult to maintain. When vulnerabilities in SSL software are found, quite often the solution is an update to the OS via a patch. Once the patch has been applied, the application has to be rebuilt—and there’s still no guarantee it will work. This dramatically increases costs—in management, maintenance, and ongoing support.

Hardware SSL Accelerators

Hardware SSL Accelerators (cryptographic coprocessors) are semiconductors designed to perform various encryption/decryption network security functions and support popular cryptographic algorithms such as RSA (Rivest Shamir Adelman) or RC4 (Rivest Cipher 4).

Using hardware SSL accelerators to achieve network security requires a dedicated host processor (CPU) to feed the coprocessor with cryptographic vectors to calculate.
At high data rates, this becomes a huge task.

And, while the makers of cryptographic coprocessors have increased performance in an attempt to keep pace with the growth in SSL applications and network bandwidth, the basic philosophy of hardware SSL accelerators (a dedicated microprocessor feeding cryptographic vectors) increases system complexity and introduces serious hurdles for achieving true instream processing.

There are three key problems that today’s system designer has to overcome in using the coprocessor approach to handle gigabit SSL traffic:

  • The bottleneck created by transferring data across a shared bus

  • The amount of TCP/IP and SSL protocol processing the host microprocessor has to perform

  • The integration of coprocessors with the OS.

Shared Bus

Most cryptographic coprocessors use a shared bus to communicate with a host microprocessor. This approach leads to a complex network security system design, both in the number of components needed and the way data flows are coordinated. As the series of arrows in the image below illustrate, memory and other peripherals share the same bus with the host microprocessor and coprocessor, which results in a huge number of data transfers and creates a serious performance bottleneck. For example, a single computation by the coprocessor requires multiple data transfers across the bus, which reduces the effective bus bandwidth and increases latency.

Coprocessor Bottleneck - Hardware SSL vs. SSL Software


Accelerated SSL Processing

The chief drawback of using cryptographic coprocessors for network security is their emphasis on accelerating SSL processing—at the expense of much-needed CPU cycles. The job of terminating and processing SSL connections involves considerably more than just cryptographic acceleration. The other tasks required to completely process SSL traffic include:

  • SSL record handling

  • SSL messaging, handshaking and error processing

  • Secure processing and storage of sensitive cryptographic information such as private RSA keys

  • TCP/IP packet processing

TCP/IP Processing

Wire speed TCP/IP packet processing is particularly onerous. This processing is required to identify secure traffic, terminate the TCP connection with SSL clients and strip off the TCP/IP headers in order to extract the SSL record information. Typically, TCP/IP processing is performed in a network security software stack running on a popular OS or an embedded RTOS. It is not uncommon for TCP/IP processing to consume up to 50% of a web server’s resources.

When combined, all of these factors consume significant CPU cycles and bus bandwidth making a bad situation even worse.

Coprocessor Integration

Coprocessors are extremely difficult to integrate into an application: They need to be programmed using network security software development kits, APIs, and drivers in order to be properly integrated into the larger operating system.

This consumes valuable time and resources, leaving designers with an unenviable integration effort that takes months to complete, comes with no assurance of predictability —and offers a 100% guarantee that it will consume enormous amounts of CPU cycles.

Network Security Hardware

Britestream's award-winning  network security hardware provides a secure, scalable and simple hardware SSL solution to processing SSL-encrypted network traffic. From web and application servers to load balancers, firewalls, and fast-growing emerging applications such as SSL VPNs, XML/Web Services, and secure e-mail gateways, Britestream's network security hardware removes the barriers and penalties to deploying-and ensuring-data privacy. Britestream Network's network security hardware is a breakthrough solution for the growing challenge of network security and regulatory compliance.