Re: Direct SSL connection and ALPN loose ends

2024-07-26 Thread Heikki Linnakangas
On 17/06/2024 21:33, Andres Freund wrote: If provided with the necessary key information, wireshark can decode TLS exchanges when using sslnegotiation=postgres but not with direct. Presumably it needs to be taught postgres' ALPN id or something. I opened https://gitlab.com/wireshark/wireshark/-

Re: Direct SSL connection and ALPN loose ends

2024-07-26 Thread Heikki Linnakangas
On 24/07/2024 02:37, Michael Paquier wrote: On Tue, Jul 23, 2024 at 08:32:29PM +0300, Heikki Linnakangas wrote: All these new tests are a great asset when refactoring this again. Thanks for doing that. The coverage, especially with v2, is going to be really useful. Yeah, I'm also not too ex

Re: Direct SSL connection and ALPN loose ends

2024-07-23 Thread Michael Paquier
On Tue, Jul 23, 2024 at 08:32:29PM +0300, Heikki Linnakangas wrote: > All these new tests are a great asset when refactoring this again. Thanks for doing that. The coverage, especially with v2, is going to be really useful. > Yeah, I'm also not too excited about the additional code in the backen

Re: Direct SSL connection and ALPN loose ends

2024-07-23 Thread Heikki Linnakangas
On 16/07/2024 09:54, Michael Paquier wrote: On Mon, Jun 24, 2024 at 11:30:53PM +0300, Heikki Linnakangas wrote: 0002: This is the main patch that fixes the SSL fallback issue + conn->failed_enc_methods |= conn->allowed_enc_methods & (~conn->current_enc_method); Sounds reasonable to me. I

Re: Direct SSL connection and ALPN loose ends

2024-07-15 Thread Michael Paquier
On Mon, Jun 24, 2024 at 11:30:53PM +0300, Heikki Linnakangas wrote: > Given that, I think it is a good thing to fail the connection completely on > receiving a V2 error. > > Attached is a patch to fix the other issue, with falling back from SSL to > plaintext. And some tests and comment fixes I sp

Re: Direct SSL connection and ALPN loose ends

2024-06-25 Thread Jacob Champion
On Tue, Jun 25, 2024 at 7:20 AM Dave Cramer wrote: > > On Tue, 25 Jun 2024 at 09:37, Vladimir Sitnikov > wrote: >> >> "SSL". Technically, the proper term is TLS, and even the document refers to >> "IANA TLS ALPN Protocol IDs" (TLS, not SSL). >> I would not die on that hill, however, going for t

Re: Direct SSL connection and ALPN loose ends

2024-06-25 Thread Jacob Champion
On Thu, Jun 20, 2024 at 4:32 PM Jacob Champion wrote: > Thanks, > --Jacob Hey Heikki, [sending this to the list in case it's not just me] I cannot for the life of me get GMail to deliver your latest message, even though I see it on postgresql.org. It's not in spam; it's just gone. I wonder if i

Re: Direct SSL connection and ALPN loose ends

2024-06-25 Thread Dave Cramer
On Tue, 25 Jun 2024 at 09:37, Vladimir Sitnikov wrote: > I reviewed the documentation for "direct ALPN connections' ', and it looks > like it could be improved. > Here's the link: > https://www.postgresql.org/docs/17/protocol-flow.html#PROTOCOL-FLOW-SSL > > The currently suggested values for "ssl

Re: Direct SSL connection and ALPN loose ends

2024-06-25 Thread Vladimir Sitnikov
I reviewed the documentation for "direct ALPN connections' ', and it looks like it could be improved. Here's the link: https://www.postgresql.org/docs/17/protocol-flow.html#PROTOCOL-FLOW-SSL The currently suggested values for "sslnegotiations" are "direct" and "postgres". The project name is Postg

Re: Direct SSL connection and ALPN loose ends

2024-06-24 Thread Heikki Linnakangas
On 21/06/2024 02:32, Jacob Champion wrote: On Thu, Jun 20, 2024 at 4:13 PM Heikki Linnakangas wrote: By "negotiation" I mean the server's response to the startup packet. I.e. "supported"/"not supported"/"error". Ok, I'm still a little confused, probably a terminology issue. The server doesn't

Re: Direct SSL connection and ALPN loose ends

2024-06-20 Thread Jacob Champion
On Thu, Jun 20, 2024 at 4:13 PM Heikki Linnakangas wrote: > > By "negotiation" I mean the server's response to the startup packet. > > I.e. "supported"/"not supported"/"error". > > Ok, I'm still a little confused, probably a terminology issue. The > server doesn't respond with "supported" or "not

Re: Direct SSL connection and ALPN loose ends

2024-06-20 Thread Heikki Linnakangas
On 20/06/2024 20:02, Jacob Champion wrote: On Mon, Jun 17, 2024 at 9:23 AM Jacob Champion wrote: I think the behavior with v2 and v3 errors should be the same. And I think an immediate failure is appropriate on any v2/v3 error during negotiation, assuming we don't use those errors for things li

Re: Direct SSL connection and ALPN loose ends

2024-06-20 Thread Jacob Champion
On Mon, Jun 17, 2024 at 9:23 AM Jacob Champion wrote: > > I think the behavior with v2 and v3 errors should be the same. And I > > think an immediate failure is appropriate on any v2/v3 error during > > negotiation, assuming we don't use those errors for things like "TLS not > > supported", which

Re: Direct SSL connection and ALPN loose ends

2024-06-17 Thread Andres Freund
Hi, On 2024-04-29 18:24:04 +0300, Heikki Linnakangas wrote: > All reported bugs have now been fixed. We now enforce ALPN in all the right > places. Please let me know if I missed something. Very minor and not really your responsibility: If provided with the necessary key information, wireshark c

Re: Direct SSL connection and ALPN loose ends

2024-06-17 Thread Jacob Champion
On Mon, Jun 17, 2024 at 8:24 AM Heikki Linnakangas wrote: > By "negotiation", which part of the protocol are we talking about > exactly? In the middle of the TLS handshake? After sending the startup > packet? By "negotiation" I mean the server's response to the startup packet. I.e. "supported"/"n

Re: Direct SSL connection and ALPN loose ends

2024-06-17 Thread Heikki Linnakangas
On 17/06/2024 17:11, Jacob Champion wrote: On Mon, Apr 29, 2024 at 8:24 AM Heikki Linnakangas wrote: I was mostly worried about the refactoring of the retry logic in libpq (and about the pre-existing logic too to be honest, it was complicated before these changes already). Some changes in the

Re: Direct SSL connection and ALPN loose ends

2024-06-17 Thread Jacob Champion
On Mon, Apr 29, 2024 at 8:24 AM Heikki Linnakangas wrote: > I was mostly worried about the refactoring of the > retry logic in libpq (and about the pre-existing logic too to be honest, > it was complicated before these changes already). Some changes in the v17 negotiation fallback order caught my

Re: Direct SSL connection and ALPN loose ends

2024-04-29 Thread Ranier Vilela
Em seg., 29 de abr. de 2024 às 15:36, Heikki Linnakangas escreveu: > On 29/04/2024 21:06, Ranier Vilela wrote: > > Em seg., 29 de abr. de 2024 às 14:56, Heikki Linnakangas > > mailto:hlinn...@iki.fi>> escreveu: > > > > On 29/04/2024 20:10, Ranier Vilela wrote: > > > Hi, > > > > >

Re: Direct SSL connection and ALPN loose ends

2024-04-29 Thread Heikki Linnakangas
On 29/04/2024 21:06, Ranier Vilela wrote: Em seg., 29 de abr. de 2024 às 14:56, Heikki Linnakangas 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]. >

Re: Direct SSL connection and ALPN loose ends

2024-04-29 Thread Ranier Vilela
Em seg., 29 de abr. de 2024 às 14:56, Heikki Linnakangas 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 correct

Re: Direct SSL connection and ALPN loose ends

2024-04-29 Thread Heikki Linnakangas
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

re: Direct SSL connection and ALPN loose ends

2024-04-29 Thread Ranier Vilela
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

Direct SSL connection and ALPN loose ends

2024-04-29 Thread Heikki Linnakangas
There's been a bunch of bugs, and discussion on the intended behavior of sslnegotiation and ALPN. This email summarizes the current status: ## Status and loose ends for beta1 All reported bugs have now been fixed. We now enforce ALPN in all the right places. Please let me know if I missed some