socket.io 1.1 - connecting - socket.io

Migrating from 0.9 to 1.1.
In our previous version we were checking to see if socket was connecting using socket.socket.connecting.
What would be the equivalent of this for 1.1? Connecting seems to no longer be present.
Thank-you

Related

The recommended protocol version is TLS 1.2 and later. -- - - - Migration Update-database Error

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?

Mosquitto no websocket connection since version 02.0.12 (Windows specific)

today I wanted to set up a simple mosquitto server on my windows machine for testing.
I am using "MQTT Explorer" for convenience and downloaded the latest 2.0.14 mosquitto binaries for windows (I am using Windows 10).
However I am unable to connect to my local server with Mosquitto 2.0.14, 2.0.13 and 2.0.12.
My connection is successful with 2.0.11, 2.0.10, 2.0.9a and 2.0.7 but these versions only work when I also have a standard http listener in the config (which I do not want since later on I only want one wss listener).
This is the config I am using:
allow_anonymous true
#HTTP listener
listener 1883
#Websocket standard listener
listener 9001
protocol websockets
This is the server output I get when using 2.0.14, 2.0.13 or 2.0.12 after my connection failed:
And this is the output when using 2.0.11, 2.0.10, 2.0.9a or 2.0.7 but without the http listener in the config:
Can anyone reproduce this behaviour or tell me where I messed up?
As per the comments I was able to duplicate the issue with Mosquitto 2.0.14 and an issue has been raised.
A workaround is to add socket_domain ipv4 into the configuration - e.g.
allow_anonymous true
listener 9001
protocol websockets
socket_domain ipv4
I came across option in this issue and it does appear to fix the issue. Note that I have not looked into why this fixes the issue so this should be considered a temporary workaround until the issue mentioned above is updated.

gSOAP throws SSLv3 alert handshake failure

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.

SOCKS Protocol Version prior to SOCKS4

I saw SOCKS protocol have the version 4 and version 5, which can be referenced from:
https://www.rfc-editor.org/rfc/rfc1928
http://www.openssh.com/txt/socks4.protocol
My question is:
Does SOCKS exist version 1 , version 2 or version 3 prior to version 4(SOCKS4)?
Yes, there were earlier versions of SOCKS prior to version 4, as evident by the following comment in the SOCKS v4 protocol spec:
http://ftp.icm.edu.pl/packages/socks/socks4/SOCKS4.protocol
SOCKS was originally developed by David Koblas and subsequently modified
and extended by me to its current running version -- version 4.
This is also mentioned in QNX's SOCKS reference:
http://www.qnx.com/developers/docs/6.5.0/topic/com.qnx.doc.neutrino_lib_ref/socksappendix.html
The original SOCKS was written by David Koblas (koblas#netcom.com). The SOCKS protocol has changed over time. The client library shipped as of printing corresponds to SOCKS v4.2. Since the server and the clients must use the same SOCKS protocol, this library doesn't work with servers of previous releases; clients compiled with these libraries won't work with older servers.
And no, you don't need to bother worrying about those earlier versions, as nobody actually uses them anymore. SOCKS4 is the minimum version still in use, though SOCKS4A and SOCKS5 are preferred.

Is it possible to enable TLS v1.2 in Ruby? If so, how?

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.

Resources