Re: Experiments with Postgres and SSL - Mailing list pgsql-hackers

On 20/01/2023 03:28, Jacob Champion wrote:
> On Wed, Jan 18, 2023 at 7:16 PM Greg Stark <stark@mit.edu> 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 excellent time
> to require clients to use ALPN on implicit-TLS connections. (There are
> no clients that can currently connect via implicit TLS, so you'll
> never have another chance to force the issue without breaking
> backwards compatibility.) That should hopefully make it harder to
> ALPACA yourself or others [2].

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.

We implemented a protocol version negotiation mechanism in the libpq 
protocol itself, how would this interact with it? If it's just 
"postgres", then I guess we'd still negotiate the protocol version and 
list of extensions after the TLS handshake.

>> Incidentally I find the logic in ProcessStartupPacket incredibly
>> confusing. It took me a while before I realized it's using tail
>> recursion to implement the startup logic. I think it would be way more
>> straightforward and extensible if it used a much more common iterative
>> style. I think it would make it possible to keep more state than just
>> ssl_done and gss_done without changing the function signature every
>> time for example.
> 
> +1. The complexity of the startup logic, both client- and server-side,
> is a big reason why I want implicit TLS in the first place. That way,
> bugs in that code can't be exploited before the TLS handshake
> completes.

+1. We need to support explicit TLS for a long time, so we can't 
simplify by just removing it. But let's refactor the code somehow, to 
make it more clear.

Looking at the patch, I think it accepts an SSLRequest packet even if 
implicit TLS has already been established. That's surely wrong, and 
shows how confusing the code is. (Or I'm reading it incorrectly, which 
also shows how confusing it is :-) )

Regarding Vladimir's comments on how clients can migrate to this, I 
don't have any great suggestions. To summarize, there are several options:

- Add an "fast_tls" option that the user can enable if they know the 
server supports it

- First connect in old-fashioned way, and remember the server version. 
Later, if you reconnect to the same server, use implicit TLS if the 
server version was high enough. This would be most useful for connection 
pools.

- Connect both ways at the same time, and continue with the fastest, 
i.e. "happy eyeballs"

- Try implicit TLS first, and fall back to explicit TLS if it fails.

For libpq, we don't necessarily need to do anything right now. We can 
add the implicit TLS support in a later version. Not having libpq 
support makes it hard to test the server codepath, though. Maybe just 
test it with 'stunnel' or 'openssl s_client'.

- Heikki