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

From: Barrett, John (John.BarrettIZZATFMR.COM)
Date: Thu Sep 05 2002 - 08:01:17 EDT

  • Next message: Edgard Castro: "[load balancing] Alteon WebOS10 OID for Bandwidth"

    I agree with Shawn, the server technically is the SSL
    terminator/accelerator, as this is the point of encryption and handshake. I
    totally agree that one should not use one certificate for the entire site.
    In our case we have several hundred URLs that are protected by SSL each with
    it's own certificate. The question around here is cost savings, if we only
    need to purchase 1 certificate per SSL that brings our cost down
    significantly (as we load balance over several servers). In these cost
    cutting days, every little bit helps.

    -John

    -----Original Message-----
    From: Shawn Nunley [mailto:shawnIZZATnunleys.com]
    Sent: Thursday, September 05, 2002 2:53 AM
    To: lb-lIZZATvegan.net
    Subject: RE: [load balancing] Help in choosing an SSL accelerator.

    Tony,

    I will agree that Verisign was attempting, for good reason, to legislate
    the proper usage of their certificates. Technically, it's very easy to
    use the cert on all of your servers in a load balanced farm, thereby
    violating the usage agreement. I think they did the right thing by
    amending their agreement to make it clear this was wrong.

    This *is not* what we are discussing.

    We are discussing the use of the one certificate at one point, the SSL
    accelerator. This provides protection to the parties on each end of the
    SSL connection enabled by that certificate. If I choose to utilize that
    protection on what I consider the 'wild' part of the net, and use my own
    security measures (more physical than cryptographic) within my web farm,
    that's my choice. Verisign is not providing any value to me on the
    portion of the network where I don't make any use of their product. If
    I have 1 or 100 servers, it should not cost me more for my one
    certificate, using their current pricing model.

    The real problem here for Verisign is the pricing model. Today, it's
    based on per-server. With hardware becoming faster and faster, they are
    getting less revenue per transaction. I'm sure they'll change the model
    when SSL cards start regularly pumping out 10,000 TPS like they should
    before mid-2003, maybe earlier.

    Of course, these are just my opinions and I'm usually wrong.

    -Shawn

    -----Original Message-----
    From: owner-lb-lIZZATvegan.net [mailto:owner-lb-lIZZATvegan.net] On Behalf Of
    tony bourke
    Sent: Wednesday, September 04, 2002 12:42 PM
    To: 'lb-lIZZATvegan.net'
    Subject: RE: [load balancing] Help in choosing an SSL accelerator.

    Hi John,

    My references come directly from talking to several people at Verisign,
    and if you take a look at their license:

    http://www.verisign.com/repository/agreements/secureSite.html

    "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
    (unless you have purchased the Shared Hosting Security Service). You are

    also prohibited from using your SSL Certificate on more than one server
    at
    a time (unless you have purchased the SPECIFIC licensing option on the
    enrollment screen that permits the use of a SSL Certificate on multiple
    servers). If you choose to display VeriSign's Secure Site Seal (the
    "Seal"), you must install and display such Seal only in accordance with
    the Secure Site Seal Licensing Agreement
    (https://www.verisign.com/repository/sslicense_agree.html) ("Secure Site

    Seal Licensing Agreement")."

    Many people were mistakingly under the impression that the Verisign cert

    covered the entire site, and didn't need to have additional licenses per

    machine (this was discussed several months back on this list).

    While you don't technically need to have more than one cert for a site
    when running on multiple servers, that is what the license agreement
    says (that you need to purchase additional licenses). I'm not sure what
    Verisign's position is on enforcement, but that's what the license says.

    Tony

    On Wed, 4 Sep 2002, 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."
    >
    > 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://lbdige
    > st.com
    > </a>
    > > > MRTG with SLB: <a
    > >
    > href="http://mail.nunleys.com//jump/http://vegan.net/MRTG">http://vega
    > n.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 ____________________ 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 : Thu Sep 05 2002 - 08:06:49 EDT