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

TLS library problem - SSL routines:SSL3_GET_RECORD - wrong version number

Expand Messages
  • Michael Büker
    Hi people, I m running postfix 2.9.6 and openssl 1.0.1 stock from Ubuntu 12.04 LTS. postfix is generally working fine as a relay to several SMTP servers (using
    Message 1 of 13 , Oct 14, 2013
    • 0 Attachment
      Hi people,

      I'm running postfix 2.9.6 and openssl 1.0.1 stock from Ubuntu 12.04 LTS.

      postfix is generally working fine as a relay to several SMTP servers (using a
      relayhost_map). However, there is one server that is causing trouble so that I
      cannot use it with postfix (while directly addressing it with e.g. kmail
      works). That server is run by a large organization, so I can't change its
      configuration.

      The errors I see are these:

      > […] postfix/smtp[9689]: warning: TLS library problem: 9689:error:1408F10B:SSL
      routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
      > […] postfix/smtp[9689]: 033661A108A: to=<foo@...>,
      relay=server[X.X.X.X]:587, delay=0.51, delays=0.09/0.03/0.39/0, dsn=4.4.2,
      status=deferred (lost connection with server[X.X.X.X] while performing the
      EHLO handshake)

      In diagnosing the problem, I found that I can connect correctly to the server
      on the command line by issuing:

      $ openssl s_client -connect server:587 -starttls smtp -tls1

      which gives (among many other things):

      > Secure Renegotiation IS supported
      > […]
      > Protocol : TLSv1

      but NOT if I say:

      $ openssl s_client -connect server:587 -starttls smtp -tls1_1

      which gives these errors:

      > 3078101192:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
      number:s3_pkt.c:337:
      > […]
      > Secure Renegotiation IS NOT supported
      > […]
      > Protocol : TLSv1.1

      (This error was the same with a self-compiled version of the latest openssl
      1.0.1e.)

      So, I thought I should try to force postfix to use tls1 instead of tls1_1 or
      1_2. I set up a tls_policy map that I know is working (because it complains on
      typos or if I forbid all the protocols):

      [server]:587 encrypt protocols=!SSLv2:!TLSv1.1:!TLSv1.2

      However, this does not help, and I still get the same error. Giving
      "protocols=TLSv1" fails just the same.

      What can I do?

      Thanks in advance!
      Michael
    • Viktor Dukhovni
      ... Obfuscating the target domain and IP address makes it much harder to help you. At the very least you MUST obfuscate using a 1-to-1 function, so that each
      Message 2 of 13 , Oct 14, 2013
      • 0 Attachment
        On Tue, Oct 15, 2013 at 03:20:13AM +0200, Michael B?ker wrote:

        > > postfix/smtp[9689]: warning: TLS library problem: 9689:error:1408F10B:SSL
        > > routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
        > > postfix/smtp[9689]: 033661A108A: to=<foo@...>,
        > > relay=server[X.X.X.X]:587, delay=0.51, delays=0.09/0.03/0.39/0, dsn=4.4.2,
        > > status=deferred (lost connection with server[X.X.X.X] while performing the
        > > EHLO handshake)

        Obfuscating the target domain and IP address makes it much harder
        to help you. At the very least you MUST obfuscate using a 1-to-1
        function, so that each distinct domain or IP address is mapped to
        a distinct obfuscated value.

        You must post the relevant entries (unmangled except for any 1-to-1
        mapping) from your transport table that direct mail for the recipients
        in question via the problem relay.

        > $ openssl s_client -connect server:587 -starttls smtp -tls1
        >
        > but NOT if I say:
        >
        > $ openssl s_client -connect server:587 -starttls smtp -tls1_1
        >
        > which gives these errors:
        >
        > [server]:587 encrypt protocols=!SSLv2:!TLSv1.1:!TLSv1.2

        The obfuscation is again most unfortunate. Most likely said
        "[server]:587" lookup key in not fact the literal nexthop from
        the transport table.

        > However, this does not help, and I still get the same error. Giving
        > "protocols=TLSv1" fails just the same.

        Support for disabling TLSv1.1 and TLSv1.2 was added with Postfix
        2.7.9, 2.8.10, 2.9.2 and 2.10. If you're using 2.9.6 you should
        be covered if you correctly specify the policy table lookup key
        and enable SMTP tls policy lookups.

        Showing "postconf -n" output would also be helpful.

        --
        Viktor.
      • Michael Büker
        ... I see the problem. Here, I just replace the domain name of the organization fom [organization].de to foo.de and replace the first IP block with 999 (it s
        Message 3 of 13 , Oct 15, 2013
        • 0 Attachment
          On Tue 15.10.13 01:48:57 Viktor Dukhovni wrote:
          > Obfuscating the target domain and IP address makes it much harder
          > to help you. At the very least you MUST obfuscate using a 1-to-1
          > function, so that each distinct domain or IP address is mapped to
          > a distinct obfuscated value.

          I see the problem. Here, I just replace the domain name of the organization
          fom [organization].de to foo.de and replace the first IP block with 999 (it's
          always the same actual value).

          > You must post the relevant entries (unmangled except for any 1-to-1
          > mapping) from your transport table that direct mail for the recipients
          > in question via the problem relay.

          Okay, I'll try to be comprehensive this time.

          First, here is my postconf -n:

          > alias_database = hash:/etc/aliases
          > alias_maps = hash:/etc/aliases
          > append_dot_mydomain = no
          > biff = no
          > config_directory = /etc/postfix
          > home_mailbox = Maildir/
          > inet_interfaces = all
          > inet_protocols = ipv4
          > mailbox_command =
          > mailbox_size_limit = 0
          > message_size_limit = 104857600
          > mydestination = localhost, asterix, asterix.home, myself.dyndns.net
          > myhostname = myself.dyndns.net
          > mynetworks = 127.0.0.0/8
          > readme_directory = no
          > recipient_delimiter =
          > sender_dependent_relayhost_maps = hash:/etc/postfix/relayhost_map
          > smtp_sasl_auth_enable = yes
          > smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
          > smtp_sasl_security_options = noanonymous
          > smtp_sasl_type = cyrus
          > smtp_sender_dependent_authentication = yes
          > smtp_tls_mandatory_ciphers = high
          > smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
          > smtp_tls_security_level = encrypt
          > smtpd_banner = postfix on asterix
          > smtpd_sasl_auth_enable = yes
          > smtpd_sasl_path = private/auth
          > smtpd_sasl_type = dovecot
          > smtpd_tls_cert_file = /etc/ssl/certs/my.crt
          > smtpd_tls_key_file = /etc/ssl/private/my.key
          > smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

          Then, this is the relevant line from /etc/postfix/relayhost_map:

          > michael.bueker@... [smtp-auth.foo.de]:587

          Which of course has an entry in /etc/postfix/sasl_passwd (win.foo.de belongs in
          the username):

          > michael.bueker@... mbueker@...:password

          This is the line for that server in /etc/postfix/tls_policy:

          > [smtp-auth.foo.de]:587 encrypt protocols=!TLSv1.1:!TLSv1.2

          Now, sending mail from michael.bueker@... gives the following postfix
          errors:

          > Oct 15 02:30:04 asterix postfix/qmgr[4428]: 42E021A0F44:
          > from=<michael.bueker@...>, size=551, nrcpt=1 (queue active)
          >
          > Oct 15 02:30:04 asterix postfix/smtp[4458]: warning: TLS library problem:
          > 4458:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
          > number:s3_pkt.c:337:
          >
          > Oct 15 02:30:04 asterix postfix/smtp[4458]: 42E021A0F44: to=<mb@michael-
          > bueker.de>, relay=smtp-auth.foo.de[999.169.5.134]:587, delay=0.51,
          > delays=0.08/0.03/0.4/0, dsn=4.4.2, status=deferred (lost connection with
          > smtp-auth.foo.de[999.169.5.134] while performing the EHLO handshake)

          Now, I _think_ the tls_policy entry is correct, because if I set if to
          something absurd like "protocols=SSLv2", the connection fails predictably:

          > Oct 15 11:55:20 asterix postfix/qmgr[15283]: 659DA1A11E1:
          > from=<michael.bueker@...>, size=550, nrcpt=1 (queue active)
          >
          > Oct 15 11:55:20 asterix postfix/smtp[15334]: SSL_connect error to
          > smtp-auth.foo.de[999.169.5.134]:587: lost connection
          >
          > Oct 15 11:55:20
          > asterix postfix/smtp[15334]: 659DA1A11E1: to=<mb@...>,
          > relay=smtp-auth.foo.de[999.169.5.134]:587, delay=0.29,
          > delays=0.08/0.03/0.17/0, dsn=4.7.5, stat us=deferred (Cannot start TLS:
          > handshake failure)

          However, when I set "protocols=TLSv1", it gives the same error as above
          ("warning: TLS library problem: 18064:error:1408F10B:SSL
          routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:" and "lost
          connection with smtp-auth.foo.de[999.169.5.134] while performing the EHLO
          handshake").

          Even the seemingly absurd values "protocols=!TLSv1:!TLSv1.1:!TLSv1.2" and
          "protocols=SSLv3" give that error ("warning: TLS library problem:
          18064:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
          number:s3_pkt.c:337:" and "lost connection with smtp-
          auth.foo.de[999.169.5.134] while performing the EHLO handshake"), so I'm not
          sure about the tls_policy line anymore. I made sure to "postmap tls_policy"
          and restart the server after every change.

          Now, for command line openssl, first with -tls1_1:

          > $ openssl s_client -connect smtp-auth.foo.de:587 -starttls smtp -tls1_1
          > CONNECTED(00000003)
          > 3077581000:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
          > number:s3_pkt.c:337: ---
          > no peer certificate available
          > ---
          > No client certificate CA names sent
          > ---
          > SSL handshake has read 440 bytes and written 7 bytes
          > ---
          > New, (NONE), Cipher is (NONE)
          > Secure Renegotiation IS NOT supported
          > Compression: NONE
          > Expansion: NONE
          > SSL-Session:
          > Protocol : TLSv1.1
          > Cipher : 0000
          > Session-ID:
          > Session-ID-ctx:
          > Master-Key:
          > Key-Arg : None
          > PSK identity: None
          > PSK identity hint: None
          > SRP username: None
          > Start Time: 1381831404
          > Timeout : 7200 (sec)
          > Verify return code: 0 (ok)
          > ---

          The error is different for -tls1_2:

          > $ openssl s_client -connect smtp-auth.foo.de:587 -starttls smtp -tls1_2
          > CONNECTED(00000003)
          > 3077904584:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
          > failure:s3_pkt.c:596: ---
          > no peer certificate available
          > ---
          > No client certificate CA names sent
          > ---
          > SSL handshake has read 435 bytes and written 0 bytes
          > ---
          > New, (NONE), Cipher is (NONE)
          > Secure Renegotiation IS NOT supported
          > Compression: NONE
          > Expansion: NONE
          > SSL-Session:
          > Protocol : TLSv1.2
          > Cipher : 0000
          > Session-ID:
          > Session-ID-ctx:
          > Master-Key:
          > Key-Arg : None
          > PSK identity: None
          > PSK identity hint: None
          > SRP username: None
          > Start Time: 1381831448
          > Timeout : 7200 (sec)
          > Verify return code: 0 (ok)
          > ---

          However, connecting works fine with -tls1:

          > $ openssl s_client -connect smtp-auth.foo.de:587 -starttls smtp -tls1
          > CONNECTED(00000003)
          > depth=2 C = DE, O = DFN-Verein, OU = DFN-PKI, CN = foo-cert -
          > G01 verify error:num=20:unable to get local issuer certificate
          > verify return:0
          > ---
          > Certificate chain
          >
          > [ … skipping lots of certificate info … ]
          > ---
          > SSL handshake has read 4414 bytes and written 570 bytes
          > ---
          > New, TLSv1/SSLv3, Cipher is RC4-MD5
          > Server public key is 2048 bit
          > Secure Renegotiation IS supported
          > Compression: NONE
          > Expansion: NONE
          >
          > SSL-Session:
          > Protocol : TLSv1
          > Cipher : RC4-MD5
          > Session-ID:
          > C80700004DDE0E3E27FD4082227D82FBF991A97FABF3674E29C2FAA3B3CD5797
          > Session-ID-ctx:
          > Master-Key:
          > 349E696910AD644B583ED97EA7FBE5B30251F681607A2E65E05DD02025FFC5ED31D03E6
          > 397813BF8898581306536F0F7 Key-Arg : None
          > PSK identity: None
          > PSK identity hint: None
          > SRP username: None
          > Start Time: 1381831489
          > Timeout : 7200 (sec)
          > Verify return code: 20 (unable to get local issuer certificate)
          >
          > ---
          > 250 OK

          Again, also setting smth-auth.foo.de as the outgoing server in my MUA (kmail)
          with the same credentials works fine for sending mails ("TLS" set for
          security), but trying to relay with postfix fails.

          I hope this was more useful now.

          Cheers,
          Michael
        • Viktor Dukhovni
          ... Note the while performing the EHLO handshake detail. This means the TLS handshake succeeded, but the subsequent SMTP commands failed inside the
          Message 4 of 13 , Oct 15, 2013
          • 0 Attachment
            On Tue, Oct 15, 2013 at 12:21:28PM +0200, Michael B?ker wrote:

            > > Oct 15 02:30:04 asterix postfix/smtp[4458]: warning: TLS library problem:
            > > 4458:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
            > > number:s3_pkt.c:337:
            > >
            > > Oct 15 02:30:04 asterix postfix/smtp[4458]: 42E021A0F44: to=<mb@michael-
            > > bueker.de>, relay=smtp-auth.foo.de[999.169.5.134]:587, delay=0.51,
            > > delays=0.08/0.03/0.4/0, dsn=4.4.2, status=deferred (lost connection with
            > > smtp-auth.foo.de[999.169.5.134] while performing the EHLO handshake)
            >
            > Now, I _think_ the tls_policy entry is correct, because if I set if to
            > something absurd like "protocols=SSLv2", the connection fails predictably:

            Note the "while performing the EHLO handshake" detail. This means
            the TLS handshake succeeded, but the subsequent SMTP commands failed
            inside the encrypted channel. Fortunately, your over-obfuscation
            of the target server left me with only 224 choices of the target
            IP address. The server in question is a Microsoft Exchange server
            with buggy 3DES ciphersuites (IIRC found in Windows XP, and
            perhaps Windows Server 2003).

            Add "exclude=3DES" to the entry table for this server, and you'll likely
            be fine. You probably don't need to tweak the protocols.

            $ posttls-finger -o 'tls_medium_cipherlist=aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:!3DES:@STRENGTH' "[smtp-auth.foo.de]:587"
            posttls-finger: Connected to smtp-auth.foo.de[999.169.5.134]:587
            posttls-finger: < 220 adxf3.win.foo.de Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 ready at Tue, 15 Oct 2013 16:43:11 +0200
            posttls-finger: > EHLO central-dogma.lan
            posttls-finger: < 250-adxf3.win.foo.de Hello [999.169.40.26]
            posttls-finger: < 250-TURN
            posttls-finger: < 250-SIZE
            posttls-finger: < 250-ETRN
            posttls-finger: < 250-PIPELINING
            posttls-finger: < 250-DSN
            posttls-finger: < 250-ENHANCEDSTATUSCODES
            posttls-finger: < 250-8bitmime
            posttls-finger: < 250-BINARYMIME
            posttls-finger: < 250-CHUNKING
            posttls-finger: < 250-VRFY
            posttls-finger: < 250-TLS
            posttls-finger: < 250-STARTTLS
            posttls-finger: < 250-X-EXPS GSSAPI NTLM
            posttls-finger: < 250-AUTH GSSAPI NTLM
            posttls-finger: < 250-X-LINK2STATE
            posttls-finger: < 250-XEXCH50
            posttls-finger: < 250 OK
            posttls-finger: > STARTTLS
            posttls-finger: < 220 2.0.0 SMTP server ready
            posttls-finger: smtp-auth.foo.de[999.169.5.134]:587: Matched subjectAltName: smtp-auth.foo.de
            posttls-finger: smtp-auth.foo.de[999.169.5.134]:587 CommonName smtp-auth.foo.de
            posttls-finger: certificate verification failed for smtp-auth.foo.de[999.169.5.134]:587: untrusted issuer /C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
            posttls-finger: smtp-auth.foo.de[999.169.5.134]:587: subject_CN=smtp-auth.foo.de, issuer_CN=FOO CA - G02, fingerprint=21:B2:6F:D3:19:96:C7:DE:73:A4:0B:70:FA:6B:4C:B1:BC:F1:97:CE, pkey_fingerprint=CC:50:03:5F:14:AA:4B:AC:46:B4:C0:0A:D2:9C:B1:77:E8:DD:0F:10
            posttls-finger: Untrusted TLS connection established to smtp-auth.foo.de[999.169.5.134]:587: TLSv1 with cipher RC4-MD5 (128/128 bits)
            posttls-finger: > EHLO central-dogma.lan
            posttls-finger: < 250-adxf3.win.foo.de Hello [999.169.40.26]
            posttls-finger: < 250-TURN
            posttls-finger: < 250-SIZE
            posttls-finger: < 250-ETRN
            posttls-finger: < 250-PIPELINING
            posttls-finger: < 250-DSN
            posttls-finger: < 250-ENHANCEDSTATUSCODES
            posttls-finger: < 250-8bitmime
            posttls-finger: < 250-BINARYMIME
            posttls-finger: < 250-CHUNKING
            posttls-finger: < 250-VRFY
            posttls-finger: < 250-X-EXPS GSSAPI NTLM LOGIN
            posttls-finger: < 250-X-EXPS=LOGIN
            posttls-finger: < 250-AUTH GSSAPI NTLM LOGIN
            posttls-finger: < 250-AUTH=LOGIN
            posttls-finger: < 250-X-LINK2STATE
            posttls-finger: < 250-XEXCH50
            posttls-finger: < 250 OK
            posttls-finger: > QUIT
            posttls-finger: < 221 2.0.0 adxf3.win.foo.de Service closing transmission channel

            I'd like to suggest that you find a less broken email provider.

            --
            Viktor.
          • DTNX Postmaster
            ... Yes on Windows 2003 Server. It s possible to add the AES ciphersuites to Window 2003 in theory, but it s one of them not really supported hotfix type
            Message 5 of 13 , Oct 15, 2013
            • 0 Attachment
              On Oct 15, 2013, at 17:18, Viktor Dukhovni <postfix-users@...> wrote:

              > On Tue, Oct 15, 2013 at 12:21:28PM +0200, Michael B?ker wrote:
              >
              >>> Oct 15 02:30:04 asterix postfix/smtp[4458]: warning: TLS library problem:
              >>> 4458:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
              >>> number:s3_pkt.c:337:
              >>>
              >>> Oct 15 02:30:04 asterix postfix/smtp[4458]: 42E021A0F44: to=<mb@michael-
              >>> bueker.de>, relay=smtp-auth.foo.de[999.169.5.134]:587, delay=0.51,
              >>> delays=0.08/0.03/0.4/0, dsn=4.4.2, status=deferred (lost connection with
              >>> smtp-auth.foo.de[999.169.5.134] while performing the EHLO handshake)
              >>
              >> Now, I _think_ the tls_policy entry is correct, because if I set if to
              >> something absurd like "protocols=SSLv2", the connection fails predictably:
              >
              > Note the "while performing the EHLO handshake" detail. This means
              > the TLS handshake succeeded, but the subsequent SMTP commands failed
              > inside the encrypted channel. Fortunately, your over-obfuscation
              > of the target server left me with only 224 choices of the target
              > IP address. The server in question is a Microsoft Exchange server
              > with buggy 3DES ciphersuites (IIRC found in Windows XP, and
              > perhaps Windows Server 2003).

              Yes on Windows 2003 Server. It's possible to add the AES ciphersuites
              to Window 2003 in theory, but it's one of them 'not really supported
              hotfix' type things. When we last tried to get it working for a client
              it simply did not work.

              For our particular situation, this provides a workaround for the few
              more months we'll need to support Exchange 2003 on the backend;

              smtp_tls_exclude_ciphers = DES-CBC3-SHA

              YMMV, of course.

              Mvg,
              Joni
            • Michael Büker
              ... Adding exclude=3DES or exclude=DES-CBC3-SHA to the smtp_tls_policy_maps file didn t quite do it, maybe because I have smtp_tls_mandatory_ciphers=high
              Message 6 of 13 , Oct 16, 2013
              • 0 Attachment
                On Tue 15.10.13 15:18:06 Viktor Dukhovni wrote:
                > The server in question is a Microsoft Exchange server with buggy 3DES
                > ciphersuites (IIRC found in Windows XP, and perhaps Windows Server 2003).
                >
                > Add "exclude=3DES" to the entry table for this server, and you'll likely
                > be fine. You probably don't need to tweak the protocols.

                Adding "exclude=3DES" or "exclude=DES-CBC3-SHA" to the smtp_tls_policy_maps
                file didn't quite do it, maybe because I have "smtp_tls_mandatory_ciphers=high"
                set globally. So I used this line, which works for this server:

                > [smtp-auth.foo.de]:587 encrypt ciphers=medium

                The next problem was the error: "5.7.3 Authentication unsuccessful", which
                appears to be unique for Exchange servers. Google suggested a broken GSSAPI
                implementation on the server side that should be excluded. That leaves only
                LOGIN in this case, which my config doesn't seem to allow for ciphers=medium.

                Globally allowing LOGIN with smtp_sasl_mechanism_filter worked, but I didn't
                want that. So I defined a new transport in master.cf:

                > exchangerelay unix - - n - - smtp -o smtp_sasl_mechanism_filter=!gssapi,login

                and configured postfix to use a sender_dependent_default_transport_maps that
                contains this line:

                > michael.bueker@... exchangerelay:

                Now, everything works. Phew.

                I might still combine the sender_dependent_default_transport_maps with my
                sender_dependent_relayhost_maps so I don't have to maintain both files. Come to
                think of it: Couldn't I combine the single line in smtp_tls_policy_maps into
                the transport definition and save one more file?

                > Fortunately, your over-obfuscation of the target server left me with only
                > 224 choices of the target IP address.

                Thanks for the effort you put in. I wasn't trying to be smart, I just sought to
                avoid angering the admin overlords at foo by publicly discussing their mail
                server.

                > I'd like to suggest that you find a less broken email provider.

                Nah, I like my employer. And I know for a fact that they keep their particle
                accelerators in much better shape than their mail servers.

                Cheers,
                Michael
              • Michael Büker
                ... Just for the record: I did, and it works. The line in my ... Thanks again everyone! Michael
                Message 7 of 13 , Oct 16, 2013
                • 0 Attachment
                  On Wed 16.10.13 10:29:21 Michael Büker wrote:
                  > I might still combine the sender_dependent_default_transport_maps with my
                  > sender_dependent_relayhost_maps so I don't have to maintain both files. Come
                  > to think of it: Couldn't I combine the single line in smtp_tls_policy_maps
                  > into the transport definition and save one more file?

                  Just for the record: I did, and it works. The line in my
                  sender_dependent_default_transport_maps is now:

                  > michael.bueker@... exchangerelay:[smtp-auth.foo.de]:587

                  and the corresponding transport in master.cf looks like this:

                  > exchangerelay unix - - n - - smtp
                  > -o smtp_tls_mandatory_ciphers=medium
                  > -o smtp_sasl_mechanism_filter=!gssapi,login

                  Thanks again everyone!
                  Michael
                • DTNX Postmaster
                  ... Document the setup in all relevant files, and be done with it. Premature optimization is the root of all evil, after all ;-) Mvg, Joni
                  Message 8 of 13 , Oct 16, 2013
                  • 0 Attachment
                    On Oct 16, 2013, at 10:29, Michael Büker <mb@...> wrote:

                    > Now, everything works. Phew.
                    >
                    > I might still combine the sender_dependent_default_transport_maps with my
                    > sender_dependent_relayhost_maps so I don't have to maintain both files. Come to
                    > think of it: Couldn't I combine the single line in smtp_tls_policy_maps into
                    > the transport definition and save one more file?

                    Document the setup in all relevant files, and be done with it.
                    Premature optimization is the root of all evil, after all ;-)

                    Mvg,
                    Joni
                  • Viktor Dukhovni
                    ... Yes, of course, the *only* high grade cipher supported by Windows 2003 (sans hot-fixes, ...) is 3DES, but it is unusable (buggy). The strongest working
                    Message 9 of 13 , Oct 16, 2013
                    • 0 Attachment
                      On Wed, Oct 16, 2013 at 10:29:21AM +0200, Michael B?ker wrote:

                      > > Add "exclude=3DES" to the entry table for this server, and you'll likely
                      > > be fine. You probably don't need to tweak the protocols.
                      >
                      > Adding "exclude=3DES" or "exclude=DES-CBC3-SHA" to the smtp_tls_policy_maps
                      > file didn't quite do it, maybe because I have "smtp_tls_mandatory_ciphers=high"
                      > set globally. So I used this line, which works for this server:

                      Yes, of course, the *only* "high" grade cipher supported by Windows
                      2003 (sans hot-fixes, ...) is 3DES, but it is unusable (buggy).
                      The strongest working cipher-suite is RC4-SHA, which is "medium".

                      > > [smtp-auth.foo.de]:587 encrypt ciphers=medium

                      You should still exclude 3DES, I found that even with RC4-SHA
                      offered by the client, depending on the exact mix of client protocol
                      versions, sometimes the server picks 3DES and breaks.

                      So for this server (de-obfuscated) I'd specify:

                      [smtp-auth.foo.de]:587 encrypt ciphers=medium exclude=3DES

                      or with suitable content in "smtp_tls_CAfile" and/or "smtp_tls_CApath"

                      [smtp-auth.foo.de]:587 secure ciphers=medium exclude=3DES

                      since one really ought to verify the SSL certificate of a submission
                      service.

                      > > exchangerelay unix - - n - - smtp
                      > > -o smtp_sasl_mechanism_filter=!gssapi,login

                      To support Exchange MSAs on Windows 2003 generically (less critical
                      state in per-relay policy entries):

                      exchangerelay unix - - n - - smtp
                      -o smtp_sasl_mechanism_filter=login
                      -o smtp_tls_security_level=secure
                      -o smtp_tls_mandatory_ciphers=medium
                      -o smtp_tls_mandatory_exclude_ciphers=3DES

                      There's no need to explicitly exclude "gssapi" when you've only
                      included "login". The "!gssapi" syntax is only useful with:

                      !gssapi, static:all

                      > > I'd like to suggest that you find a less broken email provider.
                      >
                      > Nah, I like my employer. And I know for a fact that they keep their particle
                      > accelerators in much better shape than their mail servers.

                      I see, not a consumer-grade provider, rather a corporation with
                      captive users of a museum-grade legacy infrastructure. :-) In that
                      case, since it is Oktober, perhaps over a Bier or two suggest that
                      they consider upgrading their MSAs to something less ancient when
                      they get a chance.

                      Postfix is easy to integrate with Active-Directory LDAP for user
                      validation, and you can enable PLAIN or LOGIN via saslauthd with
                      PAM as a backend, and a kerberos entry in the PAM entry for SMTP.
                      Together with a keytab on the server with "host/<fqdn>@REALM"
                      keys issued from AD it just works.

                      --
                      Viktor.
                    • KSB
                      Hello! Have the similar problem: Oct 22 17:12:12 awtech postfix/smtp[17586]: warning: TLS library problem: 17586:error:1408F10B:SSL
                      Message 10 of 13 , Oct 28, 2013
                      • 0 Attachment
                        Hello!
                        Have the similar problem:
                        Oct 22 17:12:12 awtech postfix/smtp[17586]: warning: TLS library
                        problem: 17586:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
                        number:s3_pkt.c:337:
                        Oct 22 17:12:12 awtech postfix/smtp[17586]: 034C0B14237: lost connection
                        with mail.trialtolatvia.lv[109.205.120.111] while sending MAIL FROM
                        Oct 22 17:12:13 awtech postfix/smtp[17586]: warning: TLS library
                        problem: 17586:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
                        number:s3_pkt.c:337:
                        Oct 22 17:12:13 awtech postfix/smtp[17586]: 034C0B14237:
                        to=<Jelena.Ivanova@...>,
                        relay=isa.dominantecapital.lv[109.205.120.110]:25, delay=580,
                        delays=580/0.01/0.42/0, dsn=4.4.2, status=deferred (lost connection with
                        isa.dominantecapital.lv[109.205.120.110] while sending MAIL FROM)

                        but here I have "while sending MAIL FROM".
                        What else info I need to supply, to figure out what is wrong?

                        --
                        Regards,
                        KSB
                      • Viktor Dukhovni
                        ... It is exactly the same problem, with exactly the same solution. ... tls_policy: # opportunistic, season to taste trialtolatvia.lv may exclude=3DES:aNULL
                        Message 11 of 13 , Oct 28, 2013
                        • 0 Attachment
                          On Mon, Oct 28, 2013 at 05:54:51PM +0200, KSB wrote:

                          > Hello!
                          > Have the similar problem:

                          It is exactly the same problem, with exactly the same solution.

                          > Oct 22 17:12:12 awtech postfix/smtp[17586]: warning: TLS library
                          > problem: 17586:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong
                          > version number:s3_pkt.c:337:
                          > Oct 22 17:12:12 awtech postfix/smtp[17586]: 034C0B14237: lost
                          > connection with mail.trialtolatvia.lv[109.205.120.111] while sending
                          > MAIL FROM
                          > Oct 22 17:12:13 awtech postfix/smtp[17586]: warning: TLS library
                          > problem: 17586:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong
                          > version number:s3_pkt.c:337:
                          > Oct 22 17:12:13 awtech postfix/smtp[17586]: 034C0B14237:
                          > to=<Jelena.Ivanova@...>,
                          > relay=isa.dominantecapital.lv[109.205.120.110]:25, delay=580,
                          > delays=580/0.01/0.42/0, dsn=4.4.2, status=deferred (lost connection
                          > with isa.dominantecapital.lv[109.205.120.110] while sending MAIL
                          > FROM)
                          >
                          > but here I have "while sending MAIL FROM".
                          > What else info I need to supply, to figure out what is wrong?

                          tls_policy:
                          # opportunistic, season to taste
                          trialtolatvia.lv may exclude=3DES:aNULL

                          main.cf:
                          indexed = ${default_database_type}:${config_directory}/
                          smtp_tls_policy_maps = ${indexed}tls_policy

                          # postmap tls_policy

                          --
                          Viktor.
                        • Viktor Dukhovni
                          ... Alternatively, you can exclude TLSv1.2 and 3DES: trialtolatvia.lv may protocols=!SSLv2,!TLSv1.2 exclude=3DES the effect is the same, you get RC4-MD5, you
                          Message 12 of 13 , Oct 28, 2013
                          • 0 Attachment
                            On Mon, Oct 28, 2013 at 04:17:13PM +0000, Viktor Dukhovni wrote:

                            > > What else info I need to supply, to figure out what is wrong?
                            >
                            > tls_policy:
                            > # opportunistic, season to taste
                            > trialtolatvia.lv may exclude=3DES:aNULL
                            >
                            > main.cf:
                            > indexed = ${default_database_type}:${config_directory}/
                            > smtp_tls_policy_maps = ${indexed}tls_policy
                            >
                            > # postmap tls_policy

                            Alternatively, you can exclude TLSv1.2 and 3DES:

                            trialtolatvia.lv may protocols=!SSLv2,!TLSv1.2 exclude=3DES

                            the effect is the same, you get RC4-MD5, you can coerce a working RC4-SHA
                            out of this rust-bucket with:

                            trialtolatvia.lv may protocols=!SSLv2,!TLSv1.2 exclude=3DES:MD5

                            If you are able to get through to their postmaster, please let them
                            know that their TLS stack is in need of repair, and an upgrade to
                            a less ancient O/S release is advisable. There may be relevant
                            Microsoft hot-fixes that address the issue. (Something other than
                            an old Exchange server as a perimeter MTA might be a good option).

                            --
                            Viktor.
                          • Viktor Dukhovni
                            ... So after further research it turns out that: - The Windows 2003 TLS implementation only looks at the first 64 cipher-suites in the client SSL/TLS HELLO. -
                            Message 13 of 13 , Nov 7, 2013
                            • 0 Attachment
                              On Wed, Oct 16, 2013 at 01:59:51PM +0000, Viktor Dukhovni wrote:

                              > > > exchangerelay unix - - n - - smtp
                              > > > -o smtp_sasl_mechanism_filter=!gssapi,login
                              >
                              > To support Exchange MSAs on Windows 2003 generically (less critical
                              > state in per-relay policy entries):
                              >
                              > exchangerelay unix - - n - - smtp
                              > -o smtp_sasl_mechanism_filter=login
                              > -o smtp_tls_security_level=secure
                              > -o smtp_tls_mandatory_ciphers=medium
                              > -o smtp_tls_mandatory_exclude_ciphers=3DES

                              So after further research it turns out that:

                              - The Windows 2003 TLS implementation only looks at the first
                              64 cipher-suites in the client SSL/TLS HELLO.

                              - If RC4-MD5 is found among these, it uses RC4-MD5.
                              Otherwise, if RC4-SHA is found among these, it uses RC4-SHA.
                              Otherwise, if DES-CBC3-SHA is found among these, it uses DES-CBC3-SHA.

                              - However, the DES-CBD3-SHA cipher-suite is broken (incorrect CBC padding)

                              So to use TLS with such a site "RC4-SHA" or "RC4-MD5" must be in
                              the first 64 ciphers-suites. Since no other ciphers work, and MD5
                              is deprecated the cleanest solution is a radically trimmed down
                              set of ciphers:

                              master.cf:
                              exchangerelay unix - - n - - smtp
                              -o smtp_sasl_mechanism_filter=login
                              -o smtp_tls_security_level=may
                              -o smtp_tls_ciphers=medium
                              -o smtp_tls_mandatory_ciphers=medium
                              -o tls_medium_cipherlist=$tls_compat_cipherlist

                              main.cf:
                              indexed = ${default_database_type}:${config_directory}/
                              transport_maps = ${indexed}transport
                              smtp_tls_policy_maps = ${indexed}tls_policy
                              tls_compat_cipherlist = aNULL+AES128:aRSA+AES128:RC4-SHA:@STRENGTH

                              where we throw in some AES128 algorithms just in case the server
                              is some-day patched to support a more reasonable set of cipher-suites.

                              The security level for the transport can be set to a preferred value
                              globally as above, and if desired per-site settings can be used to
                              specify non-default security levels and/or match criteria.

                              transport:
                              example.com exchangerelay:example.com

                              tls_policy:
                              example.com secure match=nexthop

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