Re: fe-secure.c and SSL/TLS

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).

--
marko