We are using one server which is currently gone through TLS 1.2 up-gradation.
Before that, our one tool which is communicating to server via gsoap works fine. Now I am getting SSLv3 alert handshake failure in soap_connect method. More precisely under soap->fopen method. I have also added certificate with for soap_ssl_client_context passing with SOAP_SSL_DEFAULT parameter and also tried with other parameters but no luck.
Can you please help me regarding to it?
I observed that I am using OpenSSL 1.0.0e but TLS 1.2 introduced in OpenSSl 1.0.1 found in thread stackoverflow.com/questions/48178052/…. SO just upgrading OpenSSL to 1.1.1 solved my issue.
Related
Security Warning: The negotiated TLS 1.0 is an insecure protocol and is supported for backward compatibility only. The recommended protocol version is TLS 1.2 and later.
I'm trying to create a table in the migration file database, but I'm getting the error above, I've researched it, but I haven't been able to get a meaningful opinion.Can anyone answer the question who knows the answer?
We are currently using java 7 and have trouble connecting to the geocode API from HERE.
When testing in our application we receive an error as follows:
Received fatal alert: handshake_failure
The url we request:
https://geocoder.ls.hereapi.com/6.2/geocode.json?apiKey={API-KEY}&searchtext=NYC,+USA
Running the same request in Postman works seamlessly.
Likewise running the code for the request in an alternative java 8 workspace. The request returns the expected response.
We assume the reason is that no matching ciphers exist between client and server when using java 7.
Does the HERE support team know of problems similar to this?
Is there a good workaround without having to upgrade to jdk1.8?
The HTTP connection to HERE APIs utilizes via TLSv1.2 cryptographic protocol because TLSv1.0 and TLSv1.1 have known security vulnerabilities.
In the jdk1.8 the SSLContext has been already set to TLSv1.2 by default therefore it works (unlike jdk1.7, you can see a handshake info if pass the -Djavax.net.debug=all parameter).
For java 7 you need to set SSLContext to TLSv1.2 before a https connection to init in your java code:
SSLContext sslCtx = SSLContext.getInstance("TLSv1.2");
sslCtx.init(null,null,null);
SSLContext.setDefault(sslCtx);
Additionally you can update the Unlimited Strength Java(TM) Cryptography
Extension (JCE) Policy Files for the Java(TM) Platform, Standard
Edition (Java SE) Runtime Environment 7 - This bundle provides "unlimited strength" policy files which contain no
restrictions on cryptographic strengths.
Trying connect to https server (https://3dsecure.kkb.kz) using TLS 1.2.
(defn- http-request-clojure [xml req-type]
(let [url-info (url-map req-type)
(prepare-response (.toString (:body (client/get
(str (:url url-info) "?"
(and (:name url-info)
(str (:name url-info) "="))
(URLEncoder/encode xml))
{:insecure? true
:socket-timeout 10000
:conn-timeout 10000}))))))
Got error "javax.net.ssl.SSLException: Received fatal alert: protocol_version"
openssl 1.0.1g , java 7.
Any ideas what goes wrong?
It's not you, it's them: from their Qualys SSL Labs report:
Java 6u45 No SNI 2 Protocol or cipher suite mismatch Fail3
Java 7u25 Protocol or cipher suite mismatch Fail3
Java 8u31 TLS 1.2 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) No FS 112
at least from today. They could fix this at any time, so hopefully you have a close enough relationship to politely encourage them to folow that link, and perhaps update openssl to they aren't vulnerable to this protocol downgrade attack.
This is almost always a simple matter of changing the nginx or apache config, though it can take a little fiddling to ensure all devices can still connect. SSL labs is an amazing resource for figuting this out.
From your perspective, is using Java 8 an option? It will be the easiest way past this.
Is it possible to use TLSv.1.2 or TLSv1.1 with Ruby?
I have compiled a Frankenstein version of Ruby using OpenSSL 1.0.1c (the latest available) and the only difference being is SSLv2 is now an option under OpenSSL::SSL::SSLContext::METHODS
Is it possible to add TLSv1.2 to that list?
Yes, we added TLS 1.1 & 1.2 support recently. It's as easy as setting ssl_version on your SSLContext:
ctx = OpenSSL::SSL::SSLContext.new
ctx.ssl_version = :TLSv1_2
You may still continue to use the more generic :SSLv23 for maximum interoperability. It will have the effect that the newest protocol supported by the peer will be used for the connection. If your peer understands TLS 1.2, then it will be used. But opposed to the above sample, if the peer does not speak 1.2, then the implementation will silently fall back to the best/newest version that the peer does understand - while in the above example, the connection would be rejected by the peer if it did not recognize 1.2.
For further details, also have a look at OpenSSL's own docs on the subject, you can transfer what's being said about TLSv1_method to TLSv1_1_method and TLSv1_2_method (represented in Ruby as :TLSv1, :TLSv1_1 and :TLSv1_2 respectively).
If your underlying OpenSSL supports TLS 1.2 (>= 1.0.1 does), you're good to go. However, this requires a Ruby build from trunk currently. But if we get no negative feedback in the meantime, it might well be that it will be backported to the next 1.9.3 release.
My Server is configured to accept both SSLv3 and TLS1.0 protocols. But a few clients are sending below handshake parameters and after the server hello, the client drops the connection and sends 'handshare failure(40) alert, not sure if it's the client fault or server.
Here's the initial client hello packet:
Secure Socket Layer
SSLv3 Record Layer: Client Hello
Content Type: Handshake (22)
Version: SSL 3.0 (0x0300) <-----------------
Length: 103
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 78
Version: TLS 1.0 (0x0301) <-------------
Random
Session ID Length: 0
Cipher Suites Length: 18
Cipher Suites (9 suites)
The Record layer is SSL 3.0 but the inside handshake protocol is TLS 1.0. My question is, is this the right way of doing it i.e. using different versions for each layer? if it is what method is it? I can't find it anywhere, I looked through the RFC but can't find any reference. Also, how can I produce such requests?
EDIT: I'm not interested in troubleshooting and fixing the issue, I just want to know how can I send such packets? Any command? And what should I name this method?
i.e. I can use curl or openssl to either use ssl3 or tls1 but that would send same version in both record layer and handshake layer:
curl -v -ssl3 https://www.mywebserver.com
Above curl command would look on wireshark:
EDIT2: Is this even legal? I have been googling around and can't find any example. Is it violating any rfc standards?
Thanks
Yes, this is legal (at least it was clarified in recent TLS specifications).
You can look this up in rfc5246 (TLS 1.2) or in rfc6101 (SSL 3.0) or other rfc's concerning the SSL/TLS. The problem is with the initial version of the record protocol and with the handshake protocol:
rfc5246:
Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.
TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version.
Regarding the handshake protocol, the client will negotiate the highest version that it has implemented:
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
I just want to know how can I send such packets? Any command?
openssl s_client -connect www.myserver.com:443 -no_ssl2
should produce something similar to the trace you provided.