I am running my web application on a JBOSS 7 server. After running an automated scan on the web application it alerts for a TLS1/SSLv3 Renegotiation Vulnerability. On researching a little bit I found that this can be fixed by disabling the capability of jboss server to renegotiate.
I am aware that this was possible in JBOSS 5 by specifying a property of the connector attribute. But this is not possible in JBOSS 7.
Also I am using JDK 1.7 which the documents indicate has the fix.
Anybody has any thoughts on how to fix this vulnerability?
Related
I have an IIS helpdesk system (3rd party so I don't have code access) running on Windows Server 2019 and IIS 10. One of the features it has is to connect to mailboxes via IMAP. When we try and use this it gives us an SSL error.
I was advised by our exchange team that the exchange server uses TLS 1.2, so I enabled it on the server. However, our network team have since advised that the connection attempt is actually being made via TLS 1.0 so I need to ensure TLS 1.1 and 1.2 are disabled on the app server.
I enabled TLS 1.0 and disabled TLS 1.1 without any issues, however when I disable TLS 1.2, the web page for the helpdesk system goes down and just gives an HTTP 500 error. Only when I re-enable TLS 1.2 does it start working again.
I found a few pages on Google of things to try, such as removing and re-adding the bindings in IIS after disabling TLS 1.2 but this hasn't worked.
Any idea why disabling TLS 1.2 breaks the web page? TLS 1.2 was disabled when I first installed the helpdesk system the page worked fine then. According to the vendor of the system, it just uses the TLS version configured on the server, so why does it seem to rely on 1.2? Is there a setting somewhere in IIS that tells it which version to use that needs updating? I didn't have to set anything when I enabled 1.2.
Thanks in advance.
... that the connection attempt is actually being made via TLS 1.0 so I need to ensure TLS 1.1 and 1.2 are disabled on the app server
This conclusion is wrong. TLS versions are not exclusiv to each other. To support TLS 1.0 clients you need to enable TLS 1.0, but keep TLS 1.1 and TLS 1.2 enabled.
You can support both TLS 1.0 and TLS 1.2. Which one is actually used also depends on the other end. Configuring 1.2 everywhere will make it work with 1.2, but you can also leave 1.0 on in case you miss a device that is still using 1.0. TLS is backward compatible. Systems using TLS1.1 and TLS1.0 will continue to function when TLS1.2 is enabled, so if any of your processing requires TLS1.0 and TLS1.1, it will remain available. Nonetheless, it is recommended that your developers upgrade to only run on TLS 1.2. This is necessary because current security standards no longer consider TLS 1.0 and TLS 1.1 to be secure.
I'm using classic asp on IIS on Windows server 2012, and Server.CreateObject("Msxml2.XMLHTTP.6.0") to make soap requests against a payment processor, and "suddenly" it stopped working.
The payment processor has disabled TLS 1.0, we're supposed to do TLS 1.1 or 1.2; I think this is the cause of the problem...
How do I see and if needed change which protocol it uses?
Take a look here: https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls#systemdefaulttlsversions - specifically at sections SystemDefaultTlsVersions and SchUseStrongCrypto. You should also go ahead and disable all insecure ciphers/protocols/key exchanges in SChannel - the windows component responsible for SSL/TLS.
There is a GUI tool called IISCrypto from a company called Nartac that has some common profiles that are (somewhat) safer than editing the registry directly for disabling various obsolete components. see https://www.nartac.com/Products/IISCrypto.
Word of warning - be careful with your SChannel settings (either editing the registry or using IIS Crypto) - the settings are used throughout windows and are required for services like RDP and WinRM among other things - backup first, then test carefully.
I had similar situation - I have used Msxml2.XMLHTTP for API endpoint call in VB script and suddenly it stopped working. I got error "The system cannot locate the resource specified" and http.status returned 12029. The problem was not in the URL, it worked when I tried to call the URL from the browser. But when I started VB script, it has failed on the line http.send.
How I solved it finally?
I hade to install recommended update to my Windows Server 2012:
Microsoft .NET Framework 4.8 for Windows Server 2012 for x64 (KB4486081)
and I have installed one optional update too:
Internet Explorer 11 for Windows Server 2012 for x64
After this and server restart it started to work again. I can use both: "Msxml2.XMLHTTP.6.0" or "Msxml2.XMLHTTP", it does not matter.
My question is this: How can I stop my .NET 1.1 application from trying to verify the digital signature in an environment where there is no access to the Internet?
Background to my question:
I have a product installed at a customer which is based on .NET 1.1 SP1. The customer site has no access to the Internet. This causes a delay in application startup which in some cases causes my Windows services to fail to start because they time out.
The delay when starting appears to be caused by the app attempting to verify the digital signature. This is well documented in other posts and the normal answer is to include generatePublisherEvidence=false in the app.config file, as documented here http://support.microsoft.com/kb/936707
It seems that using generatePublisherEvidence=false doesn't make any difference to .NET 1.1 apps, which seems to agree with MSDN (http://msdn.microsoft.com/en-us/library/0kk0kk35(VS.71).aspx does not mention the element) and with the hotfix I mentioned above, which was released for .NET 2.0 apps.
My next release to the customer will be built on .NET 3.5 SP1 and I have no problems with using generatePublisherEvidence on that version of the .NET framework, but I currently cannot simply change the customer to that release - I am stuck with .NET 1.1 SP1 - so I'm looking for an answer other than to simply use a later version of the .NET framework.
I just solved this for a vendor-supplied application today. I assume that their application was written in .net, but I did not confirm. Since the subnet did not have internet access, I removed the DNS server entry from the TCP/IP settings on the local computers that have static addresses. For addresses supplied by DHCP, I removed the DNS server option (006) from the DHCP scope.
I have some IIS 6.0 filters and extensions that I need to create a configuration panel for in IIS Manager. I need to create something similar to the ASP.NET tab, for instance.
I need to support versions of Windows Server 2003 prior to R2, and can't assume that they will have the MMC 3.0 update installed, so I guess I have to do it with unmanaged C++.
I've read up on MMC snap-ins, and I have a very basic idea of how they work, but I'm not sure about how to get one that is loaded as a tab in the IIS Manager. I'm thinking that maybe an "extension snap-in" is what I need, but I'm not positive.
So, I'm looking for any kind of documentation, literature, tutorials, examples, etc on how to do something like this. Any ideas?
There isn't much out there on how to do this....
Here's a link to the MMC 2.0 guides:
http://msdn.microsoft.com/en-us/library/aa815085(v=VS.85).aspx
Here's a link on extending IIS via snap-ins:
http://msdn.microsoft.com/en-us/library/aa814685(VS.85).aspx
About the only tutorial out there from what I could find but it is not specific to IIS....
http://msdn.microsoft.com/en-us/magazine/cc301779.aspx
This isn't the answer you're looking for, but it's the answer you need to hear:
MMC 2.0 is no longer supported by Microsoft.
MMC 3.0 is included with Windows Server 2003 Service Pack 2, which is the only remaining service pack release supported by Microsoft. Do you really have customers that refuse to upgrade to Server 2003 Service Pack 2? It came out 3.5 years ago and represents the best the Server 2003 platform has to offer in terms of security, performance, and software compatibility. It's also the only release that continues to receive security updates for IIS.
And if there are people out there that refuse to upgrade to 2003 SP2 due to specific compatibility concerns, do you really think they're going to jump at the opportunity to pay you and install your snap-in on their servers?
Probably not.
So save yourself a lot of grief, and position yourself well for the future -- do your development in MMC 3.0.
Unfortunately, there is no way to do what you are asking. You can create a snap-in/extension for MMC, but you will not be able to extend the IIS snap-in.
I recently got a notification from a McAfee service (what used to be called HackerSafe) that my website is using SSLv2 and it should be using SSLv3. I don't know anything about the versions of SSL. My site is using IIS 6.0, is there a setting somewhere to turn on SSLv3 or do I need to install something to make this happen? Also, is there any drawbacks to only using SSLv3? Are there browsers that can only use v2?
The Microsoft KB Article referenced in TravisO's answer is helpful for general reference. I used the information from that article along with information gathered from ServerSniff.net's SSL analysis tool
Also, you can copy and paste the following snippet into a .reg file to quickly disable SSLv2 on a web farm:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
"Enabled"=dword:00000000
In regards to browser support for SSLv3, the following information should help (taken from the McAfee Scan Alert):
In Internet Explorer 7, the default
HTTPS protocol settings are changed to
disable the weaker SSLv2 protocol and
to enable the stronger TLSv1 protocol.
By default, IE7 users will only
negotiate HTTPS connections using
SSLv3 or TLSv1. Mozilla Firefox is
expected to drop support for SSLv2 in
its upcoming versions.
As almost all modern browsers support
SSLv3, disabling support for the
weaker SSL method should have minimal
impact. The following browsers support
SSLv3:
Internet Explorer 5.5 or higher (PC)
Internet Explorer 5.0 or higher (Mac)
Netscape 2.0 (Domestic) or higher (PC/Mac)
Firefox 0.8 or higher (PC/Mac/Linux)
Mozilla 1.7 or higher (PC/Mac/Linux)
Camino 0.8 or higher (Mac)
Safari 1.0 or higher (Mac)
Opera 1.7 or higher (PC/Mac)
Omniweb 3.0 or higher (Mac)
Konqueror 2.0 or higher (Linux)
Microsoft has a KB article on disabling SSLv3, obviously it's in the same place as enabling it.
http://support.microsoft.com/kb/187498/en-us
If you are looking at fixing this you will probably also want the to fix weak ciphers since most scanners will complain about both. That is Microsoft KB245030. Generally any browser that supports SSLv3 will also support newer and stronger ciphers than the ones turned off by the scripts at that link.