<SCRIPT language="JavaScript1.1" SRC="http://ad.doubleclick.net/adj/idg.us.cpw.security/index;pos=top;abr=!ie;sz=728x90;tile=1;ord=13160830?"></SCRIPT><NOSCRIPT><A HREF="http://ad.doubleclick.net/jump/idg.us.cpw.security/index;pos=top;abr=!ie;sz=728x90;tile=1;ord=13160830?"><IMG SRC="http://ad.doubleclick.net/ad/idg.us.cpw.security/index;pos=top;abr=!ie;sz=728x90;tile=1;ord=13160830?" border=0 height="90" width="728"></A></NOSCRIPT>

Computerworld IDG.net
_______________ Careers CRM Data
Mgmt Development E-business ERP/Supply Chain Hardware IT Management Mobile/Wireless Networking Operating Sys ROI Security Storage Web Site Mgmt xSP

Home > Browse
Topics > Security
> Story

When Good
Security Leads to Poor Performance

A Secure Sockets Layer implementation
improves security but bogs down server response times

By MATHIAS THURMAN

MARCH 26, 2001

Content Type: Security
Manager's Journal
Source:
Computerworld

Security
Knowledge
Center
Security News
Discussions
Events
Glossary
Vendor Listing
Resource Links
White Papers
Security XML Feed
Mobile Channel
E-mail newsletters

Knowledge
Centers
Careers
CRM
Data Management
Development
E-business
ERP/Supply Chain
Hardware
IT Management
Mobile & Wireless
Networking
Operating Systems
ROI
Security
Storage
Web Site Mgmt
xSP
More topics...

Departments
QuickStudies
SharkTank
FutureWatch
Careers
Opinions/Letters
More departments...

Services
Forums
Research
QuickPolls
WhitePapers
Buyer's Guide
More services...

It's funny how even the mere whisper of the word security
causes the masses to flock to the security manager's cube. I often get
pulled into situations, meetings or projects just because security, in one
form or another, is mentioned. I probably spend about six hours per week
reviewing project plans or sitting in meetings in which I have no reason
to take part and to which I usually make no contributions.

This Week's Glossary

RC4: An algorithm used for file encryption and to provide
a secure, encrypted communications stream to and from Web sites
using the SSL protocol. RC4, which was developed in 1987 by Ronald
Rivest for RSA Security Inc. in Bedford, Mass., stands for Ron's
Code No. 4.

Secure Sockets Layer (SSL): A security protocol that
ensures privacy for the Internet communications stream between the
Web client and the server. It's designed to prevent eavesdropping,
tampering and message forgery.

LINKS

Understanding SSL is critical for security professionals. A great
resource to bookmark and read at your leisure is
"What is SSL?" on RSA Security's Web site.

The article "Fast. . . & Secure" on the Information
Security magazine Web site explains in more detail the options for
SSL acceleration and can help you decide which technology is right
for you.

Irvine, Calif.-based Rainbow Technology Inc.'s CryptoSwift accelerator cards are one approach to
accelerating SSL performance.

Intel Corp.'s NetStructure devices are a good example of the black
box approach to SSL acceleration.

One way for companies to address performance issues - SSL-related
and otherwise - may be to outsource them to a managed service
provider like Coradiant.

So I wasn't surprised when I was recently invited to a brainstorming
session on performance issues. I've also been volunteered to be part of
the "performance improvement task team." You might ask: What does
performance have to do with security? Well, quite a bit in this case. Our
application is Web-based. In order to provide transport-level security, we
enable Secure Sockets Layer (SSL) for our customers, to give them - and
ourselves - the added benefit of encryption.

For those who don't know, SSL is best identified by the little gold
lock symbol that appears when you go to a Web site that has "https"
instead of "http" in its Web address. I won't go into the details of the
SSL protocol, but it's important to know that there are two major aspects
of SSL that affect performance.

Do the Math

The first and more taxing aspect is the initial key-generation process.
Every time a browser makes an https request for a page, the server that
the user is connecting to generates a digital key. Generating this key is
a computationally intensive operation.

These mathematical computations take up CPU cycles and are the major
cause of performance degradation in SSL-enabled Web sites. Now, depending
on how the Web site has been designed, the client browser might have to
connect to the Web server many times just to display a single page. Each
time the browser makes that additional https request, the server must
generate a new encryption key, further degrading performance.

The second major issue regarding SSL is bulk encryption. This is the
technology responsible for encrypting the data stream in transit between
the client Web browser and the remote Web server. The key generation,
which I previously mentioned, only authenticates the session. It doesn't
encrypt the data that goes back and forth over the public Internet.

Most Web servers use the RC4 algorithm for bulk encryption. This
algorithm is the other aspect of SSL that can affect performance. However,
RC4 bulk encryption isn't what's causing the problem on our servers. It's
the initial key generation.

Unfortunately, our Web-based application is complex: A client Web
browser must contact our server up to 40 times just to display one page.
And for every one of those 40 connections, our system must generate a new
encryption key. Multiply that by hundreds of customers accessing our
Web-based application, and you can imagine the problem we're facing.

During normal, nonencrypted sessions, it takes about 5 seconds to load
a customer's customized home page for our application. That's not so bad,
considering all the data that's specific to our customer is right on the
main page.

But once the SSL encryption is enabled, that 5-second wait jumps to
almost 40 seconds. And that's just the average time. Add to that latency
issues related to dial-up connections and the wait could be prolonged to
as much as 90 seconds. That's unacceptable. Heck, when I'm surfing the
Web, if a page doesn't load in less than 5 seconds, I hit the Stop button
and try another link.

There are two major issues related to the encryption key generation
process each time the browser connects to our Web server. The first issue
is the processing needed to generate the initial key. The second issue is
the generation of the subsequent keys for every https connection to our
site.

Since it's the processor utilization that's in question, I thought it
would be nice to be able to off-load the computationally intensive stuff
to another server or processor.

Well, guess what? This technology is available in two flavors. The
first is a plug-in card that installs into the Web server and is
responsible for off-loading SSL encryption. The card has special
processors designed exclusively for processing the calculations needed for
encryption key generation.

The other option is a stand-alone black box that sits between the Web
server and the border router or firewall and handles SSL processing tasks.

Although the devices are different, the concept is basically the same:
off-load the SSL encryption to another device to free valuable Web server
CPU cycles for other duties. One system requires a card to be installed
and maintained in each server; the other consists of a piece of equipment
that could become a single point of failure if you don't have a second
unit as a hot standby. There are pros and cons for each approach, and I
have to make the decision.

Generational Issues

Now to the next issue: the overhead of having to regenerate keys for
each of the user's subsequent https requests to our site.

What if there was a way to identify the user so that, for every
subsequent request, I didn't have to generate an additional key for the
connection? In other words, I want to use the same key for the entire
session. Guess what? That can also be done.

Most versions of Web server software have "session reuse" or "SSL
session caching" ability. With this setting, after the initial key
generation occurs, the Web server keeps track of the session by using a
session identifier. The Web server watches, and if subsequent requests
contain the same session identifier, it uses the same key.

There are other aspects of performance that need addressing, too -
decreasing the size of the Web page, decreasing the amount of hits it
takes to render a Web page, load balancing and, of course, content caching
- but those are beyond my scope and responsibility as a security manager.

So with all these technologies, how is a small company supposed to
manage this specialized infrastructure? Well, we could hire a few
engineers who have experience in load balancing, caching, SSL acceleration
and all the other performance-enhancing technologies.

Or we could outsource the configuration and ongoing operational aspects
to a third party such as Boston-based managed service provider (MSP)
Coradiant Inc. Such MSPs have many data centers throughout the U.S. They
perform the setup, administration and ongoing maintenance of all the areas
dealing with scalability and performance and would let us focus on our
core business. It's an option we just might consider in tackling this
monster called performance.

Source:
Computerworld

Page Utilities

Send feedback to editor
Printer friendly version
E-mail this article
Request reprints of this
article

Security
Knowledge Center

• Security
Under the Gun, Monday - Jun. 03, 04:56
pm

Sponsored Links

Free trial:   HP server management software!

Find & Fix Network Vulnerabilities...   FAST. Free trial of Retina Network Security Scanner.

Prove the Business Value of IT!   Attend
Computerworld’s Premier 100 IT Leaders Conference, Feb 23-25 in
Scottsdale!

Free
Trial   The Advisory
Counsil, practical peer advice for solving IT problems

Learn how to receive a Cisco router valued at
$3,500

News  Latest News  Week in
Review  E-mail
Newsletters  Special
Coverage  This Week in
Print  Corrections

Technology
QuickStudies
Emerging
Technologies  Future
Watch  Reviews
Field
Reports  Security
Manager
Management
Book
Reviews  Case
Studies  Managing
ROI
Q&As

Careers
Career
Adviser  Education
Salary/Skills
Surveys  Best
Places  Workstyles
Search/Post
Jobs
Opinions  Editorial
Columns  Letters
to the Editor  Shark
Tank  QuickPoll
Center
Events
Premier 100 IT
Leaders  Storage Networking
World  Computerworld
Honors Program  Mobile &
Wireless World
Services
Forums  Buyer's
Guide  Research
White
Papers  Media
Kit  Subscriptions  Reprints

About Us Contacts Editorial Calendar Help Desk Advertise Privacy Policy

<SCRIPT language="JavaScript1.1" SRC="http://ad.doubleclick.net/adj/idg.us.cpw.security/index;pos=bottom;abr=!ie;sz=468x60;tile=5;ord=13160830?"></SCRIPT><NOSCRIPT><A HREF="http://ad.doubleclick.net/jump/idg.us.cpw.security/index;pos=bottom;abr=!ie;sz=468x60;tile=5;ord=13160830?"><IMG SRC="http://ad.doubleclick.net/ad/idg.us.cpw.security/index;pos=bottom;abr=!ie;sz=468x60;tile=5;ord=13160830?" border=0 height="60" width="468"></A></NOSCRIPT>

Copyright © 2003 Computerworld Inc. All rights reserved.
Reproduction in whole or in part in any form or medium without express written
permission of Computerworld Inc. is prohibited. Computerworld and
Computerworld.com and the respective logos are trademarks of International
Data Group Inc.