Dan Kaminsky wrote:
>
>
> Tom Lane wrote:
>> Magnus Hagander <magnus@hagander.net> writes:
>>
>>> (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)
>>>
>>
>> In common usages libpq doesn't have the FQDN of the server either.
>> To impose such a requirement, we'd have to forbid naming the server
>> by IP address or via a domain-search-path abbreviation.
>>
>> regards, tom lane
>>
> Well, right now, SSL does nothing for you, so you have to do something.
> It's OK, SSL isn't doing a lot for a lot of people, but this is the
> beginning of us calling people out on that.
Do feel free to explain how it "does nothing" for you with properly set
up certificates (see my previous email). (I'm still not saying it cannot
be significantly improved, of course)
> You can handle IP address and domain-search-path by having an option for
> explicitly declaring the subject name to be expected at the other side
> of the SSL connection. In other words, sever the DNS/FQDN link, and
> just explicitly say "however I reach that host over there, I expect
> database.backend.com".
You can do this today. If you are willing to do it in the application,
just verify the certificate DN and you're done.
Yes, it would certainly be a lot better to do the validation earlier in
the chain (if you're sending plaintext password, you'll end up sending
the password before you do the validation. But I don't think you even
can do that in current versions), and if it was slightly easier to do,
but you can certainly validate the cert if you want to.
//Magnus