Windows 2003 / OpenSSL 1.x interoperability

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

Windows 2003 / OpenSSL 1.x interoperability

Philipp Gesang
First off I apologize if this message is delivered twice: The
first version I sent doesn't appear to have reached the list.

-----------------------------------------------------------------

Dear list,

this is a follow-up on the interoperability issues between
Windows 2003 servers and OpenSSL versions 1.x [0, 1]. A client
generously gave us access to one of their problematic Win 2003
machines for testing purposes.

The system was patched appropriately and capable of making 3DES
connections. It did, however fail to accept connections without
tweaking due to the multitude of additional cipher suites
available in OpenSSL 1.0.1g.

Unfortunately customizing the TLS policy per host is not an
option for us. The strategy that we came up with is similar to
Victor's recommendation in the referenced posts, except that
rather than excluding certain ciphers we push them to the end of
the list. Thus we keep the same total (111) of cipher suites
advertised to the server as with the default settings
("ALL:+RC4:@STRENGTH"). What we ended up using is

    tls_export_cipherlist = ALL:RC4:+3DES:+DSS:+IDEA:+SEED:+PSK:+DES:+RC2:+aNULL:+ADH

(the export list being the default for outgoing connections). The
goal is to stay as accepting as possible so as to avoid offending
even weirder setups.

Also while there definitely is a maximum index up to which Win
2003 will recognize RC4 in the list of cipher suites, it appears
to be higher than 64: In our tests the server would prefer
RC4-SHA even with the first suite containing RC4 at index 65 and
RC4-SHA at 69; ("ALL:RC4:+SEED:+PSK:+DES:+RC2:+aNULL"). We did
not track down the exact limit.

We would welcome suggestions for better workarounds.
Unfortunately we don't have access to the machine in question any
longer so we won't be able to run further tests against a live
system.

Best regards,
Philipp

[0] http://thread.gmane.org/gmane.mail.postfix.user/239780/focus=239800
[1] http://www.ietf.org/mail-archive/web/tls/current/msg10471.html



attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows 2003 / OpenSSL 1.x interoperability

Viktor Dukhovni
On Thu, Apr 24, 2014 at 09:24:39AM +0200, Philipp Gesang wrote:

> The system was patched appropriately and capable of making 3DES
> connections. It did, however fail to accept connections without
> tweaking due to the multitude of additional cipher suites
> available in OpenSSL 1.0.1g.

Were the patches in question for Exchange 2003 or for Microsoft's
Schannel SSL/TLS library?  Did you successfully transmit email
mesages with "DES-CBC3-SHA" as the only client-side cipher-suite?

Please describe in as much detail as you have available the problems
observed on systems believed patched to correct implementations of
3DES-CBC in Exchange 2003.

> tls_export_cipherlist = ALL:RC4:+3DES:+DSS:+IDEA:+SEED:+PSK:+DES:+RC2:+aNULL:+ADH

On OpenSSL 0.9.8 systems this may be poorly sorted.  Better would be:

        ALL:@STRENGTH:+RC4:+3DES:+DSS:+IDEA:...

With OpenSSL 1.0.0 the "ALL" cipherlist is better sorted out of
the box, but I prefer to not rely on this too much.

> Also while there definitely is a maximum index up to which Win
> 2003 will recognize RC4 in the list of cipher suites, it appears
> to be higher than 64: In our tests the server would prefer
> RC4-SHA even with the first suite containing RC4 at index 65 and
> RC4-SHA at 69; ("ALL:RC4:+SEED:+PSK:+DES:+RC2:+aNULL"). We did
> not track down the exact limit.

That's because the client *does not* in fact send every cipher
suite to the server, some are dynamically excluded, e.g. PSK and
SRP cipher suites when the client has not registered values or
callbacks for the relevant shared secret.  If you captured the
traffic with wireshark, you'd observe that RC4 fails as soon as it
is in the 65th slot on the wire.  The limit is 64.

> We would welcome suggestions for better workarounds.
> Unfortunately we don't have access to the machine in question any
> longer so we won't be able to run further tests against a live
> system.

Exchange 2003 is no longer supported by Microsoft.  Windows server
2003 reaches end of support in July 2015.  Upgrades of the laggard
systems are long overdue.

Postfix 2.12 will by default retry in cleartext not only when the
TLS handshake fails, but also when TLS deliveries fail in data
transfer.  Such retries happen only for "sufficiently old" messages,
so unless your queue is congested the first delivery will be
deferred, and the fallback to cleartext will happen on the second
delivery attempt.  If an upgrade to the Postfix 2.12-20140406
snapshot is an option, that should solve the problem without tweaks.

20140209

        Workaround: the Postfix SMTP client now also falls back to
        plaintext when TLS fails after the TLS protocol handshake.
        Files: smtp/smtp.h, smtp/smtp_connect.c, smtp/smtp_trouble.c.

20140218

        Workaround: require that a queue file is older than
        $minimal_backoff_time, before falling back from failed TLS
        to plaintext (both during or after the TLS handshake).
        Viktor Dukhovni. Files: smtp/smtp.h, smtp/smtp.c,
        smtp/lmtp_params.c, smtp/smtp_params.c.

20140223

        Workaround: when a session breaks after the TLS handshake,
        do not fall back from TLS to plaintext when all recipients
        were deferred or rejected during the TLS phase. Files:
        smtp/smtp.h, smtp/smtp_rcpt.c.

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

Re: Windows 2003 / OpenSSL 1.x interoperability

Philipp Gesang
-<|  Quoting Viktor Dukhovni <[hidden email]>, on Thursday, 2014-04-24 13:15:54 |>-
> On Thu, Apr 24, 2014 at 09:24:39AM +0200, Philipp Gesang wrote:
>
> > The system was patched appropriately and capable of making 3DES
> > connections. It did, however fail to accept connections without
> > tweaking due to the multitude of additional cipher suites
> > available in OpenSSL 1.0.1g.
>
> Were the patches in question for Exchange 2003 or for Microsoft's
> Schannel SSL/TLS library?

According to the client the entire system was on the latest
patchlevel. I'm afraid I can't be more specific than that.

>                            Did you successfully transmit email
> mesages with "DES-CBC3-SHA" as the only client-side cipher-suite?

We observed the email successfully being relayed using that
cipher according to the maillog. Here's the line with the host
anonymized:

    Untrusted TLS connection established to XXX.FOO.ORG[NNN.NNN.NNN.NNN]:25: TLSv1 with cipher DES-CBC3-SHA (128/168 bits)

> Please describe in as much detail as you have available the problems
> observed on systems believed patched to correct implementations of
> 3DES-CBC in Exchange 2003.
>
> > tls_export_cipherlist = ALL:RC4:+3DES:+DSS:+IDEA:+SEED:+PSK:+DES:+RC2:+aNULL:+ADH
>
> On OpenSSL 0.9.8 systems this may be poorly sorted.  Better would be:
>
> ALL:@STRENGTH:+RC4:+3DES:+DSS:+IDEA:...
>
> With OpenSSL 1.0.0 the "ALL" cipherlist is better sorted out of
> the box, but I prefer to not rely on this too much.
We use OpenSSL 1.x but with 3DES keysize patched to 128 instead
of 168. Also most servers override the client preferences anyways
so "@STRENGTH" seems to be of limited value for outgoing connections.

> > Also while there definitely is a maximum index up to which Win
> > 2003 will recognize RC4 in the list of cipher suites, it appears
> > to be higher than 64: In our tests the server would prefer
> > RC4-SHA even with the first suite containing RC4 at index 65 and
> > RC4-SHA at 69; ("ALL:RC4:+SEED:+PSK:+DES:+RC2:+aNULL"). We did
> > not track down the exact limit.
>
> That's because the client *does not* in fact send every cipher
> suite to the server, some are dynamically excluded, e.g. PSK and
> SRP cipher suites when the client has not registered values or
> callbacks for the relevant shared secret.  If you captured the
> traffic with wireshark, you'd observe that RC4 fails as soon as it
> is in the 65th slot on the wire.  The limit is 64.
Thanks a lot for the explanation! The observed behavior is much
clearer to me now.

> > We would welcome suggestions for better workarounds.
> > Unfortunately we don't have access to the machine in question any
> > longer so we won't be able to run further tests against a live
> > system.
>
> Exchange 2003 is no longer supported by Microsoft.  Windows server
> 2003 reaches end of support in July 2015.  Upgrades of the laggard
> systems are long overdue.

Absolutely.

> Postfix 2.12 will by default retry in cleartext not only when the
> TLS handshake fails, but also when TLS deliveries fail in data
> transfer. [...]

Thanks for the  details. I'll continue lobbying for a Postfix
upgrade :)

Best regards,
Philipp


attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Windows 2003 / OpenSSL 1.x interoperability

Viktor Dukhovni
On Thu, Apr 24, 2014 at 04:05:54PM +0200, Philipp Gesang wrote:

> > Were the patches in question for Exchange 2003 or for Microsoft's
> > Schannel SSL/TLS library?
>
> According to the client the entire system was on the latest
> patchlevel. I'm afraid I can't be more specific than that.

That's unfortunate.

> > Did you successfully transmit email
> > mesages with "DES-CBC3-SHA" as the only client-side cipher-suite?
>
> We observed the email successfully being relayed using that
> cipher according to the maillog. Here's the line with the host
> anonymized:
>
>     Untrusted TLS connection established to
>     XXX.FOO.ORG[NNN.NNN.NNN.NNN]:25: TLSv1 with cipher DES-CBC3-SHA
>     (128/168 bits)

And the subsequent delivery on that connection completed successfully?

I see, you patched 3DES to 128 bits for sorting purposes, arguably,
because of meet-in-the-middle attacks, the correct strength is 112.
That's why we have SHA2-224 as a companion for 3DES.

> We use OpenSSL 1.x but with 3DES keysize patched to 128 instead
> of 168. Also most servers override the client preferences anyways
> so "@STRENGTH" seems to be of limited value for outgoing connections.

Server preferences are common for Web servers, but rather less
common for SMTP servers.  Please resist the urge to assume equivalence
for TLS with SMTP and TLS with HTTPS.  I recommend @STRENGTH for
a reason.

> > Postfix 2.12 will by default retry in cleartext not only when the
> > TLS handshake fails, but also when TLS deliveries fail in data
> > transfer. [...]
>
> Thanks for the  details. I'll continue lobbying for a Postfix
> upgrade :)

If you do manage to upgrade to Postfix 2.12, please report your
findings.  Does the new work-around solve the problem? ...

--
        Viktor.
Loading...