Does SQL require SSLv3?
-
We have a Windows 2008 R2 server running SQL 2012 Express RTM (11.0.2100.60). All three protocols (shared memory, named pipes, TCP/IP) are enabled for the server and both 32-bit and 64-bit clients. No certificate is configured, and encryption is not required. SQL is configured for mixed-mode authentication. A few weeks back, we added the registry key to disable SSLv3 for server software[^], but didn't restart the server. (All three TLS protocols - 1.0, 1.1 and 1.2 - are enabled.) This morning, after installing the critical MS14-066 patch[^] and restarting, SQL would not accept any connections. Using shared memory or named pipes returned the dreaded "no process is on the other end of the pipe" error. Using TCP/IP returned a "connection forcibly closed" error. Uninstalling the patch made no difference - we were still unable to connect to SQL. Only after re-enabling SSLv3 and restarting the server were we able to reconnect. We have since reinstalled the patch, and the problem has not returned. Therefore, I can only conclude that SQL requires SSLv3 to be enabled, even if the connections are not encrypted. However, I can't find this documented anywhere. Can anyone else confirm this? Is it a known issue?
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
We have a Windows 2008 R2 server running SQL 2012 Express RTM (11.0.2100.60). All three protocols (shared memory, named pipes, TCP/IP) are enabled for the server and both 32-bit and 64-bit clients. No certificate is configured, and encryption is not required. SQL is configured for mixed-mode authentication. A few weeks back, we added the registry key to disable SSLv3 for server software[^], but didn't restart the server. (All three TLS protocols - 1.0, 1.1 and 1.2 - are enabled.) This morning, after installing the critical MS14-066 patch[^] and restarting, SQL would not accept any connections. Using shared memory or named pipes returned the dreaded "no process is on the other end of the pipe" error. Using TCP/IP returned a "connection forcibly closed" error. Uninstalling the patch made no difference - we were still unable to connect to SQL. Only after re-enabling SSLv3 and restarting the server were we able to reconnect. We have since reinstalled the patch, and the problem has not returned. Therefore, I can only conclude that SQL requires SSLv3 to be enabled, even if the connections are not encrypted. However, I can't find this documented anywhere. Can anyone else confirm this? Is it a known issue?
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
It's a good idea, but we couldn't connect using SQL authentication either, which shouldn't involve AD at all.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
