Re: Some thoughts about SCRAM implementation

On 12 Apr. 2017 17:27, "Magnus Hagander" <magnus(at)hagander(dot)net> wrote:

On Wed, Apr 12, 2017 at 11:13 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
wrote:

> On 04/12/2017 11:22 AM, Magnus Hagander wrote:
>
>> On Wed, Apr 12, 2017 at 3:25 AM, Bruce Momjian <bruce(at)momjian(dot)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.