Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: TLS library problem - SSL routines:SSL3_GET_RECORD - wrong version number
6,266 views
Skip to first unread message
KSB
Oct 28, 2013, 11:54:51 AM10/28/13
to
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....@trialtolatvia.lv>,
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
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....@trialtolatvia.lv>,
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
Oct 28, 2013, 12:26:42 PM10/28/13
to
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:
> > What else info I need to supply, to figure out what is wrong?
>
> # 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
Oct 28, 2013, 12:17:13 PM10/28/13
to
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.
> 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....@trialtolatvia.lv>,
> 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
--
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
Nov 7, 2013, 5:13:45 PM11/7/13
to
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
transport_maps = ${indexed}transport
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.
> > > 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
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.
0 new messages