Re: PostgreSQL - Weak DH group
От | Heikki Linnakangas |
---|---|
Тема | Re: PostgreSQL - Weak DH group |
Дата | |
Msg-id | fd6eb3cc-1585-1469-fd9e-763f8e410b19@iki.fi обсуждение исходный текст |
Ответ на | Re: PostgreSQL - Weak DH group (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: PostgreSQL - Weak DH group
Re: PostgreSQL - Weak DH group |
Список | pgsql-hackers |
On 10/05/2016 09:57 PM, Heikki Linnakangas wrote: > On 10/05/2016 05:15 PM, Nicolas Guini wrote: >> We are working with Postgres 9.3.14 and executing nmap we >> found that it is using “weak DH group” (nmap –script ssl-dh-params). Weak = >> 1024 bits. > > Yeah, it seems that we're a bit behind the times on this... > >> This issue is similar to what this post explains about using weak DH >> parameters: http://www.usefuljs.net/2016/09/29/imperfect-forward-secrecy/ > > The blog post points out that, as counterintuitive as it sounds, the > SSL_CTX_set_tmp_dh_callback() callback should ignore the keylength > argument, and always return a DH group with 2048 bits, or stronger. As > you pointed out, that's not what our callback does. I propose the attached patch. It gives up on trying to deal with multiple key lengths (as noted earlier, OpenSSL just always passed keylength=1024, so that was useless). Instead of using the callback, it just sets fixed DH parameters with SSL_CTX_set_tmp_dh(), like we do for the ECDH curve. The DH parameters are loaded from a file called "dh_params.pem" (instead of "dh1024.pem"), if present, otherwise the built-in 2048 bit parameters are used. I removed the code for generating DH parameters on-the-fly altogether. The OpenSSL man page clearly says that that should not be done, because generating the parameters takes a long time. And because OpenSSL always passed keylength=1024, AFAICS that had been always dead code. If we want to get really fancy, we could generate the parameters the first time you turn ssl=on, and store them in $PGDATA. But the generation takes a very long time, so the admin might think it's stuck. I note that supplying custom DH parameters in the file is completely undocumented :-(. We should add a note in the docs on how to generate the custom DH parameters with openssl. Also, there's no easy way of telling if your custom parameters are actually been used. If you copy the params file in $PGDATA, but you have a typo in the name, you won't notice. Perhaps we should print a line in the log when the file is loaded. I'm afraid of back-patching this, out of fear that older clients would stop working, or would downgrade to an even weaker cipher. You could fix it by putting weaker 1024 bit params in dh_params.pem, so maybe we could do it if we put a warning and instructions for doing that in the release notes. Thoughts? - Heikki
Вложения
В списке pgsql-hackers по дате отправления: