Обсуждение: Comments about TLS (no SSLRequest) and ALPN

On Sat, 11 May 2024 at 21:36, AJ ONeal <coolaj86@proton.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
theupcoming 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
sweetand 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
shedlight 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
interactionanyway) 

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
switchto 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
defaultanyway), 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
unverifiedTLS takes the user down a path that's just more difficult to begin with (it's easier to get a valid TLS cert
thanit 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
configurean 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
unlessthe 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
willbe 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
theuser 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

On Sat, 11 May 2024 at 15:36, AJ ONeal <coolaj86@proton.me> wrote:

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

Routing is primarily a feature for "cloud-first" deployments. I.e.
things like Kubernetes or equivalent. I don't think people deploying
to their own metal or on their own network often need this kind of
feature today. Of course we don't know what the future holds and it
could well become more common.

In that context I think it's clear that user-oriented tools like psql
shouldn't change their default behaviour. They need the maximum
flexibility of being able to negotiate plain text and GSSAUTH
connections if possible. It's only applications deployed by the same
cloud environment building tools that deploy the database and SSL
proxies that will know where direct SSL connections are necessary.


> We live in the world of ACME / Let's Encrypt / ZeroSSL. Many proxies have that built in. As such optimizing for
unverifiedTLS takes the user down a path that's just more difficult to begin with (it's easier to get a valid TLS cert
thanit 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
configurean ACME-enable proxy for postgres and not worry about it in the server at all. 

I tend to agree that it would be good for our documentation and
install scripts to assume letsencrypt certs can be requested. That
said there are still a lot of database environments that are not on
networks that can reach internet services directly without special
firewall or routing rules set up.



> 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
theuser 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. 

I think I need a citation before I believe this. I can't imagine it
makes sense for anything other than general purpose TLS testing tools
to allow arbitrary protocol names. It seems like something that would
be mostly useful for pentesting or regression tests. But for actual
deployed applications it doesn't make any sense to me.


--
greg