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

From: shawnIZZATnunleys.com
Date: Wed Sep 04 2002 - 17:02:10 EDT

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

    John,

    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.

    -Shawn

    "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
    domain
    > name on every server in a multi-server environment, and that the
    > corresponding private keys be generated from the hosting server."
    >
    > <a
    href="http://mail.nunleys.com//jump/http://www.verisign.com/products/onsite/ssl/balancing.html">http://www.verisign.com/products/onsite/ssl/balancing.html>
    >
    > Do you have a reference that states otherwise? If so, can you send it
    > along?
    >
    > Thanks
    > -John
    >
    > -----Original Message-----
    > From: tony bourke [mailto:
    tonyIZZATvegan.net]
    > Sent: Wednesday, September 04, 2002 11:31 AM
    > To: lb-lIZZATvegan.net
    > 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, shawnIZZATnunleys.com wrote:
    > &gt;
    > &gt; &gt;
    > &gt; &gt; Alex wrote:
    > &gt; &gt;
    > &gt; &gt; &amp;gt; These two things are the biggest difference in between the
    2nd
    > generation
    > &gt; &gt; &amp;gt; of SSL accelerators, and the 3rd (the first being SSL
    accelerator
    > 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
    dedicated
    > 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
    much.
    > &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
    functionality.
    > 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
    series,
    > 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
    had
    > 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
    engine
    > 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
    needs
    > 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
    300
    > TPS
    > &gt; &gt; range. Because they didn't do bulk encryption, it didn't make any
    sense
    > 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
    100%).
    > 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
    integration).
    > &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
    theory
    > &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
    related
    > 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
    are
    > &gt; &gt; related. Compression, for example, is part of the SSL spec. Hardly
    any
    > &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
    buffering
    > 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
    use
    > 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
    someday
    > it
    > &gt; &gt; &amp;gt; will be and it will be easy for any site to turn on SSL for
    the
    > 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
    product
    > 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
    100%
    > of
    > &gt; their
    > &gt; &gt; site with no performance impact. I would expect this to become a
    trend
    > in the
    > &gt; &gt; load balancer space.
    > &gt; &gt;
    > &gt; &gt; As a real-world example, we had one particular web-based application
    in
    > house
    > &gt; &gt; that we were accessing over HTTP. The first NetScaler 9000 was
    deployed
    > 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
    effort
    > 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
    attempted
    > to
    > &gt; &gt; educate and not sell, but I'm sure my bias comes shining through.
    Sorry
    > for
    > &gt; &gt; that!
    > &gt; &gt;
    > &gt; &gt; -Shawn
    > &gt; &gt; ____________________
    > &gt; &gt; The Load Balancing Mailing List
    > &gt; &gt; Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    > &gt; &gt; Archive: &lt;a
    > &gt;
    > href=&quot;<a
    href="http://mail.nunleys.com//jump/http://vegan.net/lb/archive">http://vega">http://mail.nunleys.com//jump/http://vegan.net/lb/archive">http://vega>
    > n.net/lb/archive&lt;/a&gt;
    > &gt; &gt; LBDigest: &lt;a
    > &gt;
    > href=&quot;<a
    href="
    http://mail.nunleys.com//jump/http://lbdigest.com">http://lbdigest.com">http://mail.nunleys.com//jump/http://lbdigest.com">http://lbdigest.com>
    > &lt;/a&gt;
    > &gt; &gt; MRTG with SLB: &lt;a
    > &gt;
    > href=&quot;<a
    href="
    http://mail.nunleys.com//jump/http://vegan.net/MRTG">http://vegan.net">http://mail.nunleys.com//jump/http://vegan.net/MRTG">http://vegan.net>/
    > MRTG&lt;/a&gt;
    > &gt; &gt; Hosted by: &lt;a
    > &gt;
    > href=&quot;<a
    href="
    http://mail.nunleys.com//jump/http://www.tokkisystems.com">http://www">http://mail.nunleys.com//jump/http://www.tokkisystems.com">http://www>.
    > tokkisystems.com&lt;/a&gt;
    > &gt; ____________________
    > &gt; The Load Balancing Mailing List
    > &gt; Unsubscribe: mailto:
    majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    > &gt; Archive: <a
    href="http://mail.nunleys.com//jump/http://vegan.net/lb/archive">http://vegan.net/lb/archive>
    > &gt; LBDigest: <a
    href="
    http://mail.nunleys.com//jump/http://lbdigest.com">http://lbdigest.com>
    > &gt; MRTG with SLB: <a
    href="
    http://mail.nunleys.com//jump/http://vegan.net/MRTG">http://vegan.net/MRTG>
    > &gt; Hosted by: <a
    href="
    http://mail.nunleys.com//jump/http://www.tokkisystems.com">http://www.tokkisystems.com>
    > &gt;
    >
    > --
    > -------------- -- ---- ---- --- - - - - - -- - - - - - -
    > Tony Bourke
    tonyIZZATvegan.net
    >
    >
    >
    > ____________________
    > The Load Balancing Mailing List
    > Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    > Archive: <a
    href="http://mail.nunleys.com//jump/http://vegan.net/lb/archive">http://vegan.net/lb/archive>
    > LBDigest: <a
    href="
    http://mail.nunleys.com//jump/http://lbdigest.com">http://lbdigest.com>
    > MRTG with SLB: <a
    href="
    http://mail.nunleys.com//jump/http://vegan.net/MRTG">http://vegan.net/MRTG>
    > Hosted by: <a
    href="
    http://mail.nunleys.com//jump/http://www.tokkisystems.com">http://www.tokkisystems.com>
    > ____________________
    > The Load Balancing Mailing List
    > Unsubscribe: mailto:
    majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    > Archive: <a
    href="http://mail.nunleys.com//jump/http://vegan.net/lb/archive">http://vegan.net/lb/archive>
    > LBDigest: <a
    href="
    http://mail.nunleys.com//jump/http://lbdigest.com">http://lbdigest.com>
    > MRTG with SLB: <a
    href="
    http://mail.nunleys.com//jump/http://vegan.net/MRTG">http://vegan.net/MRTG>
    > Hosted by: <a
    href="
    http://mail.nunleys.com//jump/http://www.tokkisystems.com">http://www.tokkisystems.com>
    ____________________
    The Load Balancing Mailing List
    Unsubscribe: mailto:
    majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    Archive: http://vegan.net/lb/archive
    LBDigest: http://lbdigest.com
    MRTG with SLB: http://vegan.net/MRTG
    Hosted by: http://www.tokkisystems.com



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