<div dir="ltr">This seems like a bug to me:<div><br></div><div><div>        /*</div><div>         * If this ClientHello extension was unhandled and this is a</div><div>         * nonresumed connection, check whether the extension is a custom</div><div>         * TLS Extension (has a custom_srv_ext_record), and if so call the</div><div>         * callback and record the extension number so that an appropriate</div><div>         * ServerHello may be later returned.</div><div>         */</div><div>        else if (!s->hit) {</div><div>            if (custom_ext_parse(s, 1, type, data, size, al) <= 0)</div><div>                return 0;</div><div>        }</div></div><div><br></div><div>This is in t1_lib.c, in function ssl_scan_clienthello_tlsext.  It looks like the check for !s->hit will cause the server to ignore all custom extensions on resumed sessions.  At the same time, we do not have a mechanism for saving custom extension state in the session.  As a result, the server will lose all knowledge of the existence of a custom extension after resumption.  Some extensions are only needed during the initial handshake, but others set state on the connection that should persist.  Also, there seems to be no code to keep the client from sending custom extensions on resumption, so when OpenSSL talks to OpenSSL with identical custom extensions, we're sending TLS extensions on resumption which are ignored by the server.</div><div><br></div><div>I think the one-line fix is to change the "else if (!s->hit) {" to "else {".  Would you guys agree?</div><div><br></div><div>Any existing custom extensions that depend on the old behavior need to check SSL_session_reused(ssl) to disable custom TLS extensions on resumption.  On the positive side, this will reduce the current overhead caused by the client sending these extensions on resumption.</div><div><br></div><div>Thanks,</div><div>Bill</div></div>