Re: fe-secure.c and SSL/TLS - Mailing list pgsql-hackers
From | Jeffrey Walton |
---|---|
Subject | Re: fe-secure.c and SSL/TLS |
Date | |
Msg-id | CAH8yC8kCp_FyKoK+mYfu2WNQSo_Wsgo9w8J0Qyw113RRqaZ9EQ@mail.gmail.com Whole thread Raw |
In response to | Re: fe-secure.c and SSL/TLS (Marko Kreen <markokr@gmail.com>) |
Responses |
Re: fe-secure.c and SSL/TLS
(Marko Kreen <markokr@gmail.com>)
|
List | pgsql-hackers |
Hi Marko, Forgive me for cherry picking two of these... > I think Postgres uses SSL_VERIFY_PEER + SSL_set_verify() callback instead. > At least for me, the psql -d "dbname=foo sslmode=verify-ca" fails > when cert does not match. I can't comment on the use of psql. My apologies for my ignorance. However, here's what I see in fe-secure.c around line 695: static int verify_cb(int ok, X509_STORE_CTX *ctx) { return ok; } If `ok` is 0, then validation fails. To learn of the failure, a program must call SSL_get_verify_result to fetch the error code. Error codes are listed at https://www.openssl.org/docs/apps/verify.html. If `ok` is always 1, then validation succeeds. To learn of the success, a program must call SSL_get_verify_result and ensure X509_V_OK is returned. I know of no other ways to check the result of OpenSSL's chain validation. The open question (for me) is where are SSL_get_verify_result/X509_V_OK checked? Neither show up in the Postgres sources. > 1) OpenSSL guys change default back to TLSv1.0+. > 2) OpenSSL guys give switch to make TLSv1_method() mean TLSv1.0+. Well, I don't think that's going to happen, but I could be wrong :) For what its worth, I agree with you. I want a TLSv1.0+ option and even had this discussion with Tim Hudson offline. > 3) libpq starts using TLSv1_2_method() by default. > 4) libpq will give switch to users to request TLSv1.2. This might have negative effects on non-TLSv1.2 clients. For example, an Android 2.3 device can only do TLSv1.0 (IIRC). I think there's a similar limitation on a lot of Windows XP clients (depending on the IE version and SChannel version). And OpenSSL-based clients prior to 1.0.0h (released 14 Mar 2012) will have trouble (if I am reading the change log correctly). I believe the "standard" way of achieving TLS1.0 and above is to use the SSLv23_client_method() and then remove the SSL protocols with SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3. I have to use handwaiving around "standard" because I don't believe its documented anywhere (one of the devs told me its the standard way to do it.). Jeff On Fri, Nov 29, 2013 at 3:19 PM, Marko Kreen <markokr@gmail.com> wrote: > Reply to mails in pgsql-bugs: > > http://www.postgresql.org/message-id/CAH8yC8mc_2J2UY0Q42WQdWFyaoqT3onG+83Fr=vN46J5+ML94g@mail.gmail.com > > and > > http://www.postgresql.org/message-id/CAH8yC8nZVUyCQznkQd8=ELMM4k_=uXJRjt8YF9V22Cy2x_dDjQ@mail.gmail.com > > > * Default ciphersuite > >> I would argue nothing should be left to chance, and the project should >> take control of everything. But I don't really have a dog in the fight ;) > > Indeed, on my own servers I've stopped bothering with pattern-based > ciphersuite strings, now I am listing ciphers explicitly. > > But the discussion here is about default suite for admins who don't > know or care about TLS. Also, it would be good if it does not > need to be tuned yearly to stay good. > > > * SSL_get_verify_result > > I think Postgres uses SSL_VERIFY_PEER + SSL_set_verify() callback instead. > At least for me, the psql -d "dbname=foo sslmode=verify-ca" fails > when cert does not match. > > > * SNI (Server Name Indication extension). > > It might be proper to configure it for connections, but it's unlikely > to be useful as the many-domains-few-ips-one-port problem really does > not apply to databases. And from my experience, even the non-SNI > hostname check is underused (or even - unusable) in many database > setups. > > > * TLSv1.2 > > That's the remaining problem with Postgres SSL - new SHA2/AESGCM > ciphersuites will not be used even when both client and server > support them. Also CBC-mode fixes in TLSv1.1 will be missed. > > It's a client-side OpenSSL problem and caused indeed > by following line in fe-secure.c: > > SSL_context = SSL_CTX_new(TLSv1_method()); > > It's an ugly problem, because TLSv1_method() actually *should* mean > "TLSv1.0 and higher", but due to problems with various broken > SSL implementations, it's disabled. > > I see various ways it can improve: > > 1) OpenSSL guys change default back to TLSv1.0+. > 2) OpenSSL guys give switch to make TLSv1_method() mean TLSv1.0+. > 3) libpq starts using TLSv1_2_method() by default. > 4) libpq will give switch to users to request TLSv1.2. > > I see 1) and 3) as unlikely to happen. As it's not an urgent problem, > we could watch if 2) happens and go with 4) otherwise. > > > I tried your suggested OP_ALL patch and it does not work. And it's > even harmful to use as it disables few security workarounds. > It's mainly for servers for compat with legacy browsers. > > I also tried to clear OP_NO_TLSv1_x to see if there is some default > OPs in TLSv1_method() that we could change, but that also did not work. > My conclusion is that currently there is no switch to make TLSv1.0+ > work. (OpenSSL v1.0.1 / 1.1.0-git). >
pgsql-hackers by date: