Java client wil niet verbinden met secure websocket server

[DaCoTa]

Ik probeer een websocket verbinden op te zetten met de secure websocket feed van xBTCe. De documentatie is te vinden op https://www.xbtce.com/websocketfeedapi, de uri om te verbinden is wss://cryptottlivewebapi.xbtce.net:3020. Het probleem is dat ik in mijn Java test client nooit een onConnect event krijg. Er wordt wel een upgrade request gestuurd, maar er komt daarna niks meer terug, de verbinding is dan al verbroken.

De client is geschreven in Java 1.8.0_101 en gebruikt Jetty websocket-client 9.3.12.

Als alternatieven naast Jetty heb ik ook implementaties gemaakt met GlassFish Tyrus en met TooTallNate/Java-WebSocket. Ook die geven hetzelfde resultaat, er komt geen onConnect event.

Het vreemde is, als ik http://websocket.org/echo.html gebruik om de URL te testen, dan werkt het, direct CONNECTED. Ook via de documentatie link is het mogelijk om de websocket te testen en daar werkt het ook (connect knop rechts boven). Dus een javascript implementatie in mijn browser functioneert, een Java implementatie vanaf dezelfde machine niet. Ik heb alle request headers nagekeken die de javascript implementaties toevoegen, maar dat maakte geen verschil.

Java:

import java.net.*;
import java.util.concurrent.*;

import org.eclipse.jetty.util.ssl.*;
import org.eclipse.jetty.websocket.api.*;
import org.eclipse.jetty.websocket.api.annotations.*;
import org.eclipse.jetty.websocket.client.*;

public class WebSocketMain {
    public static void main(String[] args) throws Exception {
        //URI uri = new URI("wss://echo.websocket.org"); // werkt
        URI uri = new URI("wss://cryptottlivewebapi.xbtce.net:3020"); // werkt niet
        WebSocketClient webSocketClient = new WebSocketClient(new SslContextFactory());
        SimpleEchoSocket simpleEchoSocket = new SimpleEchoSocket();
        webSocketClient.start();
        webSocketClient.connect(simpleEchoSocket, uri);
        simpleEchoSocket.awaitClose(5, TimeUnit.SECONDS);
        webSocketClient.stop();
    }

    @WebSocket
    public static class SimpleEchoSocket {
        private CountDownLatch closeLatch = new CountDownLatch(1);

        public boolean awaitClose(int duration, TimeUnit unit) throws InterruptedException {
            return this.closeLatch.await(duration, unit);
        }

        @OnWebSocketConnect
        public void onWebSocketConnect(Session session) throws Exception {
            System.out.printf("onWebSocketConnect: %s%n", session);
            RemoteEndpoint remote = session.getRemote();
            Future<Void> future = remote.sendStringByFuture("Hello");
            future.get(2, TimeUnit.SECONDS);
            future = remote.sendStringByFuture("Thanks for the conversation.");
            future.get(2, TimeUnit.SECONDS);
            session.close(StatusCode.NORMAL, "I'm done");
        }

        @OnWebSocketClose
        public void onWebSocketClose(int statusCode, String reason) {
            System.out.printf("onWebSocketClose: %d - %s%n", statusCode, reason);
            this.closeLatch.countDown(); // trigger latch
        }

        @OnWebSocketError
        public void onWebSocketError(Throwable cause) {
            System.out.println("onWebSocketError:");
            cause.printStackTrace();
        }

        @OnWebSocketMessage
        public void onWebSocketText(String message) {
            System.out.printf("onWebSocketText: %s%n", message);
        }
    }
}

Mijn vermoeden is dat het ergens in de SSL handshake misgaat, maar daar loop ik spaak. Ook weet ik niet of het aan mijn machine ligt (Ubuntu 16.04, ook getest op Windows 10 met Java 1.8.0_91).

[Yuri_MB]

Probeer eens op te starten met dit: -Dhttps.protocols=TLSv1.1,TLSv1.2

Java stuurt een hele oude hello (sslv3 volgens mij), daar struikelen sommige webservers over, ivm security.

[DaCoTa]

Dat heeft niet geholpen, maar via een google kwam ik op https://blogs.oracle.com/...gnosing_tls_ssl_and_https, waar een debug vlag staat. Met

-Djavax.net.debug=ssl:handshake:verbose

krijg ik dit als output (zonder -Dhttps.protocols):

code:

*** ClientHello, TLSv1.2
WebSocketClient@1144648478-14, WRITE: TLSv1.2 Handshake, length = 202
WebSocketClient@1144648478-13, called closeInbound()
WebSocketClient@1144648478-13, fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack?
javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
WebSocketClient@1144648478-13, SEND TLSv1.2 ALERT:  fatal, description = internal_error
WebSocketClient@1144648478-13, WRITE: TLSv1.2 Alert, length = 2

Als ik nu de website door een SSL tester heen haal, komen er de volgende meldingen uit:

• The TLS engine does not support newer version than TLSv1.0 and seems outdated.

Klopt het dan dat de server paniekt omdat er een TLSv1.2 handshake gedaan wordt?

[DaCoTa]

De oplossing gevonden, dus even in een losse post om als antwoord te dienen.
Het toevoegen van

Java:

sslContextFactory.setExcludeCipherSuites("");

aan de sslContextFactory op regel 13 zorgt ervoor dat TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA enabled wordt. Deze (en vele anderen) zijn met Java 7 by default disabled.

Ik ben hierbij gekomen via http://stackoverflow.com/...handshake-failed-java-1-8, wat mij wees op het volgende command:

code:

openssl s_client -connect cryptottlivewebapi.xbtce.net:3020

In het antwoord wat dat teruggaf, stond onder andere:

code:

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : ECDHE-RSA-AES256-SHA

In de java ssl debug output stonden een heleboel ciphers op unavailable en unsupported, en na nog meer zoeken ben ik op de setExcludeCipherSuites uitgekomen. Standaard staat hier

code:

[^.*_(MD5|SHA|SHA1)$]

wat dus alle SHA ciphers uitschakelt.
We zijn dus nu twee dagen verder. Zucht.

En ik kan mijn eigen post niet als antwoord markeren. In ieder geval dank Yuri_MB, je hebt mij genoeg aanwijzingen gegeven om mijn google-fu aan te wakkeren :-)

[ Voor 6% gewijzigd door DaCoTa op 06-10-2016 18:11 ]

[Yuri_MB]

Mooi zo, graag gedaan!

[pedorus]

DaCoTa schreef op donderdag 06 oktober 2016 @ 18:09:
De oplossing gevonden, dus even in een losse post om als antwoord te dienen.
Het toevoegen van

Java:

sslContextFactory.setExcludeCipherSuites("");

aan de sslContextFactory op regel 13 zorgt ervoor dat TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA enabled wordt. Deze (en vele anderen) zijn met Java 7 by default disabled.

Nu heb je bijvoorbeeld SSL_RSA_WITH_NULL_SHA ook enabled, welke geeneens iets doet aan encryptie. SHA-1 is ook met een reden uitgezet, maar dan nog relatief veilig. Het werkt nu dus wel, maar je kan niet meer over 'secure' spreken.