Daniel Stenberg wrote:
> On Sat, 26 Jan 2008, Gautam Kachroo wrote:
>
>>> It seems that for a unpatched version the connection is re-used fine
>>> in the
>>> test (which means the connection is re-used when the connection is
>>> not in
>>> ssl_connection_complete yet), while the patched version refuses to
>>> reuse that
>>> connection then.
>>
>> That makes sense since test 509 changes the url in the middle of the
>> ssl connection process. The connection for the first url is never
>> fully initialized. With the check for ssl_connection_complete, that
>> connection won't be re-used. The problem is why using a new connection
>> would cause problems.
>
> Well, as far as I remember this, the whole idea behind this particular
> test case is taken from a real-life use case. The actual URL to get is
> then received in the certificate somehow, so the redirect is really
> meant and supposed to be done on the same connection. I guess the
> reason then it has reached the complete SSL connection state is that
> it gets the certificate and thus the new URL etc before the entire
> negotiation is complete!
Indeed. During the establishment of the SSL session one gets informed
about the real URL, in
most cases this would be on the same host. I don't think that this is a
real redirect or reuse, since
the initial URL was not completely used for anything (at least not on
the HTTP level).

There is a difference of having a URI with the same or a different host,
of course. The argument tthat
I used at the time was the following:

The URL is used step by step, a piec eof the protocol part, the host,
and then finally the rest.
What is does in this test is to kind of pipeline the pieces since they
are only available as
piggyback information during the ssl handshake (in the
subjectInformationAccess extension
of the certificate).

>
> The question is of course what to do about this situation. Do we stop
> allowing the method used in test 509 or do we somehow allow it and
> make sure that the re-used connection's SSL connection is continued to
> the complete state? Or is there any other alternatives?
The effect of not allowing to set an URL during the ssl callback would
have the effect that one
has to reestablish a new connection, just because one has changed:
https://my.server.foo/ or https://my.server.foo/xxx
to
https://my.server.foo/service/toto

since during the ssl handshake, the path has not been used, and is not
even related to
a connection, and the "connection part" is the same ...

>
> Either way, this gives me the feeling we won't have a solid and tested
> approach completed by tuesday so I think we can safely say that this
> fix will go in after 7.18.0 is released.
>
So be it.

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorite'; 
die Liste mit zuru"ckgerufenen Zertifikaten finden Sie da auch.