I'm using Liferay 6.2 CE GA2 Framework which is running on JDK7.
While calling Discourse Forum API using Apache httpclient it throws exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure.
I think this is because*JDK7 doesn’t implement any GCM cipher suite.
And Discourse Forum is configured with SSL Protocol: TLSv1.2 and Strong Cipher Suites: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
How to resolve this issue? Or is there any other way to call Discourse API from Java platform.
Thanks,
Saurabh Khandelwal
First of all: Before you fix this problem, you really need to upgrade and patch.
Which also might bring you closer to a solution: The compatibility matrix for Liferay EE 6.2 lists Java 8 as compatible - I'm not sure when this came in, but there's a good chance that the later GA versions in CE are also compatible. With that, you should have a newer set of TLS algorithms.
Otherwise you'd have to ask the Discourse admins to enable some algorithm that's compatible with your Java version.
(Disclaimer: I've not checked available algorithms in Java7, but it sounds like an unsupported algorithm is indeed a plausible root cause)
Did I mention that you really should update urgently?
Related
Recently, we have encountered a problem while installing one of our applications for a customer. During installation the application needs to perform some requests to our cloud service and we realised it could not establish HTTPS connection: the very TLS handshake failed. After researching a bit we found the server was a Windows Server 2008 which does not support TLS v1.2, which is the minimum required to connect to our servers. There are some workarounds (this one, for instance) but none of them worked. In addition, we cannot install any update to that windows due to customer policies.
While looking for a solution, using wireshark, we noticed that our program tried to connect using TLS v1.2 and failed, but Chrome browser was able to connect to the same cloud server using TLS v1.3, which is not even supported in Windows Server 2008. From that we deduced that Chrome is likely using its own TLS stack to establish the connection.
I am wondering that if Chrome is doing that, we should also be able to do the same. The application is developed in .Net Core and I have googled a lot looking for information on how to do this, and I've found lots of information on how to configure TLS certificates in .Net Core, but none on replacing the TLS stack with, say, OpenSSL or others. I do know this is possible in Java, so is it possible to replace the TLS stack in .Net core?
.NET Core itself doesn't let you plug in your own crypto stack.
You pointed to Bouncy Castle as an example of Java letting you use an alternate crypto stack; there's a port of Bouncy Castle to C#/.NET as well.
Their source code has a test case that demonstrates how to write a TLS client using Bouncy Castle:
https://github.com/bcgit/bc-csharp/blob/master/crypto/test/src/crypto/tls/test/TlsClientTest.cs
I have a Ubuntu 16.04 Server and I would like to know witch version of TLS is already installed on my server.
And how to upgrade to version 1.3 if version version is under v1.3
Thank you
While you don't specify it you are probably asking about the TLS support in your web and/or mail server. For the common servers on Linux the support is implemented with OpenSSL. Since you are using Ubuntu 16.04 you by default have OpenSSL version 1.0.2 which supports TLS up to TLS 1.2. But note that configuration of the servers might cause the actual protocol support to be limited.
There is no official TLS 1.3 yet, i.e. the protocol is still not finalized. Support for TLS 1.3 is expected to be available in OpenSSL 1.1.1 which is still in development.
Sniffing the packets with some application like Wireshark would reveal the information; the protocol version used in a connection is in the ServerHello message or
use http://ssl-checker.online-domain-tools.com tool to verify
I would suggest that you use the SSL test website by Qualys. If you ran your webserver with SSLProtocol +All for just a quick test, it would tell you what SSLProtocols are being served with your pages and a recommendation on which ones should and should not be used.
On a side note, I made a recurring task to test my sites; I found something even today that had changed since I last checked 3 months ago.
https://www.ssllabs.com/ssltest/index.html
Version: REBOL/View 2.7.8.3.1 1-Jan-2011
I have run a REBOL script weekly that fetches data for years. The last verified working of the script 21-Oct-2016.
As of today, 28-Oct-2016 the script fails with this error:
** Command Error: SSL Error: error:14077410:SSL routines:SSL23_GET_SERVER_HEL
LO:sslv3 alert handshake failure
Someone suggests that during the SSL/TLS handshake, REBOL only offers ciphers that current servers no longer support. Subsequently, the server my script tried to contact is not willing to work with older ciphers of REBOL and thus the handshake fails.
Is this right? If this is so, REBOL 2.7.8 will become useless before long unless patched.
Incidentally, this fails with Saphirion's R3. In that case, it simply crashes and stops working without spewing an error message.
REBOL/View 2.7.8.3.1 1-Jan-2011
I don't know much about rebol but according to the documentation it is available for a variety of systems, including various UNIX like systems. This suggests that the underlying library used for SSL/TLS is the most commonly used library which covers all supported systems, i.e. OpenSSL.
Given the data of the release if the rebol version this should be either an early version 1.0.0 of OpenSSL or more likely version 0.9.8. None of these OpenSSL releases support TLS 1.2 or ECDHE ciphers which are commonly supported by modern servers and sometimes not only supported but required. In the last case the SSL handshake simply will fail. Other reasons why the handshake might fail is that the site requires Server Name Indication (SNI). While SNI could be supported with OpenSSL 0.9.8 already it wasn't that much used in 2011 and thus only few software supported it at this time. But today SNI is often essential, for example if you try to access sites protected by Cloudflare Free SSL.
Rebol2 only has support for TLS 1.0. If you run the report from ssllabs on that server the report says that the only supported cipher suite for TLS 1.0 is TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA.
Now, Rebol3 and its forks aren't Rebol2, but if you look at the rebol3 source for prot-tls you'll see that the supported cipher suites do not include Elliptic Curve Diffie-Hellman Ephemeral or ECDHE.
We've updated the error message in the mean time so that it now says something more meaningful
read https://www.espacehifi.com/
** Error: Handshake failure - no supported cipher suite available on server
until we get ECDHE suites into rebol3.
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.
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.