Hijacking connection string with network packet analyzer

Question

I guess everything is possible but I am wondering how easy is it for someone to hijack a connection string with a network packet analyzer or equivalent tool.

A winforms application fetches data directly from an MSSQL server. (Supposing there are no webservices in the middle for extra protection)

1) Is it possible for someone with an analyzer to read the connection string as clear text?

2) The connection string could be protected with an SSL certificate?

3) The SSL certificate should be installed on the SQL server?

4) I already own an SSL certificate http**s** Could I install it also for the SQL server?

5) The speed of the the return data, will be reduced due to SSL?

Thanks in advance

Answer 1

If it isn't encrypted, it can be read, yes. Note that the SQL Native Client may often perform a non-SSL based encryption (depending on lots of factors), but yes, it can also be encrypted with SSL; see technet. And yes, it slows things down slightly. The requirements for the certificate are all in the technet article. But please don't expose your db server to the internet...

Answer 2

1. Yes. If they're on the same network as the packet sniffer (henceforth "the sniffer") and the connection string is in plain text it's easy. Using a switch instead of a hub will not make it any harder to do this.
2. still possible using a man-in-the-middle attack. Channel binding is designed to detect and prevent this, along with careful examination of the certificate received by the client. Client certificates would help strengthen this as well
3. yes it should
4. as long as the host name matches the sql server exactly it should work, otherwise you'll need a new cert.
5. it probably will reduce the speed but not by much. Benchmark it and see if the slowdown still gives acceptable performance; there's no other way to predict the impact with any degree of reliability.

One other thing: if the connection string is encrypted I can still analyze the packet to find your server's location and if the data being passed back and forth isn't encrypted I can still read it even if I can't connect to the sql server. I can also potentially modify it. This is why it's unusual for a SQL connection to exist over the internet and why it's usually either connecting to a DB on the same server, connecting via a local network, connecting via a VPN, or encrypting the whole data stream.