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

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 >>

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

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

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

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

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

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

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

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

[openssl-dev] Minor bug in custom TLS extensions

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