SQL Server 2005 offers the capability of channel encryption through the use of SSL (as did SQL Server 2000). The instructions for doing so are well documented in the BOL but I’ll briefly descirbe what’s entailed here.
- The first thing you need to do is provision a certificate on the server machine. In addition, the client machine should be configured to trust the certificate’s root signing authority. This KB article provides good instructions on doing this: http://support.microsoft.com/default.aspx?scid=kb;en-us;316898
- The server may force all incoming connections to use SSL encryption by setting the ForceEncryption parameter in the SQL Server Configuration Manager (right-click on “Protocols for <instance>” and select “Yes” in the drop-down box next to “ForceEncryption”). Any clients that do not support encryption will fail to connect.
- Alternatively, the client can request encryption on a per-machine or per-connection basis. If the server is incapable of supporting SSL, then the connection will fail.
- To set the encryption on a per-machine basis, use the SQL Server Configuration Manager (right-click “SQL Native Client Configuration” and select “Yes” in the drop-down box next to “Force protocol encryption”)
- For a per-connection basis, the encryption option can be specified in the connection string. E.g., using the “Encrypt=yes” keyword as a connection attribute for an ODBC connection. (Also for ODBC, the encryption property can be specified in a DSN.)
It’s important to note that the highest level of security is achieved when the client explicitly requests that channel encryption be used. This is because the client will attempt to validate the identity of the server using the SSL certificate in this situation and this helps mitigate man-in-the-middle attacks.
I should also mention that it is possible to get SSL encryption without provisioning a certificate because of the new self-signed certificate feature. I’ve posted a detailed explanation in the DataWorks blog so take a look if you’re interested (http://blogs.msdn.com/dataaccess/archive/2005/08/05/448401.aspx). However, for security reasons, it is always preferable to use a properly provisioned certificate.
Program Manager, SQL Server Protocols
Disclaimer: This posting is provided “AS IS” with no warranties, and confers no rights