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.
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?
--Dan
--Dan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
