RE: Idea for making SSL more efficient

["V. Poddubnyy" <vpoddubniy () mail ru>]

Hello, 

> -----Original Message-----
> From: Frank O'Dwyer [mailto:fod () littlecatZ com] 
> Sent: Sunday, July 18, 2004 4:37 AM
> To: Kurt Seifried
> Cc: Paul Johnston; webappsec () securityfocus com
> Subject: Re: Idea for making SSL more efficient
>
> 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.

Do you mean: <img src="https://myserver/mypic.jpg";
supersrc="http://myserver/mypic.jpg"; hash="agqwe54"> ? I think this will
help to revert back the traffic size, because any image will contain
additional link...

> 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.

So poor dial-up users will need to download 100 Kb image up to 2 or 3 times
(from proxy, from original server, then may be via SSL) to be sure it is
correct image? And if the page contains many images that chage often? You
will need to use standard SSL for  those images to prevent many
redownloads...

> 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.

Best regards,
 Vladimir Poddubnyy