KIO design problem

[Waldo Bastian]

On Sunday 01 December 2002 20:42, George Staikos wrote:
> I was investigating the problems with sourceforge and I came upon this
> behaviour:
>
> CN for the certificate on https://*.sourceforge.net is set to
> "sourceforge.net".  Why they did this, I do not know.  Anyways, the result
> is that whenever the browser tries to do an https session with
> *.sourceforge.net, this is what it looks like:
>
>
> GET / HTTP/1.1
> Host: www.sourceforge.net
>
> HTTP/1.1 302 Found
> Date: Sun, 01 Dec 2002 19:34:19 GMT
> Server: Apache/1.3.27 (Unix) PHP/4.1.2 mod_ssl/2.8.12 OpenSSL/0.9.6b
> X-Powered-By: PHP/4.1.2
> Location: https://sourceforge.net/
> Connection: close
> Transfer-Encoding: chunked
> Content-Type: text/html
>
> 0
>
> closed
>
>
>
> Mozilla immediately changes the URL to http://sourceforge.net.  However, we
> verify SSL before it gets to the slave, so no protocol information is
> known. What do we do here?  I don't like the idea of trusting a remote site
> in SSL mode before we even verify its credentials, but it seems that other
> browsers actually do so (!!).  Do we have to have a call-back here so that
> the slave can decide to postpone or cancel certificate verification?  Any
> other suggestions?

If you want to handle this like mozilla then ssl should indeed delay its 
certificate verification till it has parsed the header. From a security point 
of view I find that doubtfull behaviour. An attacker could redirect a user to 
https://scurceforge.net/index.html or a (hijacked) http://sourceforge.net 
this way without the user getting any alert.

Cheers,
Waldo
-- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com