Re: Direct SSL connection and ALPN loose ends

Em seg., 29 de abr. de 2024 às 15:36, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
escreveu:

> On 29/04/2024 21:06, Ranier Vilela wrote:
> > Em seg., 29 de abr. de 2024 às 14:56, Heikki Linnakangas
> > <hlinnaka(at)iki(dot)fi <mailto:hlinnaka(at)iki(dot)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