Thread: BUG #14395: sslmode=prefer not checking for certificate and allows connection as SSL
BUG #14395: sslmode=prefer not checking for certificate and allows connection as SSL
From
balaji.chithambaram@capitalone.com
Date:
VGhlIGZvbGxvd2luZyBidWcgaGFzIGJlZW4gbG9nZ2VkIG9uIHRoZSB3ZWJz aXRlOgoKQnVnIHJlZmVyZW5jZTogICAgICAxNDM5NQpMb2dnZWQgYnk6ICAg ICAgICAgIEJhbGFqaSBDaGl0aGFtYmFyYW0KRW1haWwgYWRkcmVzczogICAg ICBiYWxhamkuY2hpdGhhbWJhcmFtQGNhcGl0YWxvbmUuY29tClBvc3RncmVT UUwgdmVyc2lvbjogOS41LjQKT3BlcmF0aW5nIHN5c3RlbTogICBSZWQgSGF0 IEVudGVycHJpc2UgTGludXggU2VydmVyIHJlbGVhc2UgNi44CkRlc2NyaXB0 aW9uOiAgICAgICAgCgpXaGVuIHdlIHVzZSBkZWZhdWx0IGNsaWVudCBtZXRo b2Qgc3NsbW9kZT1wcmVmZXIgZXhwZWN0ZWQgYmVoYXZpb3VyIGlzIHRvCnRy eSBzc2wgY29ubmVjdGlvbiBieSB2YWxpZGF0aW5nIHRoZSBjZXJ0aWZpY2F0 ZSBhbmQgdGhlbiBpZiBpdCBkb2Vzbid0IGdvCmZvciBub24tU1NMIGNvbm5l Y3Rpb24uIEJ1dCBzc2xtb2RlPXByZWZlciBnb2VzIHRvIFNTTCBjb25uZWN0 aW9uIHdpdGhvdXQKY2hlY2tpbmcgY2VydGlmaWNhdGUgcHJvdmlkZWQuDQoN ClRoaXMgZ2l2ZXMgYW4gb3B0aW9uIGlmIGFueSBzZXJ2ZXJzIGlwIGNvbmZp Z3VyZWQgZm9yIHNzbCBjb25uZWN0aW9uIGNhbiBiZQpzcG9vZmVkIGJ5IHdp dGggc2FtZSBpcCwgdGhvdWdoIHdlIGVuZm9yY2VkIHNzbCB3aXRoIGNlcnRp ZmljYXRlLCBpdCBjYW4KY29ubmVjdCB3aXRoIG91dCBhY3R1YWwgY2VydGlm aWNhdGUgYW5kIGRlZmVhdHMgdGhlIHB1cnBvc2UuCgo=
Re: BUG #14395: sslmode=prefer not checking for certificate and allows connection as SSL
From
Andres Freund
Date:
On 2016-10-25 13:50:16 +0000, balaji.chithambaram@capitalone.com wrote: > The following bug has been logged on the website: > > Bug reference: 14395 > Logged by: Balaji Chithambaram > Email address: balaji.chithambaram@capitalone.com > PostgreSQL version: 9.5.4 > Operating system: Red Hat Enterprise Linux Server release 6.8 > Description: > > When we use default client method sslmode=prefer expected behaviour is to > try ssl connection by validating the certificate and then if it doesn't go > for non-SSL connection. But sslmode=prefer goes to SSL connection without > checking certificate provided. > > This gives an option if any servers ip configured for ssl connection can be > spoofed by with same ip, though we enforced ssl with certificate, it can > connect with out actual certificate and defeats the purpose. If somebody can MITM the connection, they can also fake not supporting SSL. sslmode=prefer simply isn't an adequate protection against that, and you need to use sslmode=verify-ca or verify-full.
Re: BUG #14395: sslmode=prefer not checking for certificate and allows connection as SSL
From
Andres Freund
Date:
On 2016-10-25 14:41:34 +0000, Chithambaram, Balaji (CONT) wrote: > We can enforce on our client setup sslmode=verify-ca or > verify-full. I guess you meant "can't" not "can"? > How can we make sure sslmode=prefer either checks the > certificate and establish ssl connection or not to try setting up ssl > connection. That's a nonsensical configuration, you can't. > Let me ask in another way, is it possible to block sslmode=prefer from > any clients on the server configuration like postgresql.conf or > pg_hba.conf or in any other place. No. Client configuration can't be enforced on the serverside. Random client libraries can do whatever they want. Andres
Re: BUG #14395: sslmode=prefer not checking for certificate and allows connection as SSL
From
"Chithambaram, Balaji (CONT)"
Date:
We can enforce on our client setup sslmode=3Dverify-ca or verify-full. How = can we make sure sslmode=3Dprefer either checks the certificate and establi= sh ssl connection or not to try setting up ssl connection. Let me ask in another way, is it possible to block sslmode=3Dprefer from a= ny clients on the server configuration like postgresql.conf or pg_hba.conf = or in any other place. Thanks, Balaji CT -----Original Message----- From: Andres Freund [mailto:andres@anarazel.de] = Sent: Tuesday, October 25, 2016 10:21 AM To: Chithambaram, Balaji (CONT) <Balaji.Chithambaram@capitalone.com> Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #14395: sslmode=3Dprefer not checking for certifica= te and allows connection as SSL On 2016-10-25 13:50:16 +0000, balaji.chithambaram@capitalone.com wrote: > The following bug has been logged on the website: > = > Bug reference: 14395 > Logged by: Balaji Chithambaram > Email address: balaji.chithambaram@capitalone.com > PostgreSQL version: 9.5.4 > Operating system: Red Hat Enterprise Linux Server release 6.8 > Description: = > = > When we use default client method sslmode=3Dprefer expected behaviour is = > to try ssl connection by validating the certificate and then if it = > doesn't go for non-SSL connection. But sslmode=3Dprefer goes to SSL = > connection without checking certificate provided. > = > This gives an option if any servers ip configured for ssl connection = > can be spoofed by with same ip, though we enforced ssl with = > certificate, it can connect with out actual certificate and defeats the p= urpose. If somebody can MITM the connection, they can also fake not supporting SSL.= sslmode=3Dprefer simply isn't an adequate protection against that, and you= need to use sslmode=3Dverify-ca or verify-full. ________________________________________________________ The information contained in this e-mail is confidential and/or proprietary= to Capital One and/or its affiliates and may only be used solely in perfor= mance of work or services for Capital One. The information transmitted here= with is intended only for use by the individual or entity to which it is ad= dressed. If the reader of this message is not the intended recipient, you a= re hereby notified that any review, retransmission, dissemination, distribu= tion, copying or other use of, or taking of any action in reliance upon thi= s information is strictly prohibited. If you have received this communicati= on in error, please contact the sender and delete the material from your co= mputer.
Re: BUG #14395: sslmode=prefer not checking for certificate and allows connection as SSL
From
"Chithambaram, Balaji (CONT)"
Date:
We can enforce on our client setup sslmode=3Dverify-ca or verify-full. [ I = was trying to make a statement that we can do this ]. Problem I see , sslmode=3Dprefer is not checking for certificate and if you= go the logs on server side or psql client prompt, it is saying established= SSL connection with protocols and so on . Documentation says sslmode=3Dpre= fer is the default client setup and we are using 9.5 clients. So if we mak= e sslmode=3Dprefer to check for certificate or if we block ssl connection i= tself while setting up sslmode=3Dprefer any one of those would help us and = trying to see solution on that angle. -----Original Message----- From: Andres Freund [mailto:andres@anarazel.de] = Sent: Tuesday, October 25, 2016 10:45 AM To: Chithambaram, Balaji (CONT) <Balaji.Chithambaram@capitalone.com> Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #14395: sslmode=3Dprefer not checking for certifica= te and allows connection as SSL On 2016-10-25 14:41:34 +0000, Chithambaram, Balaji (CONT) wrote: > We can enforce on our client setup sslmode=3Dverify-ca or verify-full. I guess you meant "can't" not "can"? > How can we make sure sslmode=3Dprefer either checks the certificate and = > establish ssl connection or not to try setting up ssl connection. That's a nonsensical configuration, you can't. > Let me ask in another way, is it possible to block sslmode=3Dprefer from = > any clients on the server configuration like postgresql.conf or = > pg_hba.conf or in any other place. No. Client configuration can't be enforced on the serverside. Random client= libraries can do whatever they want. Andres ________________________________________________________ The information contained in this e-mail is confidential and/or proprietary= to Capital One and/or its affiliates and may only be used solely in perfor= mance of work or services for Capital One. The information transmitted here= with is intended only for use by the individual or entity to which it is ad= dressed. If the reader of this message is not the intended recipient, you a= re hereby notified that any review, retransmission, dissemination, distribu= tion, copying or other use of, or taking of any action in reliance upon thi= s information is strictly prohibited. If you have received this communicati= on in error, please contact the sender and delete the material from your co= mputer.