Build, protect and deploy apps across any platform and mobile device
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate decision processes with a no-code business rules engine
Build mobile apps for iOS, Android and Windows Phone
A complete cloud platform for an app or your entire digital business
Deploy automated machine learning to accurately predict machine failures with technology optimized for Industrial IoT.
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
In this tutorial, learn how to use Schannel SSP via Progress DataDirect ADO.NET clients to configure Cipher Suite Open Access Client for ADO.NET.
Imagine an application communicating over SSL but that doesn’t really has a say on the Cipher Suite to be used. You may feel, what good is the SSL Communication for if I can't define my application to communicate on a Cipher Suite of my choice? But, such is the case with .NET Applications. Yes—the .NET Framework has no default provision to configure the Cipher Suite(s) to be used in a Secure Communication.
Progress DataDirect ODBC drivers support a CipherList option to control the Cipher Suites used. But has anyone done this with ADO.NET client? This blog shows you a way to do that using Schannel SSP with Progress DataDirect ADO.NET clients. And what's more; you don't even have to recompile your application. 😊
ADO.NET drivers use the “System.Net.Security.SslStream” class for Client-Server communication over the SSL protocol to authenticate the client and Server. But, this class does not allow a way to specify the “CipherSuite” to be used for the Secure Communication. It has a property for ‘CipherAlgorithm’ which allows you to get the Cipher Algorithm that the SSLStream is using—but it does not allow it to be set.
This eventually limits the ability to choose the Cipher Suite for an ADO.NET Client.
There is no direct programmatic way to get around this problem. But, we can configure the SChannel Security Support Provider (SSP) to use algorithms for key exchange, message encryption, hash algorithms etc. SChannel is a SSP which implements SSL and TLS protocols. SSPI is an API which Windows systems use for Security operations and the SChannel SSP implements the SSPI Interface.
Which means… Yes, you guessed it right!
We will define our Cipher Suite at this lower level—at the SChannel level.
SChannel SSP has different Registry keys for different parts that make up a Cipher Suite—Ciphers, KeyExchangeAlgorithms, Hashes, Protocols etc. Modifying these, we can define which Cipher Suite is to be enabled or disabled.
The Subkeys under the SChannel Registry:
For instance, to configure the TLS_RSA_WITH_RC4_128_SHA Cipher Suite, the following subkeys needs to be added and enabled. We will see the exact details of how to configure with an example in the subsequent section.
Let’s look at it in detail with reference to the Progress DataDirect Open Access SDK Client for ADO.NET, which is trying to communicate with the Progress DataDirect Open Access SDK Server over Secure Sockets Protocol (SSL).
Scenario: We have the following two Cipher Suites configured at the Open Access SDK Server side, which means a client can connect to this Server over SSL with either of these Cipher Suites.
The default Cipher Suite that gets picked up is always the latest one. When no SCHANNEL configurations are made, and an ADO.NET client for Open Access connects to the Server (with configuration shown in Figure 1), the Cipher Suite 1—TLS_RSA_WITH_RC4_128_SHA will be picked up.
Now, if I am interested (for any reason) in the other Cipher Suite with MD5, I need to add these algorithms to the SChannel’s list and disable the SHA algorithm so that the MD5 is picked up.
Here are the steps to enable the TLS_RSA_WITH_RC4_128_MD5 Cipher Suite to be picked up over TLS_RSA_WITH_RC4_128_SHA.
Note: This example is for a Windows 7 Platform. The keys and the algorithms vary with platforms.
The Open Access SDK Server to which we want to connect is configured with two Cipher Suites—one with MD5 and the other with SHA. So, we need to add both the Hashing algorithms to our SChannel configuration, and then we have to disable the SHA and enable the MD5. Let’s see how we do it.
This completes our SChannel Configuration.
Connect from a ADO.NET Client to the Server over SSL using the provider API. The Communication will use the Cipher suite—TLS_RSA_WITH_RC4_128_MD5 over the SHA one.
Yes, we are all control freaks :). Wasn't it good to get control over what Cipher Suites get used in your .NET applications?
Wait, there is something more to offer you: even more control.
The order in which Cipher Suites get picked up by your .NET application can be controlled as well. Stay tuned for our next blog, which will have details on how you can do it.
In short, to work around .NET‘s limitation of no provision to set a Cipher Suite for a Secure Communication, we can modify the SChannel SSPs configuration settings in the Windows Registry and achieve the effect of configuring Cipher Suites on a .NET Client end. More details coming in our next post.
Happy Secure Communication!
Swathy Nimbagiri is a QA Engineer at Progress with 7 years of experience in Quality Assurance. She has worked with products involving various technologies like SOA, ESB, JMS, BPM and ADO.NET. She is passionate about QA and testing products in the latest technology space. She primarily works on ensuring the functionality of products, usability and UI testing apart from developing Automation Frameworks.
Copyright © 2017 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.