Anne & Lynn Wheeler writes:

> subset ... was based on computational load caused by SSL cryptography ....
> in the online merchant scenario, it cut thruput by 90-95%; alternative to
> handle the online merchant scenario for total user interaction would have
> required increasing the number of servers by factor of 10-20.

When was this *ever* true? Seriously.

N-tier applications are I/O-bound in at least N ways. Common development
practice leads to excessive message sizes in most of the N tiers. Rare is
the web site with a low N and small message sizes. Fire up your HTTP proxy
and/or packet sniffer and compare Google to, well, just about everyone else.

Now that your packet sniffer and/or proxy is started up, it is also a fun
drinking game to play Spot The SSL Server Misconfiguration. When you see
HTTP persistence turned off, take a shot. When you see TLS session
resumption turned off or sessions destroyed after a short period of time,
take a shot. When you see a new TLS session for each new HTTP request, take
three shots (in addition to the shot you probably took when noticing HTTP
persistence turned off, because let's face it probably was). If the
misconfiguration is at a CDN, take three shots and smash your face with a
frying pan.

The game is usually played with Jaegermeister, but if you are testing a bank
site, you can afford good scotch. The adjudicating committee rarely
disqualifies a contestant on the basis of liquor, although I'd still advise
against the use of vodka.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to