On Mon, Nov 20, 2023 at 11:52:40AM +0530, anupama m wrote:
> I am trying to optimize my reverse proxy application by limiting the
> number of SSL handshakes upstream to just one instead of all the
> connections trying to establish a secure channel. Basically all the
> connections' data will be multiplexed onto this single SSL connection.
> Multiple SSL handshakes is the constraint to performance in my case and
> this is what I am trying to address.
* Have you considered using TLS resumption for all but the initial
connection? If you haven't why not? If ruled out, why?
* Do you control the software on both ends of the connection? Or
do you need to interoperate with other TLS applications you
cannot change?
* At some point, you might want to use QUIC as the upstream protocol,
as it supports particulary efficient (lower latency than unencrypted
TCP) establishment of secondary channels.
* However, QUIC support in OpenSSL is just about to appear in a
preliminary form in OpenSSL 3.2, and may not yet have all the features
you'd need.
* In the meantime, just using resumption should get you there,
and if you control the software on both ends, you can make
it cheaper by (TLS 1.3) using psk_ke, rather than psk_dhe_ke,
if the perfmance difference is sufficiently compelling and
the security tradeoffs are clearly understood.
With TLS 1.2, resumption is always of the "psk_ke" variety.
The directions you were exploring with alternative bulk ciphers are
entirely non-productive, banish them from your mind, and never
contemplate such things again.
--
Viktor.
