> [ossl...@velox.ch - Sat Jan 09 10:25:09 2010]:
>
> Here is a more "radical" attempt at solving this problem. In private
> discussions with Peter Sylvester it became clear that the solution
> I proposed last August would only superficially address the problem.
>
> I'm therefore attaching a more comprehensive patch (against
> OpenSSL_1_0_0_stable), which includes the following modifications:
>
> - tlsext_hostname is dropped from the SSL session object (i.e.,
> the hostname is now only stored in the SSL connection object)
>
[snip]
>
> As Peter is currently busy with other things, my hope is that "someone
> else" could have a look at / comment on it (in particular someone who's
> first name starts with "S" ;-). I wouldn't consider it a "perfect"
> solution - as it still requires two passes over the TLS extensions -,
> but maybe it's still something which could make it into 1.0.0?
>
Can I pretend my name begins with a "D" ;-)
I'll look into this in more detail later, however on the face of it
there's a conflict with draft-ietf-tls-rfc4366-bis-06.txt specifically:
- If, on the other hand, the older session is resumed, then the
server MUST ignore the extensions and send a server hello
containing none of the extension types. In this case, the
functionality of these extensions negotiated during the
original session initiation is applied to the resumed session.
that refers to TLS v1.2 which we currently don't support but a similar
comment occurs in RFC3546 et al. I'm never one for blindly following
specs especially if they suggest something stupid ;-) However if the
current extensions draft includes undesirable behaviour that should be
mentioned to the ietf-tls working group.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
