Re: Will TLSv1.3 always send session ticket?
On Thu, Sep 16, 2021 at 09:49:31AM -0700, Benjamin Kaduk via openssl-users wrote: > I'd be interested in hearing your thoughts about what an API/config would look > like to enable the delayed-send behavior. A simple boolean SSL_CONF_CMD called something like: -ticket_delay, or -ticket_data_prepend would cause the ticket generation to be deferred until the first application data write from server to client. The API would be either a direct call to set the boolean, or an indirect action via the SSL_CONF layer. This would require a new bit to set the policy in the SSL_CTX that would be inherited by any derived SSL handles. The first data transmission would inspect the desired ticket count computed during the handshake, and send that many tickets, resetting the count to zero. The current immediate transmission of tickets would merely squirrel away the number of tickets to send with the first batch of data. -- Viktor.
Re: Getting SSL_SESSION remaining lifetime
On Thu, Sep 16, 2021 at 06:50:40PM +0200, Hubert Kario wrote: > On Thursday, 16 September 2021 17:59:48 CEST, Viktor Dukhovni wrote: > > The Internet does not solely consist of browser traffic from portable > > devices at wifi hotspots to taboo web sites. > > taboo web sites are not the only reason to expect privacy... Indeed, but there are also applications in which client "privacy" is both unavailable and undesirable. One size does not fit all. -- Viktor.
Re: Getting SSL_SESSION remaining lifetime
On Thursday, 16 September 2021 17:59:48 CEST, Viktor Dukhovni wrote: The Internet does not solely consist of browser traffic from portable devices at wifi hotspots to taboo web sites. taboo web sites are not the only reason to expect privacy... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
Re: Will TLSv1.3 always send session ticket?
On Thu, Sep 16, 2021 at 12:40:55PM -0400, Viktor Dukhovni wrote: > On Thu, Sep 16, 2021 at 09:30:18AM -0700, Benjamin Kaduk via openssl-users > wrote: > > On Thu, Sep 16, 2021 at 12:20:05PM -0400, Viktor Dukhovni wrote: > > > > > > I don't recall whether OpenSSL makes any effort to or supports deferring > > > the transmission of session tickets until just before the first > > > application data transmission from server to client (or else perhaps > > > just before responding to a received close-notify with a reciprocal > > > close-notify) > > > > It's not the default behavior, but is supported: you can configure the > > SSL/SSL_CTX to send zero tickets by default and then manually call > > SSL_new_session_ticket(), which defers the transmission until there is > > another > > write or explicit SSL_do_handshake() call. > > So nothing built-in... What I had in mind was a built-in behaviour of > the library to delay session ticket transmission until there's a first > opportunity to send some application data, which the client application > can be reasonably expected to read at that point. While I'm not opposed to having some turnkey solution built in, I do think that the current default of sending tickets immediately after the handshake is the correct *default* behavior. That makes the new session (with ticket and resumption capability) available to clients right after the handshake, instead of needing to wait until some actual data from the server arrives. I'd be interested in hearing your thoughts about what an API/config would look like to enable the delayed-send behavior. -Ben
Re: Will TLSv1.3 always send session ticket?
On Thu, Sep 16, 2021 at 09:30:18AM -0700, Benjamin Kaduk via openssl-users wrote: > On Thu, Sep 16, 2021 at 12:20:05PM -0400, Viktor Dukhovni wrote: > > > > I don't recall whether OpenSSL makes any effort to or supports deferring > > the transmission of session tickets until just before the first > > application data transmission from server to client (or else perhaps > > just before responding to a received close-notify with a reciprocal > > close-notify) > > It's not the default behavior, but is supported: you can configure the > SSL/SSL_CTX to send zero tickets by default and then manually call > SSL_new_session_ticket(), which defers the transmission until there is another > write or explicit SSL_do_handshake() call. So nothing built-in... What I had in mind was a built-in behaviour of the library to delay session ticket transmission until there's a first opportunity to send some application data, which the client application can be reasonably expected to read at that point. If this is left entirely to applications, many of the less sophisticated ones might not know to consider the issue. In my SMTP use-cases, after STARTTLS, the client is expected to send a short "EHLO" command, and then turn around and read a server response, so deadlock would require a very small TCP window on the server side, and/or an unreasonably large (many kilobytes) client EHLO name. So Postfix does not take any application-layer steps to postpone session ticket transmission. I also would not to send session tickets without an indication that the client did not present a sufficiently fresh ticket, so handling session ticket generation in the application logic would become even more complex... -- Viktor.
Re: Will TLSv1.3 always send session ticket?
On Thu, Sep 16, 2021 at 12:20:05PM -0400, Viktor Dukhovni wrote: > > I don't recall whether OpenSSL makes any effort to or supports deferring > the transmission of session tickets until just before the first > application data transmission from server to client (or else perhaps > just before responding to a received close-notify with a reciprocal > close-notify) It's not the default behavior, but is supported: you can configure the SSL/SSL_CTX to send zero tickets by default and then manually call SSL_new_session_ticket(), which defers the transmission until there is another write or explicit SSL_do_handshake() call. -Ben
Re: Will TLSv1.3 always send session ticket?
On Thu, Sep 16, 2021 at 10:05:44AM +0100, Matt Caswell wrote: > No. Unless you configure the server otherwise OpenSSL will always send > session ticket(s) in TLSv1.3. It may be worth mentioning a discussion from some time back on the TLSWG list started by David Benjamin that notes that in TLS 1.3 it is not always opportune for the server to send post-handshake session resumption tickets unless it is also sending some application data. If the application protocol in question has the client sending first and delivering a large request to the server before attempting to read a response, an "unsolicited" transmission of session tickets from server to client may cause an application protocol deadlock if the client's TCP window is not large enough to accommodate the session tickets withour any client-side reads. This situation can with some justification be argued to be a defect in the TLS 1.3 protocol. I don't recall whether OpenSSL makes any effort to or supports deferring the transmission of session tickets until just before the first application data transmission from server to client (or else perhaps just before responding to a received close-notify with a reciprocal close-notify) -- Viktor.
Re: Getting SSL_SESSION remaining lifetime
On Thu, Sep 16, 2021 at 04:11:49PM +0200, Hubert Kario wrote: > On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote: > > > > I am trying to get the remaining lifetime of the ticket so that > > server can decide to renew ticket or not > > TLS 1.3 tickets are single use. If the ticket was used by a client, > and you expect it to make a connection in the future, server needs to > send a new one. This is wrong both in terms of specification and the extant OpenSSL implementation. The Postfix SMTP server arranges to accept multi-use tickets without reissuing replacement tickets when the original ticket is still good for reuse. Ticket reuse is well suited to the MTA-to-MTA use-case where "privacy" is not only a concern but in fact undesirable. MTAs often reject traffic from senders with no PTR records, generic PTR records, poor IP reputation, The Internet does not solely consist of browser traffic from portable devices at wifi hotspots to taboo web sites. -- Viktor.
Re: Getting SSL_SESSION remaining lifetime
On Thu, Sep 16, 2021 at 04:57:03PM +0200, Hubert Kario wrote: > On Thursday, 16 September 2021 16:28:47 CEST, Benjamin Kaduk wrote: > > On Thu, Sep 16, 2021 at 04:11:49PM +0200, Hubert Kario wrote: > > > On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote: > > > > > > > > I am trying to get the remaining lifetime of the ticket so that server > > > > can decide to renew ticket or not > > > > > > TLS 1.3 tickets are single use. If the ticket was used by a client, and > > > you expect it to make a connection in the future, server needs to > > > send a new > > > one. > > > > Single-use tickets are only a protocol requirement when 0-RTT data is used. > > The OpenSSL implementation even allows the libssl-internal enforcement of > > single-use to be disabled (see SSL_OP_NO_ANTI_REPLAY at > > https://urldefense.com/v3/__https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html__;!!GjvTz_vk!GxR4URFTB0lwkM5nlYZdtn3DUdeaujsu1sHMYc_nRTUpkmLQP8-zz_b4HS_rcA$ > > ). > > OpenSSL as a client also has some measures to encourate single-use tickets, > > which I have a PR open to provide a knob to disable: > > https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/16598__;!!GjvTz_vk!GxR4URFTB0lwkM5nlYZdtn3DUdeaujsu1sHMYc_nRTUpkmLQP8-zz_YPrcg6yw$ > > . > > They're single use not only because of replay but also because of privacy > reasons, as reuse of a ticket indicates that the same client did send it. Yes. But the protocol itself only encourages single-use for privacy reasons. The protocol does not *require* single-use in that case. -Ben
Re: Getting SSL_SESSION remaining lifetime
On Thursday, 16 September 2021 16:28:47 CEST, Benjamin Kaduk wrote: On Thu, Sep 16, 2021 at 04:11:49PM +0200, Hubert Kario wrote: On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote: I am trying to get the remaining lifetime of the ticket so that server can decide to renew ticket or not TLS 1.3 tickets are single use. If the ticket was used by a client, and you expect it to make a connection in the future, server needs to send a new one. Single-use tickets are only a protocol requirement when 0-RTT data is used. The OpenSSL implementation even allows the libssl-internal enforcement of single-use to be disabled (see SSL_OP_NO_ANTI_REPLAY at https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html). OpenSSL as a client also has some measures to encourate single-use tickets, which I have a PR open to provide a knob to disable: https://github.com/openssl/openssl/pull/16598 . They're single use not only because of replay but also because of privacy reasons, as reuse of a ticket indicates that the same client did send it. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
Re: Getting SSL_SESSION remaining lifetime
On Thu, Sep 16, 2021 at 04:11:49PM +0200, Hubert Kario wrote: > On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote: > > > > I am trying to get the remaining lifetime of the ticket so that server > > can decide to renew ticket or not > > TLS 1.3 tickets are single use. If the ticket was used by a client, and > you expect it to make a connection in the future, server needs to send a new > one. Single-use tickets are only a protocol requirement when 0-RTT data is used. The OpenSSL implementation even allows the libssl-internal enforcement of single-use to be disabled (see SSL_OP_NO_ANTI_REPLAY at https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_options.html). OpenSSL as a client also has some measures to encourate single-use tickets, which I have a PR open to provide a knob to disable: https://github.com/openssl/openssl/pull/16598 . -Ben
Re: Getting SSL_SESSION remaining lifetime
On Thursday, 16 September 2021 04:41:44 CEST, Jaya Muthiah wrote: I am trying to get the remaining lifetime of the ticket so that server can decide to renew ticket or not TLS 1.3 tickets are single use. If the ticket was used by a client, and you expect it to make a connection in the future, server needs to send a new one. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
Re: Will TLSv1.3 always send session ticket?
On 16/09/2021 09:58, Jaya Muthiah wrote: TLSv1.3 does not require the server to send any tickets if it decides not to. What makes it decide NO TO. Here I am particularly interested in OpenSSL implementation only. In OpenSSL it is possible to configure the server to set the number of tickets that are sent - including down to 0. I understand that part that, my query was for any condition not in the user's hand. So let me rephrase - if openssl is configured to send one ticket by calling SSL_CTX_set_num_tickets(), is there a condition under which OpenSSL will not send session tickets? No. Unless you configure the server otherwise OpenSSL will always send session ticket(s) in TLSv1.3. Matt
Re: Will TLSv1.3 always send session ticket?
> TLSv1.3 does not require the server to send any tickets if it decides not to. What makes it decide NO TO. Here I am particularly interested in OpenSSL implementation only. > In OpenSSL it is possible to configure the server to set the number of > tickets that are sent - including down to 0. I understand that part that, my query was for any condition not in the user's hand. So let me rephrase - if openssl is configured to send one ticket by calling SSL_CTX_set_num_tickets(), is there a condition under which OpenSSL will not send session tickets?
Re: Will TLSv1.3 always send session ticket?
On 16/09/2021 07:19, Jaya Muthiah wrote: As I can read from the documents mentioned below, "or not at all" worries me. Is there a situation when a session ticket is not sent at all (other than when reused)? TLSv1.3 does not require the server to send any tickets if it decides not to. By default in OpenSSL a server will send 2 session tickets after a normal handshake, or 1 session ticket after a resumption handshake. There is nothing in the spec about that, so other libraries are very likely to have different policies and defaults. In OpenSSL it is possible to configure the a server to set the number of tickets that are sent - including down to 0. So, yes, there may be situations where the server does not send a session ticket. Matt
