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

From: Daniel Peterson (pdiddy_saIZZATyahoo.com)
Date: Wed Sep 04 2002 - 16:02:22 EDT

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

    Unfortunately CAs got greedy and want a certificate
    purchased per server.

    I got a link from www.thawte.com which seconds what
    verisign was stating. The shocker was that the
    knowledgebase for thawte went to
    http://kb.verisign.com. I must have missed that
    buyout.

    Here is a link

    http://kb.verisign.com/esupport/esupport/thawte/esupport.asp?selected=solutionlist&user=&strCurrentSymptom=&strDisplaySymptom=

    Enter VS2101 for the solution ID.

    Greed, but business is business and monopoies are
    monopolies.

    Dan

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

    __________________________________________________
    Do You Yahoo!?
    Yahoo! Finance - Get real-time stock quotes
    http://finance.yahoo.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 - 16:05:52 EDT