[openssl-users] PSK generation for TLS 1.3

Sat Jul 8 10:28:18 UTC 2017

On 07/07/17 20:14, Neetish Pathak wrote:
> I have a query regarding the TLS 1.3 handshake message exchange. Please
> provide your comments.
> 
> 
> With TLS 1.3, I see that Application Data Protocol message is sent from
> the server side and client side (using wireshark) during the handshake.
> I am only performing handshake and not doing any read write operations.
> I see that servers and clients send application data protocol when doing
> just SSL_connect and SSL_accept .
> 
> I also know that all the messages post server hello are encrypted in TLS
> 1.3. So, I am not sure what data gets exchanged
> When checking logs for TLS 1.2, I do not see any exchange of Application
> Data Protocol which is as expected.

You would probably benefit from reading the TLSv1.3 draft to give you a
better picture of how TLSv1.3 is implemented.

As you say everything in TLSv1.3 after the ServerHello is encrypted.
Additionally the "real" content type of the record is held "inside" the
encrypted payload. The "outer" content type that TLSv1.2 and below used
is still present but is always set to "Application Data" regardless of
what the real inner content type is. What you are seeing as application
data being exchanged is really just handshake messages.

Matt

> 
> I am also attaching wireshark logs for TLS 1.2 and TLS 1.3 connections.
> 
> Basically, connection sequence for TLS 1.2 is 
> 
> *Client Hello*
> *Server Hello, Certificate, Server Key Exchange, Certificate Request,
> Server Hello Done*
> *Certificate, Client Key Exchange, Certificate Verify, Change Cipher
> Spec, Encrypted Handshake Message (Finished)*
> *Change Cipher Spec, Encrypted Handshake Message (Finished)*
> 
> 
> 
> but for TLS 1.3, it is 
> The same is the sequence of messages exchanged when doing a connection
> using resumption. I am not sure what application data gets exchanged
> when doing TLS 1.3 when I am not doing any read/writes.
> From RFC, I can see that Application Data can be optionally sent at the
> end of server Hello but I am not sure what data it is. How can I decrypt
> the exchanged data ?
> *Client Hello*
> *Server Hello, Application Data Protocol from Server*
> *Application Data Protocol from Client*
> *Application Data Protocol from Server*
> *Application Data Protocol from Client*
> 
> 
> Also, I observe that resumption connection time for TLS 1.3 using PSK
>  is more than resumption time for TLS 1.2 (by 700-800 microseconds). I
> am suspecting the exchange of application data and its processing etc
> (encryption) is causing the added delay. Could someone please provide
> any explanation or point me in the right direction. It is not very clear
> to me right now even after seeing the RFC
> 
> Thanks
> 
> 
> 
> 
> On Thu, Jul 6, 2017 at 11:40 AM, Neetish Pathak <npathak2 at ncsu.edu
> <mailto:npathak2 at ncsu.edu>> wrote:
> 
>     Thanks for the detailed explanation Matt
> 
>     On Tue, Jul 4, 2017 at 1:51 AM, Matt Caswell <matt at openssl.org
>     <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>         On 03/07/17 22:24, Neetish Pathak wrote:
> 
>         > Thanks Matt. This is quite useful.
>         > Just to clarify my understanding based on your comments, OpenSSL code
>         >  and Draft for TLS 1.3/RFC for TLS1.2, please help me with following queries
>         >
>         > 1) So, when using external PSK (by creating the new session file),
>         > client should mandatorily use SSL_CTX_set_psk_use_session_callback while
>         > server should mandatorily use
>         SSL_CTX_set_psk_find_session_casllback.
>         > They both should use a common key (psk_key) to generate the new session
>         > file and this common key is the one shared in advance to both client and
>         > server.
> 
>         Yes, that is correct. If both client and server are OpenSSL then,
>         optionally, they can just share a session file (which contains
>         the key)
>         if that is easier.
> 
>         > From the OpenSSL code, this key is used as char * type. So does
>         > it mean that any pre-decided string can be used as a key and it does not
>         > need any format etc.
> 
>         To me "string" implies NUL terminated printable string. Maybe
>         that's not
>         what you meant. Anyway in that sense "string" is not quite
>         correct. The
>         key is binary data which should be the same length as the hash
>         used for
>         the ciphersuite.
> 
> 
>         > Both client and server create sessions based on the
>         > key and connect based on the created session?
>         > In one of the examples, *strspn*(psk_key,
>         "abcdefABCDEF1234567890") is
>         > used. So, I believe I can use any hex value string of my choice as psk_key.
> 
>         Like I said above - the key is *binary* data. It does not have
>         to be a
>         printable string.
> 
> 
>         > 2) Also, from the man page , I found that PSK are used in TLS1.2 and
>         > lower versions too and SSL_CTX_set_psk_server_callback
>         > and SSL_CTX_set_psk_client_callback are used to set callback there. PSK
>         >  identity and Pre shared key is set there which can be used during the
>         > connection. It is also written that these values are required when using
>         > PSK cipher-suites. So, is my understanding correct that the role of PSK
>         > in version <= TLS1.2 is only for using PSK ciphersuites
>         > (e.g: ECDHE-PSK-AES256-CBC-SHA384)
> 
>         Correct.
> 
>         > and do not have anything to do with
>         > session resumption and thereby do not provide any performance enhancement.
> 
>         They do not have anything to do with session resumption, so you
>         don't
>         see the reduced number of message flights that you get with a
>         resumed
>         handshake. However, PSK ciphersuites in <= TLS1.2 avoid the need
>         to send
>         (and therefore process/validate) Certificate messages which may have
>         performance benefits. If the ciphersuite in use just uses
>         "plain" PSK
>         (i.e. no (EC)DHE or RSA) then a connection can be established
>         without
>         using public-key operations which may also have performance
>         benefits (at
>         the expense of forward secrecy).
> 
>         > Also, this PSK type ciphersuites are no longer valid for TLS 1.3.
> 
>         Correct.
> 
> 
>         Matt
>         --
>         openssl-users mailing list
>         To unsubscribe:
>         https://mta.openssl.org/mailman/listinfo/openssl-users
>         <https://mta.openssl.org/mailman/listinfo/openssl-users>
> 
> 
> 