[openssl-dev] DTLS session resumption with DTLS_ANY_VERSION
Rajeswari K
raji.kotamraju at gmail.com
Tue May 17 16:43:57 UTC 2016
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.
Thanks,
Rajeswari.
On Mon, May 16, 2016 at 11:20 AM, Rajeswari K <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> 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/20160517/8809f7e4/attachment.html>
More information about the openssl-dev
mailing list