ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexIBM MQ SecurityTLS_ECDHE cipher from Windows to Linux doesn't work

Post new topicReply to topic
TLS_ECDHE cipher from Windows to Linux doesn't work View previous topic :: View next topic
Author Message
isolom
PostPosted: Tue Dec 10, 2019 7:55 am Post subject: TLS_ECDHE cipher from Windows to Linux doesn't work Reply with quote

Newbie

Joined: 10 Dec 2019
Posts: 5

Hello Everyone,

we are trying to establish a TLS 1.2 connection from a Windows .NET client to 9.1 server on Linux using a TLS _ECDHE cipher. We got an TLS_RSA cipher working but none of the elliptic curve ones.

The rest of this message is technical details of what we tried. But what I would like to ask the community is this: can anyone establish such a connection? All settings possible, it just needs to be a managed client on Windows (any version), using .NET (Core or not), TLS_ECHDE cipher (any one), and on the receiving end MQ server 9.1 on Linux.

I need an understanding if it's possible. If it is, then it's on our side, and I'll keep digging. If it's not, then I'll stop wasting my time. Thank you for your attention!

We're getting 10013 in Windows Event Log, 2538 on MQ client side, and no entries in the server log.

We generated an elliptic curve certificate (ECC) and a regular RSA one with Sectigo (former Comodo). Added the cert to the Windows key repository, granted access via an HTTP utility.

Modified a SimplePut sample by IBM, compiled with .NET regular and Core libraries, tried connecting.

Modified Windows Group Policy:
gpedit.msc > Group Policy Management Console > Computer Configuration > Administrative Templates > Network > SSL Configuration Settings
double-click SSL Cipher Suite Order
and added the ciphers:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Modified the registry:
added to the registry
[HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ .NETFramework\ v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ .NETFramework\ v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\ SOFTWARE\ Wow6432Node\ Microsoft\ .NETFramework\ v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\ SOFTWARE\ WOW6432Node\ Microsoft\ .NETFramework\ v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ SSL 2.0\ Server]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ SSL 2.0\ Client]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ SSL 3.0\ Server]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ SSL 3.0\ Client]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.0\ Server]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.0\ Client]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.1\ Server]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.1\ Client]
"Enabled" = dword:00000000
"DisabledByDefault" = dword:00000001
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.2\ Server]
"Enabled" = dword:00000001
"DisabledByDefault" = dword:00000000
[HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SCHANNEL\ Protocols\ TLS 1.2\ Client]
"Enabled" = dword:00000001
"DisabledByDefault" = dword:00000000

Updated Windows security policy:
1.In Control Panel, click Administrative Tools, and then double-click Local Security Policy.
2.In Local Security Settings, expand Local Policies, and then click Security Options.
3.Under Policy in the right pane, double-click System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing, and then click Enabled.
4. Ran gpupdate /force

Changed permissions on a folder:
C:\ ProgramData\ Microsoft\ Crypto\ RSA and grant "Network Services" Read permission to "MachineKeys" folder. Then restart server to have a try.

Granted the account running SimplePut access to the Windows key repository:
winhttpcertcfg -g -c LOCAL_MACHINE\ MY -s "computer.domain.com” -a "account"

We also opened a PMR with IBM Support and spent a year generating traces without a result. I also raised this question at the Hursley Lab summit in October without a result.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Dec 10, 2019 8:24 am Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

Does it work from windows to windows?
Has it ever worked?
Does it work if you don't check for SSLPEER?

Hope it helps
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
isolom
PostPosted: Tue Dec 10, 2019 9:08 am Post subject: Reply with quote

Newbie

Joined: 10 Dec 2019
Posts: 5

Hi,

we never tried from Windows to Windows. We assume, because there's no entry in the server log, the connection is not leaving the Windows server, and, thus, the result would be the same on other server platforms.

We also have TLS_RSA cipher working in the exact same setup. And we also have TLS_ECDHE ciphers working for JMS and Java applications in the exact same setup.

It has never worked, not even once. We don't check for SSLPEER.
Our code (it fails on the qmgr constructor):
properties = new Hashtable();
properties.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED);
properties.Add(MQC.HOST_NAME_PROPERTY, "host");
properties.Add(MQC.PORT_PROPERTY, 1414);
properties.Add(MQC.CHANNEL_PROPERTY, "CHANNEL");
MQEnvironment.SSLKeyRepository = @"*SYSTEM";
MQEnvironment.CertificateLabel = "dotnetclientecc";
MQEnvironment.UserId = "account";
MQEnvironment.Password = "password";
MQEnvironment.SSLCipherSpec = "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384";

queueManager = new MQQueueManager(queueManagerName, properties);
queue = queueManager.AccessQueue(queueName, MQC.MQOO_OUTPUT + MQC.MQOO_FAIL_IF_QUIESCING);
message = new MQMessage();
message.WriteString("message");
queue.Put(message);
queue.Close();
queueManager.Disconnect();
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Dec 10, 2019 9:24 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

isolom wrote:
we never tried


Create a test environment, and try it.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Dec 10, 2019 6:38 pm Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

Does it work with an un-managed / non managed connection?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
isolom
PostPosted: Wed Dec 11, 2019 6:46 am Post subject: Reply with quote

Newbie

Joined: 10 Dec 2019
Posts: 5

We haven't tried that either.

We are a large enterprise with tens of .NET customers. Some are packaged applications with a configuration screen, some are custom-built, some go through API, some connect from outside.

We can't switch them to un-managed, even if we prove it works. Same for Windows to Windows connections. Our enterprise infrastructure uses RHEL VMs. Proving Windows to Windows works is a waste of time.
Back to top
View user's profile Send private message
tczielke
PostPosted: Wed Dec 11, 2019 7:59 am Post subject: Re: TLS_ECDHE cipher from Windows to Linux doesn't work Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

isolom wrote:
Hello Everyone,
We also opened a PMR with IBM Support and spent a year generating traces without a result. I also raised this question at the Hursley Lab summit in October without a result.


So in the IBM PMR, IBM had you run SSL/TLS traces and the results of the traces showed that the underlying issue is outside of the IBM MQ SSL/TLS code?
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
isolom
PostPosted: Wed Dec 11, 2019 8:40 am Post subject: Reply with quote

Newbie

Joined: 10 Dec 2019
Posts: 5

It was determined that the issue is somewhere in the Windows security stack.
But that is understandable from the error. 10013 is thrown by the SCHANNEL - that is a Windows component. We are currently trying to find a Microsoft support person who can help us with that.
Back to top
View user's profile Send private message
tczielke
PostPosted: Wed Dec 11, 2019 8:52 am Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

Ok, sounds like you are on the right track. The only other suggestion I can think of for debugging the issue is using the Sysinternals Process Monitor tool to see if there are any clues on what is failing. I highly doubt Windows would not support ECDHE.
_________________
Working with MQ since 2010.
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Dec 12, 2019 2:02 am Post subject: Re: TLS_ECDHE cipher from Windows to Linux doesn't work Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
Location: Bay of Plenty, New Zealand

isolom wrote:
we are trying to establish a TLS 1.2 connection from a Windows .NET client to 9.1 server on Linux using a TLS _ECDHE cipher. We got an TLS_RSA cipher working but none of the elliptic curve ones.

The rest of this message is technical details of what we tried. But what I would like to ask the community is this: can anyone establish such a connection? All settings possible, it just needs to be a managed client on Windows (any version), using .NET (Core or not), TLS_ECHDE cipher (any one), and on the receiving end MQ server 9.1 on Linux.

I need an understanding if it's possible. If it is, then it's on our side, and I'll keep digging. If it's not, then I'll stop wasting my time. Thank you for your attention!

We're getting 10013 in Windows Event Log, 2538 on MQ client side, and no entries in the server log.


You don't mention what level of .NET Framework. I assume it must be 4.5?

The 10013 reason code from Windows means:-
Quote:
WSAEACCES
10013
Permission denied.
An attempt was made to access a socket in a way forbidden by its access permissions. An example is using a broadcast address for sendto without broadcast permission being set using setsockopt(SO_BROADCAST).
Another possible reason for the WSAEACCES error is that when the bind function is called (on Windows NT 4.0 with SP4 and later), another application, service, or kernel mode driver is bound to the same address with exclusive access. Such exclusive access is a new feature of Windows NT 4.0 with SP4 and later, and is implemented by using the SO_EXCLUSIVEADDRUSE option.


I'm sure you already know that of course, but it might save other readers of this thread from looking it up.

If it works with the Java client with the exact same elliptic curve certificate, then the certificates are ruled out as problematic.
If it works with RSA certificates, then the ports and firewalls are ruled out as problematic.
Which leaves the .NET support for elliptic, and the MQ use of those services.

I notice on this page in IBM Knowledge Center, that the CipherSpec that you mention is not listed as one for managed .NET client. Have you tried any of the ones listed on this page?

Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Back to top
View user's profile Send private message Visit poster's website
isolom
PostPosted: Fri Dec 20, 2019 8:21 am Post subject: Reply with quote

Newbie

Joined: 10 Dec 2019
Posts: 5

Thank you for your suggestions. I wasn't notified of a reply to the thread, so pardon the delay.

Windows 10 Enterprise 2016 LTSB v1607, OS build 14393.3181
.NET Core 2.1
.NET MQ Regular Client 9.1.3 CD
MQ Server 9.1.0.3 LTS

I am not a Windows person, does Core supersede Framework or include it or something else?

I tried all the ciphers on the page you suggested, no luck.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexIBM MQ SecurityTLS_ECDHE cipher from Windows to Linux doesn't work
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.