Hi,
When connecting with a libpq based client, the TLS establishment ends up like
this in many configurations;
C->S: TLSv1 393 Client Hello
S->C: TLSv1.3 167 Hello Retry Request, Change Cipher Spec
C->S: TLSv1.3 432 Change Cipher Spec, Client Hello
S->C: TLSv1.3 1407 Server Hello, Application Data, Application Data, Application Data, Application Data
...
I.e. there are two clients hellos, because the server rejects the clients
"parameters".
This appears to be caused by ECDH support. The difference between the two
ClientHellos is
- Extension: key_share (len=38) x25519
+ Extension: key_share (len=71) secp256r1
I.e. the clients wanted to use x25519, but the server insists on secp256r1.
This turns out to be due to
commit 3164721462d547fa2d15e2a2f07eb086a3590fd5
Author: Peter Eisentraut <peter_e@gmx.net>
Date: 2013-12-07 15:11:44 -0500
SSL: Support ECDH key exchange
I don't know if it's good that we're calling SSL_CTX_set_tmp_ecdh at all, but
if it is, shouldn't we at least do the same in libpq, so we don't introduce
unnecessary roundtrips?
I did confirm that doing the same thing on the client side removes the
additional roundtrip.
It seems kind of a shame that we have fewer roundtrips due to
sslnegotiation=direct, but do completely unnecessary roundtrips all the
time...
In a network with ~10ms latency I see an almost 30% increased
connections-per-second for a single client if I avoid the added roundtrip.
I think this could almost be considered a small bug...
Greetings,
Andres Freund
