Double TLS 1.3 session ticket?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Double TLS 1.3 session ticket?

Yann Ylavic
Hi,

connecting s_client to s_server with TLS 1.3 seems to cause two
successive session tickets to be sent by the server (see below).

Is this expected?

$ openssl s_server -accept 127.0.0.1:4443 -cert ... -key ... -state
Using default temp DH parameters
ACCEPT
SSL_accept:before SSL initialization
SSL_accept:before SSL initialization
SSL_accept:SSLv3/TLS read client hello
SSL_accept:SSLv3/TLS write server hello
SSL_accept:SSLv3/TLS write change cipher spec
SSL_accept:TLSv1.3 write encrypted extensions
SSL_accept:SSLv3/TLS write certificate
SSL_accept:TLSv1.3 write server certificate verify
SSL_accept:SSLv3/TLS write finished
SSL_accept:TLSv1.3 early data
SSL_accept:TLSv1.3 early data
SSL_accept:SSLv3/TLS read finished
SSL_accept:SSLv3/TLS write session ticket
SSL_accept:SSLv3/TLS write session ticket
...

$ openssl s_client -connect 127.0.0.1:4443 -state
CONNECTED(00000003)
SSL_connect:before SSL initialization
SSL_connect:SSLv3/TLS write client hello
SSL_connect:SSLv3/TLS write client hello
SSL_connect:SSLv3/TLS read server hello
SSL_connect:TLSv1.3 read encrypted extensions
[]
SSL_connect:SSLv3/TLS read server certificate
SSL_connect:TLSv1.3 read server certificate verify
SSL_connect:SSLv3/TLS read finished
SSL_connect:SSLv3/TLS write change cipher spec
SSL_connect:SSLv3/TLS write finished
[]
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1344 bytes and written 395 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID:
    Session-ID-ctx:
    Master-Key:
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1529519509
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: no
---
SSL_connect:SSL negotiation finished successfully
SSL_connect:SSL negotiation finished successfully
SSL_connect:SSLv3/TLS read server session ticket
read R BLOCK
SSL_connect:SSL negotiation finished successfully
SSL_connect:SSL negotiation finished successfully
SSL_connect:SSLv3/TLS read server session ticket
read R BLOCK
...


Regards,
Yann.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Double TLS 1.3 session ticket?

OpenSSL - User mailing list
>    connecting s_client to s_server with TLS 1.3 seems to cause two
    successive session tickets to be sent by the server (see below).
   
>    Is this expected?
 
Yes.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Double TLS 1.3 session ticket?

Viktor Dukhovni
In reply to this post by Yann Ylavic


> On Jun 20, 2018, at 2:55 PM, Yann Ylavic <[hidden email]> wrote:
>
> Hi,
>
> connecting s_client to s_server with TLS 1.3 seems to cause two
> successive session tickets to be sent by the server (see below).
>
> Is this expected?

Yes.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Double TLS 1.3 session ticket?

Yann Ylavic
On Wed, Jun 20, 2018 at 8:59 PM, Viktor Dukhovni
<[hidden email]> wrote:

>
>
>> On Jun 20, 2018, at 2:55 PM, Yann Ylavic <[hidden email]> wrote:
>>
>> Hi,
>>
>> connecting s_client to s_server with TLS 1.3 seems to cause two
>> successive session tickets to be sent by the server (see below).
>>
>> Is this expected?
>
> Yes.

Thanks, it does not happen with mozzilla implementation
(tls13.crypto.mozilla.org), is this openssl specific or part of the
specification?

Also, since there does not seem to be a round trip in between, any
reason to flush the BIO/socket?
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Double TLS 1.3 session ticket?

OpenSSL - User mailing list
>    Thanks, it does not happen with mozzilla implementation
    (tls13.crypto.mozilla.org), is this openssl specific or part of the
    specification?
 
The specification allows a server to send one or more tickets, at its discretion.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Double TLS 1.3 session ticket?

Yann Ylavic
>>    Thanks, it does not happen with mozzilla implementation
>     (tls13.crypto.mozilla.org), is this openssl specific or part of the
>     specification?
>
> The specification allows a server to send one or more tickets, at its discretion.

OK thanks, I could find the relevant PR and rationale after more googling.

One caveat though, the info_callback()s can now be called multiple
times with SSL_CB_HANDSHAKE_START/DONE (for each ticket), same
possibly for others callbacks (if any) where the state could be
tracked. The s_client output from the original message is misleading
in this regard.

For instance in Apache httpd info_callback() is used to check for and
forbid client initiated renegotiations, not a big deal since they
shouldn't exist anymore with TLS 1.3 (so this check has been disabled
since it's enforced by openssl in the first place), but I wonder if
announcing the start then end of the same handshake multiple times
could/should be avoided (i.e. handshake ends after last ticket only)?
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Double TLS 1.3 session ticket?

Matt Caswell-2


On 20/06/18 22:31, Yann Ylavic wrote:

>>>    Thanks, it does not happen with mozzilla implementation
>>     (tls13.crypto.mozilla.org), is this openssl specific or part of the
>>     specification?
>>
>> The specification allows a server to send one or more tickets, at its discretion.
>
> OK thanks, I could find the relevant PR and rationale after more googling.
>
> One caveat though, the info_callback()s can now be called multiple
> times with SSL_CB_HANDSHAKE_START/DONE (for each ticket), same
> possibly for others callbacks (if any) where the state could be
> tracked. The s_client output from the original message is misleading
> in this regard.
>
> For instance in Apache httpd info_callback() is used to check for and
> forbid client initiated renegotiations, not a big deal since they
> shouldn't exist anymore with TLS 1.3 (so this check has been disabled
> since it's enforced by openssl in the first place), but I wonder if
> announcing the start then end of the same handshake multiple times
> could/should be avoided (i.e. handshake ends after last ticket only)?

They really are individual transactions, so it makes much more sense to
me to signal each one as a separate handshake. On the client side we
have little choice because we don't know how many tickets the server
will send. It seems odd to do it differently on the server.

Matt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Double TLS 1.3 session ticket?

Yann Ylavic
On Wed, Jun 20, 2018 at 11:49 PM, Matt Caswell <[hidden email]> wrote:

>
> On 20/06/18 22:31, Yann Ylavic wrote:
>>
>> but I wonder if
>> announcing the start then end of the same handshake multiple times
>> could/should be avoided (i.e. handshake ends after last ticket only)?
>
> They really are individual transactions, so it makes much more sense to
> me to signal each one as a separate handshake. On the client side we
> have little choice because we don't know how many tickets the server
> will send. It seems odd to do it differently on the server.

Right but if s_server had handled SSL_CB_HANDSHAKE_START/DONE in its
info callback (like s_client), you'd see "SSL negotiation finished
successfully" after each ticket, even if the server knows (or could).
They are not really transactions since the client isn't supposed to
send anything in between, it's still part of the initial handshake
IMHO, and the flush seems not really needed either until the last
ticket.
Looks like it's missing some state in the machine.

Regards,
Yann.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Double TLS 1.3 session ticket?

Yann Ylavic
On Thu, Jun 21, 2018 at 12:17 AM, Yann Ylavic <[hidden email]> wrote:
>
> Right but if s_server had handled SSL_CB_HANDSHAKE_START/DONE in its
> info callback (like s_client), you'd see "SSL negotiation finished
> successfully" after each ticket, even if the server knows (or could).

Hm, actually I tried that and the real end on the server seems to be
SSL_CB_HANDSHAKE_DONE && SSL_get_state(s) == TLS_ST_OK, while
SSL_CB_HANDSHAKE_* are only transactions markers (not really limited
to tickets). Sorry for the noise.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Double TLS 1.3 session ticket?

Dennis Clarke-2
In reply to this post by OpenSSL - User mailing list
On 06/20/2018 08:46 PM, Salz, Rich via openssl-users wrote:
>>     Thanks, it does not happen with mozzilla implementation
>      (tls13.crypto.mozilla.org), is this openssl specific or part of the
>      specification?
>    
> The specification allows a server to send one or more tickets, at its discretion.
>

That being the case I can close this as "not a bug" :

     https://bz.apache.org/bugzilla/show_bug.cgi?id=62413

Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Double TLS 1.3 session ticket?

Matt Caswell-2
In reply to this post by Yann Ylavic


On 20/06/18 23:17, Yann Ylavic wrote:

> They are not really transactions since the client isn't supposed to
> send anything in between,

This is not the case. The client can be sending data before, during/in
between, and after the period that the server is issuing tickets.

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