mirror of
https://github.com/postgres/postgres.git
synced 2025-11-26 23:43:30 +03:00
We don't actually support session tickets, since we do not create an SSL session identifier. But it seems that OpenSSL will issue a session ticket on-demand anyway, which will then fail when used. This results in reconnection failures when using ticket-aware client-side SSL libraries (such as the Npgsql .NET driver), as reported by Shay Rojansky. To fix, just tell OpenSSL not to issue tickets. At some point in the far future, we might consider enabling tickets instead. But the security implications of that aren't entirely clear; and besides it would have little benefit except for very short-lived database connections, which is Something We're Bad At anyhow. It would take a lot of other work to get to a point where that would really be an exciting thing to do. While at it, also tell OpenSSL not to use a session cache. This doesn't really do anything, since a backend would never populate the cache anyway, but it might gain some micro-efficiencies and/or reduce security exposures. Patch by me, per discussion with Heikki Linnakangas and Shay Rojansky. Back-patch to all supported versions. Discussion: https://postgr.es/m/CADT4RqBU8N-csyZuzaook-c795dt22Zcwg1aHWB6tfVdAkodZA@mail.gmail.com
src/backend/libpq/README.SSL
SSL
===
>From the servers perspective:
Receives StartupPacket
|
|
(Is SSL_NEGOTIATE_CODE?) ----------- Normal startup
| No
|
| Yes
|
|
(Server compiled with USE_SSL?) ------- Send 'N'
| No |
| |
| Yes Normal startup
|
|
Send 'S'
|
|
Establish SSL
|
|
Normal startup
>From the clients perspective (v6.6 client _with_ SSL):
Connect
|
|
Send packet with SSL_NEGOTIATE_CODE
|
|
Receive single char ------- 'S' -------- Establish SSL
| |
| '<else>' |
| Normal startup
|
|
Is it 'E' for error ------------------- Retry connection
| Yes without SSL
| No
|
Is it 'N' for normal ------------------- Normal startup
| Yes
|
Fail with unknown
---------------------------------------------------------------------------