I have implemented a secure SSL connection on the SQL Server 2005 server. I use the "Microsoft SQL Server Management studio" to connect to the SQL Server and I check the "Encrypt Connection" check box in the options section. The connection is successful and when I look at the connection properties in the mgmt studio, it shows me "Encrypted=Yes".
So that tells me that my SSL setup is correct and I'm able to successfully connect my management studio to sql server on a secure SSL encryption channel.
Question
I want to find out what "security functions" are being used behind the scenes on this connection...because I want to make sure it complies with one of the approved standards by
fips 140-2 anex a (http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexa.pdf), which has information on approved encryption functions
So I used wireshark to capture the traffic and find out the protocols/handshakes. For instance something like 'Auth TLS' request etc...
But I couldn't find out any of the encryption related information (I guess don't know how to). I don't see any SSL protocol packets. Maybe its doing all the encryption stuff at some other protocol level.
So how I do go about figuring this out? I have the packet capture from wireshark and I can provide it to whoever is interested in looking at it. stackoverflow probably doesnt allow attachments.
Any help would be appreciated.
Thanks
Amit
You want to enter ssl as the Wireshark filter to show only SSL and TLS packets, and you should see the client and server handshake and exchange a list of ciphers. If the client initiates any SSL connection, you should see a CLIENT HELLO somewhere in your capture. You can show only these packets with the filter ssl.handshake.type == 1.
That being said, running SQL Server 2005 SP1+ in FIPS 140-2 mode is covered by KB article 920995. From what you wrote, it sounds like you are just hoping the client and server pick an allowed cipher, but that's not how FIPS 140-2 works. Even if your session chooses an allowed cipher, it may not choose a FIPS-certified cipher, and the certification is what's important.
The KB article spells it out with this quote:
Note that it is not sufficient to use
an algorithm from the approved lists
in FIPS 140-2. It is necessary to use
an instance of such an algorithm that
has been certified.
To guarantee the server uses a FIPS-certified cipher, you need to enable the FIPS 140-2 policy like the KB article says.
not using wireshark but using netmon, i have a write up on doing this here:
http://cornasdf.blogspot.com/2010/04/sql-server-data-in-transit-cipher.html
Using Wireshark, you can easily find whether the connection is encrypted by looking at the packet data. This document explains the analysis clearly => https://middlewareworld.org/2020/09/04/step-by-step-ssl-handshake-with-wireshark/
Related
We have an app that requires SSL3 to be enabled on Windows Server 2016. The server is internal, no public access.
I followed the steps from Microsoft: https://learn.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#ssl-30
Except I set enabled to 1. But the server still does not accept SSL3 connections.
Is there something I'm missing?
Thanks
Obviously this is a terrible idea, but if you absolutely have to make something work with SSL v3 on server '16, then you then are going to need to modify other SChannel settings to enable legacy Ciphers/Cipher Suites/Hashes/Key Exchanges as well as enabling the sslv3 protocol itself.
All SChannel settings are configured in the keys under: HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\. Theres plenty of guides to securing SSLv3 on Server 2003 & 2008 - pretty sure the registry paths are unchanged - but im not sure if server 2016 will actually support the required combination of the above (im guessing its all still there and disabled). Based on the age if your system you should be able to work out likely supported configs. Also, seem to think there is a value called DisableByDefault as well as Enabled on some of the schannel subkeys.
DISCLAIMER - this is a terrible idea - SChannel is used by many Windows services and your proposed configuration opens up the entire server to unnecessary risks (e.g Powershell remoting and RDP also rely on SChannel).
Few things you should consider...
By weakening the server side, will you also have to make client side changes to allow other systems (or worse actual desktops & laptops) to make a connection?
Just because something is on your internal network, dont assume it cant be attacked (via hacked WIFI, or malware etc). Make sure its in a DMZ/VLAN/firewalled (inbound and outbound) so you can tightly control access and reduce the risks.
I'm assuming whatever it is that requires SSLV3 is unmaintainable, might it be possible use a Proxy of some description to either offload SSL entirley, or act as a "man-in-the-middle" and decrypt/re-encrypt traffic from SSLv3 to TLS.
For my current project i need to implement http over tls at client ,for this i need a local server able to simulate this . is there any online or offline tool. which i can use and and see the handshake in wireshark .
For watching the TLS handshake you might not get far enough with wireshark. For such kind of monitoring you would ensure the security is low enough for wireshark to be able getting the session key from watching the handshake for decoding the later parts. Thus, you need to avoid any forward secrecy.
Otherwise any (https) server that is accessible (and willing to talk) to your client will do.
In case you are in an environment that is supported (e.g. any unix/linux), you might try using openssl. It allows setting up a server that will do handshake. And it will log the handshake such that you will be able looking at what is going on. This will eliminate the need for using wireshark for debugging.
For achieving this you need a Web Server accepting connection over TLS.I have achieved this on Apache Tomcat web Server.
TLS configuration needs to be done in the server.xml file present in config directory of Tomcat webserver. Connector tag needs to be added in the server.xml file that contains information like
TLS version to be used, port, List of supported Cipher Suites, Keystore path and password, Truststore path and password.
Any regular Rest client can be used to make a call like Postman client. But to use that over TLS/SSL certificate is needed to be installed in Chrome browser.
Hope this answers your doubt.
I would like to display a message to customers who's browser's highest level of encryption is SSLv3. Is it possible for me to target browser settings of SSLv3 and lower? Client or Server code? We will be allowing lower versions of SSL to use our site during a certain grace period. During this grace period, we would like to display a message only to those users that have browser settings of SSL3 or lower.
Not easily. The browser's supported SSL versions are not detectable until the SSL handshake is in progress, and even then only if the browser uses an SSLv2 handshake to allow dynamic version negotiation. If an unsupported version were detected, you would not be able to send a message back since the handshake failed and the connection would be closed before you could send any message. However, SSL itself has an error packet that gets sent during handshaking, and it can specify a version mismatch error.
The best you can do in your own code is support all SSL versions on the server side, let the client complete a handshake normally, and then detect which version was actually used and send back a message if the SSL version is too low.
Or, you could simply enable TLSv1 or higher only, and simply refuse to let older clients connect at all. They just would not get a nice error message unless the browser decided to detect the SSL version mismatch error and display its own pretty message about it.
Firstly, nowadays, you can generally forget about clients that don't support at least SSLv3. SSLv3 has been widely available for many years.
The TLS Client Hello message, sent when the connection is initiated by the browser, should contain the highest TLS version it supports:
client_version
The version of the TLS protocol by which the client wishes to
communicate during this session. This SHOULD be the latest
(highest valued) version supported by the client. For this
version of the specification, the version will be 3.3 (see
Appendix E for details about backward compatibility).
Appendix E is of course worth looking at.
(The Client Hello message will also contain the list of cipher suites the client supports, which is possibly relevant for the general idea of your question.)
Of course, this specification is just a "SHOULD", so a client supporting TLS 1.2 could still send a Client Hello for TLS 1.1, but what would be the point? By doing so it would have no chance ever to use TLS 1.2 anyway. It could be a preference box that is turned off, but that would effectively make it a client that doesn't support the highest version anyway. (If you want anything more subtle, you'd need to build a database of known user agents, which will be partly unreliable, and for which you'd need to analyse the full user agent string to know everything possible about the platform.)
Now, how to convey the content of the Client Hello message to your application is another matter, and depends very much on which SSL/TLS stack you use. It might not even be directly possible without modifying that SSL/TLS library or the server you're using.
This being said, you can generally get the negotiated TLS version during the current session quite easily. Since that version is the "lower of that suggested by the client in the client hello and the highest supported by the server" (i.e. "min(max(client), max(server))"). If your server supports SSLv3, TLS 1.0, TLS 1.1 and TLS 1.2, and since the latest version is TLS 1.2 anyway, what you'll get during your current connection will also be the max currently supported by the client. As long as your server supports the latest version, you should be able to know what the client supports at best from any live connection.
If you're behind Apache HTTP server's mod_ssl, you should be able to get that from the SSL_PROTOCOL environment variable. You should also be able to get the protocol from the SSLSession in Java.
(If you are willing to write a more bespoke service, you could pass further details like the cipher suites more directly to your application, like this service from Qualys SSL Labs does, although I'm not sure if it's meant to be widely available or just a test service.)
I'd have to agree with Remy about it being a bit challenging.
However, a good starting point may be to retrieve some SSL (certificate) information.
Something similar to this:
X509Certificate certChain[] =
(X509Certificate[]) req.getAttribute("javax.net.ssl.peer_certificates");
Another way of getting more information is to retrieve the cipher_suite attribute (similar to the code snippet above).
javax.net.ssl.cipher_suite
I hope this (at least) gets you closer.
Good luck.
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).
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.