SLES11 Sp4 + Zypper + curl force use TLSv1.2?

[dgersic]

I have a collection of SLES11 Sp4 boxes here being managed and patched via SUSE Manager. All of them are more-or-less current (SLES Sp4 updates applied up through last week, SUSE Manager is on SLES12 Sp2 with updates applied last week). Most of them work fine when being scheduled to patch (managed via Salt, if that matters). A few fail to patch.

I can see that Zypper attempts to fetch its patches from SuMa using curl. I can reproduce the symptom using curl or wget, so it’s not a Zypper problem. Basically, what I see (packet trace) is that the curl client goes out and makes a https:// attempt with TLSv1, which is kicked back. Through some investigation, we seem to have found a device that is on the network between the SLES11 server and the SuMa server. I think what I’m seeing is that this device is acting as a proxy, intercepting the https:// traffic, trying to “step up” the connection to TLSv1.2, which is then rejected, and it kills the connection.

Interestingly, if I immediately retry, the https:// connection goes through to SuMa and away we go. There’s about a 5 minute window during which this mysterious device allows TLSv1 connections, then it goes back to trying to step up to TLSv1.2.

Given that SuMa is up to date, it seems that it should accept TLSv1.2 connections. What I’m looking for / hoping to find, is a way to get curl to use TLSv1.2 by default. But since it’s being called from Zypper, I have no control over how curl is being used to fetch patches. Whether that will convince this device to get out of the way of the connections, I don’t know, but it seems worth a try.

[ab1]

I think I must be misunderstanding something, but let’s see.

On 01/05/2018 08:34 AM, dgersic wrote:[color=blue]

I have a collection of SLES11 Sp4 boxes here being managed and patched
via SUSE Manager. All of them are more-or-less current (SLES Sp4 updates[/color]

Which version of SUSE Manager, and along those lines, which version of
SLES (with which SP) is SUMA on?
[color=blue]

applied up through last week, SUSE Manager is on SLES12 Sp2 with updates
applied last week). Most of them work fine when being scheduled to patch
(managed via Salt, if that matters). A few fail to patch.

I can see that Zypper attempts to fetch its patches from SuMa using
curl. I can reproduce the symptom using curl or wget, so it’s not a
Zypper problem. Basically, what I see (packet trace) is that the curl[/color]

From where is the packet trace taken? Both the SLES client and the SUMA
box, hopefully?
[color=blue]

client goes out and makes a https:// attempt with TLSv1, which is kicked
back. Through some investigation, we seem to have found a device that is
on the network between the SLES11 server and the SuMa server. I think
what I’m seeing is that this device is acting as a proxy, intercepting
the https:// traffic, trying to “step up” the connection to TLSv1.2,
which is then rejected, and it kills the connection.[/color]

This sounds to me like you have TLSv1.0 to the mysterious proxy thing, and
the proxy has a second connection to the SUMA box using whatever, in this
case TLSv1.2, but that should be transparent to your SLES client. It is
also something that sounds like you should fix on the proxy.
[color=blue]

Interestingly, if I immediately retry, the https:// connection goes
through to SuMa and away we go. There’s about a 5 minute window during
which this mysterious device allows TLSv1 connections, then it goes back
to trying to step up to TLSv1.2.[/color]

Bad proxy; fix it.
[color=blue]

Given that SuMa is up to date, it seems that it should accept TLSv1.2
connections. What I’m looking for / hoping to find, is a way to get curl[/color]

I am not sure that is true unless you have the Security Module added to
SLES 11. SLES 11 comes with openssl 0.9.8 which did not support TLS 1.2.
Even if it did, the connection seems to be dying because of something your
proxy is doing, not something your client is doing, so I do not see how
the client side matters since it is able to make a connection with the proxy.
[color=blue]

to use TLSv1.2 by default. But since it’s being called from Zypper, I
have no control over how curl is being used to fetch patches. Whether
that will convince this device to get out of the way of the connections,
I don’t know, but it seems worth a try.[/color]

https://www.suse.com/documentation/suse-best-practices/singlehtml/securitymodule/securitymodule.html

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

[dgersic]

[QUOTE=ab;40718]I think I must be misunderstanding something, but let’s see.

On 01/05/2018 08:34 AM, dgersic wrote:[color=blue]

I have a collection of SLES11 Sp4 boxes here being managed and patched
via SUSE Manager. All of them are more-or-less current (SLES Sp4 updates[/color]

Which version of SUSE Manager, and along those lines, which version of
SLES (with which SP) is SUMA on?
[/QUOTE]

No, I think you understand it perfectly. “bad proxy”, except that I can’t “fix”.

SuMa is 3.1.3 on SLES12 Sp2.

@ab;40718

[color=blue]

applied up through last week, SUSE Manager is on SLES12 Sp2 with updates
applied last week). Most of them work fine when being scheduled to patch
(managed via Salt, if that matters). A few fail to patch.

I can see that Zypper attempts to fetch its patches from SuMa using
curl. I can reproduce the symptom using curl or wget, so it’s not a
Zypper problem. Basically, what I see (packet trace) is that the curl[/color]

From where is the packet trace taken? Both the SLES client and the SUMA
box, hopefully?

I’ve done both sides, yes. The interesting trace is from the SLES11 Sp4 client side of the connection. The SuMa box doesn’t receive any packets, so its trace is kinda boring to look at.

@ab;40718

[color=blue]

client goes out and makes a https:// attempt with TLSv1, which is kicked
back. Through some investigation, we seem to have found a device that is
on the network between the SLES11 server and the SuMa server. I think
what I’m seeing is that this device is acting as a proxy, intercepting
the https:// traffic, trying to “step up” the connection to TLSv1.2,
which is then rejected, and it kills the connection.[/color]

This sounds to me like you have TLSv1.0 to the mysterious proxy thing, and
the proxy has a second connection to the SUMA box using whatever, in this
case TLSv1.2, but that should be transparent to your SLES client. It is
also something that sounds like you should fix on the proxy.

Yeah. The box in the middle is, IMHO, broken. But, it’s not my box, and I haven’t yet managed to get somebody to fix it. That’s been going on for a while now, so I’m trying to see if I can work around its brokenness.

@ab;40718

[color=blue]

Interestingly, if I immediately retry, the https:// connection goes
through to SuMa and away we go. There’s about a 5 minute window during
which this mysterious device allows TLSv1 connections, then it goes back
to trying to step up to TLSv1.2.[/color]

Bad proxy; fix it.

Right. I can’t.

@ab;40718

[color=blue]

Given that SuMa is up to date, it seems that it should accept TLSv1.2
connections. What I’m looking for / hoping to find, is a way to get curl[/color]

I am not sure that is true unless you have the Security Module added to
SLES 11. SLES 11 comes with openssl 0.9.8 which did not support TLS 1.2.
Even if it did, the connection seems to be dying because of something your
proxy is doing, not something your client is doing, so I do not see how
the client side matters since it is able to make a connection with the proxy.

[color=blue]

to use TLSv1.2 by default. But since it’s being called from Zypper, I
have no control over how curl is being used to fetch patches. Whether
that will convince this device to get out of the way of the connections,
I don’t know, but it seems worth a try.[/color]

https://www.suse.com/documentation/suse-best-practices/singlehtml/securitymodule/securitymodule.html

Haven’t added anything, so I guess I’m stuck at TLSv1.0 for now. I’ll see if that’s something I want to try adding.

Overall, it’s a stupid problem, that I shouldn’t have to work around, but with no other really good options, it’s worth a shot.

[ab1]

On 01/05/2018 12:24 PM, dgersic wrote:[color=blue]

No, I think you understand it perfectly. “bad proxy”, except that I
can’t “fix”.

SuMa is 3.1.3 on SLES12 Sp2.[/color]

At least that version probably nicely understands TLS 1.2 since it is on a
SLES 12 box; hooray for small, and in your case, irrelevant things.
[color=blue]

I’ve done both sides, yes. The interesting trace is from the SLES11 Sp4
client side of the connection. The SuMa box doesn’t receive any packets,
so its trace is kinda boring to look at.[/color]

If you never see anything relevant on the SUMA side, what good will there
be in getting SLES 11 to speak TLS 1.2? If the Proxy is doing any
connection handling at all at the TLS (session) layer, then I presume it
is decrypting traffic, then re-encrypting for the second part of the
journey, which makes sense for a proxy to do if it is not just a simple
pass-these-encrypted-things-along-untouched proxy. It also seems like a
silly thing to have in the middle generally, but the bigger point is that
there is nothing the client can do to get past it, and nothing the server
can do to help.

Care to post your LAN trace showing the proxy trying to change to TLS 1.2?
That would be weird to see; typically a TLS client offers the
ciphersuites it supports, and then the RFC states that the server chooses
the strongest one and tells the client they agree on that strong
ciphersuite, and that’s it.

What may be happening is less about trying to change to TLS 1.2, and
instead the proxy is just configured to only do TLS 1.2, in which case
when it gets the supported ciphersuite list from the client (SLES box) it
simply responds with an alert indicating there are no compatible
algorithms and kills the connection. This should be a 100% of the time
thing, though, and I think you said it is intermittent, so that’s weird,
but broken things are weird.
[color=blue]

Yeah. The box in the middle is, IMHO, broken. But, it’s not my box, and
I haven’t yet managed to get somebody to fix it. That’s been going on
for a while now, so I’m trying to see if I can work around its
brokenness.[/color]

Configure SLES to NOT use the proxy and try again.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.