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 make sslmode=​ 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(at)iki(dot)fi

- https://www.postgresql.org/message-id/flat/ad45965c-8b95-4bde-bf05-509ab6fccf96(at)iki(dot)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