Skip to main content

When using the windows GUI (TSF_dotNET.exe version 2022.2.16.1) to connect to a SQL Server 2022 database backend it shows when using 

USE  master];
GO

SELECT *
FROM sys.dm_exec_connections;
GO

that no connection to our application is using an encrypted connection.

The encryption of the connection can be forced from the server (by using a (if needed self signed) certificate), but of course the clients (windows GUI, Indicium and whatsoever) should support this.

Regarding this situation the following questions come into mind:

  • Is using an encrypted connection between de windows GUI 2022.2.16.1 and the backend database server supported ? If so, please point to the appropriate documentation
  • Am I correct in assuming that username and password are at this moment (in a situation of no encrypted connection) exchanged in plain sight ?
  • How is the exchanging of username and password between GUI in general and application, by whatever means, ensured that it is encrypted should we be using the latest releases of the platform ?

Hi Frans,

When encryption is forced by the database server, this should be picked up by the Windows GUI. 

I’ve verified this on a local instance:

Force encryption turned on

The connections made by the Windows GUI then shows as encrypted. However, I’m using a more recent version of the Windows GUI. Version 2022.2 is no longer within our supported lifecycle policy. You may have to update your GUI.

 

Encrypted connections from the Windows GUI

 

Note that Indicium always used an encrypted connection, even when it’s not forced by the server.

Regarding your question about the credentials, if I’m not mistaken the authentication section for the database connection is always encrypted if the database server allows it. The connection can then return to unencrypted if the server allows it and the client allows it. This is in regard to RDBMS authentication. For Windows authentication, this is token-based so there are no credentials involved.

Source: Configure SQL Server Database Engine for encryption - SQL Server | Microsoft Learn

At a high level, there are two types of packets in the network traffic between a SQL Server client application and SQL Server: credential packets (login packets) and data packets. When you configure encryption (either server-side or client-side), both these packet types are always encrypted. But, even when you don't configure encryption, the credentials (in the login packet) that are transmitted when a client application connects to SQL Server are always encrypted. SQL Server uses a certificate that meets the certificate requirements from a trusted certification authority if available. This certificate is either manually configured by the system administrator, using one of the procedures previously discussed in the article, or present in the certificate store on the SQL Server computer.

Excellent Anne, thank you for your reply. It is good to hear and read that credentials are never transferred in plain sight / text.

I will check if the current GUI supports the behaviour described by you and otherwise I will plan an update of the GUI to the last version.

Reply


Terms & ConditionsCookie settings