Re: fe-secure.c and SSL/TLS
От | Jeffrey Walton |
---|---|
Тема | Re: fe-secure.c and SSL/TLS |
Дата | |
Msg-id | CAH8yC8nZVUyCQznkQd8=ELMM4k_=uXJRjt8YF9V22Cy2x_dDjQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: fe-secure.c and SSL/TLS (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-bugs |
Thanks Peter. On Fri, Nov 22, 2013 at 8:22 AM, Peter Eisentraut <peter_e@gmx.net> wrote: > On 11/12/13, 11:49 PM, Jeffrey Walton wrote: >> I believe fe-secure.c has a few opportunities for improvement. I >> believe the first three are features requests/improvements, but the >> fourth and fifth could be a security vulnerabilities. > > Please create patches and send them to the next commit fest. That is a pretty cool concept. > that the current commit fest contains a few SSL-related patches, which > might overlap with your suggestions: > https://commitfest.postgresql.org/action/commitfest_view?id=20 I kind of disagree with this from http://www.postgresql.org/message-id/20131114231105.GA23669@gmail.com: Main goal is to leave low-level ciphersuite details to OpenSSL guys and give clear impression to Postgres admins what it is about. 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 ;) From this comment at http://www.postgresql.org/message-id/20131114231105.GA23669@gmail.com: !aNULL Needed to disable suites that do not authenticate server. DEFAULT includes !aNULL by default. If server authentication is desired, then SSL_get_verify_result should be called in addition to the name checks when in an enterprise environment (i.e., a CAfile was provided) or the client knows who to trust (by whatever means). Ommiting SSL_get_verify_result basically results in an ADH-like protocol :) Its OK for opportunistic encryption, but its not OK for an enterprise deployment running a private PKI or the client knows who to trust. Also, what about eNULL? Is it OK to send authenticated plain text (that's what the eNULL:!aNULL combination provides). Jeff
В списке pgsql-bugs по дате отправления: