Hello everyone,

I am trying to modify the NewSessionTicket from a TLS1.3 communication and create a custom smaller session ticket due to some restrictions and to a specific TLS13 application, and additionally, I want to pass some specific data using the NewSessionTicket
I am using the client/server example running them with arguments:

server/client -v 4 -r -s -t -0

Initially, I tried concatenating the custom session ticket and data I needed into the NewSessionTicket and therefore there was no issue. The structure of the NewSessionTicket was:

Session Ticket: [SessionTicket|data|customSessionTicket]

Where the data is 32-bytes and the customSessionTicket is 5-bytes. As shown in [img]customSessionTicket.PNG[/img]
Now though, I want to remove the original NewSessionTicket and in its place add the custom ticket and data at its place. The structure I need must be:

Session Ticket: [data|customSessionTicket]

I can observe that the NewSessionTicket is sent perfectly, with no issue, and the initial handshake works.
Also when the 0-RTT resumption is happening I can see that the client sends the Session Ticket in the PSK Identity: field as it suppose to. Thus the handshake does not happen eventually, as I get an error from the servers side:

SSL_read input error -306, parse error on header

So, how do I fix this issue and be able to send a custom NewSessionTicket where the server will check the last 5 bytes to resume the session?

Thank you in advance
Thank you

Hello everyone,
I am working in the client/server example using TLS 1.3
I want to change the encryption key of the early_data that are sent during the resumption session.
I am running my examples with:

./client -v 4 -r -s -t -0

both client and server.

Therefore, as the documentation says, https://tools.ietf.org/html/rfc8446#section-2.3, "The client uses the PSK to authenticate the server and to encrypt the early data".
I would like to find the exact point where the client uses the PSK to encrypt the early data. I observed that this is done in the function EncryptTLS13 in the tls.c file using the function wc_AesGcmEncrypt_ex, but going there I could observe that the aes->key was already initialized.
So where does the PSK encrypt the early data or how is it used in the aes function?
Additionally, what is the relation of the aadwith the PSK ?

Hello everyone,

I am using the client/server example and specifically TLS 1.3
I would like to customize the New Session Ticket packet from the initial handshake, by adding an extra extension to it which will provide a DH public key parameter.

I am currently in the function

SendTls13NewSessionTicket

of the tls13.c file right before the

ret = SendBuffered(ssl); 

line. I have tried add a new extension to my New Session Ticket message with:

  • wolfSSL_UseKeyShare

  • TLSX_KeyShare_Use

  • TLSX_KeyShare_Parse

but unfortunately I get for all a segmentation fault for all of them.
Why do I have this issue and how can I add that ?

Thank you in advance

Thank you David,

That was indeed helpful.

Best,
Chris

I am using the #define WOLFSSL_STATIC_EPHEMERAL setting so I have static keys in order to be able to decrypt my packets. I get from a client/server ( from the examples ) run, that the used curve is SECP256R1 which I think is fine and I could use either that or FFDHE2048.

1.) Now, I need to be able from the code of the examples ( client and server ) to be able to get their private keys.
At which point of the code's can I get these ( without the STATIC EPHEMERAL )?

2.)  If I use the static ephemeral, do the buffers at:

 ssl->ctx->staticKE->dhKey and eccKey

correspond to the private keys of the ffdhe-2048 and secp256r1 ? Because during debugging I can see something completely different even when trying to decode it from the octal value that the debugger gives me to ASCII. (See attached screenshot: [img]privateKey.PNG[/img])

3.) Last question, the sent public keys as seen Wireshark of the ClientHello and ServerHello can be seen in the Key Share Entry: Group: secp256r1 > Key Exchange 04faa99a... ? ( this is more to confirm that I am indeed capturing the correct public keys )

Thank you

Thank you Sean,

Your answer was helpful indeed. Therefore to be honest I did not understand what you mean exactly with the

Try calling wolfSSL_set_group_messages() and this will send fewer messages which may then line up the packets sent with what you expect

Best,
Chris

7

(4 replies, posted in wolfSSL)

@dgarske
Does that support TLS 1.3 though ? I have enabled the flags and also use WOLFSSL_STATIC_EPHEMERAL in order to capture my TLS 1.3 packets with the sniffer etc.
If no, how can I decrypt the traffic exchanged from a local server-client ( from the examples ) and watch it on wireshark or any similar traffic analyzer ?

Thank you

Hello,
I am using the server client example of the wolfssl library and I am currently trying to implement a custom NewSessionTicketin the handshake procedure with resumption.
I am running my server/client with

server/client -v 4 -r -s

commands.
According to the official TLS 1.3 documentation: https://tools.ietf.org/html/rfc8446#section-2.2 the NewSessionTicket ticket is sent at the fourth message of the server. Thus I was not able to locate at which exact point of the code the new session ticket is created so I could deploy there my custom session ticket. The only thing that I was able to observe is that the msgType becomes 4 which maps to session_ticket after the 6th message of the handshake. Additionally, this ticket will be created when a custom psk_key_exchange_modes is sent by the client. I have created this custo exchange mode as you can see in figure [img]psk_key_exchange_mode.PNG[/img].

At which part of the code should I implement the new custom NewSessionTicket ? How does the server choose a psk_key_exchange_mode in general, so I could use it to create that custom session ticket ?

Thank you in advance

Thank you very much for your reply ! That saved me a lot !

best,
Christos

embhorn wrote:

Hi cxenof03,

Welcome to the wolfSSL Forums!

The specific option for enabling TLS sessions is `HAVE_SESSION_TICKET`.

There is not currently an equivalent macro for the `./configure --enable-all` option, but you can use the "user_settings" method to get close:
https://github.com/wolfSSL/wolfssl/tree … es/configs

Here is an example that configures most of the library options:
https://github.com/wolfSSL/wolfssl/blob … ings_all.h

Thanks,
Eric @ wolfSSL Support

I am using an "Ubuntu 20.04" machine along with the "CLion IDE 2020.3.2" and I want to create an app using WolfSSL which would need the TLS1.3 implementation of it.

Using CLion, I cloned the official repository "https://github.com/wolfSSL/wolfssl.git". CLion automatically built the project and was I am able to run all the \wolfssl\examples perfectly.
Thus, the resumption session does not work.
I run both Server/Client with these arguments:

client/server -v 4 -r

And I am getting this output: "didn't reuse session id!!!" which I can verify from Wireshark that there was no resumption made but just another handshake.

At another build I did where instead of

cmake 

( which is the default of CLion ) I used

make

I manged to run properly the resumption but for that I had to add in the configuration before the build this command:

./configure --enable-all

which "Enables all wolfSSL features, excluding SSL v3".

What is the equivalent command of

--enable-all

for the Cmake options, that would enable me the exact same features? Is there any mapping for that ? Or what should I do so I can achieve properly the resumption ? Is there an IDE that could provide me both the build with debugging and supports the --enable-all command ? ( I tried Netbeans, Eclipse but didn't manage to have both build and debugging)

I tried -DWOLFSSL_ALL -DENABLE_ALL and others but did not managed to do it. I tried including many of them separately to find which is the one that enables the resumption but nothing yet.

Thank you in advance