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.
Related
I have created a service (WCF) that acts as a backend for a DB. For now it does basic operations such as INSERT, SELECT etc. I have run it locally and now it is time to expose her to the internet and enter 'production'. Is there a best practice to doing so? Bear in mind this service will be hosted on a PC as a Windows Service (not IIS). This is the first time I am putting a Windows Service into production so I am hazy on the details but I think this is the main idea:
On the service: Check for 'rookie' errors such as SQL Injection. Set maximum message sizes to ones marginally higher than the largest message that should be transmitted by my service. Also upgrade self signed X.509 certificate to one issued by a CA. (Where does one store this certificate? Locally on the PC?)
On the PC: Fully patched software (OS etc) and windows firewall with a specific set of rules that allows traffic only on the ports being used (I suppose the safest way to do this is to use the windows tool Allow a program or feature through Windows Firewall ?). Furthermore an updated antivirus running.
On the Network: For the network router, port forward the respective ports being used (the base address is declared as http://localhost:8080 so I guess port 80 for HTTP and 443 for HTTPS? I am using message level Security.)
General precautions: Full message logging on the service to analyze traffic and potential attackers. Also run a Network intrusion detection system such as Snort so that I can sleep a bit better at night.
Am I missing anything obvious? Also should I be hosting in IIS, on security exchange someone said that I would be vulnerable to HTTP attacks if I did not put the code behind a web server. However I have not read this anywhere else
We have clients who can be using anything, WindowsXP,Vista,Linux....
Currently our systems support SSLV2 and SSLV3.But, we are planning to disable both SSLV2 and SSLV3 in windows server 2008R2 in favour of TLS 1.2.
Will it have any breaking changes with the end user?I'm worried that If I disable SSLV3 ( and SSLV2) , some of the clients who use windowsXP(for example) might not be able to access my web service.
PS: Tried to find a similar question in stackoverflow, didn't find any. So, posting this as a question. :)
This is one of the scenarios where you will NOT be able to support old clients using insecure protocols and expect to have decent security.
If you have not enabled TLS 1.2 yet, do so.
Some clients do not support TLS 1.2 (e.g., older Android versions). You may need to support TLS 1.0 and 1.1 in addition to 1.2. While not ideal, it is definitely better than supporting SSL 2.0 and 3.0.
Post an announcement indicating that your web service is being upgraded to meet minimum security requirements and set a date for retiring insecure protocols.
Optionally, check your server metrics to see what protocols/ ciphers are used. Since you haven't mentioned your web server, I'm assuming it is IIS, in which case this is not easy[1][2].
Retire SSL 2.0 and SSL 3.0. There will be a few clients who will not be able to connect. Plan to have an answer ready for them. If you have clients running XP and using IE6, they have bigger issues than not being able to access your web service.
While you are at it, run your TLS configuration through an online
scanner like SSL Labs to ensure you fix any other issues.
We are setting up replication between RavenDB instances running in server mode. The instances are in different availability zones so we need a secure connection between the servers. According this this post SSL is not supported in server mode but
should be easy to add
Is there an extensibility point in the API where SSL support can be plugged in?
The API doesn't have any place for this currently, but I'm sure it would be a welcome contribution if you were so inclined to write this and submit a pull request. The underlying server is just a System.Net.HttpListener, which can be wired for ssl.
Your entry point would be at Raven.Database.Server.HttpServer.StartListening()
You would want the SSL certificate to be as easy to configure as the hostname or port. The cert itself should probably be pulled in from the Windows certificate store.
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/
On a customer's internal network, I can make a request to my SSL site using IE6 SP1 (on Win2K) and see one cert validation requests, but if I use IE6 SP2 (on XP) 13 separate cert validation requests get fired off. Needless to say, this slows down my page load a lot.
Firefox loads the page just fine with no unnecessary cert validation requests.
The server is Apache running a pretty new lampp stack. All the server certificate / CA chain configurations seem to be fine (users can authenticate w/ trusted certs, the system can communicate to other systems with that server cert, etc.)
Is there anything I can do from a configuration standpoint? Any other ideas at all?
I'm guessing that "upgrade IE" is off the table, right? You're probably trying to find a way to support IE 6.0, SP2, with XP, so your users can use this version.
OK... one thought is trying to mess with the SSL configuration. As I remember, SSL has a number of settings that can be used and perhaps you can change one of them on your server and get a different behavior. It might be worth it to research what's happening during the SSL Handshake on the working and not-working versions of IE 6.0. I favor Ethereal, a free network traffic watching tool that will capture the SSL. It can't decrypt it easily, but you can at least see the first few messages that happen in the clear. It might give an inkling into why all these validation requests are coming in.