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/-
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
> > >
> >
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].
>
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
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
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
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
23 matches
Mail list logo
