[openssl-dev] DTLS session resumption with DTLS_ANY_VERSION

[Matt Caswell]

On 13/05/16 18:33, Rajeswari K wrote:
> Hi Matt,
> 
> Thanks for the response. 
> 
> But, this fix doesn't perform session resumption. 

Did you try the patch?

As you pointed out we hit the following line:

        if (i == 1 && s->version == s->session->ssl_version) { /* previous
                                                                * session */

The version from the SSL object and the version from the session do not
match and that is why session resumption does not take place.

The reason that the versions do not match is because version negotiation
takes place *after* this check. So at this point s->version equals
DTLS_ANY_VERSION. My patch moves the version negotiation to before the
above test so that s->version should now be equal to DTLSv1, and
therefore should be the same as in s->session->ssl_version, and session
resumption should be successful.

Matt



> 
> Thanks,
> Rajeswari.
> 
> On Wed, May 11, 2016 at 2:56 PM, Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 10/05/16 18:34, Rajeswari K wrote:
>     > Hello openssl-dev team,
>     >
>     > Having query regarding DTLS session resumption when configured SSL_CTX
>     > with DTLS_ANY_VERSION.
>     >
>     > When we select SSL_CTX with DTLS_ANY_VERSION, method will be of
>     > DTLS_Server_method(), which will have ssl_ctx->version as 0xFEFD to
>     > support both the versions (i.e. DTLS1.0 and DTLS1.2).
>     >
>     > During handshake, we landed on to version DTLS1.0.i.e.
>     > s->session->version holds 0xFEFF.
>     >
>     > In order to perform session resumption, we derived new SSL structure
>     > from global ssl_ctx using SSL_new() and tried performing ssl
>     handshake.
>     >
>     > With the below logic,
>     > else {
>     >         i = ssl_get_prev_session(s, p, j, d + n);
>     >         /*
>     >          * Only resume if the session's version matches the negotiated
>     >          * version.
>     >          * RFC 5246 does not provide much useful advice on resumption
>     >          * with a different protocol version. It doesn't forbid it but
>     >          * the sanity of such behaviour would be questionable.
>     >          * In practice, clients do not accept a version mismatch and
>     >          * will abort the handshake with an error.
>     >          */
>     >         if (i == 1 && s->version == s->session->ssl_version) { /*
>     previous
>     >                                                                 *
>     session */
>     >             s->hit = 1;
>     >         } else if (i == -1)
>     >             goto err;
>     >         else {                  /* i == 0 */
>     >
>     >             if (!ssl_get_new_session(s, 1))
>     >                 goto err;
>     >         }
>     >
>     > Since s->version is with 0xFEFD and s->session->ssl_version is 0xFEFF,
>     > we always try for new session and wont land on to session resumption
>     > though client has sent the  session_id.
>     >
>     > Is this intended behaviour? Please clarify.
> 
> 
>     No. This appears to be a bug introduced by commit 03d14f588734 in
>     November 2014.
> 
>     The real problem though is that the DTLS version negotiation is
>     happening too late - after session resumption. Interestingly this only
>     seems to be a problem in 1.0.2. In 1.1.0 this is working correctly (the
>     version negotiation logic has been substantially rewritten in the new
>     version).
> 
>     Please could you try out the attached patch? Let me know how you get on.
> 
>     Thanks
> 
>     Matt
> 
>     --
>     openssl-dev mailing list
>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 
> 
> 
>