Re: TLS 1.3 Early data
On Sat, Nov 05, 2022 at 11:50:18AM +0100, Dirk Menstermann wrote: > Hello, > > I did few experiments with early data but was not successful in solving my > exotic use case: "Using early data dependent on the SNI" > > I control the server (linux, supports http2) based on OpenSSL 111q and use a > recent firefox as client: > > 1) Setting SSL_CTX_set_max_early_data in the SSL_CTX* works (FF sends early > data) > 2) Setting SSL_set_max_early_data on the just created SSL* works (FF sends > early > data) > 3) Setting SSL_set_max_early_data in the SNI callback during the handshake > does > not work (FF does not send early data) > > I guess there is a dirty way to "peek" into the client hello and parse it > without OpenSSL, extracting the SNI and make it then like in 2), but I wonder > if > there is a better way. > > Any idea? The SNI callback runs far too late for this purpose (and, to be honest, a lot of other purposes). You should be able to use the client_hello callback for it, though (https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_client_hello_cb.html). Note that SSL_get_servername() does not provide something useful within the client hello callback execution and you'll have to do something like https://github.com/openssl/openssl/blob/master/test/helpers/handshake.c#L146-L198 in order to access the provided SNI value from the client. -Ben
RE: an oldie but a goodie .. ISO C90 does not support 'long long'
> From: openssl-users On Behalf Of raf via > openssl-users > Sent: Friday, 4 November, 2022 18:54 > > On Wed, Nov 02, 2022 at 06:29:45PM +, Michael Wojcik via openssl-users > wrote: > > > > > I'm inclined to agree. While there's an argument for backward compatibility, > > C99 was standardized nearly a quarter of a century ago. OpenSSL 1.x is > > younger than C99. It doesn't seem like an unreasonable requirement. > > Would this be a choice between backwards-compatibility with C90 > compilers and compatibility with 32-bit architectures? I don't see how. It's a question of the C implementation, not the underlying architecture. A C implementation for a 32-bit system can certainly provide a 64-bit integer type. If that C implementation conforms to C99 or later, it ought to do so using long long and unsigned long long. (I'm excluding C implementations for exotic systems where, for example, CHAR_BIT != 8, such as some DSPs; those aren't going to be viable targets for OpenSSL anyway.) > Is there another way to get 64-bit integers on 32-bit systems? Sure. There's a standard one, which is to include and use int64_t and uint64_t. That also requires C99 or later and an implementation which provides those types; they're not required. And for some implementations there are implementation-specific extensions, which by definition are not standard. And you can roll your own. In a non-OO language like C, this would be intrusive for the parts of the source base that rely on a 64-bit integer type. > I suspect that that there are more 32-bit systems than there are > C90 compilers. Perhaps, but I don't think it's relevant here. In any case, OpenSSL is not in the business of supporting every platform and C implementation in existence. There are the platforms supported by the project, and there are contributed platforms which are included in the code base and supported by the community (hopefully), and there are unsupported platforms. If someone wants OpenSSL on an unsupported platform, then it's up to them to do the work. -- Michael Wojcik
TLS 1.3 Early data
Hello, I did few experiments with early data but was not successful in solving my exotic use case: "Using early data dependent on the SNI" I control the server (linux, supports http2) based on OpenSSL 111q and use a recent firefox as client: 1) Setting SSL_CTX_set_max_early_data in the SSL_CTX* works (FF sends early data) 2) Setting SSL_set_max_early_data on the just created SSL* works (FF sends early data) 3) Setting SSL_set_max_early_data in the SNI callback during the handshake does not work (FF does not send early data) I guess there is a dirty way to "peek" into the client hello and parse it without OpenSSL, extracting the SNI and make it then like in 2), but I wonder if there is a better way. Any idea? Thanks Dirk
