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 majord...@metzdowd.com
