[openssl-users] Session Ticket Support in Openssl TLS 1.2

Neetish Pathak npathak2 at ncsu.edu
Sat Jun 17 01:15:47 UTC 2017

Appreciate your tips and help so far.
Could you give me any pointers for placing my timestamps within the OpenSSl
code for right measurement for handshake. I am reading through the master
code. I think since in TLS 1.3 is session tickets are sent after handshake,
it would be ok to place a timestamp in the
*ossl_statem_server_pre_work *function
before *tls_finish_handshake* is called (This function is in state_srvr.c
which updates the stjatemachine I think). *It is only called for TLS 1.3*
*But I do not see any significant change when I put a timestamp here or at
the end of SSL_accept on my server application program.*
*Any help for the right location of time stamps will be appreciated.*


        *if* (SSL_IS_TLS13(s)) {


             * Actually this is the end of the handshake, but we're going

             * straight into writing the session ticket out. So we finish

             * the handshake, but keep the various buffers active.


/***************************End time

        *struct* timespec end;

            *clock_gettime*(CLOCK_MONOTONIC_RAW, &end);

            uint64_t tempTimeEnd = end.tv_nsec / 1000;

            *printf*("Handshake End time : %llu \n", tempTimeEnd);

            *return* tls_finish_handshake(s, wst, 0);

        } *if* (SSL_IS_DTLS(s)) {


             * We're into the last flight. We don't retransmit the last

             * unless we need to, so we don't use the timer


            st->use_timer = 0;





On Fri, Jun 16, 2017 at 5:54 PM, Benjamin Kaduk via openssl-users <
openssl-users at openssl.org> wrote:

> On 06/16/2017 05:36 PM, Matt Caswell wrote:
> The security properties of such "external" PSKs are substantially
> different than the "ephemeral" PSKs used in resumption flows.
> Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE
> based secret (assuming a suitable kex_mode is used). What do you see as
> the concern?
> The risk of accidentally using psk_ke instead of psk_dhe_ke is noticeable,
> and in terms of concrete differences, there are additional requirements on
> external PSKs that the KDF and PSK identity must remain fixed across uses.
> That, combined with the potential for insufficient entropy during key
> generation (mentioned in section 2.2 of draft-20) seem to provide more
> openings for cryptographic attacks than for the full resumption flow.  It
> is probably fine for uses where the other properties of external PSKs are
> needed, but I'm not sure that the risk/reward balance favors using it just
> to get a speedup -- TLS 1.3 resumption should already be pretty fast.
> -Ben
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170616/45ed82b7/attachment.html>

More information about the openssl-users mailing list