sql server encryption

  • Hi All,

    What is the difference between client side encryption and server side encryptiion.

    To my knowledge , server side encryption is , we load the certificate on database server issued by certification authority and we do a Force Encryption using sql server configuration manager. This is what i believe server side encryptio.

    Then what is client side encryptiom. On client machine, if i open a manaement studio and while connecting to the server , go to options button and we check mark encrypt data , is that the one mean client side encryption ???

    How does encryption takes place? Can anyone reference link how a 3way handshaking happens diagramatically?

    Can i have both client side and server side encryption on both at the same time ? if yes/no why?

    Thanks in advance.

  • This is a little generalized as I am not an expert on this

    The purpose of client side encryption is to secure the data while it is being communicated between the client and the server.

    The purpose of server side encryption is to secure the data that is on the server.

    MSDN: Encrypting Connections to SQL Server

    Director of Transmogrification Services
  • Thank you.

    Basically, am looking for someone to answer why we cant have both client side and server side encryption at the same time?

  • They are used for two totally different things. Server side encryption (TDE or Column-Level Encryption) is used to protect data while on the server, or protect the files if they fall into the wrong hands (someone steals a tape or can copy a backup). The data in the file is scrambled, so they can't just load the file up into a text editor and see the sensitive data.

    Client side encryption, I'm thinking, means possibly two things, as the other person stated, it protects the data traveling across the network (in the case of SSL) to prevent sniffers from picking up the data, and another possibility is the encryption occuring in the front-end application, being encrypted and decrypted at the front-end.

    If server side encryption is used, obviously it is advisable to use SSL connections, since the data is sent to the server, and data is sent back from the server, in unencrypted form. Therefore, you would want an SSL connection to shield the data from prying eyes. The encryption and decryption is on the server, so the data has to get there unencrypted to then be encrypted and saved on the server. Reverse the process going back to the client.

    Essentially server side encryption protects the data when it is in file form (live data files, backups, etc.).

    Client side encryption (front-end app does the encrypting and decrypting) is the safest as far as the network is concerned, since only encrypted traffic is passed back and forth across the network. The downside to this system is that the program is responsible for the encryption and decryption. If keys need to be changed for whatever reason, or the algorithm needs to change, all the programs have to be changed to the upgraded version.

    Server side does it on the server, so any changes can be accomplished there, so no program changes have to occur. Much easier. Downside is that the data is going to and from the server unencrypted, hence the need for the SSL connection for security.

    As with everything, there are trade-offs. You have to decide what is required for your particular situation and look at the benefits and drawbacks of the possibilities to determine what is best.

    SQL Server can have connections utilize SSL (can also make ALL connections require SSL), and can use TDE (Transparent Data Encryption) and column-level encryption. TDE is only on SQL Server 2008 and above, and only in Enterprise version. Column-level encryption is available on 2005 and above, all versions (express edition, standard, enterprise). Yes, even Express Edition.

    Hope this helps in some way.

  • To the best of my knowledge you can.

    Director of Transmogrification Services

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

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