SQL Server connections with TLS vs. through an encrypted tunnel?

Question

I'm developing an application that will connect to Microsoft SQL Server in a local network:

• I'm considering whether these connections need to use TLS
• Or whether to leave it to the customer's administrators to use an encrypted tunnel, if they see fit. they may have other third party applications, also connecting to SQL Server.

But i'm not familiar with the solutions available to administrators to use an encrypted tunnel, besides VPN (and maybe a load balancer?).

Questions

• What would you do?
• What are the disadvantages to not using TLS in this context?
• Are there any solutions available for sending connections through an encrypted tunnel? (examples of products please)

I would prefer the simpler case, where i'm not responsible for the encryption

Edit:

I expect that SQL Server will be running in a local network

Answer 1

You don't need to do anything specific in this regard. If you need secure channel to SQL server, just insert encrypt=true in SQL connection string. This will request secure channel. The behavior of connection is controlled using TrustServerCertificate connection parameter. If it is set to True, client will fallback to insecure transport (if SQL server does not implement TLS) and will accept arbitrary certificate (potentially, untrusted, or MITM) when presented by server.

By default and when not configured, SQL server automatically generate a self-signed certificate to clients that require secure transport. If TrustServerCertificate is set to False, then client will fail if either, SQL does not implement TLS or server certificate is not valid according to validation rules. ADO.NET clients use Windows built-in certificate chaining engine to validate server certificate.

That's all what you shall to do regarding transport security for SQL client. If you expose connection string altering to systems administrators or application users, leave it up to management personnel.

Answer 2

In general: use TLS. Only if the data stays within a limited network that is not accessible from the outside, you might possibly get away to do it without TLS.

There are a number of options for creating an encrypted tunnel, among which IPSec and OpenVPN. Although possible, all administrators will first frown upon your lack of TLS support and then curse you for requiring them to build the tunnel. All require additional software, and all are harder to configure than simply using TLS. Some may need additional hardware to run reliably.

The only valid reason for not doing TLS is that you have very high (not just high, VERY high) transaction volumes. In that case, you would adapt your network architecture to accommodate for that quantity of transactions. If that is a possible deployment, you could provide an option to switch it off. But default should be TLS.

In the past, TLS (or SSL at that time) may not not have been common. It is now.