Re: Idea for making SSL more efficient

["Frank O'Dwyer" <fod () littlecatZ com>]

There seems to be a couple misconceptions running through some of the 
responses here:

1. That SSL's only performance issue is compute time. It isn't (plus the 
proposal seems unlikely to help much with that anyway). It also 
increases network latency, it expands traffic (although not that much if 
you discount the handshake), and it prevents (proxy) caching. The 
proposal would help with the caching, and might help with the expansion, 
whereas an SSL accelerator card wouldn't help with either.

2. That you have to modify *every* browser if anything is added to the 
HTML. You don't. The history of the web is full of stuff added to HTML 
(javascript, CSS, frames, images, plugins, applets, generator markup, 
forms, MS Office XML, etc), and even to HTTP, and at no time have all 
browsers understood all of the new protocol at once. Instead most of 
these changes have been made to be backward compatible. So far from 
"never happen", it's (a) already happened umpteen times, and (b) no sign 
it will stop happening any time soon.

In this particular case, even if only one browser was modified, that 
browser's user should benefit (less traffic). If a significant 
proportion of browsers were modified, then servers & networks should 
start to see some benefits (less traffic). Plus if done right, 
unmodified browsers could be made see a standard SSL link, so a site 
using this approach could work with those too, and still deliver SSL 
level integrity. A good place to start might be a mozilla/firefox 
extension, plus an apache module to do this (or just run a script on 
some static content), experiment and see how it goes in practice.

As for the remark about proxies, not only does the scheme not seem to 
require "HUGE" changes to proxies, it doesn't seem to require any 
changes to proxies at all (though it could benefit from them) - hardly 
surprising since a major motivation for it is to be able to make use of 
standard caching proxies(*).  I'm curious as to what changes you think 
are needed.

Cheers,
Frank.

(*) There is a potential for a false alarm, which would need some extra 
checking to avoid - this could arise if the image had changed on the 
server but the proxy held onto an old version. The browser would get the 
latest page, via SSL, and the old image, from the proxy cache - and the 
hashes wouldn't match up - the browser would then need to retry the 
image without caching and recompute the hash before it raised the alarm. 
Still no change to the proxy though, and not a big deal for images that 
rarely change, nor for caches which update correctly.

Kurt Seifried wrote:

> Highly flawed, requires HUGE changes to proxy software, and to client
> software, which will never happen, even assuming it does there's still
> several potential avenues of attack. My advice: buy an SSL accelerator like
> everyone else does, you can get them as cheap as 100$ or so now for a PCI
> card.
>
>
> Kurt Seifried, kurt () seifried org
> A15B BEE5 B391 B9AD B0EF
> AEB0 AD63 0B4E AD56 E574
> http://seifried.org/security/
>
> ----- Original Message ----- 
> From: "Paul Johnston" <paul () westpoint ltd uk>
> To: <webappsec () securityfocus com>
> Sent: Thursday, July 15, 2004 2:12 AM
> Subject: Idea for making SSL more efficient
>
>
>  
>
> > Hi,
> >
> > A disadvantage with SSL is that it places increased load on the server,
> > in particular because client's ISP caches cannot be used. In most
> > situations the images on an SSL site are not confidential. If they are
> > included as HTTP links then the browser will display a "mixture of
> > secure and insecure content" warning. That is sensible, because an
> > attacker could potentially manipulate the images to deceive the user.
> >
> > My idea is to include a MD5 hash of the image in the img tag, so in an
> > https page you could do <img src="http://x.y.z/a.png"; md5="xyz789"/> to
> > reference an HTTP image. Images protected by these integrity checks
> > would then not cause a browser warning.
> >
> > I expect roll-out would not be easy, and also there may be concerns
> > about infering what is on the SSL page from what images are requested
> > (e.g. whether "overdrawn.png" gets requested).
> >
> > Anyone got thoughts on this?
> >
> > Paul
> >
> > --
> > Paul Johnston
> > Internet Security Specialist
> > Westpoint Limited
> > Albion Wharf, 19 Albion Street,
> > Manchester, M1 5LN
> > England
> > Tel: +44 (0)161 237 1028
> > Fax: +44 (0)161 237 1031
> > email: paul () westpoint ltd uk
> > web: www.westpoint.ltd.uk
> >
> >
> >    
>
>
>  


--
Frank O'Dwyer      <fod () littlecatZ com>
Little cat Z       http://www.littlecatZ.com/

This message is intended only for the use of the addressee and may contain information that is privileged, confidential 
and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the 
employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any 
dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail 
in error, please notify us immediately by return e-mail and delete this e-mail and all attachments from your system.