[openssl-dev] Possible bug in extended master secret resumption logic

[Bill Cox]

I work on Token Binding/ChannelID, which is why I'm diving into OpenSSL
code recently, and the extended master secret code specifically.  Adam
Langley pointed out some fishy code  to me, which I've just had time to
analyze.  Here's some code in t1_lib.c, function
ssl_add_serverhello_tlsext, at line 1724:

    if (!s->hit && s->session->flags & SSL_SESS_FLAG_EXTMS) {
        s2n(TLSEXT_TYPE_extended_master_secret, ret);
        s2n(0, ret);
    }

Adam thought the check for !s->hit should be removed, IIRC.  It looks like
this check will cause the EXTMS TLS extension to never be sent by the
server in a session-resumption handshake.  This violates the latest EXTMS
spec <https://tools.ietf.org/html/draft-ietf-tls-session-hash-05#page-7>:

"If the ClientHello contains the extension and the server decides to accept
the abbreviated handshake, then the server MUST include the
"extended_master_secret" extension in its ServerHello message."

In this case, I think the client should assume the server resuming the
session is not EXTMS capable, while the original server was.  This might
occur in some cases, when data-centers are transitioning, for example.  I
think the client should abort the handshake and try again with a new
session.  It seems to me that clients behaing this way might result in a
lot of session resumptions failing.  Am I reading this correctly?

Thanks,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150617/8edeea60/attachment.html>