Dan Kaminsky wrote:
>
>
> Tom Lane wrote:
>> Dan Kaminsky <dan@doxpara.com> writes:
>>
>>> My question has been: When you attempt to create an SSL connection
>>> to database.backend.com, do you actually validate that:
>>>
>>
>>
>>> 1) The subject name of the certificate you're connecting to is
>>> database.backend.com, and
>>> 2) At least the basic checks (expiration, chaining back to a valid
>>> root) occur?
>>>
>>
>> [ shrug... ] We do whatever OpenSSL's default validation behavior is.
>> If that's inadequate you probably ought to be taking it up with them,
>> instead of trying to get downstream projects to fix it one at a time.
>>
>> regards, tom lane
>>
> Heh, you're the one making guarantees to your users. I'm just asking
> the exact nature of those guarantees. I agree that #2 is entirely under
> the control of OpenSSL -- but I'd like to know if #1 is being satisfied,
> i.e. OpenSSL knows you're looking to validate database.backend.com as
> opposed to "some cert that chains back", which is a worthless security
> assertion.
We do not validate the name. It is stated in a comment at the top of
f-secure.h that we do, but the code is all behind #ifdef NOT_USED. It
would probably not be a bad idea to have that check enabled by default,
but a way to turn it off.
(I don't believe OpenSSL does this verification either, because AFAICS
OpenSSL only ever sees the IP address of the server, and not the FQDN)
We do, however, return the peer certificate information to the libpq
client, that can verify this if it's considered necessary by the
*application*.
That said, claiming that the check of the chain up to a root certificate
is wortheless is very far from correct. Used the proper way, and the
way I most often see it deployed with PostgreSQL, makes it very worthy.
Because people normally either bundle the server certificate itself with
the application, in which case it will only ever connect to that server
(self-signed cert). Or they have a dedicated CA for this purpose. Is it
perfect? Far from. But it's certainly not worthless.
//Magnus