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