[review] libpq: Support TLSv1.1+ (was: fe-secure.c and SSL/TLS)
От | Wim Lewis |
---|---|
Тема | [review] libpq: Support TLSv1.1+ (was: fe-secure.c and SSL/TLS) |
Дата | |
Msg-id | 20140110061253.46E0E153E0AE@machamp.omnigroup.com обсуждение исходный текст |
Ответ на | [patch] libpq: Support TLSv1.1+ (was: fe-secure.c and SSL/TLS) (Marko Kreen <markokr@gmail.com>) |
Ответы |
Re: [review] libpq: Support TLSv1.1+ (was: fe-secure.c and SSL/TLS)
|
Список | pgsql-hackers |
I applied both libpq.tls11plus.diff and the related psql.conninfo.tlsver.diff patch to postgresql git head. Source review: The source changes are pretty tiny. Although I think the change from TLSv1_method to SSLv23_method is correct, the comment is not quite correct: > * SSLv23_method() is only method that negotiates > * higher protocol versions. Rest of the methods > * allow only one specific TLS version. As I understand it (backed up by a quick glance through the openssl source), the TLSv1_method, TLSv1_1_method, and TLSv1_2_method will all advertise the corresponding protocol version to the peer, meaning that in practice they will negotiate *up to* that TLS version, but will still negotiate down to SSLv3. So, using TLSv1_2_method would give the right behavior when compiled against a recent openssl. However, someday when TLSv1.3 (or 2.0) appears, presumably the SSLv23_method will be extended to include it but TLSv1_2_method would have to be changed to TLSv1_3_method. Therefore using SSLv23_method and disabling older protocol versions with SSL_CTX_set_options() should have the desired behavior even in future versions. (And it doesn't require autoconf to probe the openssl version.) Testing: I built the patched postgresql against a handful of openssl versions: 1.0.1 (netbsd, x86-64, supports TLSv1.1); Git head aka 1.0.1f++ (osx, x86-32, supports TLSv1.2), and 0.9.8y (osx, x86-32, supports TLSv1.0). They all built cleanly and passed 'make check'. I also built 'contrib' and installed the sslinfo extension. I connected between each pair of versions (with psql) and saw that the connection negotiated the highest protocol version supported by both ends and a corresponding ciphersuite. /conninfo and the sslinfo extension agreed on the protocol version and ciphersuite in use. Things I didn't test: Client certificates, restricted sets of ciphersuites, MITM protocol-downgrade attacks, non-x86 architectures, or 1.0.0* versions of openssl.
В списке pgsql-hackers по дате отправления: