Handshake Failure

Hi Michail,

With a quick test with JDK 1.7.0_80, HttpsURLConnection:

HttpsURLConnection connection = null;
URL url = new URL(requestURL);
connection = (HttpsURLConnection) url.openConnection();

I received another exception "Received fatal alert: protocol_version":

Exception in thread "main" javax.net.ssl.SSLException: Received fatal alert: protocol_version
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
    at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1979)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1086)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
    at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1092)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:250)
    at com.oss.guide.rest.CreatePackageREST.main(CreatePackageREST.java:191)

And I can work around this exception by specifying the JVM property:

System.setProperty("https.protocols", "TLSv1.2");

In your case, which HttpClient are you using? Could you share some sample codes around how you send out the RESTful request?

Duo

 

Hello Duo,

We use EslClient.

Where is our dependency:

<dependency>
            <groupId>com.silanis.esl</groupId>
            <artifactId>sdk</artifactId>
            <version>10.9.1</version>
            <exclusions>
                <exclusion>
                    <groupId>com.fasterxml.jackson.core</groupId>
                    <artifactId>jackson-databind</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

Does it help?

Regards,

Michail

I see, I can reproduce the same now. However, as per the communication email, seems US1 sandbox hasn't been applied the upgrade:

• Canada Sandbox: Tuesday, April 27, 2021
• US2 Sandbox: Wednesday, April 28, 2021
• US1 Sandbox: Thursday, April 29, 2021 

And what's interesting I found from my tests is, it seems that I can successfully connect to CA and US2 sandbox (which has already been applied the upgrade) with the same SDK code. Could you also try to connect to US2 or CA sandbox or wait a bit until the upgrades applied to US1 sandbox?

Duo

Hello Duo,

I have just tried and I got the same error.

Regards,

Michail

Hello Duo,

Do you have any suggestion?

Thanks,

Michail

Hi Michail,

From my understanding, OneSpan Sign will only be supporting below TLS versions and cipher suites after this upgrade:

TLS 1.2 cipher suites (open SSL and their cipher suite names)

ECDHE-ECDSA-AES128-GCM-SHA256         TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
ECDHE-RSA-AES128-GCM-SHA256              TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ECDHE-RSA-AES256-GCM-SHA384              TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
ECDHE-ECDSA-AES256-GCM-SHA384         TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
ECDHE-ECDSA-AES128-SHA256                   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
ECDHE-RSA-AES128-SHA256                        TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
ECDHE-ECDA-AES256-SHA384                      TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
ECDHE-RSA-AES256-SHA384                        TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS 1.3 cipher suites

TLS13-CHACHA20-POLY1305-SHA256
TLS13- AES-256-GCM-SHA384
TLS13- AES-128-GCM-SHA256
 

From the exception message "Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure", it's mostly likely because the Java 1.7 doesn't support these cipher suites.

After some research, I did find a workaround by installing Java Cryptography Extension (JCE) and modifying the source code a bit. However, this won't be easier than directly upgrade to Java 8. If you are interested, I can share the steps to you, but again, this may not be straightforward nor suggested.

Duo

Hello Duo,

Thanks a lot for your research.

Could you please share the steps with me? We will check with my team and decide how to proceed.

PS. In case we don't have the time to move forward (either with Java Cryptography Extension or with Java 8) until the Production release of OneSpan on 30th of June, is there any alternative solution/workaround so that we don't interrupt our business's productivity?

Best Regards,

Michail

Hi Michail,

Below are the steps. Just keep in mind that to modify SDK source code is not suggested.

Step1: install JCE to your JDK

As many discussions out there suggested (e.g. below StackOverflow post), seems the JREs disable all 256-bit crypto by default.

https://stackoverflow.com/questions/33089150/enable-tlsv1-2-and-tls-rsa-with-aes-256-cbc-sha256-cipher-suite

If stronger algorithms are needed (for example, AES with 256-bit keys), the JCE Unlimited Strength Jurisdiction Policy Files must be obtained and installed in the JDK/JRE. Replace the local_policy.jar and US_export_policy.jar jars files into your lib/security in jre directory.

https://www.oracle.com/java/technologies/javase-jce7-downloads.html

Step2: Override the SDK source code

Create class com.silanis.esl.sdk.internal.RestClient in your local

Copy paste the source code, and modify the line 238 to

SSLContext sslContext = SSLContext.getInstance("TLSv1.2");

From there, whenever you build an EslClient object, set "allowAllSSLCertificates" to true:
​EslClient eslClient = new EslClient(API_KEY, API_URL, true);

To prevent product release interrupting your business's productivity, it's better to create a support ticket ([email protected]) and escalate the issue to R&D team, with the background information and our findings. Once you got the support ticket, please share the reference number to me and I will keep working with support team.

Duo

Hello Duo,

Thanks for the steps to implement this workaround. 

I have a question:

If I create locally the RestClient class, how can I “force” the EslClient to call the local RestClient instead of the sdk’s class?

Thanks,

Michail

Hi Michail,

The local Java classes will by default take priority over the dependencies'.

Duo

Hello Duo,

We are in the process to install the JCE and do the code changes. I will inform you once we are done in our side.

The case I opened is CS0065348. I have not mentioned anything about the handshake issue yet, as I am waiting for the installation of JCE to be completed by our server team.

Nevertheless, I raised another question about the new incoming IP addresses which we have to whitelist in our side, for Sandbox.

Maybe you can have a look in the case.

Thanks and Regards,

Michail

Hello Duo,

Did you have some time to check this case?

Regards,

Michail

Hello Duo,

I hope you have been keeping well.

First of all I would like to mention that we have not done any change in our side yet.

On Thursday 20/05/2021, we simply tried again to create a new package for OneSpan (US1 Sandbox) and everything is working fine again since that day.

We didn't get any handshake failure issue and also no issue related to the new incoming IP addresses.

Could you please check if there is any change in your side, which made the things work again?

Thanks and Regards,

Michail

Hi Michail,

My testing code with Java 7 update 80 + SDK 10.9.1 + US1 sandbox environment still receives "Received fatal alert: handshake_failure" error like before. I've consulted support team and they also weren't aware of the changes which could lead the result. I will keep investigating it and let you know if I found anything.

Duo

Hello Duo,
 

We have applied the changes in our side and tested against Sandbox. Everything is working fine.

If we release the changes to our Production environment, before the release to OneSpan Production (US1), do you think it will be a problem?

Best Regards,
Michail

Hello Duo,

Do you have an update on my last question?

Thanks and Regards,
Michail

Hi Michail,

Sorry for the late reply. From my own test with Java 1.7.0.80 + OSS SDK 10.9.1 + the fix, it works fine with both US2 sandbox and production environments.

Although I don't think there will be a problem deploying the same changes to production environment before Cloudflare actually set up, it could be safer if you point your development/qa environment to OSS production and perform some smoke tests before the deployment.

Duo

Hello Duo,

What is the OSS Production? Could you please provide me the URL we have to use?

Thanks and Regards,
Michail

Please refer to below URLs:

Europe Production: apps.esignlive.eu

Canada Production: apps.e-signlive.ca

US2 Production: apps.esignlive.com

US1 Production: apps.e-signlive.com

Hello Duo,

We released the changes to our Production environment yesterday, and until now everything is working fine.

We keep our eyes on the release to OneSpan Production, on 30th of June.

Best Regard,
Michail