I want to create a secure websocket client-server communication using Netty framework. I looked at the netty examples and there is an example with websocket ssl server: https://github.com/netty/netty/tree/master/example/src/main/java/io/netty/example/http/websocketx/sslserver
and there is also another example with websocket client, but without ssl: https://github.com/netty/netty/tree/master/example/src/main/java/io/netty/example/http/websocketx/client
So I've put the SslHandler as the first hander in the ChannelPipelinehandle as suggested here: How can use netty websocket client with wss?
But it still does not work. Client successfully connects to server (handshake succeeds), but then when client sends a message to server (for example PingWebSocketFrame or any other WebSocketFrame) nothing happens. Server does not receive any message.
Do you have an idea what might be wrong?
EDIT: I use 4.0.0.CR5 and to be exact, server always receives something, but only first SSLHandler. Next handler in the pipeline (HttpRequestDecoder) then receives a message only sometimes, and when it does, it creates DefaultHttpRequest with this failure:
decodeResult: failure(java.lang.IllegalArgumentException: invalid version format: |LZSﾺ
Those weird characters should probably represent an HTTP version, but it looks like SSLHandler did not decode them correctly?
I had the same issue (you can see the stackoverflow post here).
The sample code on the client uses the channel.write() method, which seems not to forward the messages to the Websocket ssl server. By using the channel.writeAndFlush() instead, messages are correctly sent to the server.
All these were tested using the netty 4.0.9.Final version
Related
I would like to seek for your advice if you have any idea or you have already encountered this issue “SSL/TLS handshake Issue” ?
To give you a summary, we’re getting an error the error below when connecting to Coupa (ERP) through HTTP.
Remote host closed connection. Possible SSL/TLS handshake issue. Check protocols, cipher suites and certificate set up. Use -Djavax.net.debug=ssl for further debugging.
We have several HTTP requests using the same HTTP config, but there’s this only one specific request that gives the said error. Also, this HTTP request works in postman. This occurs only in one Mule environment (UAT Environment). It works fine in our sandbox environment.
We are not sure whether the SSL connection/Handshake is closed on our end or server end.
If ever its on our end, how do we identify the fix for that?
If it’s on the server end, what should be the proof that we need to provide to them to say that the issue is on their end.
The server -Coupa in this case- is closing the connection just after it was opened by the client -a Mule application- probably before the client can send the HTTP request. The server could do this by any of a number of causes and the client does not receive any error messages or codes to indicate a reason. You will need to learn the reason from the server side.
Usual reasons are because an HTTPS connection doesn't match thee required ciphers suites or protocol versions accepted by the server, or because the client IP is not whitelisted. In those situations documentation from what's acceptable to the server side is useful. There could some other reasons that are known only to the server side.
A method to troubleshoot TLS connection issues is to do a traffic capture of the TCP packets, ideally from both sides, but if you don't control the server it will be only possible from the client. Another option if you are using HTTPS is to enable Java SSL Debug log in the Mule runtime to print the HTTPS connection information. You need to understand how to troubleshoot TLS to use these tools.
For my current project i need to implement http over tls at client ,for this i need a local server able to simulate this . is there any online or offline tool. which i can use and and see the handshake in wireshark .
For watching the TLS handshake you might not get far enough with wireshark. For such kind of monitoring you would ensure the security is low enough for wireshark to be able getting the session key from watching the handshake for decoding the later parts. Thus, you need to avoid any forward secrecy.
Otherwise any (https) server that is accessible (and willing to talk) to your client will do.
In case you are in an environment that is supported (e.g. any unix/linux), you might try using openssl. It allows setting up a server that will do handshake. And it will log the handshake such that you will be able looking at what is going on. This will eliminate the need for using wireshark for debugging.
For achieving this you need a Web Server accepting connection over TLS.I have achieved this on Apache Tomcat web Server.
TLS configuration needs to be done in the server.xml file present in config directory of Tomcat webserver. Connector tag needs to be added in the server.xml file that contains information like
TLS version to be used, port, List of supported Cipher Suites, Keystore path and password, Truststore path and password.
Any regular Rest client can be used to make a call like Postman client. But to use that over TLS/SSL certificate is needed to be installed in Chrome browser.
Hope this answers your doubt.
I'm testing SSL/TLS stream proxying within NGINX that will connect to a web server using gnutls as the underlying TLS API. Using the command line test tool in gnutls (gnutls-serv) the entire process works, but I can't understand the logic:
the NGINX client (proxying HTTP requests from an actual client to the gnutls server) seems to want to handshake the connection multiple times. In fact in most tests it seems to handshake 3 times without error before the server will respond with a test webpage. Using wireshark, or just debugging messages, it looks like the socket on the client side (in the perspective of the gnutls server) is being closed and reopened on different ports. Finally on the successful connection, gnutls uses a resumed sessions, which I imagine is one of the previously mentioned successful handshakes.
I am failing to find any documentation about this sort of behaviour, and am wondering if this is just an 'NGINX thing.'
Though the handshake eventually works with the test programs, it seems kind of wasteful (to have multiple expensive handshakes) and implementing handshake logic in a non-test environment will be tricky without actually understanding what the client is trying to do.
I don't think there are any timeouts or problems happening on the transport, the test environment is a few different VMs on the same subnet connected between 1 switch.
NGINX version is the latest mainline: 1.11.7. I was originally using 1.10.something, and the behaviour was similar though there were more transport errors. Those errors seemed to get cleaned up nicely with upgrading.
Any info or experience from other people is greatly appreciated!
Use either RSA key exchange between NGINX and the backend server or use SSLKEYLOGFILE LD_PRELOAD for NGINX to have the necessary data for Wireshark to decrypt the data.
While a single incoming connection should generate just one outgoing connection, there may be some optimisations in NGINX to fetch common files (favicon.ico, robots.txt).
I have configured the Websocket on my live server and I'm using SSL on live server. When I used following code on my localhost, websockets were fine.
ws://localhost:8080/server.php
Once I moved the file to the live server I have changed the code to the following
wss://IP:PORT/server.php
I have created a seperate port for web socket and configured on firewall TCP IN and OUT. However, I'm receiving the following error on console
WebSocket connection to ............ failed: Error in connection establishment: net::ERR_SSL_PROTOCOL_ERROR
Can anyone suggest me some solutions to overcome this issue
Basically when you are using wss you are just serving the WebWocket over SSL/TLS.
Meanwhile using a simple ws does not require a particular setup, wss does. Indeed you have to create a secure connection using a valid SSL Certificate when opening the communication.
If you certificate is missing or invalid the connection cannot be enstabilished therefore an error will be raised while attempting to start the communication.
So you can't just switch from ws to wss but also have to make a proper implementation.
You can find more details here, hope that helps!
here is what I did, I never able to install ssl in local, so I started using the w3cwebsocket client
https://www.npmjs.com/package/websocket
and test it in console using
node index.js
var W3CWebSocket = require('websocket').w3cwebsocket; var client =
new W3CWebSocket('wss://127.0.0.1:7000/'); console.log(client)
We are facing a problem and I am sure this is the right place. We have a load balancer (cisco's) and for various reasons the SSL configuration on the load balancer (the server) side is set to use "SSLv3" protocol version. Now after setting the same, when I access the load balancer in CHROME browser, I am able to access the pages but I do see the below message when I click on their security icon.
"connection had to be retried using ssl 3.0" - I looked at the packet capture using wireshark and I see that browser tries TLSv1 and receives a "fatal alert" from the server saying "protocol_version" and then immediately browser tries SSLv3 version and finishes the handshake. So browser is able to negotiate this as a client.
However when I set up a stand alone java (tried using 1.6 as well as 1.7) client from eclipse and try connecting to the server I am getting the below exception.
: Received fatal alert: protocol_version javax.net.ssl.SSLException: Received fatal alert: protocol_version
As per various documentations, I saw two options I have
to set https.protocol system property to SSLv3. [this works for us, but the problem is it is affects the outbound SSL calls globally. I have another outbound SSL call to another server which does not work with SSLv3]
setEnabledprotocols() - this works as well but sometimes, we dont have access to the socket directly (sometime we generates stubs using third party and the stub takes care of the low level connection stuff, so no access to that socket).
But my actual question is, If by default TLSv1/SSLv3 and SSLv2Hello(just the format I believe) are enabled in java, why is JSSE implementation not able to negotiate like how chrome browser is able to negotiate. Is this expected? If browser is doing it, I believe it should be part of some SSL RFC and if that is the case, same functionality of this "negotiation" should be provided by java itself right?
I did go through this http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/SSLSocketImpl.java and was not able to find any part for this negotiation during handshake.
Is there a possibility of issue from the server side (load balancer) that i. I see that server sends fatal alert but that being cisco I believe the ssl implementation should be perfect and that is expected. Am I wrong?
Issue happens both in java 1.6 and 1.7. Do let me know if more information would be required to answer, will be happy to help.