Post reply

SQL Server Encryption - TLS 1.2

  • May 28, 2019 at 8:18 pm

    #3648034

    I was recently contacted by our Infrastructure group with a question about when\if we were going to implement TLS 1.2 on our SQL Servers.  I hate to admit it but this is one are where I am pretty ignorant.  So, I have been doing a LOT of reading and I'm getting to the point where I feel like I am reading the same things over and over, with just each person's little twist on the presentation.  In all that I am reading, however, I am not finding answers to some of my questions or I am getting conflicting answers.  I'm hoping some of you gurus out there can either help me with these questions or point me in the right direction for a good explanation.

    As of now, we only have one SQL Server that has any encrypted connections.

    1. Is it even necessary for me to implement TLS?  All of our database servers are internal with no outward facing access.
    2. I believe I read that, even if I implement TLS, it only encrypts the connection information but the data that flows in, and out, is still not encrypted.  I am led to believe that if I want to encrypt the data, I would need to implement something like TDS.  Is this correct?
    3. In the "Protocols for MSSQLSERVER", under "SQL Server Network Configuration", in the SQL Server Configuration Manger, what, exactly, does selecting "Force Encryption" do?  On the one server that has encrypted connections, that option is not selected but I do see a couple of certificates.  If I select "Force Encryption", does that mean there cannot be any connections that are not encrypted?  Does that mean existing applications that do not specify ENCRYPTED in their connection strings will stop working?  Is it possible to allow encryption but not enforce it if I DON'T select "Force Encryption"?
    4. Since none of our servers, minus the one, currently has encryption setup, is it a wise thing to do to existing servers or would this be best to do only when a need arises or upon the initial setup of any new servers?  My concern is causing any problems for existing applications.

    Sorry if these sound like newbie questions but I am getting overwhelmed by the amount of information I am reading but underwhelmed at the actual limited amount of differences in the posts without answers to some of my questions.

    Any help is greatly appreciated!

    ----------------------------------------------------------01010011010100010100110000100000010100110110010101110010011101100110010101110010001000000101001001101111011000110110101101110011

  • May 29, 2019 at 9:10 pm

    #3648422

    Thanks for posting your issue and hopefully someone will answer soon.

    This is an automated bump to increase visibility of your question.

  • May 30, 2019 at 3:15 pm

    #3648631

    Hi Hawg

    There is a PASS video about TLS 1.2 made by a microsoft sql tiger team.

    https://youtu.be/KrPp-G_1aAk

     

    Alex S

  • May 30, 2019 at 5:28 pm

    #3648667

    Funny, we started working on this last week.  Our security admin rolled out some changes to the registry that disabled TLS 1 and RC4 to eliminate some vulnerabilities.  Here is what has happened so far. It is turning out to be much more work than expected.  It's not just ssl encrypted sql server connections, but lots of other encryption that happens by default behind the scenes. Basic functionality of apps to the database was not broken.

    Spotlight monitoring broke to the 2008 servers.   Patched those and resolved that small issue.

    SSRS 2016 on a windows 2012 R2 server broke - report builder could not connect.  RSScripter, another utility could not connect.  Resolved that using the entries shown here.  However, that caused Power BI to not be able to connect to a web service on another web server in our environment.  Still working on that issue.  Guessing the web app is running on older .net that doesn't support TLS 1.2.

    Back to the 2008 servers.  Started testing connections to the servers with TLS 1.0 disabled.

    • Replication: broken
    • SSMS: works
    • SQLCMD: broken
    • OLEDB Linked servers: broken
    • Native client Linked servers: work
    • ODBC DSN Tests

      • sql 10 client: broken
      • sql 11 client: works

    Co-worker found another registry key that needed to be enabled after the patch, that got SQLCMD working.

    See this article, seems like a good resource.

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply