I want to force all external connections to be encrypted using SSL, essentially I want to encrypt only one of the network interfaces.
This article comes about as close to my answer as I can get:
http://basitaalishan.com/2012/07/16/encrypting-connections-to-sql-server/
However, it seems to me that either all connections are forced to use encryption or all connections may be able to not use encryption at all. I want all external connections to be encrypted (no choice) and all internal connections (behind the firewall) to not be encrypted.
I need to encrypt both SQL 2005 and 2008R2. Both are running on Windows 2008 Std
Can this be done at all?
You could use a SSL wrapper/proxy like stunnel, then set the firewall to allow external connections only to the port where said SSL wrapper runs.
Related
I was curious on why a client cannot directly to a machine running webrtc server but can do that via turn server. Both turn & webrtc are in same VPC of AWS.
Could be a lot of things.
Assuming you have the TURN configuration file correct, and as you are noting both AWS instances have public IPs, then it's possible that on the instance with the TURN server, you do not have all the firewall ports opened needed related to the TURN server: https://stackoverflow.com/a/59212004/8201657
Or, maybe it's a DNS issue and the domain of your TURN server is unknown to your peer, so it is not able to access it.
Or, maybe you are attempting to connect via WebRTC but not securely. WebRTC requires a secure connnection (https).
I know generally how HTTPS works, and from what I read, it seems that the generation of the encryption key could be done by a computer that isn't the one establishing the connection.
My thought is to create a proxy that isn't actually able to see the traffic going over the SSL connection. To do this, you would have a handshake in the same way as usual between the proxy and the server. However you would pass the encrypted symmetrical key to the proxy from your computer who would then transmit it on to the server. Then, when the server returned an encrypted payload, the proxy would not be able to decrypt it, but would forward it on to the users computer.
Am I missing something fundamental about how HTTPS works?
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'm pretty far out of my depth here, so bear with me. We're using JDBC via com.intersys.jdbc.cachedriver to run stored procedures in Intersystems Cache and get the results in Java. However, there are other clients that connect directly to the Cache using a terminal over telnet. We have to lock down Cache's telnet port so that only telnet over SSL is possible. However, the Cache experts here say that locking down one port in Cache locks them all down, so the Java to Cache connection will also have to use SSL. I understand vaguely that some JDBC drivers support SSL, but I don't see that the Cache one does. What I need to know is:
What's needed to configure SSL for the JDBC connections? (We're using JBoss 4.2.3)
What about certificates? I assume those have to go somewhere.
Is it actually true that locking down the telnet connections is also going lock down JDBC in the same way?
Configuring Java Clients to Use SSL/TLS with Caché
Using SSL/TLS with Caché
Telnet vs ssh is a question about what the OS allows and only relates to Cache peripherally. It doesn't mean anything regarding items 1 or 2. So in answer to the direct question you are asking, "No".
1. What's needed to configure SSL for the JDBC connections? (We're using JBoss 4.2.3)
See http://docs.intersystems.com/cache20102/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_ssltls#GCAS_ssltls_javacli for details. This section doesn't explicitly mention JDBC, but it's true for JDBC (and the reference has been added for the documentation 2011.1 [next release] .)
2. What about certificates? I assume those have to go somewhere.
To quote the documentation: "If the client has a private key and certificate, these are stored in the client’s keystore; the keystore can also hold the client’s root CA certificate and any intermediate CA certificates. To authenticate the server, the client may need to have the root CA certificate for the server and any intermediate CA certificates, these can be stored either in the client’s truststore or along with client certificate information in the keystore. For more information on keystores and truststores, see the section “Keystores and Truststores” in the Java Secure Socket Extension (JSSE) Reference Guide."
3. Is it actually true that locking down the telnet connections is also going lock down JDBC in the same way?
Yes -- if telnet connections are to require TLS, then the superserver TLS setting needs to be Required, which means that you have to use TLS for anything that goes through the superserver (including JDBC). If you just want to allow the use of TLS for telnet connections, set the TLS value to Enabled, which allows non-TLS connections by other means (such as JDBC).
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.