[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: kssl
From:       Dawit Alemayehu <adawit () kde ! org>
Date:       2000-09-11 18:29:38
[Download RAW message or body]

On Mon, 11 Sep 2000, George Staikos wrote:
> On Mon, 11 Sep 2000, David Faure wrote:
> 
> > >  Also some other issues I came up with...  We have to warn if the
> > >certificate doesn't verify.  We have to warn if a possible attack is in place
> > >(these are detectable by OpenSSL but I don't know if this code will make it
> > >for KDE2... this will likely be future support).  When entering SSL we could
> > >provide a link to the SSL info dialog as well, so the user can see the
> > >information right away.  Finally, if the certificate CA is unknown, we have
> > >to have a dialog saying "unknown certificate authority..." and a link to the
> > >ssl dialog once again.
> > 
> > Wow :)
> 
>   Yeah there's alot to consider with something like this.  You can't afford
> to have even 1 bug or you put most of the work to waste.  And most of the
> bugs are missing or improper checks, not crashes - often subtle or
> hidden.
> 
>   Anyhow I found a bug with the padlock icon... Hitting the back button
> doesn't update it.  We need to trigger this somehow.  The only problem is
> that the SSL information might not be available any longer.  This will
> probably have to be fixed in the info dialog and in khtml (either caching it
> or just saying that it is unavailable). HOWEVER, now that I think about it, is
> it really safe to cache SSL pages? I mean, half the reason is to encrypt the
> page so no-one can see it.  Saving it in memory or disk cache is probably
> a bad idea.  

Hmmm... good point.  There is nothing specifically about encrypted connection
and caching in the HTTP spec so it is safe to assume that it is supposed to
follow the cahing spec as defined in HTTP so it will be upto the server to send
a do not cache page.  However there are other things that need fixing like not
sending the "Referer" tag when a redirection from a secure to a non-secure page
occurs and other stuff we need to check from section 15.1.2 & 15.1.3 of RFC 2616.

> In any case, hitting the back button from a secured to an insecure page
> still leaves the secured icon in place too.

BTW, we also need a dialog here to inform the user that (s)he requested to go
to a secure page when they are in a non-secure page and vise-versa.  This is
required by the HTTP spec for security purposes (ex: redirection from a secure
page to a non-secure one...)

Regards,
Dawit A.

[prev in list] [next in list] [prev in thread] [next in thread]