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

Date: Wed Sep 04 2002 - 17:09:12 EDT

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


    That is true, if each sever is doing SSL. I'm trying to tell you that when you
    are load blancing servers that ARE NOT doing SSL (that is, they have a device in
    front of them that is doing the SSL, and traffic to the server from the SSL
    accelerator is *not* encrypted) you only need one certificate (per domain) on
    the SSL accelerator. This is clearly within their usage agreement.


    Daniel Peterson wrote:

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