Re: Serverside SNI support in libpq
От | Jacob Champion |
---|---|
Тема | Re: Serverside SNI support in libpq |
Дата | |
Msg-id | CAOYmi+=ZjGJLw8tCkzY88acd=ir1r8eAxO-+5wXm9gtCUV97Sg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Serverside SNI support in libpq (Cary Huang <cary.huang@highgo.ca>) |
Список | pgsql-hackers |
On Fri, May 24, 2024 at 12:55 PM Cary Huang <cary.huang@highgo.ca> wrote: > pg_hosts should also have sslpassword_command just like in the postgresql.conf in > case the sslkey for a particular host is encrypted with a different password. Good point. There is also the HBA-related handling of client certificate settings (such as pg_ident)... I really dislike that these things are governed by various different files, but I also feel like I'm opening up a huge can of worms by requesting nestable configurations. > + if (ssl_snimode != SSL_SNIMODE_OFF) > + SSL_CTX_set_tlsext_servername_callback(context, sni_servername_cb); > > If libpq client does not provide SNI, this callback will not be called, so there > is not a chance to check for a hostname match from pg_hosts, swap the TLS CONTEXT, > or possibly reject the connection even in strict mode. I'm mistrustful of my own test setup (see previous email to the thread), but I don't seem to be able to reproduce this. With sslsni=0 set, strict mode correctly shuts down the connection for me. Can you share your setup? (The behavior you describe might be a useful setting in practice, to let DBAs roll out strict protection for new clients gracefully without immediately blocking older ones.) Thanks, --Jacob
В списке pgsql-hackers по дате отправления: