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.
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 am working on configuring multiple TLS version in websphere bpm 8.5.6 .i have selected SSL_TLSV2 to use all tls versions. I am able to see the configuration updated on ssl.client.props file after restart.
But still calls from websphere are rejected by salesforce
UNSUPPORTED_CLIENT: TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https
Can anyone help me in configuring multiple tls version through which i can use tls 1.0 and 1.1
Thanks in advance
I'm trying to integrate U2F Authentication in GWT project and I need to know if is this solution compatible with all new web browsers (Firefox, Internet Explorer, Safari...)? Normally in Google Chrome I've to install a plugin that's called "FIDO U2F (Universal 2nd Factor) extension".
Is the same for others browsers?
Is there any way to work without a plugin for new web browser?
Do other browsers support U2F? currently not.
Is there any way to work without a plugin for a new web browser? No, that's the whole point of U2F: a phishing attack is made impossible thanks to direct communication with the browser.
Extra information
You had to install a plugin in Chrome in the past, currently (I think starting from version 40), this is not required anymore: U2F capability is built in from that version on in Chrome. As to which other browsers support U2F: currently none. Firefox supports U2F via the U2F Support Add-on, and is working on supporting U2F natively.
Microsoft reportedly will include FIDO support in Windows 10. It might be possible that browsers will rely on the OS-U2F-check then, and do not (need to) include FIDO support directly anymore. However, this is speculation only for the moment.
An easy compatibility check I'd like to carry out is to use the Yubikey's demo site.. It will be reported immediately when your browser does not support U2F (try opening the demosite in Firefox and see what happens).
Yes, it is an old thread, but let's make an update:
2016 September update : FIDO U2F browser support
Chrome for Windows, OS X and Linux: Yes (Built-in)
Chrome for Android [for FIDO U2F over NFC and over BLE devices]: Yes (You still have to download the official Google Authenticator App but this requirement will disappear in the future)
Firefox: Devs are now officially working on it. Mozilla Foundation joined the FIDO Alliance. For now, while waiting for the official built-in support, you can use this great addon: https://addons.mozilla.org/en-US/firefox/addon/u2f-support-add-on/ (It won't work on websites that do not know Firefox can be used too...)
Safari, Internet Explorer and Edge: No U2F support is even planned, but who cares anyway... :)
Just for the record: Opera Public Beta (v41) has U2F built-in support too. The next stable release should support FIDO U2F too.
Google Chrome: out-the-box since Chrome 41 (no extension required) https://support.google.com/accounts/answer/6103523?hl=en
Internet Explorer: "in development" https://dev.modern.ie/platform/status/fido20webapis/
Mozilla Firefox: popular feature request https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
It isn't specifically true that browsers can't add compatibility via extensions as per Michael's post, the issue isn't that it's secure because the browser "directly communicates" - USB can be sniffed so U2F isn't secure in that sense, which is precisely why it has defences against replay attacks.
The issue relates to browsers not generally having support internally to directly talk to USB devices - or more usefully for extensions to do that (but that would throw up other unrelated security concerns). It's perfectly plausible for a piece of software to act as an intermediary for an extension and pass on authentication events to a FIDO device; I've investigated the possibility and it absolutely would work without harming the security of U2F itself - native browser support would be preferable though.
I am adding SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256 in .htaccess file and after that my website is opening in Firefox but not opening in internet explorer 11.
Do i need any other combination for SSLCipherSuite to run my website in Internet Explorer 11?
thanks
SSL cipher suite support on Internet Explorer depends both on the
version of IE and on the version of the operating system
https://github.com/client9/sslassert/wiki/IE-Supported-Cipher-Suites
Try either one of the following for IE11:
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
Take the guesswork out of the configuration by using a tool such as the Mozilla SSL Configuration Generator to check which configuration you should use.
(as described in this answer)
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?