Re: Need help understanding how the custom extension interacts with the SSL pointer, if at all

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Many thanks for your fast answer,

I'll take a look at the resources you've indicated.

I'll also try to elaborate what I am trying to do:

I make a local SSL proxy to add some extensions to the ClientHello of the TLS session. It create a new SSL session for each incoming ones.

Since the process is always the same, I think I can use a single SSL_CTX for all client side SSL connexions the same way I did for the server part.

My interrogation is since I have to add the new extensions to the SSL_CTX object, it looks hard to customize or retrieve them by only knowing a SSL pointer.

But since you say we can attach data to SSL pointer I will check it since it can solve my problem this way.

In my use case, the client randomize a value and use it as a 1st custom extension to share it with the server, both will use it for some processing so that why I need to set/get them for each new handshake.
It also set another value in a 2nd extension to check some stuff related to the 1st one, but outside the fact both are related I think the way to handle it is the same.

I tried to find a way to "extract" these values from the extension fields so I can use them after the handshake, but I don't really know how to do it as it is define at a higher level (SSL_CTX instead of SSL).
I also didn't know we can store arbitrary data in OpenSSL object until you mention it.

Regards,

Xavier Marchal

----- Mail original -----
> De: "Matt Caswell" <matt@xxxxxxxxxxx>
> À: "Xavier Marchal" <xavier.marchal@xxxxxxxx>, "openssl-users" <openssl-users@xxxxxxxxxxx>
> Envoyé: Jeudi 19 Octobre 2023 14:08:37
> Objet: Re: Need help understanding how the custom extension interacts with the SSL pointer, if at all

> On 19/10/2023 14:51, Xavier Marchal wrote:
>> Hello,
>> 
>> In the context of a research project I need to add some extensions to
>> the ClientHello during TLS handshake but I don't understand well some
>> concepts of the custom extensions.
>> 
>> I can successfully send custom extensions between my client and server
>> thanks to the SSL_CTX_add_custom_ext function but I have a hard time to
>> use these values.
>> 
>> I currently define them like this on both sides:
>> SSL_CTX_add_custom_ext(ssl_ctx, 101, SSL_EXT_CLIENT_HELLO, addScalar,
>> freeScalar, NULL, parseScalar, NULL);
>> 
>> What I want to do is to store the value of the extension in a structure
>> linked with with each SSL sessions pointer I have but the callbacks are
>> set at the context level so I don't think I can give pointers to my
>> structures easily as they do no exist yet when the custom extension is
>> defined.
> 
> It's a bit unclear from your description exactly what you are trying to
> do. But IIUC you want to associate custom data with the SSL object. Many
> OpenSSL objects (including the SSL object) support the "ex_data"
> interface which enables you to store and retrieve custom data associated
> with the object.
> 
> See in particular:
> 
> https://www.openssl.org/docs/man3.1/man3/CRYPTO_get_ex_new_index.html
> 
> The SSL_get_app_data() and SSL_set_app_data() convenience macros wrap
> "ex_data" to give a simplified interface:
> 
> https://www.openssl.org/docs/man3.1/man3/SSL_get_app_data.html
> 
> E.g. call SSL_set_app_data() to associate a custom pointer with an SSL,
> and SSL_get_app_data() to retrieve it again later.
> 
> Matt
> 
> 
>> 
>> I think it may be possible to keep a global map with SSL session
>> pointers as keys but I am not sure it is the way to do.
>> 
>> Or maybe I can do a 1:1 with only a session per context but it looks
>> suboptimal.
>> 
>> In the same way, is it possible for a SSL client to set a specific value
>> for a custom extension if it only has access to a SSL pointer? (in my
>> case it would be better if I have only one SSL_CTX for all SSL clients)
>> 
>> Is what I'm trying to do feasible?
>> 
>> Regards,
>> 
> > Xavier Marchal




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux