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.

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 aa 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

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine