how is it possible to confirm that a TLS ticket was used?

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

how is it possible to confirm that a TLS ticket was used?

Sam Roberts
And is it possible that this is different for TLS1.2 and 1.3?

Using TLS1.3, SSL_session_reused() is always returning false, I'm not
sure if that's because I'm doing something else wrong, and the ticket
is not being accepted and a full handshake is occurring, or if the API
literally only signals "session reuse" not "tls ticket" reuse. Its
also not clear from the docs if this API is supposed to work for both
client & server sides.

With TLS1.2, I notice that the cb to SSL_CTX_sess_set_new_cb() occurs
when a session is NOT reused (and I guess a new ticket is issued), but
in situation that I would expect the session to be resumed, I don't
get the callback. I assume this is because it doesn't make sense to
issue more tickets for a resumed connection? This gives me some
confidence that ticket use is occurring.

For 1.3, I'm always getting the callback (twice per connection, of
course), which makes me think that somehow my ticket reuse code is
working only for 1.2.

For both, I'm getting the session in the new session callback, and
then setting it with SSL_set_session(), so I'd expect resumption to
work for either protocol.

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

Re: how is it possible to confirm that a TLS ticket was used?

Viktor Dukhovni
On Mon, Feb 04, 2019 at 03:54:48PM -0800, Sam Roberts wrote:

> And is it possible that this is different for TLS1.2 and 1.3?

The resumption API is the same.  However, because in TLS 1.3, session
tickets are sent *after* the completion of the handshake, it is
possible that the session handle you're saving is the one that does
not yet have any associated tickets, because they've not yet been
received.  Session ticket resumption is working with Postfix and
TLS 1.3.

    $ posttls-finger -c -Lsummary,cache,ssl-debug -r 4 smtp.dukhovni.org
    posttls-finger: looking for session [100.2.39.101]:25&4A46567FCBCF5C0617FE221FA66FD0CB8F240EB24DB6BD261D53255FC8C9BE94 in memory cache
    posttls-finger: smtp.dukhovni.org[100.2.39.101]:25: SNI hostname: smtp.dukhovni.org
    posttls-finger: SSL_connect:before SSL initialization
    posttls-finger: SSL_connect:SSLv3/TLS write client hello
    posttls-finger: SSL_connect:SSLv3/TLS write client hello
    posttls-finger: SSL_connect:SSLv3/TLS read server hello
    posttls-finger: SSL_connect:TLSv1.3 read encrypted extensions
    posttls-finger: SSL_connect:SSLv3/TLS read server certificate
    posttls-finger: SSL_connect:TLSv1.3 read server certificate verify
    posttls-finger: SSL_connect:SSLv3/TLS read finished
    posttls-finger: SSL_connect:SSLv3/TLS write change cipher spec
    posttls-finger: SSL_connect:SSLv3/TLS write finished
    posttls-finger: Verified TLS connection established to smtp.dukhovni.org[100.2.39.101]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
    posttls-finger: SSL_connect:SSL negotiation finished successfully
    posttls-finger: SSL_connect:SSL negotiation finished successfully
    posttls-finger: save session [100.2.39.101]:25&4A46567FCBCF5C0617FE221FA66FD0CB8F240EB24DB6BD261D53255FC8C9BE94 to memory cache
    posttls-finger: SSL_connect:SSLv3/TLS read server session ticket
    posttls-finger: Reconnecting after 4 seconds
    posttls-finger: looking for session [100.2.39.101]:25&4A46567FCBCF5C0617FE221FA66FD0CB8F240EB24DB6BD261D53255FC8C9BE94 in memory cache
    posttls-finger: reloaded session [100.2.39.101]:25&4A46567FCBCF5C0617FE221FA66FD0CB8F240EB24DB6BD261D53255FC8C9BE94 from memory cache
    posttls-finger: smtp.dukhovni.org[100.2.39.101]:25: SNI hostname: smtp.dukhovni.org
    posttls-finger: SSL_connect:before SSL initialization
    posttls-finger: SSL_connect:SSLv3/TLS write client hello
    posttls-finger: SSL_connect:SSLv3/TLS write client hello
    posttls-finger: SSL_connect:SSLv3/TLS read server hello
    posttls-finger: SSL_connect:TLSv1.3 read encrypted extensions
    posttls-finger: SSL_connect:SSLv3/TLS read finished
    posttls-finger: SSL_connect:SSLv3/TLS write change cipher spec
    posttls-finger: SSL_connect:SSLv3/TLS write finished
    posttls-finger: smtp.dukhovni.org[100.2.39.101]:25: Reusing old session
    posttls-finger: Verified TLS connection established to smtp.dukhovni.org[100.2.39.101]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)
    posttls-finger: Found a previously used server.  Done reconnecting.

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

Re: how is it possible to confirm that a TLS ticket was used?

Matt Caswell-2
In reply to this post by Sam Roberts


On 04/02/2019 23:54, Sam Roberts wrote:
> And is it possible that this is different for TLS1.2 and 1.3?
>
> Using TLS1.3, SSL_session_reused() is always returning false, I'm not
> sure if that's because I'm doing something else wrong, and the ticket
> is not being accepted and a full handshake is occurring, or if the API
> literally only signals "session reuse" not "tls ticket" reuse. Its
> also not clear from the docs if this API is supposed to work for both
> client & server sides.

SSL_session_reused() works in both TLSv1.2 and TLSv1.3 on both the client and
the server, regardless of whether the reuse comes from a traditional session or
from a ticket. If you're always getting false in TLSv1.3 then you are failing to
resume in TLSv1.3.


> With TLS1.2, I notice that the cb to SSL_CTX_sess_set_new_cb() occurs
> when a session is NOT reused (and I guess a new ticket is issued), but
> in situation that I would expect the session to be resumed, I don't
> get the callback. I assume this is because it doesn't make sense to
> issue more tickets for a resumed connection? This gives me some
> confidence that ticket use is occurring.
>
> For 1.3, I'm always getting the callback (twice per connection, of
> course), which makes me think that somehow my ticket reuse code is
> working only for 1.2.

In TLSv1.3, by default, we issue two tickets if session reuse did not occur, and
one if reuse did occur.


> For both, I'm getting the session in the new session callback, and
> then setting it with SSL_set_session(), so I'd expect resumption to
> work for either protocol.

Yes - it should. It would be helpful to check whether the ticket is actually
appearing in the ClientHello or not.

Matt

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

Re: how is it possible to confirm that a TLS ticket was used?

Sam Roberts
In reply to this post by Viktor Dukhovni
On Mon, Feb 4, 2019 at 9:46 PM Viktor Dukhovni
<[hidden email]> wrote:
> On Mon, Feb 04, 2019 at 03:54:48PM -0800, Sam Roberts wrote:
> However, because in TLS 1.3, session
> tickets are sent *after* the completion of the handshake, it is
> possible that the session handle you're saving is the one that does
> not yet have any associated tickets, because they've not yet been
> received.

I'm saving the session that is passed to the callback in
SSL_CTX_sess_set_new_cb() as described in
https://wiki.openssl.org/index.php/TLS1.3#Sessions.

>     posttls-finger: smtp.dukhovni.org[100.2.39.101]:25: Reusing old session

What API are you using to confirm that the ticket was used to resume
the session? SSL_session_reused?

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

Re: how is it possible to confirm that a TLS ticket was used?

Viktor Dukhovni
> On Feb 5, 2019, at 10:41 AM, Sam Roberts <[hidden email]> wrote:
>
>> However, because in TLS 1.3, session
>> tickets are sent *after* the completion of the handshake, it is
>> possible that the session handle you're saving is the one that does
>> not yet have any associated tickets, because they've not yet been
>> received.
>
> I'm saving the session that is passed to the callback in
> SSL_CTX_sess_set_new_cb() as described in
> https://wiki.openssl.org/index.php/TLS1.3#Sessions.

And then?  How are you restoring the saved session for re-use?

>
>>    posttls-finger: smtp.dukhovni.org[100.2.39.101]:25: Reusing old session
>
> What API are you using to confirm that the ticket was used to resume
> the session? SSL_session_reused?

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: how is it possible to confirm that a TLS ticket was used?

Sam Roberts
I tracked down my problem, its due to a change in the relative order
of handshake completion (as detected by the info callback, anyhow),
and the callback to SSL_CTX_set_tlsext_ticket_key_cb().

With TLS1.2, I can rotate ticket keys on the server when the handshake
completes, and they will only apply to the next connection.

With TLS1.3, the tickets haven't been sent yet, at the time the
handshake completes, so when I "rotate" the keys, the new keys are
used immediately afterwards in the ticket_key_cb to encrypt the
tickets for the connection that just handshaked.

Its semi-obvious in retrospect, after having read our ticket key
handling code, but it took me a while to find it.

And it turns out that yes, SSL_session_resumed() does work with TLS tickets.

Thanks for the suggestions, Viktor.

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

Re: how is it possible to confirm that a TLS ticket was used?

Viktor Dukhovni
On Tue, Feb 05, 2019 at 02:43:03PM -0800, Sam Roberts wrote:

> I tracked down my problem, its due to a change in the relative order
> of handshake completion (as detected by the info callback, anyhow),
> and the callback to SSL_CTX_set_tlsext_ticket_key_cb().
>
> With TLS1.2, I can rotate ticket keys on the server when the handshake
> completes, and they will only apply to the next connection.
>
> With TLS1.3, the tickets haven't been sent yet, at the time the
> handshake completes, so when I "rotate" the keys, the new keys are
> used immediately afterwards in the ticket_key_cb to encrypt the
> tickets for the connection that just handshaked.

Your ticket rotation approach looks a bit fragile.

Postfix keeps two session ticket keys in memory, one that's used
to both encrypt new tickets and decrypt freshly issued tickets, and
other that's used only decrypt unexpired tickets that were isssued
just before the new key was introduced. This maintains session
ticket continuity across a single key change. The key change interval
is either equal to or is twice the maximum ticket lifetime, ensuring
that tickets are only invalidated by expiration, not key rotation.

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

Re: how is it possible to confirm that a TLS ticket was used?

Sam Roberts
On Wed, Feb 6, 2019 at 1:01 PM Viktor Dukhovni
<[hidden email]> wrote:
> On Tue, Feb 05, 2019 at 02:43:03PM -0800, Sam Roberts wrote:
> Your ticket rotation approach looks a bit fragile.

I agree, though perhaps I should not have described what was happening
as rotation. The test that was failing with TLS1.3 was one in which
clearing the ticket keys was supposed to invalidate previously issued
keys, but it wasn't (at least, not in the same way as it did for 1.2).

> Postfix keeps two session ticket keys in memory, one that's used
> to both encrypt new tickets and decrypt freshly issued tickets, and
> other that's used only decrypt unexpired tickets that were isssued
> just before the new key was introduced. This maintains session
> ticket continuity across a single key change. The key change interval
> is either equal to or is twice the maximum ticket lifetime, ensuring
> that tickets are only invalidated by expiration, not key rotation.

This seems a very reasonable approach, I may propose it as the default
after we have 1.3 support, thanks.

Cheers,
Sam
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users