RE: [load balancing] Help in choosing an SSL accelerator.

Date: Wed Sep 04 2002 - 17:02:10 EDT

  • Next message: "RE: [load balancing] Help in choosing an SSL accelerator."


    On the Verisign site, you can download their usage agreement. In it, it states
    the following:

    "1. Use Restrictions. You are prohibited from using your SSL Certificate (i) for
    or on behalf of any other organization, (ii) to perform private or public key
    operations in connection with any domain name and/or organization name other
    than the submitted by you during enrollment, or (iii) on more than one server at
    a time."

    Now, if you are using the NetScaler to terminate SSL as the server-side end of
    an SSL connection, and there is no SSL communication to the server itself, I
    cannot see how they could argue that more than one server is doing SSL. It
    simply isn't the case. Now, if you throw back-end encryption into the mix, the
    water looks a bit murkier, but we are talking about a cut-and-dried approach
    where one server (and only one server) is actually doing SSL, the NetScaler.


    "Barrett, John" wrote:

    > According to the Verisgn web site this isn't the case.
    > "VeriSign recommends that one SSL Certificate be used to secure each
    > name on every server in a multi-server environment, and that the
    > corresponding private keys be generated from the hosting server."
    > <a
    > Do you have a reference that states otherwise? If so, can you send it
    > along?
    > Thanks
    > -John
    > -----Original Message-----
    > From: tony bourke [mailto:]
    > Sent: Wednesday, September 04, 2002 11:31 AM
    > To:
    > Subject: Re: [load balancing] Help in shoosing an SSL accelerator.
    > Hi Shawn,
    > &gt; Costs for certificates can be a huge issue. Verisign says you need a
    > &gt; certificate for every server that is doing SSL. If you have a NetScaler
    > doing
    > &gt; the SSL, you only need one certificate for each destination, regardless of
    > how
    > &gt; many servers are actually in the farm. This is not a violation of the
    > Verisign
    > &gt; agreement since you are not doing SSL all the way to the servers.
    > &gt;
    > This is incorrect: While you only need one &lt;em&gt;certificate&lt;/em&gt;
    per SSL
    > site, Verisign does require you to buy an additional license for every
    > server serving the SSL content. So if you've got a NetScaler or any other
    > SSL accelerator sitting in front of 3 servers serving up an SSL site, you
    > need 3 licenses from Verisign to be in license compliance.
    > &gt; Now, if you're doing SSL on the server side as well (it is required in
    > &gt; some environments) you would need certificates on each server, but
    > &gt; because it is behind the NetScaler, you could use privately generated
    > &gt; certificates on the servers and the Verisign certificate on the
    > &gt; externally facing NetScaler. All of this would lead to significant
    > &gt; savings on certificates.
    > &gt;
    > &gt; -Shawn
    > &gt;
    > &gt; Shawn Nunley
    > &gt; Director of Technology Development
    > &gt; NetScaler, Inc.
    > &gt;
    > Tony
    > &gt;
    > &gt; On Tue, 03 September 2002, wrote:
    > &gt;
    > &gt; &gt;
    > &gt; &gt; Alex wrote:
    > &gt; &gt;
    > &gt; &gt; &amp;gt; These two things are the biggest difference in between the
    > generation
    > &gt; &gt; &amp;gt; of SSL accelerators, and the 3rd (the first being SSL
    > cards
    > &gt; &gt; &amp;gt; directly in the servers)
    > &gt; &gt; &amp;gt;
    > &gt; &gt; &amp;gt;
    > &gt; &gt; &amp;gt; the 2nd generation accelerators are characterized by
    100-200 rsa
    > &gt; &gt; &amp;gt; handshakes per second per chip. And no bulk encryption
    > acceleration.
    > &gt; &gt; &amp;gt; Some accelerators have up to 3 chips working in unison.
    Most of
    > these
    > &gt; &gt; &amp;gt; are rainbow's chipset or sometimes a general purpose cpu
    > to
    > &gt; &gt; &amp;gt; ssl.
    > &gt; &gt; &amp;gt;
    > &gt; &gt; &amp;gt;
    > &gt; &gt; &amp;gt; I don't like to use the TPS term since TPS varies way too
    > &gt; &gt; &amp;gt; Especially in 2nd gen SSL accelerators because of the lack
    of bulk
    > &gt; &gt; &amp;gt; encryption support.
    > &gt; &gt;
    > &gt; &gt; That is so true. Most vendors use the TPS number given to them by
    > Broadcom,
    > &gt; &gt; Rainbow, nCipher or who ever is providing their core SSL
    > The
    > &gt; sad
    > &gt; &gt; fact is, in most cases, the consumer would never actually experience
    > these
    > &gt; &gt; numbers for several reasons:
    > &gt; &gt;
    > &gt; &gt; 1) Bulk encryption throttles the performance to a lower TPS value
    > &gt; &gt; 2) The vendor has never actually tested the SSL performance of their
    > system
    > &gt; &gt; 3) The SSL TPS number is based on completely unrealistic traffic
    > patterns.
    > &gt; &gt;
    > &gt; &gt; In fact, when we announced 4400 TPS with the NetScaler 9000 iON
    > our SSL
    > &gt; &gt; vendor (Broadcom) cried foul. We are using a card they had rated at
    > 4000 TPS,
    > &gt; &gt; and they admitted that even 4000 TPS was an engineering spec,
    > unrealistic for
    > &gt; &gt; real-world applications, but achievable in some special cases. We
    > taken
    > &gt; the
    > &gt; &gt; same card and shown them 4400 *real* SSL sessions per second, with a
    > full
    > &gt; &gt; response. They were impressed with the raw speed of our packet
    > which
    > &gt; &gt; enabled the SSL card to post numbers fully 10% over their own
    > specification.
    > &gt; &gt;
    > &gt; &gt; &amp;gt; With the lack of bulk encryption support it usually pegs
    the CPU at
    > 100%
    > &gt; &gt; &amp;gt; when doing 100-200 conn/sec. Since the general purpose CPU
    > to do
    > &gt; &gt; &amp;gt; the encryption for that.
    > &gt; &gt;
    > &gt; &gt; This is why most early models of SSL accelerator cards were at the
    > TPS
    > &gt; &gt; range. Because they didn't do bulk encryption, it didn't make any
    > to
    > &gt; make
    > &gt; &gt; the SSL key generation any faster, the server couldn't utilize it.
    > &gt; &gt;
    > &gt; &gt; &amp;gt; A 800mhz PIII with mod_ssl can do 150-200 conn/sec (cpu at
    > so
    > &gt; &gt; &amp;gt; it sometimes isn't necessaril worth it. (that doesn't give
    you the
    > same
    > &gt; &gt; &amp;gt; features as a SSL accelerator, as well as easy of
    > &gt; &gt; &amp;gt;
    > &gt; &gt; &amp;gt; The 3rd generation of accelerators do anywhere from
    500-2500 rsa
    > &gt; &gt; &amp;gt; handshakes per second on a single chip. Plus they do bulk
    > encryption.
    > &gt; &gt; &amp;gt; broadcom, and some custom chips do these. Same multi chip
    > &gt; &gt; &amp;gt; applies here.
    > &gt; &gt; &amp;gt;
    > &gt; &gt; &amp;gt;
    > &gt; &gt; &amp;gt; The DOS protection, compression, etc are really not
    functions of
    > the SSL
    > &gt; &gt; &amp;gt; accelerator. they are additional features but not directly
    > to
    > &gt; &gt; &amp;gt; ssl acceleration in my opinion.
    > &gt; &gt;
    > &gt; &gt; I almost agree with Alex here, but one must realize how closely they
    > &gt; &gt; related. Compression, for example, is part of the SSL spec. Hardly
    > &gt; vendors
    > &gt; &gt; implement compression in SSL because it would steal performance from
    > their TPS
    > &gt; &gt; number, just like bulk encryption. So, they make customers choose
    > between
    > &gt; &gt; security and performance.
    > &gt; &gt;
    > &gt; &gt; In today's climate, people want the added security of SSL, but they
    > won't
    > &gt; &gt; tolerate a huge dip in performance to get it (in most cases). By
    > integrating
    > &gt; &gt; features like HTTP compression, connection multiplexing, TCP
    > and
    > &gt; other
    > &gt; &gt; 'features', we are attempting to give them both security and
    > performance. In
    > &gt; my
    > &gt; &gt; humble opinion, that's what it's going to take to convince people to
    > SSL
    > &gt; for
    > &gt; &gt; ALL content, not just a few pages deemed worthy or protection.
    > &gt; &gt;
    > &gt; &gt; &amp;gt; Prices for SSL accelerators are usually not cheap. Maybe
    > it
    > &gt; &gt; &amp;gt; will be and it will be easy for any site to turn on SSL for
    > whole
    > &gt; &gt; &amp;gt; site (just because they can).
    > &gt; &gt; &amp;gt;
    > &gt; &gt; &amp;gt; -Alex
    > &gt; &gt;
    > &gt; &gt; Well, that's just happens to be exactly what we engineered our
    > for. In
    > &gt; &gt; our view, there is no good reason to deliver any part of your web
    > application
    > &gt; &gt; over unencrypted connections, and we aim to enable sites to secure
    > of
    > &gt; their
    > &gt; &gt; site with no performance impact. I would expect this to become a
    > in the
    > &gt; &gt; load balancer space.
    > &gt; &gt;
    > &gt; &gt; As a real-world example, we had one particular web-based application
    > house
    > &gt; &gt; that we were accessing over HTTP. The first NetScaler 9000 was
    > in
    > &gt; &gt; front of this application. In little more than 10 minutes, and no
    > changes to
    > &gt; &gt; the application or server, we placed the NetScaler in front of this
    > application
    > &gt; &gt; and had a 100% secured (100% SSL) site. This was 10 minutes of
    > to
    > &gt; &gt; achieve what normally requires massive site restructure and scaling.
    > And the
    > &gt; &gt; performance improved. How cool is that?
    > &gt; &gt;
    > &gt; &gt; Hopefully, this post isn't seen as a blatent commercial. I've
    > to
    > &gt; &gt; educate and not sell, but I'm sure my bias comes shining through.
    > for
    > &gt; &gt; that!
    > &gt; &gt;
    > &gt; &gt; -Shawn
    > &gt; &gt; ____________________
    > &gt; &gt; The Load Balancing Mailing List
    > &gt; &gt; Unsubscribe:
    > &gt; &gt; Archive: &lt;a
    > &gt;
    > href=&quot;<a
    > &gt; &gt; LBDigest: &lt;a
    > &gt;
    > href=&quot;<a
    > &lt;/a&gt;
    > &gt; &gt; MRTG with SLB: &lt;a
    > &gt;
    > href=&quot;<a
    > MRTG&lt;/a&gt;
    > &gt; &gt; Hosted by: &lt;a
    > &gt;
    > href=&quot;<a
    > &gt; ____________________
    > &gt; The Load Balancing Mailing List
    > &gt; Unsubscribe: mailto:
    > &gt; Archive: <a
    > &gt; LBDigest: <a
    > &gt; MRTG with SLB: <a
    > &gt; Hosted by: <a
    > &gt;
    > --
    > -------------- -- ---- ---- --- - - - - - -- - - - - - -
    > Tony Bourke
    > ____________________
    > The Load Balancing Mailing List
    > Unsubscribe:
    > Archive: <a
    > LBDigest: <a
    > MRTG with SLB: <a
    > Hosted by: <a
    > ____________________
    > The Load Balancing Mailing List
    > Unsubscribe: mailto:
    > Archive: <a
    > LBDigest: <a
    > MRTG with SLB: <a
    > Hosted by: <a
    The Load Balancing Mailing List
    Unsubscribe: mailto:
    MRTG with SLB:
    Hosted by:

    This archive was generated by hypermail 2.1.4 : Wed Sep 04 2002 - 17:05:20 EDT