Create and deliver personalized experiences across digital properties at scale
Build engaging websites with intuitive web content management
Leverage a complete UI toolbox for web, mobile and desktop development
Build, protect and deploy apps across any platform and mobile device
Build mobile apps for iOS, Android and Windows Phone
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate UI, load and performance testing for web, desktop and mobile
Host, deploy and scale Node.js, Java and .NET Core apps on premise or in the cloud
Optimize data integration with high-performance connectivity
Automate decision processes with a no-code business rules engine
Globally scale websites with innovative content management and infrastructure approaches
Content-focused web and mobile solution for empowering marketers
Faster, tailored mobile experiences for any device and data source
UX and app modernization to powerfully navigate today's digital landscape
Fuel agility with ever-ready applications, built in the cloud
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!
Chandra Sekhar Mondeti is a QA Engineer at Progress Software, India. He has several years of industry experience in automation, cloud testing and automation framework development, such as model-based automated test generation frameworks. He also has experience in various cutting-edge technologies, including cloud, mobile applications and analytics. He writes technical blogs about Telerik Test Studio, Telerik Analytics and other Progress products. He also developed a Telerik mobile application by integrating D2C-Telerik and Rollbase-Telerik.
Copyright © 2016, 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 or appropriate markings.