Why does OpenSSL 3.0-alpha5 use more memory for TLS handshake than OpenSSL 1.1.1f

[dennisokko]

Hi,I want to know these questions.
Why does OpenSSL 3.0-alpha5 use more memory than OpenSSL 1.1.1f when use SSL_connect function for TLS handshake?
What code/features changes caused it?
How to reduce memory to the same as OpenSSL 1.1.1f?
Thanks in advance.

[kaduk]

It is generally expected that openssl 3.0 will have a larger memory footprint than 1.1.1, due to the re-architecture and needing to keep around some level of legacy support for a transition period until the old APIs can be removed.
This would account for most of the baseline difference in library footprint; if you are talking about a per-connection overhead that would probably have a different explanation (but I would not be surprised if there is also an increase in per-connection overhead).
If your application is compatible with doing so, configuring with no-deprecated will remove a large portion of the legacy support and thus reduce library footprint.

[dennisokko]

@kaduk Thank you for your reply.
I'm really saying that there is an increase in per-connection overhead.
I used the AES256-GCM-SHA384 Cipher Suite and the test data showed that there is an increase in per-connection overhead.It increased by 78%.
I want to know where the increase is caused and how to reduce to the same as OpenSSL 1.1.1f?

[levitte]

When diverse crypto implementations are fetched from the providers, their diverse methods are created on the fly and cached internally. That will probably be a noticeable chunk of memory. However, that's expected to be a one time overhead, not a per-connection one. I'd like to know if you do, say, 1000 connections to the same address, are you seeing a 78% memory increase 1000 times, or just the first time (or possibly a very limited amount of times)?

[dennisokko]

@levitte hi, levitte.
Sorry, I didn't make it clear.
Just the first time it increased by 78%.
Re-establishing connection after first connection is similar to 1.1.1f.

[dennisokko]

Does this mean that the change of crypto library cause the increase of runtime memory in the first connection?

[levitte]

Does this mean that the change of crypto library cause the increase of runtime memory in the first connection?

Yes

[richsalz]

It's building some tables of function pointers. I am surprised it is noticeable. A malloc-trace or some such would help figure things out.

[dennisokko]

@levitte Can i add feature options to reduce default provider to reduce the increase of runtime memory in the first connection,such as no-ec etc.
Do you have any recommendations？

[dennisokko]

Load the default provider is on the thread or a process？Load only once in a multi-thread?

[kaduk]

@levitte Can i add feature options to reduce default provider to reduce the increase of runtime memory in the first connection,such as no-ec etc.
Do you have any recommendations？

A similar question was answered at #13219 (comment) but I note that this is known to only regain part of the memory footprint in question.

Load the default provider is on the thread or a process？Load only once in a multi-thread?

I believe it is per-process.

[dennisokko]

After load default provider, per-connection increase 1KB runtime memory, is "struct ssl3_state_st *s3;" change in struct ssl_st cause it？

[levitte]

After load default provider, per-connection increase 1KB runtime memory, is "struct ssl3_state_st *s3;" change in struct ssl_st cause it？

I assume not. The structure itself is the same, it's just that in 3.0, it's included inside struct ssl_st, while in 1.1.1, it's a separately allocated chunk of memory, so only looking at that particular structure, it should take 4 or 8 bytes less (on pointer less, and that's forgetting memory allocation overhead), assuming the arrays in that structure are still the same size.