Reply to mails in pgsql-bugs: http://www.postgresql.org/message-id/CAH8yC8mc_2J2UY0Q42WQdWFyaoqT3onG+83Fr=vn46j5+ml...@mail.gmail.com
and http://www.postgresql.org/message-id/CAH8yC8nZVUyCQznkQd8=ELMM4k_=uxjrjt8yf9v22cy2x_d...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
