On 24/04/2024 23:51, Peter Eisentraut wrote:
On 08.04.24 10:38, Heikki Linnakangas wrote:
On 08/04/2024 04:25, Heikki Linnakangas wrote:
One important open item now is that we need to register a proper ALPN
protocol ID with IANA.
I sent a request for that:
On Wed, Apr 24, 2024 at 1:57 PM Peter Eisentraut wrote:
> I'm concerned that there appears to be some confusion over whether ALPN
> is a performance feature or a security feature. RFC 7301 appears to be
> pretty clear that it's for performance, not for security.
It was also designed to give
On 01.03.24 22:49, Jacob Champion wrote:
If we're interested in ALPN negotiation in the future, we may also
want to look at GREASE [1] to keep those options open in the presence
of third-party implementations. Unfortunately OpenSSL doesn't do this
automatically yet.
If we don't have a reason
On 08.04.24 10:38, Heikki Linnakangas wrote:
On 08/04/2024 04:25, Heikki Linnakangas wrote:
One important open item now is that we need to register a proper ALPN
protocol ID with IANA.
I sent a request for that:
On 08/04/2024 04:25, Heikki Linnakangas wrote:
One important open item now is that we need to register a proper ALPN
protocol ID with IANA.
I sent a request for that:
https://mailarchive.ietf.org/arch/msg/tls-reg-review/9LWPzQfOpbc8dTT7vc9ahNeNaiw/
--
Heikki Linnakangas
Neon
On 08/04/2024 04:28, Tom Lane wrote:
Heikki Linnakangas writes:
Committed this. Thank you to everyone involved!
Looks like perlcritic isn't too happy with the test code:
koel and crake say
./src/test/libpq_encryption/t/001_negotiate_encryption.pl: Return value of
flagged function ignored -
Heikki Linnakangas writes:
> Committed this. Thank you to everyone involved!
Looks like perlcritic isn't too happy with the test code:
koel and crake say
./src/test/libpq_encryption/t/001_negotiate_encryption.pl: Return value of
flagged function ignored - chmod at line 138, column 2. See
Committed this. Thank you to everyone involved!
On 04/04/2024 14:08, Matthias van de Meent wrote:
Patch 0003:
The read size in secure_raw_read is capped to port->raw_buf_remaining
if the raw buf has any data. While the user will probably call into
this function again, I think that's a waste of
On Thu, 28 Mar 2024, 13:37 Heikki Linnakangas, wrote:
>
> On 28/03/2024 13:15, Matthias van de Meent wrote:
> > On Tue, 5 Mar 2024 at 15:08, Heikki Linnakangas wrote:
> >>
> >> I hope I didn't joggle your elbow reviewing this, Jacob, but I spent
> >> some time rebase and fix various little
On 28/03/2024 13:15, Matthias van de Meent wrote:
On Tue, 5 Mar 2024 at 15:08, Heikki Linnakangas wrote:
I hope I didn't joggle your elbow reviewing this, Jacob, but I spent
some time rebase and fix various little things:
With the recent changes to backend startup committed by you, this
On Tue, 5 Mar 2024 at 15:08, Heikki Linnakangas wrote:
>
> I hope I didn't joggle your elbow reviewing this, Jacob, but I spent
> some time rebase and fix various little things:
With the recent changes to backend startup committed by you, this
patchset has gotten major apply failures.
Could you
I keep forgetting -- attached is the diff I'm carrying to plug
libpq_encryption into Meson. (The current patchset has a meson.build
for it, but it's not connected.)
--Jacob
commit 64215f1e6b68208378b34cc0736d2f0eb1d45919
Author: Jacob Champion
Date: Wed Feb 28 11:28:17 2024 -0800
WIP:
On Tue, Mar 5, 2024 at 6:09 AM Heikki Linnakangas wrote:
>
> I hope I didn't joggle your elbow reviewing this
Nope, not at all!
> The tests are still not distinguishing whether a connection was
> established in direct or negotiated mode. So if we e.g. had a bug that
> accidentally disabled
I hope I didn't joggle your elbow reviewing this, Jacob, but I spent
some time rebase and fix various little things:
- Incorporated Matthias's test changes
- Squashed the client, server and documentation patches. Not much point
in keeping them separate, as one requires the other, and if
On 01/03/2024 23:49, Jacob Champion wrote:
On Wed, Feb 28, 2024 at 4:10 AM Heikki Linnakangas wrote:
I think we'd want to *avoid* changing the major protocol version in a
way that would introduce a new roundtrip, though.
I'm starting to get up to speed with this patchset. So far I'm mostly
On Wed, Feb 28, 2024 at 4:10 AM Heikki Linnakangas wrote:
> I think we'd want to *avoid* changing the major protocol version in a
> way that would introduce a new roundtrip, though.
I'm starting to get up to speed with this patchset. So far I'm mostly
testing how it works; I have yet to take an
On 28/02/2024 14:00, Matthias van de Meent wrote:
I don't think I understand what you meant here, could you correct the
sentence or expand why we want to do that?
Note that with ALPN you could negotiate postgres/3.0 or postgres/4.0
during the handshake, which could save round-trips.
Sorry, I
On Thu, 22 Feb 2024 at 18:02, Heikki Linnakangas wrote:
>
> On 22/02/2024 01:43, Matthias van de Meent wrote:
>> On Wed, 10 Jan 2024 at 09:31, Heikki Linnakangas wrote:
>>> 4. The number of combinations of sslmode, gssencmode and sslnegotiation
>>> settings is scary. And we have very few tests
On 22/02/2024 01:43, Matthias van de Meent wrote:
On Wed, 10 Jan 2024 at 09:31, Heikki Linnakangas wrote:
4. The number of combinations of sslmode, gssencmode and sslnegotiation
settings is scary. And we have very few tests for them.
Yeah, it's not great. We could easily automate this better
On Wed, 10 Jan 2024 at 09:31, Heikki Linnakangas wrote:
>
> Some more comments on this:
>
> 1. It feels weird that the combination of "gssencmode=require
> sslnegotiation=direct" combination is forbidden. Sure, the ssl
> negotiation will never happen with gssencmode=require, so the
>
I've been asked to take a look at this thread and review some patches,
and the subject looks interesting enough, so here I am.
On Thu, 19 Jan 2023 at 04:16, Greg Stark wrote:
> I had a conversation a while back with Heikki where he expressed that
> it was annoying that we negotiate SSL/TLS the
On 05/07/2023 02:33, Michael Paquier wrote:
On Tue, Jul 04, 2023 at 05:15:49PM +0300, Heikki Linnakangas wrote:
I don't see the point of the libpq 'sslalpn' option either. Let's send ALPN
always.
Admittedly having the options make testing different of combinations of old
and new clients and
On Tue, Jul 04, 2023 at 05:15:49PM +0300, Heikki Linnakangas wrote:
> I don't see the point of the libpq 'sslalpn' option either. Let's send ALPN
> always.
>
> Admittedly having the options make testing different of combinations of old
> and new clients and servers a little easier. But I don't
On 31/03/2023 10:59, Greg Stark wrote:
IIRC I put a variable labeled a "GUC" but forgot to actually make it a
GUC. But I'm thinking of maybe removing that variable since I don't
see much of a use case for controlling this manually. I *think* ALPN
is supported by all the versions of OpenSSL we
And the cfbot wants a small tweak
From 3d0a502c25504da32b7a362831c700b4e891f79b Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Fri, 31 Mar 2023 02:31:31 -0400
Subject: [PATCH v6 5/6] Allow pipelining data after ssl request
---
src/backend/postmaster/postmaster.c | 54
On Mon, 20 Mar 2023 at 16:31, Greg Stark wrote:
>
> Here's a first cut at ALPN support.
>
> Currently it's using a hard coded "Postgres/3.0" protocol
Apparently that is explicitly disrecommended by the IETF folk. They
want something like "TBD" so people don't start using a string until
it's been
Sorry, checking the cfbot apparently I had a typo in the #ifndef USE_SSL case.
From 4b6e01c7f569a919d660cd80ce64cb913bc9f220 Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Mon, 20 Mar 2023 14:09:30 -0400
Subject: [PATCH v4 4/4] alpn support
---
src/backend/libpq/be-secure-openssl.c| 65
Here's a first cut at ALPN support.
Currently it's using a hard coded "Postgres/3.0" protocol (hard coded
both in the client and the server...). And it's hard coded to be
required for direct connections and supported but not required for
regular connections.
IIRC I put a variable labeled a "GUC"
Here's an updated patch for direct SSL connections.
I've added libpq client support with a new connection parameter. This
allows testing it easily with psql. It's still a bit hard to see
what's going on though. I'm thinking it would be good to have libpq
keep a string which describes what
On Tue, Feb 28, 2023 at 10:33 AM Greg Stark wrote:
> On Wed, 22 Feb 2023 at 07:27, Heikki Linnakangas wrote:
> > Good idea. Do we want to just require the protocol to be "postgres", or
> > perhaps "postgres/3.0"? Need to register that with IANA, I guess.
>
> I had never heard of this before, it
On Wed, 22 Feb 2023 at 07:27, Heikki Linnakangas wrote:
>
> On 20/01/2023 03:28, Jacob Champion wrote:
> > On Wed, Jan 18, 2023 at 7:16 PM Greg Stark wrote:
> >> * "Service Mesh" type tools that hide multiple services behind a
> >> single host/port ("Service Mesh" is just a new buzzword for
On Wed, Feb 22, 2023 at 4:26 AM Heikki Linnakangas wrote:
> On 20/01/2023 03:28, Jacob Champion wrote:
> > If you want to multiplex protocols on a port, now is an excellent time
> > to require clients to use ALPN on implicit-TLS connections. (There are
> > no clients that can currently connect
On 20/01/2023 03:28, Jacob Champion wrote:
On Wed, Jan 18, 2023 at 7:16 PM Greg Stark wrote:
* "Service Mesh" type tools that hide multiple services behind a
single host/port ("Service Mesh" is just a new buzzword for "proxy").
If you want to multiplex protocols on a port, now is an
>You could just hard code that servers newer than a
> specific version would have this support
Suppose PostgreSQL 21 implements "fast TLS"
Suppose pgjdbc 43 supports "fast TLS"
Suppose PgBouncer 1.17.0 does not support "fast TLS" yet
If pgjdbc connects to the DB via balancer, then the server
On Fri, 20 Jan 2023 at 01:41, Vladimir Sitnikov
wrote:
>
> Do you think the server can de-support the old code path soon?
I don't have any intention to de-support anything. I really only
picture it being an option in environments where the client and server
are all part of a stack controlled by
>I don't think it's worth implementing a code path in
> the server like this as it would then become cruft that would be hard
> to ever get rid of.
Do you think the server can de-support the old code path soon?
> I think you can do the same thing, more or less, in the client. Like
> if the
On Wed, Jan 18, 2023 at 7:16 PM Greg Stark wrote:
> I had a conversation a while back with Heikki where he expressed that
> it was annoying that we negotiate SSL/TLS the way we do since it
> introduces an extra round trip. Aside from the performance
> optimization I think accepting standard TLS
On Thu, 19 Jan 2023 at 15:49, Vladimir Sitnikov
wrote:
>
> What if the server that supports 'fast TLS' added an extra notification in
> case client connects with a classic TLS?
> Then a capable client could remember host:port and try with newer TLS appoach
> the next time it connects.
>
> It
It would be great if PostgreSQL supported 'start with TLS', however, how
could clients activate the feature?
I would like to refrain users from configuring the handshake mode, and I
would like to refrain from degrading performance when a new client talks to
an old database.
What if the server
On Thu, 19 Jan 2023 at 00:45, Andrey Borodin wrote:
> But..do we have to treat any unknown start sequence of bytes as a TLS
> connection? Or is there some definite subset of possible first bytes
> that clearly indicates that this is a TLS connection or not?
Absolutely not, there's only one
On Wed, Jan 18, 2023 at 7:16 PM Greg Stark wrote:
>
> So I took a look into what it would take to do and I think it would
> actually be quite feasible. The first byte of a standard TLS
> connection can't look anything like the first byte of any flavour of
> Postgres startup packet because it
I had a conversation a while back with Heikki where he expressed that
it was annoying that we negotiate SSL/TLS the way we do since it
introduces an extra round trip. Aside from the performance
optimization I think accepting standard TLS connections would open the
door to a number of other
42 matches
Mail list logo
