C
Chandra Sekhar Mondeti
Guest
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.
What Is the Deal with .NET Clients?
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.
How Do We Have a Say on Cipher Suites?
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.
Figure 1: OpenAccess SDK Server Configuration
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.
Figure 2: KeyExchangeAlgorithm Registry Entry
Figure 3: Enabling RC4 Cipher Algorithm
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.
Figure 5: Enabling the MD5 Algorithm
This completes our SChannel Configuration.
Figure 6: How the Entire Registry Settings Should Look (Exported Format)
.png?sfvrsn=0)
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.
Fig 7: Snippet from the Server Log
Controlling the Order of Cipher Suites:
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.
A Preview: Configuring Cipher Suites on a .NET Client
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!
References:
Try Progress DataDirect ODBC Drivers Free
Continue reading...
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.
What Is the Deal with .NET Clients?
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.
How Do We Have a Say on Cipher Suites?
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:
- Protocols—Controls the SSL Protocols (TLS1.1, SSL 3.0 etc.) that we want to be enabled or disabled which are not negotiated by default
- Ciphers—Defines the symmetric algorithms such as DES, RC4, RC2 etc.
- Hashes—Defines the Hashing algorithms like MD5, SHA
- KeyExchangeAlgorithms—Defines the Key Exchange Algorithms like RSA
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.
- SCHANNEL\Protocols\TLS1.2—This configures the use of TLS1.2 protocol
- SCHANNEL\KeyExchangeAlgorithms\PKCS—This defines enabling/disabling of the RSA Algorithm for Key Exchange
- SCHANNEL\Ciphers\RC4 128/128—This defines the use of RC4 Symmetric Algorithm
- SCHANNEL\Hashes\SHA
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.
- Cipher Suite 1—TLS_RSA_WITH_RC4_128_SHA
- Cipher Suite 2—TLS_RSA_WITH_RC4_128_MD5
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.
Figure 1: OpenAccess SDK Server Configuration
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.
- Start the Registry Editor and locate the key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
- To enable the RSA Key Exchange Algorithm, we need to add the following subkey under SCHANNEL:
SCHANNEL\KeyExchangeAlgorithms\PKCS
- Add a DWORD type key—‘Enabled’ under this subkey and set the value to 0xffffffff to enable RSA. The value 0x0 is used to disable RSA based Cipher Suites.
Figure 2: KeyExchangeAlgorithm Registry Entry
Figure 3: Enabling RC4 Cipher Algorithm
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.
- Add the subkey—SCHANNEL/Hashes subkey
- Under Hashes subkey, add two subkeys—SCHANNEL\Hashes\MD5 and SCHANNEL\Hashes\SHA
- Add a DWORD value type with the name “Enabled” under both subkeys—MD5 and SHA
- For MD5, set the value of the "Enabled" key to 0xffffffff
- For SHA, to disable it, use 0x0 as value to the “Enabled” key.
Figure 5: Enabling the MD5 Algorithm
This completes our SChannel Configuration.
Figure 6: How the Entire Registry Settings Should Look (Exported Format)
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.
Fig 7: Snippet from the Server Log
Controlling the Order of Cipher Suites:
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.
A Preview: Configuring Cipher Suites on a .NET Client
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!
References:
Try Progress DataDirect ODBC Drivers Free
Continue reading...