Обсуждение: Comments about TLS (no SSLRequest) and ALPN
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
--tlsv1.3 # same as curl; require tls
-k, --insecure # same as curl: don't require verification
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)
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
- We've more or less reached Peak Database, therefore Postgres will probably be around in another 20 years. There's probably not going to be a significant advance in storage and indexing technology that would make Postgres obsolete (re: the only NoSQL database left is Mongo, and in the next "revolution", that generation will likely come back around to the same conclusions people reached in the 1960s and 1970s: "relational algebra wins" and "SQL syntax is good enough").
- We've more or less reached Peak Web, therefore TLS or a very close successor will probably be around in another 20 years as well. Even if a non-incremental, non-backwards-compatible protocol that is extraordinarily better were announced by a FAANG consortium tomorrow and immediately available by patches from them in every major product they touch, sunsetting TLS would probably take 20+ years.
- Postgres versions (naturally) take years to make it into mainstream LTS server distros (without explicit user interaction anyway)
- All of that is to say that I believe that optimizing for the Happy Path is going to be a big win. Optimizing for previous behavior will just make "easy, secure defaults" take (perhaps decades) longer to be fully adopted, and may not have any measurable benefit now or in the future.
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.
- 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.
- 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.
- 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.
- 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).
Don't add extra flags
sslnegotiation=xxxx
seems to makesslmode=
more confusing - which modes will be compatible? Will it come into conflict more if others are added in the future? How many conflict-checks will be needed in the client code that make reading that code more complicated? What all has to be duplicated now (i.e. require)? How about the future?- reusing
sslmode=
and adding new flags is simpler and less error prone - "sslnegotiation" is also prolonging the use of the term "ssl" for something that isn't actually "ssl"
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.
Re:
- https://www.postgresql.org/message-id/flat/ad45965c-8b95-4bde-bf05-509ab6fccf96@iki.fi
- https://www.postgresql.org/message-id/flat/ad45965c-8b95-4bde-bf05-509ab6fccf96@iki.fi
- https://www.postgresql.org/message-id/ECNyobMWPeoCd4yj_5J0RsDL1yKC9MbbBwOGCYHgcts7v0BW_-znGIoxcvfzUsf3yKvUB6Lef22OBMZnJyZ-0T2U1qaVflQqEGO0RFHp1PE%3D%40proton.me
- https://www.postgresql.org/message-id/y3hCpl3ALJQPlIn8aKG19aiYbNM_HbchVTOqlwm2Y9OE-sWmtre-Cljlt9Jd_yYsv5S3mDNG-T5OXXfU8GgDrdu2MjTBEcWl23_NUesj8i8%3D%40proton.me
AJ ONeal
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