PSK generation for TLS 1.3

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

PSK generation for TLS 1.3

neetish
Hi All,
Can anyone provide me pointers on how can we generate external PSK to be used inTLS 1.3.

When I save a a session using SSL_CTX_sess_set_new_cb(), it provides an in-band PSK for next resumption connection. 
I use PEM_write_bio_SSL_SESSION to save the session.


How do we use PSK externally. Can I use the same session file which was saved during in-band connection. I believe in case of an external PSK, both client and server should have a copy in advance.

Thanks
Best Regards,
Neetish

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

Re: PSK generation for TLS 1.3

Matt Caswell-2


On 30/06/17 22:18, Neetish Pathak wrote:

> Hi All,
> Can anyone provide me pointers on how can we generate external PSK to be
> used inTLS 1.3.
>
> When I save a a session using SSL_CTX_sess_set_new_cb(), it provides an
> in-band PSK for next resumption connection.
> I use PEM_write_bio_SSL_SESSION to save the session.
>
>
> How do we use PSK externally. Can I use the same session file which was
> saved during in-band connection. I believe in case of an external PSK,
> both client and server should have a copy in advance.

Yes, you can do if you want - like you said you just need to make sure
that the session file is used on both the client and the server.
Alternatively you can "create" a new session file, e.g.
s_server/s_client do it like this:

        usesess = SSL_SESSION_new();
        if (usesess == NULL
                || !SSL_SESSION_set1_master_key(usesess, key, key_len)
                || !SSL_SESSION_set_cipher(usesess, cipher)
                || !SSL_SESSION_set_protocol_version(usesess,
TLS1_3_VERSION)) {
            OPENSSL_free(key);
            goto err;
        }


Matt


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

Re: PSK generation for TLS 1.3

neetish


On Mon, Jul 3, 2017 at 2:11 AM, Matt Caswell <[hidden email]> wrote:


On 30/06/17 22:18, Neetish Pathak wrote:
> Hi All,
> Can anyone provide me pointers on how can we generate external PSK to be
> used inTLS 1.3.
>
> When I save a a session using SSL_CTX_sess_set_new_cb(), it provides an
> in-band PSK for next resumption connection.
> I use PEM_write_bio_SSL_SESSION to save the session.
>
>
> How do we use PSK externally. Can I use the same session file which was
> saved during in-band connection. I believe in case of an external PSK,
> both client and server should have a copy in advance.

Yes, you can do if you want - like you said you just need to make sure
that the session file is used on both the client and the server.
Alternatively you can "create" a new session file, e.g.
s_server/s_client do it like this:

        usesess = SSL_SESSION_new();
        if (usesess == NULL
                || !SSL_SESSION_set1_master_key(usesess, key, key_len)
                || !SSL_SESSION_set_cipher(usesess, cipher)
                || !SSL_SESSION_set_protocol_version(usesess,
TLS1_3_VERSION)) {
            OPENSSL_free(key);
            goto err;
        }


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_callback.
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. 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. 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.


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) and do not have anything to do with session resumption and thereby do not provide any performance enhancement.
Also, this PSK type ciphersuites are no longer valid for TLS 1.3.


Thanks
BR,
Neetish


 
Matt


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


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

Re: PSK generation for TLS 1.3

Matt Caswell-2


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: PSK generation for TLS 1.3

neetish


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.



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 <[hidden email]> wrote:
Thanks for the detailed explanation Matt

On Tue, Jul 4, 2017 at 1:51 AM, Matt Caswell <[hidden email]> 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




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

Re: PSK generation for TLS 1.3

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


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 <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Thanks for the detailed explanation Matt
>
>     On Tue, Jul 4, 2017 at 1:51 AM, Matt Caswell <[hidden email]
>     <mailto:[hidden email]>> 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>
>
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Loading...