Trusting postfix client certs for relaying
All, The dayjob has a number of machines out in the wild that need to be able to send mail (mostly from cron jobs) home to the mothership. Not all have controllable reverse DNS. It's an issue with donated colo and transit. Doing a bunch of tunnels would work but it's a really stupid answer. We'd like to use client-certs as an auth mechanism. We're already deploying trusted client certs for use with puppet, so we have a full CA setup already in place. If we trust any cert signed by our puppetmaster's CA (which uses a root/intermediate/leaf setup for signing) we should be golden. However, reading the postfix docs (http://www.postfix.org/TLS_README.html#server_vrfy_client) , I see warnings that one should not use permit_tls_all_clientcerts for something like that. If an outside client were to connect with (say) a let's encrypt cert configured as a client cert (which we may want to *validate*, but *not permit for relaying*, that cert would allow relay) It seems that There are knobs that let you list *individual certs* for allowing trusted relaying, but not *individual ca's*. Is there any way around this? -Dan Mahoney -- Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC FB: fb.com/DanielMahoneyIV LI: linkedin.com/in/gushi Site: http://www.gushi.org ---
Re: Trusting postfix client certs for relaying
Dnia 17.04.2021 o godz. 11:56:54 Dan Mahoney (Gushi) pisze: > > The dayjob has a number of machines out in the wild that need to be > able to send mail (mostly from cron jobs) home to the mothership. > Not all have controllable reverse DNS. It's an issue with donated > colo and transit. Doing a bunch of tunnels would work but it's a > really stupid answer. I don't fully understand why do you need *relaying* in your scenario. Can't they just send emails to address located on your "mothership" server? In that case you have a scenario of simple incoming mail, no relaying at all. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: Trusting postfix client certs for relaying
Dan Mahoney (Gushi): > All, > > The dayjob has a number of machines out in the wild that need to be able > to send mail (mostly from cron jobs) home to the mothership. Not all have > controllable reverse DNS. It's an issue with donated colo and transit. > Doing a bunch of tunnels would work but it's a really stupid answer. > > We'd like to use client-certs as an auth mechanism. We're already > deploying trusted client certs for use with puppet, so we have a full CA > setup already in place. If we trust any cert signed by our puppetmaster's > CA (which uses a root/intermediate/leaf setup for signing) we should be > golden. > > However, reading the postfix docs > (http://www.postfix.org/TLS_README.html#server_vrfy_client) , I see > warnings that one should not use permit_tls_all_clientcerts for something > like that. If an outside client were to connect with (say) a let's > encrypt cert configured as a client cert (which we may want to *validate*, > but *not permit for relaying*, that cert would allow relay) > > It seems that There are knobs that let you list *individual certs* for > allowing trusted relaying, but not *individual ca's*. > > Is there any way around this? Yes: handle that traffic with a dedicated smtpd instance that only trusts your internal root. Postfix check_ccert_access currently supports matches based on certificate fingerprint and public key fingerprint. The other available attributes, issuer name and subject name, are too soft for security decisions. Wietse
Re: Trusting postfix client certs for relaying
On 4/17/21 5:15 PM, Wietse Venema wrote: > Dan Mahoney (Gushi): >> All, >> >> The dayjob has a number of machines out in the wild that need to be able >> to send mail (mostly from cron jobs) home to the mothership. Not all have >> controllable reverse DNS. It's an issue with donated colo and transit. >> Doing a bunch of tunnels would work but it's a really stupid answer. >> >> We'd like to use client-certs as an auth mechanism. We're already >> deploying trusted client certs for use with puppet, so we have a full CA >> setup already in place. If we trust any cert signed by our puppetmaster's >> CA (which uses a root/intermediate/leaf setup for signing) we should be >> golden. >> >> However, reading the postfix docs >> (http://www.postfix.org/TLS_README.html#server_vrfy_client) , I see >> warnings that one should not use permit_tls_all_clientcerts for something >> like that. If an outside client were to connect with (say) a let's >> encrypt cert configured as a client cert (which we may want to *validate*, >> but *not permit for relaying*, that cert would allow relay) >> >> It seems that There are knobs that let you list *individual certs* for >> allowing trusted relaying, but not *individual ca's*. >> >> Is there any way around this? > > Yes: handle that traffic with a dedicated smtpd instance that only > trusts your internal root. > > Postfix check_ccert_access currently supports matches based on > certificate fingerprint and public key fingerprint. The other > available attributes, issuer name and subject name, are too soft > for security decisions. > > Wietse Would it be possible to support trusting based on subject alt name? I would like a machine with a certificate for a.example.com to send mail from a.example.com domains. Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Trusting postfix client certs for relaying
Demi Marie Obenour: > >> It seems that There are knobs that let you list *individual certs* for > >> allowing trusted relaying, but not *individual ca's*. > >> > >> Is there any way around this? > > > > Yes: handle that traffic with a dedicated smtpd instance that only > > trusts your internal root. > > > > Postfix check_ccert_access currently supports matches based on > > certificate fingerprint and public key fingerprint. The other > > available attributes, issuer name and subject name, are too soft > > for security decisions. > > Would it be possible to support trusting based on subject alt name? > I would like a machine with a certificate for a.example.com to send > mail from a.example.com domains. What is the trust model here? Wietse
Re: Trusting postfix client certs for relaying
Sent from my iPad > On Apr 17, 2021, at 14:16, Wietse Venema wrote: > Dan Mahoney (Gushi): >> All, >> >> The dayjob has a number of machines out in the wild that need to be able >> to send mail (mostly from cron jobs) home to the mothership. Not all have >> controllable reverse DNS. It's an issue with donated colo and transit. >> Doing a bunch of tunnels would work but it's a really stupid answer. >> >> We'd like to use client-certs as an auth mechanism. We're already >> deploying trusted client certs for use with puppet, so we have a full CA >> setup already in place. If we trust any cert signed by our puppetmaster's >> CA (which uses a root/intermediate/leaf setup for signing) we should be >> golden. >> >> However, reading the postfix docs >> (http://www.postfix.org/TLS_README.html#server_vrfy_client) , I see >> warnings that one should not use permit_tls_all_clientcerts for something >> like that. If an outside client were to connect with (say) a let's >> encrypt cert configured as a client cert (which we may want to *validate*, >> but *not permit for relaying*, that cert would allow relay) >> >> It seems that There are knobs that let you list *individual certs* for >> allowing trusted relaying, but not *individual ca's*. >> >> Is there any way around this? > > Yes: handle that traffic with a dedicated smtpd instance that only > trusts your internal root. > > Postfix check_ccert_access currently supports matches based on > certificate fingerprint and public key fingerprint. The other > available attributes, issuer name and subject name, are too soft > for security decisions. Yes, but “signed by this cert, which is on local disk” or “traceable back to this root cert, which is on local disk” is not. If the feature’s not there, it’s not there, but this feels possible. -Dan
Re: Trusting postfix client certs for relaying
On 4/18/21 2:39 PM, Wietse Venema wrote: > Demi Marie Obenour: It seems that There are knobs that let you list *individual certs* for allowing trusted relaying, but not *individual ca's*. Is there any way around this? >>> >>> Yes: handle that traffic with a dedicated smtpd instance that only >>> trusts your internal root. >>> >>> Postfix check_ccert_access currently supports matches based on >>> certificate fingerprint and public key fingerprint. The other >>> available attributes, issuer name and subject name, are too soft >>> for security decisions. >> >> Would it be possible to support trusting based on subject alt name? >> I would like a machine with a certificate for a.example.com to send >> mail from a.example.com domains. > > What is the trust model here? > > Wietse Each system is issued a certificate for its own domain. Perhaps a better example would be email Subject Alternative Names. Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Trusting postfix client certs for relaying
On Sun, Apr 18, 2021 at 07:59:07PM -0400, Demi Marie Obenour wrote: > >> Would it be possible to support trusting based on subject alt name? > >> I would like a machine with a certificate for a.example.com to send > >> mail from a.example.com domains. This rather mixes end-to-end properties (the message envelope sender is a fixed element of a mult-hop SMTP relay chain) with hop-by-hop properties (TLS client certificates). Permitting particular client certs is fine for MSA relay authorisation, but is rather dubious for enforcing the envelope sender domain. Are then going to forbid the use of these sender domains unless the client presents a corresponding certificate? Is this an a message submission service or an inbound MTA? > Each system is issued a certificate for its own domain. Perhaps a > better example would be email Subject Alternative Names. That's not an example (use-case), it is a certificate field. What is the use-case. With some specificity... -- Viktor.
Re: Trusting postfix client certs for relaying
On 4/18/21 8:04 PM, Viktor Dukhovni wrote: > On Sun, Apr 18, 2021 at 07:59:07PM -0400, Demi Marie Obenour wrote: > Would it be possible to support trusting based on subject alt name? I would like a machine with a certificate for a.example.com to send mail from a.example.com domains. > > This rather mixes end-to-end properties (the message envelope sender is > a fixed element of a mult-hop SMTP relay chain) with hop-by-hop > properties (TLS client certificates). > > Permitting particular client certs is fine for MSA relay authorisation, > but is rather dubious for enforcing the envelope sender domain. > > Are then going to forbid the use of these sender domains unless the > client presents a corresponding certificate? Is this an a message > submission service or an inbound MTA? > >> Each system is issued a certificate for its own domain. Perhaps a >> better example would be email Subject Alternative Names. > > That's not an example (use-case), it is a certificate field. What > is the use-case. With some specificity... If I were to run my own email server (I don’t, but I plan on doing so someday), my preferred means of authentication would be by client certificate. And I would want users to be able to send emails as a specific user if, and only if, I have issued them a certificate with the corresponding email address in the SAN. Why client certificates? Because requiring authentication to even connect to the service avoids whole heaps of problems. If the user doesn’t present a certificate, they aren’t going to even get an SMTP greeting, much less be able to send mail. And that is extremely easy to validate: I just need to ensure that connections with no certificate, or with an invalid certificate, fail during TLS negotiation. Furthermore, client certificate authentication does not require any form of credentials (other than the server’s own certificate) to be stored on the server, nor does it require that the server have any form of authentication database. Finally, Postfix needs to run TLS and verify certificates anyway, so that it can securely relay mail. So client certificate authentication hardly increases the attack surface at all. Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Trusting postfix client certs for relaying
On Sun, Apr 18, 2021 at 08:49:34PM -0400, Demi Marie Obenour wrote: > >> Each system is issued a certificate for its own domain. Perhaps a > >> better example would be email Subject Alternative Names. > > > > That's not an example (use-case), it is a certificate field. What > > is the use-case. With some specificity... > > If I were to run my own email server (I don’t, but I plan on doing > so someday), my preferred means of authentication would be by client > certificate. And I would want users to be able to send emails as a > specific user if, and only if, I have issued them a certificate with > the corresponding email address in the SAN. Though you didn't quite say it explicitly, it seems that you have in mind an MSA (submission) use-case. And you'd like to associate the the email addresses that users are allowed to use with their certificates (possibly as email address SANs, but see below). > ... requiring authentication to even connect to the service avoids > whole heaps of problems. That's only true if one neglects many practical details. > If the user doesn’t present a certificate, they aren’t going to even > get an SMTP greeting, much less be able to send mail. Perhaps true on port 465, but not quite on 587, though of course establishing STARTTLS on 587 and getting to "AUTH" can mandate the same client cert requirements. > And that is extremely easy to validate: I just need to ensure that > connections with no certificate, or with an invalid certificate, fail > during TLS negotiation. Well, the key question is what's an "invalid certificate"? An no longer authorised user may still be in posession of a certificate that has not yet expired, and so one way or another you'll need to distinguish certificates of authorised users from certificates of formerly authorised users. I'd like to suggest that CRLs are by far the worst way to go about this, and that therefore, you'll want a positive mapping (a table of authorised certificates, mapping them to notional authorised users). > Furthermore, client certificate authentication does not require any > form of credentials (other than the server’s own certificate) to be > stored on the server, nor does it require that the server have any > form of authentication database. Somewhat true, but the server still needs an authorisation database. Which means that the mapping from certificate to user name may as well happen outside the certificate, and will then be possible to manage without reissuing certificates every time a user's authorisation changes, ... There was some discussion on the Postfix list some time back about supporting the SASL TLS AUTH EXTERNAL mechanism with Dovecot. I don't recall where it went, but the idea would be to map client certificate fingerprints to SASL login names, the latter would then be communicated by Postfix to the dovecot SASL backend as the authenticated user name. The rest of the session can then pretend that SASL auth took place, and leverage the smtpd_sender_login_maps tables, check_sasl_access, reject_sender_login_mismatch, ... -- Viktor.
Re: Trusting postfix client certs for relaying
> On Apr 18, 2021, at 10:30 PM, Viktor Dukhovni > wrote: > > On Sun, Apr 18, 2021 at 08:49:34PM -0400, Demi Marie Obenour wrote: > Each system is issued a certificate for its own domain. Perhaps a better example would be email Subject Alternative Names. >>> >>> That's not an example (use-case), it is a certificate field. What >>> is the use-case. With some specificity... >> >> If I were to run my own email server (I don’t, but I plan on doing >> so someday), my preferred means of authentication would be by client >> certificate. And I would want users to be able to send emails as a >> specific user if, and only if, I have issued them a certificate with >> the corresponding email address in the SAN. > > Though you didn't quite say it explicitly, it seems that you have in > mind an MSA (submission) use-case. And you'd like to associate the the > email addresses that users are allowed to use with their certificates > (possibly as email address SANs, but see below). > >> ... requiring authentication to even connect to the service avoids >> whole heaps of problems. > > That's only true if one neglects many practical details. > >> If the user doesn’t present a certificate, they aren’t going to even >> get an SMTP greeting, much less be able to send mail. > > Perhaps true on port 465, but not quite on 587, though of course > establishing STARTTLS on 587 and getting to "AUTH" can mandate the same > client cert requirements. > >> And that is extremely easy to validate: I just need to ensure that >> connections with no certificate, or with an invalid certificate, fail >> during TLS negotiation. > > Well, the key question is what's an "invalid certificate"? An no longer > authorised user may still be in posession of a certificate that has not > yet expired, and so one way or another you'll need to distinguish > certificates of authorised users from certificates of formerly > authorised users. > > I'd like to suggest that CRLs are by far the worst way to go about this, > and that therefore, you'll want a positive mapping (a table of > authorised certificates, mapping them to notional authorised users). Trying to get postfix to check an OCSP responder would be *hard*. Not that most “toy” CA’s (like ca.pl) have a worthwhile one in place. Since I started this thread, I found *one* possible workaround. (Remember, dayjob is using puppet). I am able to use puppet’s collected facts to build an access db, if that’s something I want to do. We already do something like this where the services on a running machine establish what a host’s monitoring profile will be. For demi, that may be your answer as well — since your CA keeps a list of what certs it has issued, perhaps pumping those into an access table of some sort (with a perl script or the like) may be helpful to you. That said, if what you’re trying to do is use certs to say: the cert issued to bob.domain.com will only allow sending from b...@domain.com, then except on your own mail server, nobody is going to be inspecting the headers for this. (That is to say, this isn’t S/MIME). If the result is that mail is rejected unless this matches, then you’re only increasing the load on yourself. -Dan >
