[openssl-dev] DTLS session resumption with DTLS_ANY_VERSION
Matt Caswell
matt at openssl.org
Tue May 17 16:57:24 UTC 2016
On 17/05/16 17:43, Rajeswari K wrote:
> Hi Matt,
>
> Can you share s3_srvr.c file which is based on 1.1.0 release where DTLS
> session resumption works? I tried downloading 1.1.0-pre5 but i didnt see
> any file related with s3_srvr.c.
See the tls_process_client_hello() function in ssl/statem/statem_srvr.c,
around line 1240.
Matt
>
> Thanks,
> Rajeswari.
>
> On Mon, May 16, 2016 at 11:20 AM, Rajeswari K <raji.kotamraju at gmail.com
> <mailto:raji.kotamraju at gmail.com>> wrote:
>
> 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
> <mailto: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>
> > <mailto: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
>
>
>
>
>
More information about the openssl-dev
mailing list