I had a conversation a while back with Heikki where he expressed that it was annoying that we negotiate SSL/TLS the way we do since it introduces an extra round trip. Aside from the performance optimization I think accepting standard TLS connections would open the door to a number of other opportunities that would be worth it on their own.
So I took a look into what it would take to do and I think it would actually be quite feasible. The first byte of a standard TLS connection can't look anything like the first byte of any flavour of Postgres startup packet because it would be the high order bits of the length so unless we start having multi-megabyte startup packets.... So I put together a POC patch and it's working quite well and didn't require very much kludgery. Well, it required some but it's really not bad. I do have a bug I'm still trying to work out and the code isn't quite in committable form but I can send the POC patch. Other things it would open the door to in order from least controversial to most.... * Hiding Postgres behind a standard SSL proxy terminating SSL without implementing the Postgres protocol. * "Service Mesh" type tools that hide multiple services behind a single host/port ("Service Mesh" is just a new buzzword for "proxy"). * Browser-based protocol implementations using websockets for things like pgadmin or other tools to connect directly to postgres using Postgres wire protocol but using native SSL implementations. * Postgres could even implement an HTTP based version of its protocol and enable things like queries or browser based tools using straight up HTTP requests so they don't need to use websockets. * Postgres could implement other protocols to serve up data like status queries or monitoring metrics, using HTTP based standard protocols instead of using our own protocol. 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. -- greg