verification levels and Milter

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

verification levels and Milter

A. Schulze
Hello,

postfix smtp server may classify incoming TLS sessions as anonymous, untrusted and trusted.
(http://www.postfix.org/FORWARD_SECRECY_README.html#status)

Is it possible to access this information from within a milter?

I did not found such funktionallity on http://www.postfix.org/MILTER_README.html#macros
so I expect "not documented -> not implemented" but I would like to be sure. Maybe I've overseen it...

Andreas
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verification levels and Milter

Wietse Venema
A. Schulze:
> Hello,
>
> postfix smtp server may classify incoming TLS sessions as anonymous, untrusted and trusted.
> (http://www.postfix.org/FORWARD_SECRECY_README.html#status)
>
> Is it possible to access this information from within a milter?
>
> I did not found such funktionallity on http://www.postfix.org/MILTER_README.html#macros
> so I expect "not documented -> not implemented" but I would like to be sure. Maybe I've overseen it...

Postfix does not implement TLS-related Milter macros. That would
require some new code. Currently, the cleanup daemon does not know
anything about TLS, so getting that info from the smtpd(8) process
would also require some new code.

Postfix does store some TLS info in its own Received: header, but
that is no good for Milters, because the MTA-generated Received:
header is hidden from Milter applications, for compatibility
with Sendmail.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verification levels and Milter

Viktor Dukhovni
In reply to this post by A. Schulze

> On Jul 31, 2017, at 9:06 AM, A. Schulze <[hidden email]> wrote:
>
> Postfix smtp server may classify incoming TLS sessions as anonymous, untrusted and trusted.
> (http://www.postfix.org/FORWARD_SECRECY_README.html#status)
>
> Is it possible to access this information from within a milter?

Some TLS information is made available to milters:

#ifdef USE_TLS
#define IF_ENCRYPTED(x) (state->tls_context ? (x) : 0)
#define IF_TRUSTED(x) (TLS_CERT_IS_TRUSTED(state->tls_context) ? (x) : 0)

    if (strcmp(name, S8_MAC_TLS_VERSION) == 0)
        return (IF_ENCRYPTED(state->tls_context->protocol));
    if (strcmp(name, S8_MAC_CIPHER) == 0)
        return (IF_ENCRYPTED(state->tls_context->cipher_name));
    if (strcmp(name, S8_MAC_CIPHER_BITS) == 0) {
        if (state->tls_context == 0)
            return (0);
        vstring_sprintf(state->expand_buf, "%d",
                        IF_ENCRYPTED(state->tls_context->cipher_usebits));
        return (STR(state->expand_buf));
    }
    if (strcmp(name, S8_MAC_CERT_SUBJECT) == 0)
        return (IF_TRUSTED(state->tls_context->peer_CN));
    if (strcmp(name, S8_MAC_CERT_ISSUER) == 0)
        return (IF_TRUSTED(state->tls_context->issuer_CN));
#endif

> I did not found such funktionallity on http://www.postfix.org/MILTER_README.html#macros
> so I expect "not documented -> not implemented" but I would like to be sure. Maybe I've overseen it...

You'll only get issuer and subject "CN" information when a client
certificate is present and trusted.  So anonymous and untrusted
appear identical to milters, while "trusted" will generally provide
a subject and issuer CN.  Sometimes the subject will have no CN,
but a missing issuer CN is far less common, and unlikely to also be
trusted in that case.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verification levels and Milter

Viktor Dukhovni
In reply to this post by Wietse Venema

> On Jul 31, 2017, at 10:55 AM, Wietse Venema <[hidden email]> wrote:
>
> Postfix does not implement TLS-related Milter macros. That would
> require some new code. Currently, the cleanup daemon does not know
> anything about TLS, so getting that info from the smtpd(8) process
> would also require some new code.

It sure looks to me like smtpd (at EHLO time) supports:

src/milter/milter.h:#define S8_MAC_TLS_VERSION  "{tls_version}"
src/milter/milter.h:#define S8_MAC_CIPHER       "{cipher}"
src/milter/milter.h:#define S8_MAC_CIPHER_BITS  "{cipher_bits}"
src/milter/milter.h:#define S8_MAC_CERT_SUBJECT "{cert_subject}"
src/milter/milter.h:#define S8_MAC_CERT_ISSUER  "{cert_issuer}"

I don't know what milters expect to find in "{cert_issuer}" and
"{cert_subject}".  The CN or the full DN (and if so in what
encoding).  We provide CNs, but perhaps Sendmail provides
DNs?

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verification levels and Milter

Claus Assmann-22
On Mon, Jul 31, 2017, Viktor Dukhovni wrote:

> I don't know what milters expect to find in "{cert_issuer}" and
> "{cert_subject}".  The CN or the full DN (and if so in what
> encoding).  We provide CNs, but perhaps Sendmail provides
> DNs?

It's in the fine documentation (op.*)

      ${cert_issuer}
           The DN (distinguished name) of the CA
           (certificate authority) that signed the presented
           certificate (the cert issuer) (STARTTLS only).

      ${cert_subject}
           The DN of the presented certificate (called the
           cert subject) (STARTTLS only).
....
   6.7.  Encoding of STARTTLS and AUTH related Macros

           Macros that contain STARTTLS and AUTH related
      data which comes from outside sources, e.g., all
      macros containing information from certificates, are
      encoded to avoid problems with non-printable or
      special characters.  The latter are '\', '<', '>',
      '(', ')', '"', '+', and ' '.  All of these characters
      are replaced by their value in hexadecimal with a
      leading '+'.  For example:

          /C=US/ST=California/O=endmail.org/OU=private/CN=Darth Mail (Cert)/
          Email=[hidden email]

      is encoded as:

          /C=US/ST=California/O=endmail.org/OU=private/
          CN=Darth+20Mail+20+28Cert+29/Email=[hidden email]

      (line breaks have been inserted for readability).  The
      macros which are subject to this encoding are
      {cert_subject}, {cert_issuer}, {cn_subject},
      {cn_issuer}, as well as {auth_authen} and
      {auth_author}.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verification levels and Milter

Viktor Dukhovni

> On Jul 31, 2017, at 12:08 PM, Claus Assmann <[hidden email]> wrote:
>
> On Mon, Jul 31, 2017, Viktor Dukhovni wrote:
>
>> I don't know what milters expect to find in "{cert_issuer}" and
>> "{cert_subject}".  The CN or the full DN (and if so in what
>> encoding).  We provide CNs, but perhaps Sendmail provides
>> DNs?
>
> It's in the fine documentation (op.*)
>
>      ${cert_issuer}
>           The DN (distinguished name) of the CA
>           (certificate authority) that signed the presented
>           certificate (the cert issuer) (STARTTLS only).
>
>      ${cert_subject}
>           The DN of the presented certificate (called the
>           cert subject) (STARTTLS only).
> ....
>   6.7.  Encoding of STARTTLS and AUTH related Macros
>
>           Macros that contain STARTTLS and AUTH related
>      data which comes from outside sources, e.g., all
>      macros containing information from certificates, are
>      encoded to avoid problems with non-printable or
>      special characters.  The latter are '\', '<', '>',
>      '(', ')', '"', '+', and ' '.  All of these characters
>      are replaced by their value in hexadecimal with a
>      leading '+'.  For example:
>
>          /C=US/ST=California/O=endmail.org/OU=private/CN=Darth Mail (Cert)/
>          Email=[hidden email]
>
>      is encoded as:
>
>          /C=US/ST=California/O=endmail.org/OU=private/
>          CN=Darth+20Mail+20+28Cert+29/Email=[hidden email]
>
>      (line breaks have been inserted for readability).  The
>      macros which are subject to this encoding are
>      {cert_subject}, {cert_issuer}, {cn_subject},
>      {cn_issuer}, as well as {auth_authen} and
>      {auth_author}.

Thanks for that.  We should probably update Postfix to send {cn_subject}
and {cn_issuer} (xtext encoded) and perhaps also the DNs in {cert_subject}
and {cert_issuer}.

Mind you, the encoding I was asking about was not the "super-encoding"
with xtext as seen above, but rather which of the various forms of the
subject and issuer DNs are expected.  There's the ad-hoc lossy form in
the OpenSSL "oneline" form of the DN, then there's RFC 2253, and one
can also choose various multibyte encodings or UTF-8.  The relevant
manpage is X509_NAME_print_ex(3):

   NOTES
       The functions X509_NAME_oneline() and X509_NAME_print() are legacy
       functions which produce a non standard output form, they don't handle
       multi character fields and have various quirks and inconsistencies.
       Their use is strongly discouraged in new applications.


I prefer to go with X509_NAME_print_ex() and a flags setting of:

    (XN_FLAG_RFC2253 & ~ASN1_STRFLGS_ESC_MSB)

The xtext encoding is an added complication at the next layer up...

In any case, I think that we need to provide macros that are compatible
reasonably compatible with Sendmail, and so even if the RFC2253 form is
technically superior, we may need to go with one of the deprecated forms
for compatibility...

Any interest in introducing new macros if the current underlying DN
format (once xtext decoded) is one of the deprecated ones?

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verification levels and Milter

Wietse Venema
In reply to this post by Viktor Dukhovni
Viktor Dukhovni:

>
> > On Jul 31, 2017, at 10:55 AM, Wietse Venema <[hidden email]> wrote:
> >
> > Postfix does not implement TLS-related Milter macros. That would
> > require some new code. Currently, the cleanup daemon does not know
> > anything about TLS, so getting that info from the smtpd(8) process
> > would also require some new code.
>
> It sure looks to me like smtpd (at EHLO time) supports:
>
> src/milter/milter.h:#define S8_MAC_TLS_VERSION  "{tls_version}"
> src/milter/milter.h:#define S8_MAC_CIPHER       "{cipher}"
> src/milter/milter.h:#define S8_MAC_CIPHER_BITS  "{cipher_bits}"
> src/milter/milter.h:#define S8_MAC_CERT_SUBJECT "{cert_subject}"
> src/milter/milter.h:#define S8_MAC_CERT_ISSUER  "{cert_issuer}"
>
> I don't know what milters expect to find in "{cert_issuer}" and
> "{cert_subject}".  The CN or the full DN (and if so in what
> encoding).  We provide CNs, but perhaps Sendmail provides
> DNs?

I looked at the code for the cleanup daemon which is TLS unaware.
So the corrected reply would be that we may have partial support.

        Wietse
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verification levels and Milter

A. Schulze


Am 31.07.2017 um 20:16 schrieb Wietse Venema:

> I looked at the code for the cleanup daemon which is TLS unaware.
> So the corrected reply would be that we may have partial support.

Hello,

thanks to all. I'll give Viktor's point a try:
seeing cert_subject + cert_issuer inside a milter may be an indicator of "trusted connection"
and report my findings ...

Andreas
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: verification levels and Milter (solved)

A. Schulze


Am 31.07.2017 um 20:43 schrieb A. Schulze:
> seeing cert_subject + cert_issuer inside a milter may be an indicator of "trusted connection"
> and report my findings ...

as Viktor said:

a milter get issuer and subject only for connections SMTPD also log as "trusted"
On untrusted and anonymous connections the macros are empty.

That's enough for me...

Andreas
Loading...