| |||||||||||||
A serious PostgreSQL security fixA serious PostgreSQL security fixPosted Apr 7, 2013 5:31 UTC (Sun) by gdt (subscriber, #6284)In reply to: A serious PostgreSQL security fix by cesarb Parent article: A serious PostgreSQL security fix
And yet Postgres could have used TLS with client and server certificates. Which would have avoided this attack, even for Internet-visible ports. So it really is throwing stones in a glass house.
(Log in to post comments)
A serious PostgreSQL security fix Posted Apr 7, 2013 9:32 UTC (Sun) by cortana (subscriber, #24596) [Link] It doesn't?
A serious PostgreSQL security fix Posted Apr 7, 2013 12:53 UTC (Sun) by gdt (subscriber, #6284) [Link]
I didn't mean "support" so much as "requires". My apologies for not expressing my thought more clearly.
A serious PostgreSQL security fix Posted Apr 7, 2013 13:59 UTC (Sun) by cesarb (subscriber, #6266) [Link]
AFAIK, the authentication is per-database, which means it has to read the database name from the client before authenticating, even if you are using certificates.
The bug in question involved the client sending an invalid database name.
Oops.
A serious PostgreSQL security fix Posted Apr 7, 2013 22:40 UTC (Sun) by hummassa (subscriber, #307) [Link]
IIRC correctly my SSL/TLS, the authentication (and the start of encrypting the whole session) comes before anything else. I suppose when the client asks for connection to a database, he is already autheticated via his cert (and the dbms can check if he can effectively connect to *that* particular db).
A serious PostgreSQL security fix Posted Apr 7, 2013 23:31 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
SSL/TLS authentication has a very high overhead. Postgresql supports SSL/TLS authentication, but it also supports many other types of authentication so that you can choose what one is the best fit for your needs.
|
|||||||||||||