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
Related
I'm using sim800 module to connect to a server using TLS. Due to a security policy in our company, the module must not continue the connection establishment if the remote host tries to use and older version of SSL/TLS.
Is there a command or setting in sim800 that can be used to choose the TLS/SSL version when connecting to a server?
*I have searched its SSL and AT command manuals and couldn't find anything useful.
There's a TLS firmware of sim800 and you can upgrade to it, this firmware use TLS version 1.2 but you can't select the version of TLS,infact sim800 use latest version of TLS that firmware supported.
TLS Firmware version
1418B09SIM800C24_TLS
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?
We are about to upgrade our TLS version and I want to make sure that nothing breaks in our http requests. We're using axios as our library of choice to make requests and I'm just wondering if anyone knows what TLS versions are supported by axios? Thank you.
As a server, axios uses node's underlying http and https implementation judging from the code on GitHub. For node, the answer your question is "whatever your version of node supports". Practically speaking, recent versions of node support TLS 1.0 through 1.3.
Node by default statically links OpenSSL, so the answer for node can depend on what version of OpenSSL (or alternative TLS library) Node was compiled with; or if it is using dynamic loading.
Assuming the pre-built node packages, node 6.x+ have support for TLS up to TLSv1.2. Node 11.x has support for TLSv1.3, but it needs to be enabled with maxVersion or DEFAULT_MAX_VERSION; and node 12.x has support for TLSv1.3 out of the box.
If you are using axios in a browser, then it will use xhr.js, and TLS support will be provided by the browser. This is where it gets a little more complicated. Most browsers support TLS 1.2, but not all. All recent versions of browsers do. You can use SSLLab's list of browser versions to determine what version of TLS they support.
We have a legacy web application that runs in a tomcat under java 6, upgrading to 7 or 8 is infeasible as the application needs significant work to allow this and the fixes required are too large to implement in a legacy application. We now have a requirement to connect outbound (i.e. as a client) over TLS 1.2 however java 6 only supports 1.0. We use Apache as our web-server and OpenSSL for incoming connections and this happily supports TLS 1.2 etc.
Has anyone had to address a similar issue, or can you comment on the following potential work arounds:
Loopback to localhost (or otherwise redirect) and use OpenSSL to create a TLS 1.2 connection,
effectively an internal proxy
can openssl be a client?
do we need s_client?
Use our current the firewall to upgrade the connection
this would need to be selective
Obviously implementing this will depend on the firewall
Use “Bouncy Castle” (https://www.bouncycastle.org/)
Don't use openssl's s_client for this - it's slow, and intended more for debugging/testing.
Try using stunnel. It's designed for use cases like yours, and you can find plenty of example configs to get you started. You'd want to make sure to include the sslVersion = TLSv1.2 directive in your configuration to force use of TLS 1.2.
Having trouble with chrome v 4x.xx and WebLogic not automatically handshaking via tls 1.0 minimum. While calling a RESTful service from JavaScript front end I keep getting net::ERR_SSL_FALLBACK_BEYOND_MINIMUM_VERSION since Google have dropped support for SSL V3.0. I have tried adding the flag forcing this to JAVA_OPTIONS and on another occasion to the starting arguments for WebLogic, despite knowing these only become suported in 10.3.6. Is there another way?
So it turns out WebLogic 10.3.2.0 has a bug in it. When the client makes contact with the server for the first time it tells the server which SSL/TLS certificate version it supports - UP TO. The latest Chrome I believe supports TLS v1.2, so this is the only information sent to WebLogic. WebLogic has problems recognising that 1.2 is greater than 1.0, (which is the highest version available on WebLogic 10.3.2.0 (AFAIK, it is on ours) and should therefore be trusted, so terminates the connection.
source - https://productforums.google.com/forum/#!topic/chrome/iwX2PbNGk8E