[openssl-dev] DTLS session resumption with DTLS_ANY_VERSION

[Rajeswari K]

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>