Re: [openssl-dev] Minor bug in custom TLS extensions

[Emilia Käsper]

On Wed, Sep 2, 2015 at 3:00 AM, Bill Cox  wrote:

> On Tue, Sep 1, 2015 at 2:50 PM, Emilia Käsper  wrote:
>
>> It's not quite clear to me why you'd have to resend parameters on
>> resumption. After all, they are definitive for the session. Best if the
>> draft explicitly specifies resumption behaviour.
>>
>
> I agree the draft should be enhanced to address resumption.  I'll ping the
> ietf list.
>
>
>> It's also not clear to me that the serialized TLS session is the place to
>> store the parameters. Shouldn't they rather be stored at the application
>> level, alongside with the eventual token?
>>
>
> I think everyone is opposed to storing state from the Token Binding
> extension in the TLS session state.  I agree it could be saved higher in
> the application stack in the client, but what if the resumption is with a
> server that does not support Token Binding for some reason?  In that case
> the server ignores the extension and the client knows to disable Token
> Binding because it did not receive the extension from the server.  This is
> how I implemented it locally, but I think this behavior should be clarified
> in the spec.
>

Ah right. Yes, the spec should spell that out.


>
>
>> But setting that aside, the interaction with extended master secret makes
>> using custom extensions for this purpose tricky anyway. Custom extensions
>> don't really support interaction with other extensions; there's no
>> guarantee that you'll end up processing them in the right order.
>>
>> (But I've only skimmed the docs so it's possible I got it all wrong.)
>>
>
> In this case I am lucky.  EMS is baked-in with native support, and all
> native extensions are parsed before all custom extensions.  However, I
> realize this is not gaurenteed behavior.  I should add a test for it...
>

As far as I can see, the OpenSSL client processes extensions in the order
they come in. But nothing is guaranteed.


>
> I do think this is a good candidate for custom extensions.
>
> Thanks,
> Bill
>
> ___
> 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

Re: [openssl-dev] Minor bug in custom TLS extensions

[Matt Caswell]

On 02/09/15 15:50, Bill Cox wrote:
> As for the order issue, we parse headers before creating any, so I'll
> just not add the header in the AddCallback if s->hit is set on the
> server side.  This should behave well long term, I think.

Except that in master (i.e. version 1.1.0) you will not be able to
access s->hit. You should use SSL_cache_hit instead.

Matt
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Minor bug in custom TLS extensions

[Bill Cox]

On Wed, Sep 2, 2015 at 7:55 AM, Matt Caswell  wrote:

>
>
> On 02/09/15 15:50, Bill Cox wrote:
> > As for the order issue, we parse headers before creating any, so I'll
> > just not add the header in the AddCallback if s->hit is set on the
> > server side.  This should behave well long term, I think.
>
> Except that in master (i.e. version 1.1.0) you will not be able to
> access s->hit. You should use SSL_cache_hit instead.
>

Yes, I already had that pointed out :)  Thanks, though!  You can't be too
careful in this code base.

Bill
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Minor bug in custom TLS extensions

[Emilia Käsper]

On Fri, Aug 28, 2015 at 2:21 AM, Bill Cox  wrote:

> On Thu, Aug 27, 2015 at 5:00 PM, Emilia Käsper  wrote:
>
>> A client should (SHOULD) always repeat extensions on resumption though,
>> as it can't know whether the resumption will be accepted.
>>
>> Do you have a specific example where you need to save custom extension
>> state? We can think about extending the API, even though I imagine that
>> anything that does need to keep state will be too complex and hairy to be
>> handled by the generic extension mechanism.
>>
>> Cheers,
>> Emilia
>>
>>
> Yes, I need it for the Token Binding Negotiation
> 
> extension.  We negotiate acceptable Token Binding key parameters in this
> TLS extension.  On resumption, the negotiation fails because the server
> does not include the custom extension in it's server hello.  At this point,
> the client loses the ability to use channel bound tokens.
>

It's not quite clear to me why you'd have to resend parameters on
resumption. After all, they are definitive for the session. Best if the
draft explicitly specifies resumption behaviour.

It's also not clear to me that the serialized TLS session is the place to
store the parameters. Shouldn't they rather be stored at the application
level, alongside with the eventual token?

But setting that aside, the interaction with extended master secret makes
using custom extensions for this purpose tricky anyway. Custom extensions
don't really support interaction with other extensions; there's no
guarantee that you'll end up processing them in the right order.

(But I've only skimmed the docs so it's possible I got it all wrong.)

Cheers,
Emilia


> Thanks,
> Bill
>
> ___
> 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

Re: [openssl-dev] Minor bug in custom TLS extensions

[Emilia Käsper]

It's not really a bug. The behaviour upon resumption is extension-specific.
Most extensions are only needed for establishing the session; they're
ignored during resumption, and aren't stored in the session state. So it's
rather that the custom extensions API doesn't support stateful extensions.

A client should (SHOULD) always repeat extensions on resumption though, as
it can't know whether the resumption will be accepted.

Do you have a specific example where you need to save custom extension
state? We can think about extending the API, even though I imagine that
anything that does need to keep state will be too complex and hairy to be
handled by the generic extension mechanism.

Cheers,
Emilia

On Tue, Aug 25, 2015 at 7:26 PM, Bill Cox waywardg...@google.com wrote:

 This seems like a bug to me:

 /*
  * If this ClientHello extension was unhandled and this is a
  * nonresumed connection, check whether the extension is a custom
  * TLS Extension (has a custom_srv_ext_record), and if so call the
  * callback and record the extension number so that an appropriate
  * ServerHello may be later returned.
  */
 else if (!s-hit) {
 if (custom_ext_parse(s, 1, type, data, size, al) = 0)
 return 0;
 }

 This is in t1_lib.c, in function ssl_scan_clienthello_tlsext.  It looks
 like the check for !s-hit will cause the server to ignore all custom
 extensions on resumed sessions.  At the same time, we do not have a
 mechanism for saving custom extension state in the session.  As a result,
 the server will lose all knowledge of the existence of a custom extension
 after resumption.  Some extensions are only needed during the initial
 handshake, but others set state on the connection that should persist.
 Also, there seems to be no code to keep the client from sending custom
 extensions on resumption, so when OpenSSL talks to OpenSSL with identical
 custom extensions, we're sending TLS extensions on resumption which are
 ignored by the server.

 I think the one-line fix is to change the else if (!s-hit) { to else
 {.  Would you guys agree?

 Any existing custom extensions that depend on the old behavior need to
 check SSL_session_reused(ssl) to disable custom TLS extensions on
 resumption.  On the positive side, this will reduce the current overhead
 caused by the client sending these extensions on resumption.

 Thanks,
 Bill

 ___
 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