From: Daniel Peterson (pdiddy_saIZZATyahoo.com)
Date: Wed Sep 04 2002 - 16:02:22 EDT
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
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:
> > >
> > > > These two things are the biggest difference
> in between the 2nd
> generation
> > > > of SSL accelerators, and the 3rd (the first
> being SSL accelerator
> cards
> > > > directly in the servers)
> > > >
> > > >
> > > > the 2nd generation accelerators are
> characterized by 100-200 rsa
> > > > handshakes per second per chip. And no
> bulk encryption
> acceleration.
> > > > Some accelerators have up to 3 chips
> working in unison. Most of
> these
> > > > are rainbow's chipset or sometimes a
> general purpose cpu dedicated
> to
> > > > ssl.
> > > >
> > > >
> > > > I don't like to use the TPS term since TPS
> varies way too much.
> > > > Especially in 2nd gen SSL accelerators
> because of the lack of bulk
> > > > 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.
> > >
> > > > With the lack of bulk encryption support it
> usually pegs the CPU at
> 100%
> > > > when doing 100-200 conn/sec. Since the
> general purpose CPU needs
> to do
> > > > 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.
> > >
> > > > A 800mhz PIII with mod_ssl can do 150-200
> conn/sec (cpu at 100%).
> so
> > > > it sometimes isn't necessaril worth it.
> (that doesn't give you the
> same
> > > > features as a SSL accelerator, as well as
> easy of integration).
> > > >
> > > > The 3rd generation of accelerators do
> anywhere from 500-2500 rsa
> > > > handshakes per second on a single chip.
> Plus they do bulk
> encryption.
> > > > broadcom, and some custom chips do these.
> Same multi chip theory
> > > > applies here.
> > > >
> > > >
> > > > The DOS protection, compression, etc are
> really not functions of
> the SSL
> > > > accelerator. they are additional features
> but not directly related
> to
> > > > 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.
> > >
> > > > Prices for SSL accelerators are usually not
> cheap. Maybe someday
> it
> > > > will be and it will be easy for any site to
> turn on SSL for the
> whole
> > > > site (just because they can).
> > > >
> > > > -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