We have an application running on windows 2012 R2 OS with 4.6 framework and database as SQL server 2012. Due to security concerns we were asked to enable TLS1.2 protocol for the calls made between application server to database server and vice versa. I have followed below URL and we have all patches installed.
https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server.
Our front end application doesnt directly call the database instead we have WCF service in between front end application (asp.net) and SQL server. I read in an article we can achieve this without making changes to the code and change the providername ="SQLNCI11". When i change the provider name like below i am getting error. saying that "Unable to find the requested .Net Framework Data Provider"
Data Source=servername;Initial Catalog=DBname;uid=XXX;pwd=XXXX;Connect Timeout=200;MultipleActiveResultSets=True;Current Language=us_english; providername="SQLNCI11"
I have verified machine.config and i dont find DBproviderfactory for SQL native client.Am i missing anything here?
As an alternative, Without changing provider name in connection string i have added Encrypt=true;TrustServerCertificate=true in connection string
Data Source=servername;Initial Catalog=DBname;uid=XXX;pwd=XXXX;Connect Timeout=200;MultipleActiveResultSets=True;Current Language=us_english; Encrypt=true;TrustServerCertificate=true providername="System.Data.SqlClient"
After making above changes in connection string database call was success and when i see Ethernet communication using wireshark tool, database to WCF service communication is made with TDS protocol and TLS is involved according to wireshark tool. If i remove "Encrypt=true;TrustServerCertificate=true" from connection string then i dont see "TLS Exchange" message.
What steps should I need to take to ensure the application use TLS 1.2 protocol to communicate with the database? and also please suggest how to prove this communication.
One year later, I wanted to assess the same thing - knowing exactly what TLS version is in use for my MS SQL traffic.
Actually TLS is encapsulated in TDS when it comes to MS SQL traffic.
You can see TDS header (starting by 0x12 - higlighted in yellow in the picture).
After this header begins the TLS packets and you can check version by looking at 2nd and 3rd TLS packets.
In my example, 0x03 0x03 stands for TLS 1.2 (3rd version of TLS protocol)
Related
This is resulting from an outbound connection to Equifax's new TLS 1.2-enabled URL.
Background:
Servers: Windows 2012 R2, .NET 4.6.2, all TLS 1.x Enabled in Test, Stage and Production tiers per this. IIS configurations match between servers (app pools/code except tier-specific configurations/IIS settings.)
Servers are load balanced via Citrix Netscaler, but this site uses Port 80/HTTP, no HTTPS configuration.
Both tiers use the same Equifax URL, but with tier-specific credentials.
The Situation:
Prod will not communicate with their site, we get the opening error.
Our stage environment has no problem communicating.
What we have done:
- Validated TLS reg settings match
- Swapped the prod web.config to the Stage server and the communication worked, so it seems unlikely that it is a web.config issue in production.
- Validated .NET versions
- Checked LSA fips reg setting (set to 0)
- checked for wonky updates known to cause issues
We are going to setup a network trace, but for the moment we are at a bit of a loss. I would appreciate any insights as to what I might be missing.
Developers had to do the following:
Added the specification of using 4.6 per Microsoft recommendations.
Updated some other .NET references in the web.config to point specifically to 4.6.2
They made some changes in some older code pieces to make them 4.6.2-compliant.
I have an IIS hosted WCF Service that uses SSL encryption. This service makes requests to a SQL Server 2014 database instance. When I make a call to the service the response message is encrypted. So, the connection between the client (browser) and the service is secure. I also want the connection between the service and the SQL Server 2014 database to be secure.
This is where my question comes in. I am not exactly sure how to do this. I read the following article Enable Encrypted Connections to the Database Engine and I was able to successfully add the certificate to the SQL server database engine and changed the Force Encryption flag to True. But now I am a bit confused as to whether I want to configure the server to accept encrypted connections or the client to request encrypted connections. Based on the scenario I presented above it seems I want the client to request encrypted connections from the SQL Server DB correct? I guess one reason I am confused is because this is ALL happening on my development machine. SQL Server is being hosted there as is the IIS Service.
If someone with experience could maybe clarify that for me I would greatly appreciate it.
If you haven't restarted the service, then do so to complete the configuration change. It sounds like you applied the change correctly and using a domain or public CA certificate will prevent a man in the middle attack. To verify that the connections are secure, you can use a DMV named sys.dm_exec_connection which should display true for the encrypt_option for all sessions, as below:
select session_id, net_transport, encrypt_option from sys.dm_exec_connections
I'm not certain that connections from the host to SQL Server will be encrypted by SSL\TLS since they would be using the shared memory protocol and Windows manages the security of shared memory.
In the SSH transport layer protocol specification, http://www.ietf.org/rfc/rfc4253.txt, section "4.2. Protocol Version Exchange", it says, "When the connection has been established, both sides MUST send an identification string.".
but it doesn't define which side shall initiate this process, the server side or the client side?
here are some observations,
In http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-4/124_ssh.html, "Figure 2: SSH Transport Layer Protocol Packet Exchanges", the client side initiate the exchange process.
I tried using JSCH as client to connect server, and here is the snapshot. the server side send the SSH Protocol version first.
And here is one issue, both JSCH and SSH server doesn't send Protocol version.
The TCP connection is setup in package 93, 94, 95. And after 5 seconds, the server side close the connection in package 99.
can you help figure out why both client and server doesn't send out the protocol version? thanks a lot!
Regards,
Joey
Yes, we had found that some cisco box does not send its version string
without receiving the client's version string.
The recent jsch version will send it immediately.
but it doesn't define which side shall initiate this process, the server side or the client side?
Correct. As both sides must send it, and neither is defined as a response to the other, it is irrelevant who does so first.
I thank you in advance for sharing your knowledge. Here is my question:
By default, SQL Azure connections are encrypted. so what is the significance of checking the 'encrypt connection' checkbox in the connection properties while connecting to SQL Azure from SSMS? Does it make any difference?
Paras,
When the client library first attempts a connection to SQL Server / SQL Azure, it sends an initial connection request. Consider this a "pre-pre-connection" request. At this point the client does not know if SSL/Encryption is required and waits an answer from SQL Server/SQL Azure to determine if SSL is indeed required throughout the session (not just the login sequence, the entire connection session). A bit is set on the response indicating so. Then the client library disconnects and reconnects armed with this information.
Consider a proxy sitting between the client and SQL Azure (or SQL Server). The client talks to the proxy, and the proxy talks to SQL Azure/Sql Server. If you do not force the encryption bit on the client, you leave it to the proxy to encrypt or not the session. The proxy could encrypt the connection on the backend (it would have to for SQL Azure) but not on the client-side of the connection, hence accessing all your sensitive data. So checking the encryption box bypasses the "pre-pre-connection" request which prevents any proxy from turning off the encryption bit in question on the client side of the proxy, hence avoiding the man-in-the-middle attack.
Hopefully that makes sense... :) If you download Wireshark and watch what happens with the pre-pre-login packets, you will see what I mean. Checking the box changes the pre-login handshake mechanism to avoid the man-in-the-middle attack I described.
If you turn on encryption in SAP between the client and the server using the Secure Network Connection, then is there a load placed on the server to do all the encryption work? How big a load? Is it equivalent to the difference between HTTP and HTTPS on a web server?
Please clarify what you want to do.
Do you just want to create secure RFC connections from the SAP GUI to the SAP system? Which 3rd party security product will you be using (e.g. Kerberos).
Will you be using Single Sign On? i.e. via an AD server. If so, where will the secure connection be - full end to end?
With encryption, the main load is during the initial handshaking between the client and the server. During this process, keys are calculated and exchanged.
See the SNC User's Guide for information.
I have not seen any references to the load on the system. I did ask SAP OSS years ago but did not get a satisfactory reply.
You cannot compare the load of SNC (using DIAG) to HTTPS because the protocols are very different - DIAG is a lot leaner.
I have investigated the use of F5 servers. They can be used for software and hardware accelleration of HTTPS, but not for the DIAG protocol.