3.4-20180605-nonprod tlsproxy permissions

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

3.4-20180605-nonprod tlsproxy permissions

Noel Jones-2
Using postfix 3.4-20180605-nonprod as a gateway to an internal
server, with a tls policy of "secure".

3.4-20180605-nonprod has been running *without* connection reuse for
a couple days error-free.

When I set smtp_tls_connection_reuse=yes, I get:

Jun 13 10:53:29 mgate3 postfix/tlsproxy[93495]: warning: cannot get
RSA certificate from file "/var/certs/cert-20180314.pem": disabling
TLS support
Jun 13 10:53:29 mgate3 postfix/tlsproxy[93495]: warning: TLS library
problem: error:0200100D:system library:fopen:Permission
denied:bss_file.c:398:fopen('/var/certs/cert-20180314.pem','r'):
Jun 13 10:53:29 mgate3 postfix/tlsproxy[93495]: warning: TLS library
problem: error:20074002:BIO routines:FILE_CTRL:system
lib:bss_file.c:400:
Jun 13 10:53:29 mgate3 postfix/tlsproxy[93495]: warning: TLS library
problem: error:140DC002:SSL
routines:SSL_CTX_use_certificate_chain_file:system lib:ssl_rsa.c:722:
Jun 13 10:53:29 mgate3 postfix/smtp[93494]: warning:
private/tlsproxy service role "client" is not available


Temporarily making the cert world-readable clears the error and
allows connection reuse.

Maybe tlsproxy is dropping permissions too soon?




  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: 3.4-20180605-nonprod tlsproxy permissions

Viktor Dukhovni


> On Jun 13, 2018, at 12:09 PM, Noel Jones <[hidden email]> wrote:
>
> Maybe tlsproxy is dropping permissions too soon?

Because it serves multiple SMTP delivery agents, with
potentially different client certs, it can't obtain
the certs in advance.  The solution is to serialize
the client cert and key and pass it to the proxy, or
to create a "store" for client certs, SNI-based
server certs, etc. and have the proxy extract the
certs from the "store", with root privs used to
gain access to the store.

This is a work in progress.  For now, to continue
testing, making the cert owned by "postfix" is a
bit better than world-readable.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: 3.4-20180605-nonprod tlsproxy permissions

Noel Jones-2
On 6/13/2018 11:19 AM, Viktor Dukhovni wrote:

>
>
>> On Jun 13, 2018, at 12:09 PM, Noel Jones <[hidden email]> wrote:
>>
>> Maybe tlsproxy is dropping permissions too soon?
>
> Because it serves multiple SMTP delivery agents, with
> potentially different client certs, it can't obtain
> the certs in advance.  The solution is to serialize
> the client cert and key and pass it to the proxy, or
> to create a "store" for client certs, SNI-based
> server certs, etc. and have the proxy extract the
> certs from the "store", with root privs used to
> gain access to the store.
>
> This is a work in progress.  For now, to continue
> testing, making the cert owned by "postfix" is a
> bit better than world-readable.
>


Thanks.  Will do.



  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: 3.4-20180605-nonprod tlsproxy permissions

Wietse Venema
Noel Jones:

> On 6/13/2018 11:19 AM, Viktor Dukhovni wrote:
> >
> >
> >> On Jun 13, 2018, at 12:09 PM, Noel Jones <[hidden email]> wrote:
> >>
> >> Maybe tlsproxy is dropping permissions too soon?
> >
> > Because it serves multiple SMTP delivery agents, with
> > potentially different client certs, it can't obtain
> > the certs in advance.  The solution is to serialize
> > the client cert and key and pass it to the proxy, or
> > to create a "store" for client certs, SNI-based
> > server certs, etc. and have the proxy extract the
> > certs from the "store", with root privs used to
> > gain access to the store.
> >
> > This is a work in progress.  For now, to continue
> > testing, making the cert owned by "postfix" is a
> > bit better than world-readable.
>
> Thanks.  Will do.

The 'postfix check' command will complain if you store non-root
files under /etc/postfix, so you may want to store them under
/etc/postfix-certs or something like that.

Thanks for testing the code.

        Wietse