Em seg., 29 de abr. de 2024 às 15:36, Heikki Linnakangas <hlinn...@iki.fi> escreveu:
> On 29/04/2024 21:06, Ranier Vilela wrote: > > Em seg., 29 de abr. de 2024 às 14:56, Heikki Linnakangas > > <hlinn...@iki.fi <mailto:hlinn...@iki.fi>> escreveu: > > > > On 29/04/2024 20:10, Ranier Vilela wrote: > > > Hi, > > > > > > With TLS 1.3 and others there is possibly a security flaw using > > ALPN [1]. > > > > > > It seems to me that the ALPN protocol can be bypassed if the > > client does > > > not correctly inform the ClientHello header. > > > > > > So, the suggestion is to check the ClientHello header in the > > server and > > > terminate the TLS handshake early. > > > > Sounds to me like it's working as designed. ALPN in general is > > optional; > > if the client doesn't request it, then you proceed without it. We do > > require ALPN for direct SSL connections though. We can, because > direct > > SSL connections is a new feature in Postgres. But we cannot require > it > > for the connections negotiated with SSLRequest, or we break > > compatibility with old clients that don't use ALPN. > > > > Ok. > > But what if I have a server configured for TLS 1.3 and that requires > > ALPN to allow access? > > What about a client configured without ALPN requiring connection? > > Sorry, I don't understand the questions. What about them? > Sorry, I'll try to be clearer. The way it is designed, can we impose TLS 1.3 and ALPN to allow access to a public server? And if on the other side we have a client, configured without ALPN, when requesting access, the server will refuse? best regards, Ranier Vilela
