Is there a difference between SSLv3 and TLSv1? How does IIS6.0 control what type of security is used for a website enabled with HTTPS?
MS says that there is a hierarchy in which the security and encryption level is negotiated before connection is established. What is this hierarchy?
Is SSLv3 available in IIS6.0 by default on Windows Server 2003?
SSLv3 and TLSv1 are not the same, however TLSv1 is based on SSLv3.
This is a protocol which is backward compatible, and gives a way to determine which version to use according to the "handshake" that takes place between the client and the server.
Read more here (this helped me understand it better): http://en.wikipedia.org/wiki/Secure_Sockets_Layer
Related
I'm running a web application that communicates with various APIs. One API requires TLSv1.2 while another will not support something that current (TLSv1 or TLSv1.1).
Does Websphere support multiple SSL versions?
I've found documentation about successfully changing the version of SSL, however I really need to be able to run TLSv1.1 and 1.2 together (if that's even possible) or run one version for one application while another for another application.
According to documentation for setting up SSL in WebSphere, to support the use of TLS 1.0, 1.1 and 1.2, I need to enable SSL_TLSv2:
Question: WAS is act SSL client, What does remote SSL server support
only TLSv1.0 or TLSv1.1 and Similar WAS is act SSL Server, What does
Remote SSL client does support only TLSv1.0 or TLSv1.1 or TLSv1.2.
What to do in order to work such environments?
Answer: There is an alternative option, SSL_TLSv2, which will enable
support for TLSv1.0, TLSv1.1, and TLSv1.2 in the environment. Please
use this setting SSL_TLSv2 in environments where support for multiple
TLS protocols is required, or if you are not sure whether your WAS
environment interacts with other servers or clients using non-TLSv1.2
protocols then, you can configure WAS to use SSL_TLSv2 using same
steps as given in the above.
Note:
Without poddle fix and configured WAS to use SSL_TLSv2
SSL_TLSv2 ==> Enables all SSL v3.0 and TLS v1.0, v1.1 and v1.2
protocols. Accepts SSLv3 or TLSv1 hello encapsulated in an SSLv2
format hello.
If you installed Poddle fix (will disable SSLv3 ) and configured WAS
to use SSL_TLSv2
SSL_TLSv2 ==> Enables these three TLS v1.0, v1.1 and v1.2 protocols.
So, changing the QoS settings to SSL_TLSv2 allows SSL Handshakes to multiple TLS versions when required.
Considering the POODLE attack, I want to disable the SSLv3 in my web app deployed on IBM WebSphere 6. There are a few concerns I cant address:
1. How to disable SSL and enable TLS in WAS 6.0 and 6.1?
2. When a client hits the url of my application in browser, and the browser supports SSL, the request will be initiated with SSL. Is there such a possibility wherein end user will get a handshake exception as the WAS 6 will have SSL disabled?
3. Is there a change required in application configuration or changing web server properties will help?
You don't need to change anything in your application.
There is already fixpack provided for latest WebSphere versions - check this page Vulnerability in SSLv3 affects IBM WebSphere Application Server
For V6.1.0.0 through 6.1.0.47:
Apply Interim Fix PI28796 : Will upgrade you to IBM Java SDK Version 5.0 Service Refresh 16 Fix Pack 7 + APAR IV66111 for change to
disable SSLv3 by default.
6.0 is soo old, that I don't remember if it even supports TLS. You will have to dig in the admin console somewhere in SSL settings (the exact path might be different) Security > SSL > SSL_configuration_name and change the protocol to TLS.
If you access WebSphere via web server (Apache or IHS), then you need to disable SSLv3 on the web server instead of application server. For details see Vulnerability in SSLv3 affects IBM HTTP Server
Add the following directive to the httpd.conf file to disable SSLv3
and SSLv2 for each context that contains "SSLEnable":
# Disable SSLv3 for CVE-2014-3566
# SSLv2 is disabled in V8R0 and later by default, and in typical V7
# and earlier configurations disabled implicitly when SSLv3 ciphers
# are configured with SSLCipherSpec.
SSLProtocolDisable SSLv3 SSLv2
Stop and restart IHS for the changes to take affect.
This is closely related to
Using nxlog to ship logs in to logstash from Windows using om_ssl
Using SSL to ship from NXlog to Logstash
I have a working NXlog and Logstash configuration as described in the above links.
However, the TLS connection fails with following exception in the logstash log:
OpenSSL::SSL::SSLError: Client requested protocol SSLv3 not enabled or not supported
It seems that NXlog relies on SSLv3 instead of TLS 1.x to do the SSL handshake. However, the former has been disabled in recent Java versions (as used by logstash) due to the POODLE vulnerability.
So how can I disable SSLv3 on the client side and force NXlog to use TLS 1.2?
I have to answer this one myself (after getting help on the NXlog community forum).
TLS is only supported by nxlog-ce-2.9.1347 and later.
A client installed on jBOSS is trying to access a secured website configured on DataPower xi50v6.0.0.2 appliance. The connection is getting failed at SSL handshake.
I have taken a packet capture at DataPower and observed that SSL Handshake is failing with the Description:Handshake failure(40).
However, at the Client Hello step, I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
The TLS protocol used ( as per packet capture) is TLS1.1. Can this Cipher Suite be a problem?
In the DataPower system logs I can see below error:
Request processing failed: Connection terminated before request headers read because of the connection error occurs
Update:
The client application is running on jBOSS7.I have asked our jBOSS administrator to check the configuration at jBOSS end. I somehow got the access to server where jBOSS instance is installed and checked domain.xml where the ssl is configured. Where exactly in domain.xml, ths configuration related to cipher suites can be found?
I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV
This is no real cipher. If no other ciphers are specified then the client does not offer any ciphers at all which means that no shared ciphers can be found and thus the handshake will fail. It looks like the client is buggy. Reason might be a failed attempt to fight POODLE attack by disabling all SSL3.0 ciphers, which in effect disables all ciphers for TLS1 1.0 and TLS 1.1.
Following a really outdated tutorial I managed to create an HTTPS server using OpenSSL with TLS1.2, and I'm very proud of it ;)
However TLS 1.2 is only supported in latest browsers and I would like to have some kind of negotiation of the protocol between the client and server, which I'm sure it can be done, but I'm not able to find how! So that if the client only supports TLS1.0, well use that. And if it only supports SSLv3, use that. Not sure about SSLv2, maybe better leave that...
The code I use right now is:
SSL_library_init();
OpenSSL_add_all_algorithms();
SSL_load_error_strings();
ssl_method = TLSv1_2_server_method();
ssl_ctx = SSL_CTX_new(ssl_method);
Then the server certificates are loaded and the ssl_ctx is shared among all connections. When a client is accepted by the server socket it is encapsulated in an SSL object (whatever it represents):
ssl = SSL_new(ssl_ctx);
SSL_set_fd(ssl, client_socket);
SSL_accept(ssl);
So I guess that something has to be changed in the ssl_ctx creation to allow more methods... Any idea?
<rant> No decent, extensive documentation can be found for OpenSSL, the best available is a 10 years old tutorial! </rant>
Thanks in advance.
You do this by using SSLv23_method() (and friends) instead of a specific method (e.g. TLSv1_2_server_method() in your example). This sends the SSLv2 ClientHello but also specifies the highest protocol supported. The somewhat outdated man page says:
SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
A TLS/SSL connection established with these methods will understand
the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2
client hello messages and will indicate that it also understands SSLv3
and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1 client
hello messages. This is the best choice when compatibility is a
concern.
This online man page doesn't discuss the newer TLSv1_1 and TLSv1_2 protocols, but I verified in the 1.0.1g source of s23_clnt.c that SSLv23_method() includes them.
You then limit the protocols you actually accept with SSL_CTX_set_options():
The list of protocols available can later be limited using the
SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1 options of the
SSL_CTX_set_options() or SSL_set_options() functions. Using these
options it is possible to choose e.g. SSLv23_server_method() and be
able to negotiate with all possible clients, but to only allow newer
protocols like SSLv3 or TLSv1.
Note, however, that you can't enable arbitrary sets of protocols, only contiguous protocols in SSLv2, SSLv3, TLSv1, TLSv1_1, TLSv1_2. For example, you can't choose only SSLv3 and TLSv1_1, omitting TLSv1. This comment in the source explains why:
SSL_OP_NO_X disables all protocols above X if there are some protocols below X enabled. This is required in order to maintain "version capability" vector contiguous. So that if application wants to disable TLS1.0 in favour of TLS1>=1, it would be insufficient to pass SSL_NO_TLSv1, the answer is SSL_OP_NO_TLSv1|SSL_OP_NO_SSLv3|SSL_OP_NO_SSLv2.