Re: [HACKERS] Possible SSL improvements for a newcomer to tackle

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: [HACKERS] Possible SSL improvements for a newcomer to tackle
Дата
Msg-id CABUevEx4Q8O8MhoxeDPNLo_jP31_gcN7qwJG+WGQ7+aKW_nzyQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Possible SSL improvements for a newcomer to tackle  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Possible SSL improvements for a newcomer to tackle  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


On Tue, Oct 3, 2017 at 6:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Zeus Kronion <zkronion@gmail.com> writes:
> 2) I was surprised to learn the following from the docs:

>> By default, PostgreSQL will not perform any verification of the server
>> certificate.

> Is there a technical reason to perform no verification by default? Wouldn't
> a safer default be desirable?

I'm not an SSL expert, so insert appropriate grain of salt, but AIUI the
question is what are you going to verify against?  You need some local
notion of which are your trusted root certificates before you can verify
anything.  So to default to verification would be to default to failing to
connect at all until user has created a ~/.postgresql/root.crt file with
valid, relevant entries.  That seems like a nonstarter.

Yes, you need something to verify against.

One way to do it would be to default to the "system global certificate store", which is what most other SSL apps do. For example on a typical debian/ubuntu, that'd be the store in /etc/ssl/certs/ca-certificates.crt. Exactly where to find them would be distribution-specific though, and we would need to actually add support for a second certificate store. But that would probably be a useful feature in itself.

 
It's possible that we could adopt some policy like "if the root.crt file
exists then default to verify" ... but that seems messy and unreliable,
so I'm not sure it would really add any security.

No that's horrible. If it's unreliable, it doesn't provide any actual benefit. We have a history of that in our default being prefer instead of allow, but we definitely shouldn't make that situation even worse. 

--

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Vladimir Sitnikov
Дата:
Сообщение: Re: [HACKERS] 64-bit queryId?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] SendRowDescriptionMessage() is slow for queries with alot of columns