>> else" could have a look at / comment on it (in particular someone >> who's
Correcting myself (to keep English grammar straight): s/who's/whose/, actually > 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: Hmm, interesting. Thanks for pointing this out - apparently this text was only added in the latest revision of that I-D (published on 26 October 2009)... as a consequence of the AD review comments here, I assume: http://www.ietf.org/mail-archive/web/tls/current/msg03720.html. > 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. I think it's good to see that draft-ietf-tls-rfc4366-bis-06 is now really explicit about this point. If we follow this rule (and I don't have specific arguments against it), then the current OpenSSL code is probably already correct, indeed. It also means that a client should not attempt session resumption for the case I originally described in this ticket (note that future NSS-based versions of Chrome/Chromium will no longer trigger this issue with mod_ssl anyway, cf. http://code.google.com/p/chromium/issues/detail?id=28732). One smaller issue remains, nevertheless: when working on the patch, I noticed that ssl_parse_clienthello_tlsext() currently chokes on an SNI extension with more than one hostname - and aborts with a (fatal) decode_error alert. I wonder if that's really the most appropriate way of handling this case (for decode_error, RFC 5246 says "This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network)". Should we change it to send an unrecognized_name alert instead (or simply ignore the additional names, as I'm proposing in the previously attached patch)? Kaspar ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
