need to encrypt communication between client and server

[Former Member]

We were recently purchased by a much larger company. Our new company has a person in charge of application security. This person has said that all communication between sa client and server must be encrypted. We have about 150 sites using various sa 8-12 versions. Please give me suggestions/guidance/links/warnings regarding the changes necessary so that client-server communications at these sites are encrypted. Thank you.

[MarkCulp]

The change should be relatively simple (depending on your app) but what it entails is changing your connection strings to use TLS encryption and to start your server(s) with the -x tcpip{...} option and specify the TLS certificate.

Please refer to the section in the docs on Transport-layer security for more information.

[VolkerBarth]

Note, that for older versions, AFAIK not all application types (APIs) support TLS, cf. the v8 docs on the dbsrv8 -ec option:

The -ec option instructs the database server to accept only connections from ODBC, OLE DB, or embedded SQL interfaces that are encrypted using one of the specified types. Connections over the TDS protocol, which include Java applications using jConnect, are always accepted, regardless of encryption.

[Former Member]

the "-ec simple" method is truly simple. i included -ec simple as a startup parameter and viola, checking with wireshark, packets were encrypted. i did not even have to change the client odbc dsn (on the network tab) to simple encrypted mode: the clients knew to start communicating in encrypted mode. pretty neat! actually, it all seems too simple. am i missing something? will performance take a serious hit? is the encryption method too simple? too easy to crack?

[Former Member]

I have used those words many times, "it all seems too simple". For 16 years now I have always been impressed that SQLA "just works the way it should". But I forget that isn't necessarily the industry norm until reminded by another example like this of how lucky I am to be using this product!

[graeme_perrow]

"simple encryption" is a very simple proprietary algorithm that is more accurately described as "obfuscation" rather than "encryption". It is intended to prevent casual snooping using packet sniffers and such but is not intended to be unbreakable. It does not perform server authentication, and does not prevent man-in-the-middle or replay attacks, but (as you found) is much easier to set up.

TLS, on the other hand, is intended to be unbreakable, and does prevent these attacks but requires an extra file on the server and each client machine, extra switches on the server line, and extra parameters in the connection string.

On modern machines, the performance impact of either of these is negligible.

[VolkerBarth]

I sure agree with you generally, Bill, but in this particular situation, I would claim that "-ec simple" really is too simple if security is a real concern, as Graeme has pointed out...

[Former Member]

Epilogue: Our manager of program security was very impressed with the "-ec simple" implementation. He commented that he does not even see text of the initial "handshaking" normally seen with other encryption methods. Granted, a hacker with the right knowledge might not need very much computing power to crack "ec simple" encryption, but it looks to be good enough for our purposes. We just don't want someone with 10 minutes of Wireshark experience to be able to see everyone's salaries and ss nbrs, etc. By the way, a few customers run our apps against Oracle. I know of no simple (or cheap) method to take our Oracle customers to "ec simple" equivalent security. From my perspective, it's Kudos to Sybase! Thank you!