Which ciphers are supported for the HERE geocode api rest service? - java-7

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.

Related

Why are two TLS protocol versions TLS 1.2 and TLS 1.3 used alternatively under heavy load?

I am using Spring Rest template for making GET requests calls to an external API. This API does not support TLS 1.3 yet. The connection to the service works fine during normal work load.
During load testing, I observed that some of the calls were failing with the below exception:
Remote host terminated the handshake; nested exception is javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:748)
at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:674)
at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:583)
On enabling javax.debug level logs, found that for the calls that failed, TLS1.3 protocol was used for handshake.
javax.net.ssl|DEBUG|9D|http-nio-8080-exec-28|2021-02-09 16:34:59.588 UTC|SSLSocketOutputRecord.java:71|WRITE: **TLS12** alert(close_notify), length = 10
javax.net.ssl|DEBUG|06 87|http-nio-8080-exec-176|2021-02-09 16:34:08.621 UTC|SSLSocketOutputRecord.java:71|WRITE: **TLS13** alert(handshake_failure), length = 2
My application is implemented in Java 11 [openjdk 11.0.3]. Java 11 also supports TLS 1.3. In order to resolve the issue, I will have to enforce it to use TLS1.2.
I want to understand, how is the TLS protocol version to be used determined by Java? In this case, both TLS1.2 and TLS1.3 were used alternatively.

RFHUtil MQ utility tool not supporting TLSV1.2 Cipher to connect MQ-9

I am not able to connect the WMQ-9.1 queue manager via RFHUtil in case the channel configured with TLSV1.2 Cipher means.
No issues when i am connecting from SSL to TLSV1.0 version in that. Never tried TLSV1.1 before.
Any idea how to overcome this also can you suggest any alternate open source tools are available in the market or git repo?
You can pull the latest from here.
https://github.com/ibm-messaging/mq-rfhutil/tree/master/bin/Release

IBM WAS sslSocket.getEnabledProtocols() issue

We have a single installation of WAS(8.5.5.10), with multiple clusters(JVMs). We enabled TLS1.2 on one of the JVMs, (say JVM1). But when I run the code sslSocket.getEnabledProtocols(), it gives me supported protocols=[TLSv1], which is V 1.0. My application runs on Java 1.7.
When I check in Security > SSL certificate and key management, and under Related Items, click SSL configurations. ( such as CellDefaultSSLsetting , NodedefaultSSLsetting and any other SSLConfig), it shows 'TLS' as the protocol, under QoP settings.
But when I check in SSL certificate and key management > Manage endpoint security configurations > jvm1_cluster, it shows 'TLS1.2' as SSL configuration.
From IBM forums, I came to understand that it is possible to enable TLSV1.2 at only one cluster. and need to use jssehelper to specify an outbound ssl configuration.
Tried following the link on how to programmatically specifying an outbound SSL configuration using JSSEHelper API. https://www.ibm.com/support/knowledgecenter/en/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/tsec_ssloutconfiguseJSSE.html
but I still could not get it to work. When I print the properties, I can see protocol as TLSV1.2 (com.ibm.ssl.protocol = TLSv1.2). Application uses com.ibm.jsse2.SSLSocketFactoryImpl for ssl socket provider.
To give you some background, am trying to connect to APNS using okhttp3 library. Am adding these properties, at the place where I create the socket connection. And after the socket is created, when I do sslSocket.getEnabledProtocols(), it gives me supported protocols=[TLSv1], which is V 1.0.
Since it tries to connect via TLS1, it gives javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure, when trying to establish connection to APNS. I have the certificate added to was store already and the firewall rules are in place as well, to allow the connection.
Error:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at com.ibm.jsse2.j.a(j.java:23)
at com.ibm.jsse2.j.a(j.java:21)
at com.ibm.jsse2.qc.b(qc.java:465)
at com.ibm.jsse2.qc.a(qc.java:451)
at com.ibm.jsse2.qc.h(qc.java:759)
at com.ibm.jsse2.qc.a(qc.java:353)
at com.ibm.jsse2.qc.startHandshake(qc.java:800)
Pls guide me on how to fix the issue. Thanks.

clojure https connect using TLS 1.2 protocol

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.

TLS handshake inside SSLv3 record layer

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.

Resources