Re: Comments about TLS (no SSLRequest) and ALPN

On Sat, 11 May 2024 at 21:36, AJ ONeal <coolaj86(at)proton(dot)me> wrote:
>
> I just joined the mailing list and I don't know how to respond to old messages. However, I have a few suggestions on the upcoming TLS and ALPN changes.
>
> TL;DR
>
> Prefer TLS over SSLRequest or plaintext (from the start)
>
> ?sslmode=default # try tls, then sslrequest, then plaintext
> ?sslmode=tls|tlsv1.3 # require tls, no fallback
> ?sslmode=tls-noverify|tlsv1.3-noverify # require tls, ignore CA

I'm against adding a separate mini configuration language within our options.

> Allow the user to specify ALPN (i.e. for privacy or advanced routing)
>
> ?alpn=pg3|disable|<empty>
> --alpn 'pg3|disable|<arbitrary-string>' # same as curl, openssl
> (I don't have much to argue against the long form "postgres/3" other than that the trend is to keep it short and sweet and all mindshare (and SEO) for "pg" is pretty-well captured by Postgres already)

The "postgresql" alpn identifier has been registered, and I don't
think it's a good idea to further change this unless you have good
arguments as to why we'd need to change this.

Additionally, I don't think psql needs to request any protocol other
than Postgres' own protocol, so I don't see any need for an "arbitrary
string" option, as it'd incorrectly imply that we support arbitrary
protocols.

> Rationales
>
> I don't really intend to sway anyone who has considered these things and decided against them. My intent is just to shed light for any of these aspects that haven't been carefully considered already.
>
> Prefer the Happy Path
[...]
> Postgres versions (naturally) take years to make it into mainstream LTS server distros (without explicit user interaction anyway)

Usually, the latest version is picked up by the LTS distro on release.
Add a feature freeze window, and you're likely no more than 1 major
version behind on launch. Using an LTS release for its full support
window would then indeed imply a long time of using that version, but
that's the user's choice for choosing to use the LTS distro.

> Prefer Standard TLS
>
> As I experience it (and understand others to experience it), the one-time round trip isn't the main concern for switch to standard TLS, it's the ability to route and proxy.

No, the one RTT saved is one of the main benefits here for both the
clients and servers. Server *owners* may benefit by the improved
routing capabilities, but we're not developing a database connection
router, but database clients and servers.

> Having an extra round trip (try TLS first, then SSLRequest) for increasingly older versions of Postgres will, definitionally, become even less and less important as time goes on.

Yes. But right now, there are approximately 0 servers that use the
latest (not even beta) version of PostgreSQL that supports direct
SSL/TLS connections. So, for now, we need to support connecting to
older databases, and I don't think we can just decide to regress those
users' connections when they upgrade their client binaries.

> Having postgres TLS/SNI/ALPN routable by default will just be more intuitive (it's what I assumed would have been the default anyway), and help increase adoption in cloud, enterprise, and other settings.

AFAIK, there are very few companies that actually route PostgreSQL
client traffic without a bouncer that load-balances the contents of
those connections. While TLS/SNI/SLPN does bring benefits to these
companies, I don't think the use of these features is widespread
enough to default to a more expensive path for older server versions,
and newer servers that can't or won't support direct ssl connections
for some reason.

> We live in the world of ACME / Let's Encrypt / ZeroSSL. Many proxies have that built in. As such optimizing for unverified TLS takes the user down a path that's just more difficult to begin with (it's easier to get a valid TLS cert than it is to get a self-signed cert these days), and more nuanced (upcoming implementors are accustomed to TLS being verified). It's easy to document how to use the letsencrypt client with postgres. It will also be increasingly easy to configure an ACME-enable proxy for postgres and not worry about it in the server at all.

I don't think we should build specifically to support decrypting
connection proxies, and thus I don't think that proxy argument holds
value.

> With all that, there's still this issue of downgrade attacks that can't be solved without a breaking change (or unless the user is skilled enough to know to be explicit). I wish that could change with the next major version of postgres - for the client to have to opt-in to insecure connections (I assume that more and more TLS on the serverside will be handled by proxies).

AFAIK, --sslmode=require already prevents downgrade attacks (assuming
your ssl library does its job correctly). What more would PostgreSQL
need to do?

> I assume that more and more TLS on the serverside will be handled by proxies

I see only negative value there: We have TLS to ensure end-to-end
connection security. A proxy in between adds overhead and negates this
security principle.

> Don't add extra flags

We can't add completely new configurable features without adding new
configuration options (i.e. flags) for those configurable features. If
you don't want new options, you're free to stay at older versions.

> Allow the user to specify ALPN
>
> I don't think this is particularly controversial or nuanced, so I don't have much to say here - most TLS tools allow the user to specify ALPN for the same reason they allow specifying the port number - either for privacy, security-by-obscurity, or navigating some form of application or user routing.

As I mentioned above, I don't see any value, and only demerits, in the
psql client reporting support for anything other than the protocol
that PostgreSQL supports, i.e. the alpn identifier "postgresql".

Kind regards,

Matthias van de Meent