I was exploring SSL certificates and its advantages. There I came across using SSL certificate for Database connection. I am confused with why we need secure connection with database. Since if secure connection is established between client and server, anyways server is what going to connect and fetch from Database. Can someone help me in understanding why we need secure connection with Database? Thanks in advance.
You need SSL when the connection method is not secure, such as attaching to a remote database over the Internet. It's probably not a bad idea in general even for an internal application if there is any risk that someone, such as employee, may be able to intercept and either view the data in plaintext or do a MITM attack and they're not otherwise authorized to completely control the database.
The main idea of SSL is to prevent man-in-the-middle attacks and to make sure the remote server is really who they say they are.
Related
I am investigating the use of SSL to ensure security when performing remote software updates to embedded systems. This means that I would like to ensure that only specific client machines may communicate with the embedded server system.
I understand that server certificates authenticate the identity of the server and client certificates authenticate the identity of the client and this prevents man in the middle attacks.
What I would like to know is if client certificates can be used in such a way that only clients with specific certificates, compatible with the server, can communicate with the server.
My interpretation so far from reading up on this is that that certificates are used to ensure that either client or server are who they say they are. Not to restrict access to specific clients. Is this correct?
If someone could help clarify this, and provide some pointers, I'd be grateful.
Thanks
I have an IIS hosted WCF Service that uses SSL encryption. This service makes requests to a SQL Server 2014 database instance. When I make a call to the service the response message is encrypted. So, the connection between the client (browser) and the service is secure. I also want the connection between the service and the SQL Server 2014 database to be secure.
This is where my question comes in. I am not exactly sure how to do this. I read the following article Enable Encrypted Connections to the Database Engine and I was able to successfully add the certificate to the SQL server database engine and changed the Force Encryption flag to True. But now I am a bit confused as to whether I want to configure the server to accept encrypted connections or the client to request encrypted connections. Based on the scenario I presented above it seems I want the client to request encrypted connections from the SQL Server DB correct? I guess one reason I am confused is because this is ALL happening on my development machine. SQL Server is being hosted there as is the IIS Service.
If someone with experience could maybe clarify that for me I would greatly appreciate it.
If you haven't restarted the service, then do so to complete the configuration change. It sounds like you applied the change correctly and using a domain or public CA certificate will prevent a man in the middle attack. To verify that the connections are secure, you can use a DMV named sys.dm_exec_connection which should display true for the encrypt_option for all sessions, as below:
select session_id, net_transport, encrypt_option from sys.dm_exec_connections
I'm not certain that connections from the host to SQL Server will be encrypted by SSL\TLS since they would be using the shared memory protocol and Windows manages the security of shared memory.
I have a couple questions about SSL.
What happens if someone tampers or changes the encrypted data? There are many ways in which the data being transferred can be tampered, so though the encrypted data will not make any sense to the tamperer, what would happen if he just tampers it? How would I handle such scenarios?
What will happen if a webpage is requested by a browser which does not support SSL? Or the client accessing the website is actually some kind of malware?
I am pretty new to SSL so maybe my questions are very trivial but I don't have answers to them.
The packets including the URL itself is encrypted. Modify the bytes will make the packet invalid. As far as I know it is not accepted by the server then.
If a client browser don't support your SSL protocol it can't access the website. The client get a "Insecured Request Denied Error".
SSL is to establish a secured connection. Any software, including malware, that support the protocol can start a connection. The SSL protocol "just" encrypt the communication so the packets can't be inspected outside. So your software itself need to be protected against any attacks anyway.
The tampering will be detected on arrival and the connection automatically dropped, probably resulting in a dialog box to the browser user.
I'm not aware of any browser that doesn't support SSL. Such a thing would be singularly useless.
I thank you in advance for sharing your knowledge. Here is my question:
By default, SQL Azure connections are encrypted. so what is the significance of checking the 'encrypt connection' checkbox in the connection properties while connecting to SQL Azure from SSMS? Does it make any difference?
Paras,
When the client library first attempts a connection to SQL Server / SQL Azure, it sends an initial connection request. Consider this a "pre-pre-connection" request. At this point the client does not know if SSL/Encryption is required and waits an answer from SQL Server/SQL Azure to determine if SSL is indeed required throughout the session (not just the login sequence, the entire connection session). A bit is set on the response indicating so. Then the client library disconnects and reconnects armed with this information.
Consider a proxy sitting between the client and SQL Azure (or SQL Server). The client talks to the proxy, and the proxy talks to SQL Azure/Sql Server. If you do not force the encryption bit on the client, you leave it to the proxy to encrypt or not the session. The proxy could encrypt the connection on the backend (it would have to for SQL Azure) but not on the client-side of the connection, hence accessing all your sensitive data. So checking the encryption box bypasses the "pre-pre-connection" request which prevents any proxy from turning off the encryption bit in question on the client side of the proxy, hence avoiding the man-in-the-middle attack.
Hopefully that makes sense... :) If you download Wireshark and watch what happens with the pre-pre-login packets, you will see what I mean. Checking the box changes the pre-login handshake mechanism to avoid the man-in-the-middle attack I described.
There are times we need to create an ODBC connection over the "tubes" to one of our customer sites. We would like to provide as much security as possible to our customers, given we are using ODBC and, well...
Anyway, there is a checkbox setting in the SQL Server DSN that says "Use strong encryption for data", but absolutely no documentation for it. The only references I can find on the Google nets are unanswered questions -- not very encouraging. Does anybody have a clue what it does or how it works? If that isn't a way to encrypt the data stream, is there another way?
BTW, we cannot rely on our customers to force encryption from their end, and dealing with security certificates would be a real nightmare.
Thanks in advance,
Dave
Is it SQL 2000 or 2005/2008?
The encryption enforcement can be requested by the client or enforced by the server. The encryption is based on Schannel protocol (ssl) and as such requires an valid certificate deployed on the server and trusted by the client, there is no way out of that. The certificate has to be signed by an authority that is trusted by the client and, amongst other typical server certificate requirements, must have the FQDN name used to connect by the client as its subject.
In SQL 2005 How to: Enable Encrypted Connections
In SQL 2000 Configure the Server and Request encryption by client
There is no reason you can't have a secure connection while using ODBC. Basically, the responsibility for over-the-wire security would fall under the ODBC driver (basically the database-specific part). If the driver doesn't already provide for this (SQL Server may or may not - I don't know what "Use strong encryption for data" applies to) you can probably add your own. One possibility would be to create a SSH bridge, e.g. using ssh -L. I don't know if this counts as a "nightmare", but it would probably be an effective and fairly simple technique.