On 12 Apr. 2017 17:27, "Magnus Hagander" <mag...@hagander.net> wrote:
On Wed, Apr 12, 2017 at 11:13 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote: > On 04/12/2017 11:22 AM, Magnus Hagander wrote: > >> On Wed, Apr 12, 2017 at 3:25 AM, Bruce Momjian <br...@momjian.us> wrote: >> >> And which enterprises are using SSL without certificates? And I thought >>> channel binding required certificates anyway, e.g.: >>> >>> https://en.wikipedia.org/wiki/Salted_Challenge_Response_ >>> Authentication_Mechanism#Channel_binding >>> >>> For instance, for the tls-server-end-point channel binding, it is >>> the >>> server's TLS certificate. >>> >> >> AFAIK it does require the TLS certifificates, but it does not require TLS >> certificate *validation*. You can use channel binding with just >> self-signed >> certs. >> > > tls-server-end-point channel binding type relies on certificates. But > SCRAM uses "tls-unique" by default, and it does not use certificates. It's > a bit weird that the wikipedia article uses tls-server-end-point as the > example, I don't know why anyone would use tls-server-end-point with SCRAM. Interesting. But we don't support TLS without certificates, do we? We support it without client certificates, but we need a server certificate. So the TLS connection itself still relies on the certificates, justn ot the channel binding. Actually, by default we just use the server certificate as a public key container. libpq pretty much ignores the rest of the certificate's ASN.1 data (or rather, doesn't ask OpenSSL to care about it). It doesn't do any trust chain checking to find a path to a root cert. It doesn't check the host name/IP. It doesn't remember the key for later connections, SSH known-hosts style. You can freely MITM a sslmode=require libpq connection with your own self signed cert based proxy and nobody will be the wiser. It provides only transport encryption. Or just have your MITM not offer SSL; libpq silently degrades to unencrypted in its default sslmode=prefer mode :( If you use sslmode=verify-full then you get the behaviour you'd normally expect - validation of server key against local trusted cert, and ip/hostname check. Even then we don't do any sort of smart cert trust path finding like libnss or Java's JSSE do. We just look at the cert file and expect it to have signed the server's cert. But at least we can do some kind of validation. It's painful if you talk to multiple different servers with different certs, but it works. I'm not taking a position on the urgency of channel binding by pointing this out. Just trying to set out current behaviour and limitations.