Skip site navigation (1) Skip section navigation (2)

Re: BUG #4340: SECURITY: Is SSL Doing Anything?

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Dan Kaminsky <dan(at)doxpara(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4340: SECURITY: Is SSL Doing Anything?
Date: 2008-08-19 19:48:13
Message-ID: 48AB237D.4090201@hagander.net (view raw or flat)
Thread:
Lists: 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

In response to

Responses

pgsql-bugs by date

Next:From: Andrew SullivanDate: 2008-08-19 19:52:07
Subject: Re: BUG #4340: SECURITY: Is SSL Doing Anything?
Previous:From: Dan KaminskyDate: 2008-08-19 19:40:00
Subject: Re: BUG #4340: SECURITY: Is SSL Doing Anything?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group