Loading ...
Sorry, an error occurred while loading the content.
 

Configuring SASL PLAIN auth only after STARTTLS

Expand Messages
  • Johannes Bauer
    Hi list, I have a Postfix setup with Dovecot SASL. Other MTAs drop their mail at my host (without authentication obviously) and I have a couple of clients
    Message 1 of 11 , Jan 30, 2014
      Hi list,

      I have a Postfix setup with Dovecot SASL. Other MTAs drop their mail at
      my host (without authentication obviously) and I have a couple of
      clients which drop their relay mail off after authentication. So, a
      pretty standard setup.

      For SASL authentication I have hashed passwords in the backend. This
      means that Postfix has to accept a plaintext authentication method.
      Usually this is no problem, since the MTA uses TLS (after STARTTLS).

      What I would like to do and cannot figure out: How can I *force*
      authenticated clients to perform a STARTTLS before performing a "AUTH
      PLAIN"? I tried the following:

      smtpd_sasl_security_options = noanonymous, noplaintext
      smtpd_sasl_tls_security_options = noanonymous

      Which results in Postfix pretty much crashing as soon as someone only
      connects to it:

      Jan 30 23:50:49 ira postfix/smtpd[5065]: connect from
      my.local-dynip.com[1.2.3.4]
      Jan 30 23:50:49 ira postfix/smtpd[5065]: fatal: no SASL authentication
      mechanisms
      Jan 30 23:50:50 ira postfix/master[5045]: warning: process
      /usr/lib/postfix/smtpd pid 5065 exit status 1
      Jan 30 23:50:50 ira postfix/master[5045]: warning:
      /usr/lib/postfix/smtpd: bad command startup -- throttling

      i.e. this is the same behvaior as when I disallow Postfix plaintext
      authentication altogether. I would just like to force misconfigured
      clients to accidently trainsmit their credentials in plaintext.

      I'm sure there's a way to do what I want; really appreciate any help of
      you guys.

      Thanks in advance,
      Johannes
    • Viktor Dukhovni
      ... If plaintext mechanisms are all you have: smtpd_tls_auth_only = yes This disables auth completely without TLS. It looks like you have no other mechanisms
      Message 2 of 11 , Jan 30, 2014
        On Fri, Jan 31, 2014 at 12:54:01AM +0100, Johannes Bauer wrote:

        > What I would like to do and cannot figure out: How can I *force*
        > authenticated clients to perform a STARTTLS before performing a "AUTH
        > PLAIN"?

        If plaintext mechanisms are all you have:

        smtpd_tls_auth_only = yes

        This disables auth completely without TLS. It looks like you have
        no other mechanisms available.

        --
        Viktor.
      • Johannes Bauer
        ... You re a genius! Thank you so much, this is exactly what I wanted. If we ever meet in person, be sure to claim your well-deserved beer :-) Best regards,
        Message 3 of 11 , Jan 30, 2014
          On 31.01.2014 01:41, Viktor Dukhovni wrote:
          > On Fri, Jan 31, 2014 at 12:54:01AM +0100, Johannes Bauer wrote:
          >
          >> What I would like to do and cannot figure out: How can I *force*
          >> authenticated clients to perform a STARTTLS before performing a "AUTH
          >> PLAIN"?
          >
          > If plaintext mechanisms are all you have:
          >
          > smtpd_tls_auth_only = yes
          >
          > This disables auth completely without TLS. It looks like you have
          > no other mechanisms available.

          You're a genius! Thank you so much, this is exactly what I wanted.

          If we ever meet in person, be sure to claim your well-deserved beer :-)

          Best regards,
          Johannes
        • Viktor Dukhovni
          ... Instead of buying me a beer, you can pay me back in kind and take 5-10 minutes to read Section 1.2 (and its subsections 1.2.1, 1.2.2, 1.2.3 and 1.2.4) of:
          Message 4 of 11 , Jan 30, 2014
            On Fri, Jan 31, 2014 at 02:07:51AM +0100, Johannes Bauer wrote:

            > On 31.01.2014 01:41, Viktor Dukhovni wrote:
            > > On Fri, Jan 31, 2014 at 12:54:01AM +0100, Johannes Bauer wrote:
            > >
            > >> What I would like to do and cannot figure out: How can I *force*
            > >> authenticated clients to perform a STARTTLS before performing a "AUTH
            > >> PLAIN"?
            > >
            > > If plaintext mechanisms are all you have:
            > >
            > > smtpd_tls_auth_only = yes
            > >
            > > This disables auth completely without TLS. It looks like you have
            > > no other mechanisms available.
            >
            > You're a genius! Thank you so much, this is exactly what I wanted.
            >
            > If we ever meet in person, be sure to claim your well-deserved beer :-)

            Instead of buying me a beer, you can pay me back in kind and take
            5-10 minutes to read Section 1.2 (and its subsections 1.2.1, 1.2.2,
            1.2.3 and 1.2.4) of:

            http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html#rfc.section.1.2

            then email me feedback about what could/should be more clear or
            how the structure of the introduction could be improved.

            Yes, I know that an RFC is not a tutorial, and is aimed at primarily
            at would-be implementors, not users. That said, I want the
            introduction to be more widely accessible,

            If you feel that the document as a whole is not too taxing,
            constructive suggestions always appreciated for the other sections
            too.

            Then, start planning to deploy DNSSEC for your domains. With care,
            since one must not neglect to automate periodic re-signing of zone
            files either daily or weekly, but in any case often enough to avoid
            RRSIG expiration.

            --
            Viktor.
          • Johannes Bauer
            ... I was at work until now but now I m back and will read through it and provide feedback via mail. ... Phew, that s a big one. I m pretty much clueless on
            Message 5 of 11 , Jan 31, 2014
              On 31.01.2014 02:22, Viktor Dukhovni wrote:

              >> You're a genius! Thank you so much, this is exactly what I wanted.
              >>
              >> If we ever meet in person, be sure to claim your well-deserved beer :-)
              >
              > Instead of buying me a beer, you can pay me back in kind and take
              > 5-10 minutes to read Section 1.2 (and its subsections 1.2.1, 1.2.2,
              > 1.2.3 and 1.2.4) of:
              >
              > http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html#rfc.section.1.2
              >
              > then email me feedback about what could/should be more clear or
              > how the structure of the introduction could be improved.

              I was at work until now but now I'm back and will read through it and
              provide feedback via mail.

              > Then, start planning to deploy DNSSEC for your domains. With care,
              > since one must not neglect to automate periodic re-signing of zone
              > files either daily or weekly, but in any case often enough to avoid
              > RRSIG expiration.

              Phew, that's a big one. I'm pretty much clueless on how DNSSEC works at
              all and already found configuring bind9/DNS relatively complicated to
              set up (admittedly with a non-trivial setup, but anyways). Why does DNS
              always have to be such a bitch to debug? Really frustrating. Oh well.

              Best regards,
              Johannes
            • Viktor Dukhovni
              ... 1. Use appropriate tools to generate a DNS key signing key and zone key and automate periodic re-signing of your zone file via the ZSK. The passphrase
              Message 6 of 11 , Jan 31, 2014
                On Fri, Jan 31, 2014 at 05:00:44PM +0100, Johannes Bauer wrote:

                > > Then, start planning to deploy DNSSEC for your domains. With care,
                > > since one must not neglect to automate periodic re-signing of zone
                > > files either daily or weekly, but in any case often enough to avoid
                > > RRSIG expiration.
                >
                > Phew, that's a big one. I'm pretty much clueless on how DNSSEC works at
                > all and already found configuring bind9/DNS relatively complicated to
                > set up (admittedly with a non-trivial setup, but anyways). Why does DNS
                > always have to be such a bitch to debug? Really frustrating. Oh well.

                1. Use appropriate tools to generate a DNS key signing key and zone
                key and automate periodic re-signing of your zone file via the
                ZSK. The passphrase for the KSK should be kept offline, while
                the ZSK is used for unattended re-signing of the zone file.

                2. Configure some machine with explicit trust anchor keys for
                your now signed zone, and run tests for a some weeks to make
                sure that DNS lookups for the signed zone work consistently.

                3. In the mean time get familiar with the tools and concepts.
                Basically you have signatures on all your DNS records and
                the signatures have relatively short (a few hours to a days)
                expiration times. If you automate and monitor signing, so
                that nobody ever sees expired signatures, you're fine.
                Otherwise, your domain's data is "bogus" and you have an
                outage.

                4. Once you've had it working for a while and feel confident that
                you can go live, work with your domain registrar (or find a new
                one) to publish your domains's DS records in the parent domain.

                5. Registrar lock your domain. Don't want some other compromised
                registrar changing or removing your DNSSEC DS records.

                This will take a while, but you have plenty of time. Don't rush
                it, do it well. DNSSEC adoption is happening slowly so far, if you
                have it done by 2015, you'll probably still be an "early adopter".

                Once (soon I hope) the SMTP DANE draft specification is adopted as
                a standards track RFC, I am hoping that DANE for SMTP will be
                implemented by more MTAs and will motivate more people to adopt
                DNSSEC. Perhaps Exim first, the Exim developers want to do it,
                but have been starved for developer cycles.

                If anyone on this list can help nudge another implementation along,
                that would be great. If you're a customer of one of the border
                email security appliance vendors (IronPort, Barracuda, ...) ask them
                about DANE support. If your email is hosted by a major provider,
                nudge them along, ...

                --
                Viktor.
              • lst_hoe02@...
                Not sure if someone already noticed (in German): http://www.heise.de/newsticker/meldung/Bund-sichert-ueberraschend-Mailtransport-per-DANE-ab-2196565.html Looks
                Message 7 of 11 , May 24 5:39 AM
                  Not sure if someone already noticed (in German):

                  http://www.heise.de/newsticker/meldung/Bund-sichert-ueberraschend-Mailtransport-per-DANE-ab-2196565.html

                  Looks like the german government is at least in progress of setup DANE
                  for e-mail for domain "bund.de"

                  Would be a big "marketing" point i guess.

                  Regards

                  Andreas
                • lst_hoe02@...
                  ... Hm, looks like a short test as of now. There are no TLSA records any more :-( Regards Andreas
                  Message 8 of 11 , May 24 5:42 AM
                    Zitat von lst_hoe02@...:

                    > Not sure if someone already noticed (in German):
                    >
                    > http://www.heise.de/newsticker/meldung/Bund-sichert-ueberraschend-Mailtransport-per-DANE-ab-2196565.html
                    >
                    > Looks like the german government is at least in progress of setup
                    > DANE for e-mail for domain "bund.de"
                    >
                    > Would be a big "marketing" point i guess.
                    >
                    > Regards
                    >
                    > Andreas

                    Hm, looks like a short test as of now. There are no TLSA records any more :-(

                    Regards

                    Andreas
                  • Jonas Wielicki
                    ... I still see the records for _25._tcp.mx1.bund.de when asking their NS (xenon.bund.de) directly. dig +dnssec _25._tcp.mx1.bund.de TLSA @xenon.bund.de.
                    Message 9 of 11 , May 24 6:01 AM
                      On 24.05.2014 14:42, lst_hoe02@... wrote:
                      >
                      > Zitat von lst_hoe02@...:
                      >
                      >> Not sure if someone already noticed (in German):
                      >>
                      >> http://www.heise.de/newsticker/meldung/Bund-sichert-ueberraschend-Mailtransport-per-DANE-ab-2196565.html
                      >>
                      >>
                      >> Looks like the german government is at least in progress of setup DANE
                      >> for e-mail for domain "bund.de"
                      >>
                      >> Would be a big "marketing" point i guess.
                      >>
                      >> Regards
                      >>
                      >> Andreas
                      >
                      > Hm, looks like a short test as of now. There are no TLSA records any
                      > more :-(

                      I still see the records for _25._tcp.mx1.bund.de when asking their NS
                      (xenon.bund.de) directly.

                      dig +dnssec _25._tcp.mx1.bund.de TLSA @....

                      >
                      > Regards
                      >
                      > Andreas
                      >
                      >
                    • Patrick Ben Koetter
                      ... Works for me: p@mail:~$ posttls-finger -t30 -T180 -c -L verbose,summary bund.de posttls-finger: initializing the client-side TLS engine posttls-finger:
                      Message 10 of 11 , May 24 9:59 AM
                        * lst_hoe02@... <lst_hoe02@...>:
                        >
                        > Zitat von lst_hoe02@...:
                        >
                        > >Not sure if someone already noticed (in German):
                        > >
                        > >http://www.heise.de/newsticker/meldung/Bund-sichert-ueberraschend-Mailtransport-per-DANE-ab-2196565.html
                        > >
                        > >Looks like the german government is at least in progress of setup
                        > >DANE for e-mail for domain "bund.de"
                        > >
                        > >Would be a big "marketing" point i guess.
                        > >
                        > >Regards
                        > >
                        > >Andreas
                        >
                        > Hm, looks like a short test as of now. There are no TLSA records any more :-(

                        Works for me:

                        p@mail:~$ posttls-finger -t30 -T180 -c -L verbose,summary bund.de
                        posttls-finger: initializing the client-side TLS engine
                        posttls-finger: using DANE RR: _25._tcp.mx2.bund.de IN TLSA 3 0 1 59:E3:CF:5F:A1:51:55:3F:45:76:C9:4C:25:00:D7:05:EF:DD:D8:55:B6:A5:9D:88:D2:8D:03:28:87:6A:04:CB
                        posttls-finger: setting up TLS connection to mx2.bund.de[77.87.228.110]:25
                        posttls-finger: mx2.bund.de[77.87.228.110]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"
                        posttls-finger: mx2.bund.de[77.87.228.110]:25: depth=2 verify=0 subject=/C=DE/O=PKI-1-Verwaltung/CN=PCA-1-Verwaltung-10
                        posttls-finger: mx2.bund.de[77.87.228.110]:25: depth=2 verify=1 subject=/C=DE/O=PKI-1-Verwaltung/CN=PCA-1-Verwaltung-10
                        posttls-finger: mx2.bund.de[77.87.228.110]:25: depth=1 verify=1 subject=/C=DE/O=PKI-1-Verwaltung/OU=Bund/CN=CA IVBB Deutsche Telekom AG 11
                        posttls-finger: mx2.bund.de[77.87.228.110]:25: depth=0 verify=1 subject=/C=DE/O=Service/OU=ivbb-betrieb/L=ivbb-betrieb/CN=mx2.bund.de
                        posttls-finger: mx2.bund.de[77.87.228.110]:25: depth=0 matched end entity certificate sha256 digest 59:E3:CF:5F:A1:51:55:3F:45:76:C9:4C:25:00:D7:05:EF:DD:D8:55:B6:A5:9D:88:D2:8D:03:28:87:6A:04:CB
                        posttls-finger: mx2.bund.de[77.87.228.110]:25: subject_CN=mx2.bund.de, issuer_CN=CA IVBB Deutsche Telekom AG 11, fingerprint=72:78:BE:C8:3E:61:A0:12:BE:BF:3B:79:F0:CE:9A:A2:8C:26:24:FF, pkey_fingerprint=3A:3E:5F:A4:50:F8:DD:FC:56:35:FF:08:2A:F9:ED:82:B9:AB:7B:82
                        posttls-finger: Verified TLS connection established to mx2.bund.de[77.87.228.110]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)

                        p@rick



                        --
                        [*] sys4 AG

                        https://sys4.de, +49 (89) 30 90 46 64
                        Franziskanerstraße 15, 81669 München

                        Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
                        Vorstand: Patrick Ben Koetter, Marc Schiffbauer
                        Aufsichtsratsvorsitzender: Florian Kirstein
                      • Viktor Dukhovni
                        ... And for me, even from my PBL-listed road-runner dynamic IP. Sensibly short TLSA TTLs, and separate certs on each MX host: $ dig +noall +ad +comment +ans
                        Message 11 of 11 , May 24 10:38 AM
                          On Sat, May 24, 2014 at 06:59:11PM +0200, Patrick Ben Koetter wrote:

                          > Works for me:
                          >
                          > p@mail:~$ posttls-finger -t30 -T180 -c -L verbose,summary bund.de
                          > posttls-finger: Verified TLS connection established to mx2.bund.de[77.87.228.110]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)

                          And for me, even from my PBL-listed road-runner dynamic IP. Sensibly short
                          TLSA TTLs, and separate certs on each MX host:

                          $ dig +noall +ad +comment +ans -t mx bund.de
                          ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 6

                          ;; ANSWER SECTION:
                          bund.de. 21600 IN MX 10 mx2.bund.de.
                          bund.de. 21600 IN MX 10 mx1.bund.de.

                          $ dig +noall +ad +comment +ans -t tlsa _25._tcp.mx1.bund.de
                          ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4

                          ;; ANSWER SECTION:
                          _25._tcp.mx1.bund.de. 900 IN TLSA 3 0 1 CC7C93BF7367FD0E47F4399D9CDF2A53DA0DCC4C86DEA331EA894ACF D91351A7

                          $ dig +noall +ad +comment +ans -t tlsa _25._tcp.mx2.bund.de
                          ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 4

                          ;; ANSWER SECTION:
                          _25._tcp.mx2.bund.de. 900 IN TLSA 3 0 1 59E3CF5FA151553F4576C94C2500D705EFDDD855B6A59D88D28D0328 876A04CB

                          $ posttls-finger -c -Lsummary bund.de
                          posttls-finger: Verified TLS connection established to mx1.bund.de[77.87.224.163]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)

                          The MX hosts in question can also probably pass PKIX for anyone
                          who wants to manually configure "secure" with "bund.de", the chain
                          for "mx2" is:

                          subject=/C=DE/O=Service/OU=ivbb-betrieb/L=ivbb-betrieb/CN=mx2.bund.de
                          issuer=/C=DE/O=PKI-1-Verwaltung/OU=Bund/CN=CA IVBB Deutsche Telekom AG 11

                          subject=/C=DE/O=PKI-1-Verwaltung/OU=Bund/CN=CA IVBB Deutsche Telekom AG 11
                          issuer=/C=DE/O=PKI-1-Verwaltung/CN=PCA-1-Verwaltung-10

                          subject=/C=DE/O=PKI-1-Verwaltung/CN=PCA-1-Verwaltung-10
                          issuer=/C=DE/O=PKI-1-Verwaltung/CN=PCA-1-Verwaltung-10

                          The subjectAltName is just the MX hostname just like the CN, so
                          when not using a DNSSEC-validating resolver, one would use the
                          default "nexthop, dot-nexthop" match patterns. With a DNSSEC
                          validating resolver, the MX lookup is no longer insecure, so
                          you could use:

                          bund.de secure match=nexthop,hostname

                          The advantage of DANE is that no per-destination manual configuration
                          is required.

                          --
                          Viktor.
                        Your message has been successfully submitted and would be delivered to recipients shortly.