Re: OpenSSL 3.0.0 compatibility
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Michael Paquier <michael@paquier.xyz>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-07-03T15:00:42Z
Lists: pgsql-hackers
Attachments
- 0001-Use-EVP_EncryptFinal_ex-and-EVP_DecryptFinal_ex.patch (text/plain) patch 0001
On 12.03.21 08:51, Peter Eisentraut wrote: > > On 11.03.21 11:41, Daniel Gustafsson wrote: >> .. and apply the padding changes as proposed in a patch upthread like >> this (these >> work for all OpenSSL versions I've tested, and I'm rather more puzzled >> as to >> why we got away with not having them in the past): > > Yes, before proceeding with this, we should probably understand why > these changes are effective and why they haven't been required in the past. I took another look at this with openssl-3.0.0-beta1. The issue with the garbled padding output is still there. What I found is that pgcrypto has been using the encryption and decryption API slightly incorrectly. You are supposed to call EVP_DecryptUpdate() followed by EVP_DecryptFinal_ex() (and similarly for encryption), but pgcrypto doesn't do the second one. (To be fair, this API was added to OpenSSL after pgcrypto first appeared.) The "final" functions take care of the padding. We have been getting away with it like this because we do the padding manually elsewhere. But apparently, something has changed in OpenSSL 3.0.0 in that if padding is enabled in OpenSSL, EVP_DecryptUpdate() doesn't flush the last normal block until the "final" function is called. Your proposed fix was to explicitly disable padding, and then this problem goes away. You can still call the "final" functions, but they won't do anything, except check that there is no more data left, but we already check that elsewhere. Another option is to throw out our own padding code and let OpenSSL handle it. See attached demo patch. But that breaks the non-OpenSSL code in internal.c, so we'd have to re-add the padding code there. So this isn't quite as straightforward an option. (At least, with the patch we can confirm that the OpenSSL padding works consistently with our own implementation.) So I think your proposed patch is sound and a good short-term and low-risk solution.
Commits
-
Define OPENSSL_API_COMPAT
- 96f96398d398 11.21 landed
- 265c9138da58 12.16 landed
- 8aa9a26236aa 13.12 landed
- 4d3db13621be 14.0 landed
-
Add alternative output for OpenSSL 3 without legacy loaded
- eb643536b9f1 10.19 landed
- 8e7199453bf9 13.5 landed
- 7b6ce36fbab5 12.9 landed
- 6d0001aabf2a 14.0 landed
- 19e91a40bf26 11.14 landed
- 72bbff4cd6ea 15.0 landed
-
Disable OpenSSL EVP digest padding in pgcrypto
- e802b594e794 10.19 landed
- 4fa2b15e1c9c 14.0 landed
- 135d8687adf1 13.5 landed
- 11901cd9628b 11.14 landed
- 00c72da4a22d 12.9 landed
- 318df8023559 15.0 landed
-
pgcrypto: Check for error return of px_cipher_decrypt()
- a69e1506f618 13.5 landed
- 90cfd269f226 12.9 landed
- 841075a65cdc 10.19 landed
- 0f28d267c7e0 11.14 landed
- 22e1943f13b6 14.0 landed
-
OpenSSL 3.0.0 compatibility in tests
- f0d2c65f17ca 13.0 landed
-
Make ssl certificate for ssl_passphrase_callback test via Makefile
- b846091fd0a7 13.0 landed
-
Provide a TLS init hook
- 896fcdb230e7 13.0 cited