Re: BUG #4340: SECURITY: Is SSL Doing Anything? - Mailing list pgsql-bugs

Dan Kaminsky wrote:
>
>>> 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)
>>
>>
> If the only roots set up are private roots, it works great.
>
> If there are generic roots (Verisign etc), or if no roots are checked at
> all, it's useless.
>
> Pretty simple

Good, then we're in agreement that far.

(FWIW, I don't think I've ever seen a PostgreSQL server with a
certificate off a global root. I've seen plenty off a corporate root
though, which could in theory have similar issues - but at least you're
in control of your own problem in that case)


>>> 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
>>
> See, I don't care *why* things are broken -- whether they're broken at
> the application, at libpq, or at openssl, I'm asking the direct question
> -- is SSL doing anything in common deployment, and if not, what needs to
> be done to fix that?
>
> Background:  After the DNS flaw was found, I started looking around to
> see if SSL was a legitimate protection.  Everywhere I looked, I found
> issues.  It's pretty embarrassing to find out that even SSL VPN's aren't
> checking certs.  So, yeah, I'm looking to see what level of protection
> is out there.
>
> So, not caring *why* things are broken -- is it fair to say that libpq's
> use of SSL didn't defend against the DNS bug, in any scenario except
> where custom roots were set up?

Yes, I think that's fair. You *can* do the verification yourself, but
libpq will not do it for you.

Only I will claim that the common deployment, as you refer to above,
*is* with a custom root. PostgreSQL server are *very* seldom "published
to the internet", and therefor tend not to use the global CA roots.

//Magnus