At 12:09 PM 3/25/2003 -0800, bear wrote:
ISP's don't want to support encrypted links
because it raises their CPU costs.  And mail
clients generally aren't intelligently designed
to handle encrypted email which the mail servers
could just "pass through without decrypting and
encrypting".



circa '95 .... there were comments that ISP's didn't want to verify from/spoofed packet addresses on DHCP modem connections because it increased their router cpu costs (actually one of the most common routers didn't have enuf processor power to implement even trivial packet filtering on modem lines).

http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement


now there is the observation in this thread (or the previous thread) that many websites use SSL very sparingly because it cuts their web traffic capacity by 80-90 percent (http vis-a-vis https given the same hardware).

Typical sequence is that person clicks-on/types something and goes to a site with straight HTTP, they shop for a while ... until they are ready to check-out, they then click on the "check-out" button. That button supplies a URL that sends them off to a HTTPS site (aka the user didn't actually originated the HTTPS url) ... where all the payment information is provided. Now since the client/consumer never provided the actual HTTPS sequence .... but it was provided for them by a webpage at the HTTP site they were shopping at .... it is presumably trivial for the HTTP site that they are shopping at to make sure that the HTTPS URL domain that clients are sent to .... matches the certificate domain at that site (and a lot of shopping URLs have a lot of appended history so that it is relatively easily contrived that the consumer doesn't notice the domain name of the "check-out/payment" page).

A lot of the requirement for encryption is end-to-end ... or at least VPN-like .... so encrypted packets should mostly be transparent to operations in their ISP roles. This isn't as true on the web-hosting side of the house ... where SSL or similar encryption activity can represent significant additional CPU processing load.
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm



--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to