Linked Server Data Stream Encryption

  • Hi everyone,

    I am new here and tried to find this answer but could not find what I need; sorry if I am duplicating a previous post...

    I have a client running a SQL server 2008 system containing user data that they need to send to our SQL server every night via a linked server and ssis package. We have secured a linked server connection between our 2 systems via firewall rules plus SQL encyption enabled and used between them and us.

    I can see from netmon that the connection itself is encrypted but the tds stream itself is not. I can look right into the packets and see the data. This tells me that the data itself is not being encrypted.

    Can so done tell e how to go about encrypting the data in this stream? This is a web app and the data on each end is not encrypted as we can't decrypt it in the application currently so for now I just need the data protected in the transfer between us and them.

    Thanks for any help.

  • When you create the linked server, you need to provide "Encrypt=yes" in the @provstr argument to sp_addlinkedserver. Obviously, both servers need to have the same certificate for the encryption to be secure.

    [font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]

  • I haven done this already. The connection itself starts out encrypted but the table data going through the tds packets is not. I have verified it isn't. If you inspect the packets going between the servers you will see this. I can look right into the tds packets and read the table data.

    I could of course encrypt the data itself via symmetric keys, etc but this isn't what we want as we have multiple sources and destinations involved. We need the encryption transparent but not via tde. Hopefully someone has encountered this before and know what to do

  • I will have to admit that I have not worked much with encrypted connections. But from what I read in Books Online, it should be possible. You need to set up SSL. Have you looked at this topic in Books Online: http://technet.microsoft.com/en-us/library/ms189067%28v=sql.105%29.aspx

    [font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]

  • Yep. I have the ssl working on server and client. I can see the tls connection and handshakes and many encrypted packets which is suspect is the dts and dml itself. Then when the data stream gets sent it is encapsulated tds packets inside tcp. When I inspect these packets I can read the table data. So this tells me that the table data stream is excluded from the encryption.

    This is either because I am doing something wrong or this is expected behavior. If it is expected I bet many people would be upset as from all articles and books online there is no indication your data isn't being protected.

    Can anyone confirm this and if your data is being encrypted what did you do differently?

  • Hm, exactly which connections did you specify to be encrypted? You talk both about SSIS and a linked server, and that's definitely two different things. If you move data through both, you need to enable encryption in both connections.

    [font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]

  • What we have done is create an ssis package on their system and then schedule it to run every night. The source is the server holding the package and the destination is the linked server which has been setup to encrypt. When we run the job I can see the tls handshake happening and everything not in a tds packet looks to be encrypted. When I view the tds packet itself I can read the data.

    Is there something else I need to specify on the ssis package to force the tds data to be encrypted? I have looked at the package options and nothing jumps out at me so your expertise here would be a great help. I have been a SQL server dba since 2000 but have to admit I am weak with linked servers and encryption sadly.

  • It still not clear to me: does SSIS connect directly to your site? Or does it connect to a server at the client where it inserts data into a table through four-part notation? That sounds a little funny, but you keep talking about a linked server.

    I have never worked with SSIS myself, so I don't really know what to configure there. But common sense tells me that it is just another conncetion string, and you need Encrypt=Yes in the connection string. And you need a certificate that is installed in both places. (Or use the self-signed certificate that SQL Server generates, but then someone can eavesdrop that certificate when it crosses the wire.)

    Maybe you should first to get encrypted connections going locally. The simplest is to try SQLCMD with the -N option.

    [font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]

  • We have it setup this way. In their data centre they added our SQL server as a linked server. Our server is in our data centre which is accessible through the internet, we locked down the connection via firewall rules of course.

    They created a ssis package that sends data from their hr table to our users table. The ssis source is their server and the destination is the linked server they added. The linked server is configured to use encryption.

    I think I may be understanding what you are getting at though. Why add a linked server destination when ssis itself can make the connection.

    I will give that a try on Monday and see if I get the desired results.

    You don't know by chance where to configure encryption in ssis though? I did not see any options that do this.

    Thx

  • rcraig 51362 (3/8/2014)


    You don't know by chance where to configure encryption in ssis though? I did not see any options that do this.

    There is not much I know about SSIS, but I presume there is a place where you can enter the connection string. That would be the place.

    [font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]

Viewing 10 posts - 1 through 9 (of 9 total)

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