[openssl-dev] DTLS session resumption with DTLS_ANY_VERSION

[Rajeswari K]

Hi Matt,

Yes, i tested with your patch. Honestly, before writing to openssl-dev
team, i tried session resumption with moving the version just like what you
gave as patch. But, still session resumption didn't work for me. Am
debugging same at openssl front.

Just to confirm on the issue, i tried hardcoding s->version and s->method
with DTLSv1 just after calling SSL_new() followed by SSL_clear(). Then
Session resumption worked as expected.

So, updation of s->version during handshake and updation of
s->session->version has some relation which am trying to find out.

I was looking at updation of s->session->version during handshake when the
version is DTLS_ANY_VERSION. Will check and update you on my findings if
any.

Thanks,
Rajeswari.


On Fri, May 13, 2016 at 11:16 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> 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
> >
> >
> >
> >
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160516/1a89e788/attachment-0001.html>