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.
Related
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.
I have written a simple "Get" request in Delphi7 using the Indy10 TIdSNMP component but it returns an empty reply.
The target device's Agent doesn't support v1 SNMP so I have configured it for SNMP version 2c.
I know that the OID I am requestin is correct as I used a MIB Browser to obtain it from the same device using its MIB.
I vaguely recall seeing a comment on the forums that Indy 9 only supported SNMP version 1, so I am wondering that's still the case for Indy 10?
At this time, Indy 10 still does not support SNMP versions above v1. It is on the TODO list:
#56: Update TIdSNMP to support newer SNMP versions
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.
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
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.