ntlmrelayx: socket ssl wrapping error

[dtrizna]

Hi!

I'm facing the issue when using relay for LDAPs traffic.
Whole exception with -debug flug:

[-] Exception in HTTP request handler: ('unable to open socket', [(LDAPSocketOpenError('socket ssl wrapping error: [Errno 104] Connection reset by peer',), ('A.B.C.D', 636))]) [+] Traceback (most recent call last): File "build/bdist.linux-x86_64/egg/impacket/examples/ntlmrelayx/servers/httprelayserver.py", line 72, in handle_one_request SimpleHTTPServer.SimpleHTTPRequestHandler.handle_one_request(self) File "/usr/lib/python2.7/BaseHTTPServer.py", line 328, in handle_one_request method() File "build/bdist.linux-x86_64/egg/impacket/examples/ntlmrelayx/servers/httprelayserver.py", line 193, in do_GET if not self.do_ntlm_negotiate(token, proxy=proxy): File "build/bdist.linux-x86_64/egg/impacket/examples/ntlmrelayx/servers/httprelayserver.py", line 261, in do_ntlm_negotiate if not self.client.initConnection(): File "build/bdist.linux-x86_64/egg/impacket/examples/ntlmrelayx/clients/ldaprelayclient.py", line 144, in initConnection self.session.open(False) File "/usr/local/lib/python2.7/dist-packages/ldap3/strategy/sync.py", line 56, in open BaseStrategy.open(self, reset_usage, read_server_info) File "/usr/local/lib/python2.7/dist-packages/ldap3/strategy/base.py", line 147, in open raise LDAPSocketOpenError('unable to open socket', exception_history) LDAPSocketOpenError: ('unable to open socket', [(LDAPSocketOpenError('socket ssl wrapping error: [Errno 104] Connection reset by peer',), ('A.B.C.D', 636))])

System:

• Python 2.7.15+
• up to date Kali
• up to date impacket
• ldap3 tested both 2.5.1 and 2.5.2

Same problem was slightly touched in #514, where @dirkjanm mentioned:

(..) it has something to do with whether the SSL certificates are set correctly on the server. Usually targeting another DC worked

I have access to ~12 AD systems (2012 R2 and 2016), targeting any of them results into this error.
Connections using ldp.exe works well (along with many production calls to some of ADs):

LDAP signing not enabled:

Behavior is that LDAPs service RST connection just after TLS hello is received:

So this is not caused by ntlmrelayx not trusting LDAPs sertificate - it's about LDAPs refusing this TLS hello packet.

Any ideas?

[dtrizna]

One key difference I noticed between request made by ldap3 and by f.e. ldp.exe, is timestamp here and TLS version here:

This is screen from failed TLS hello message. Valid authentication uses TLSv1.2 and correct timestamp, whilst ntlmrelayx generates for every TLS session kinda random starting from year 1996 up to 2072.

I've tried to investigate where this settings can be tuned, by modifying some aspects of this Class https://github.com/SecureAuthCorp/impacket/blob/master/impacket/examples/ntlmrelayx/clients/ldaprelayclient.py#L141 with no success.

[dirkjanm]

Good analysis! I can't reproduce it locally (maybe i'd have to play with which ciphers are accepted by the DC) but the TLS logic of LDAP3 is here:
https://github.com/cannatag/ldap3/blob/master/ldap3/core/tls.py
Maybe it will help you in the right direction.

[dirkjanm]

Can you check what the algorithmIdentifier is that your server is sending when you connect with ldp.exe? Reading around a bit suggests this could be a certificate signing option that is not supported by your version of openssl/python.

[dtrizna]

Hi, @dirkjanm!
Thanks for reference to tls logics, will try to find a way to tune timestamp there.

I see algorithmIdentifier under the server's certificate, is that right?
It's Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

Any ideas about that?

[hausec]

Also having this issue. I'm able to connect via ldp.exe over 636, however get a 104 reset from ntlmrelayx. Looking on the DC event log shows two relevant alerts:

• A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205.

• An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

My openssl library is 1.1.1a

[dirkjanm]

If anyone can look what ciphers the python client supports (in the Client Hello package) and what the server offers (in the Server Hello of the working ldp.exe) I can try to replicate it and maybe figure out if this is purely related to openssl or with how python interacts with it.

[hausec]

So this is definitely just related to Kali. It works fine on Ubuntu 18 & 16.

• Then of course, getST.py doesn't work with Ubuntu out of the box but does with Kali. Didn't really feel like trouble shooting but I was getting
  [Errno Connection error (LAB.LOCAL:88)] [Errno -2] Name or service not known. Separate issue though, I'll open another issue if I can't get it working.

[dirkjanm]

* Then of course, getST.py doesn't work with Ubuntu out of the box but does with Kali. Didn't really feel like trouble shooting but I was getting
  [Errno Connection error (LAB.LOCAL:88)] [Errno -2] Name or service not known. Separate issue though, I'll open another issue if I can't get it working.

That sounds like avahi messing up resolving for .local domains.
apt-get purge avahi-daemon to fix

[dtrizna]

@hausec , unfortunately for me with Ubuntu 18.04.2 situation is the same:

Will try to dig deeper on cipher question after a while.

[xianyuzailushang]

ubuntu 16.04
windows server 2012
Also encountered this problem

[l3m0n]

ubuntu 18.04
windows 2008 r2

[dirkjanm]

If anyone could share a PCAP of this error and also include how a working connection (using for example ldp.exe on Windows) looks, it would be very useful for debugging this.

[l3m0n]

ubuntu 18.04
windows 2008 r2

I solved the problem, Because I forgot to open ladps over SSL.

Enable LDAP over SSL (LDAPS) for Microsoft Active Directory servers

Finally, I succeeded on Windows 2012 and Windows 7.
Thank you.

[iambooker]

The solution that was posted by @l3m0n also worked for me! It seems that the LDAP over SSL was not enabled/properly configured in the DC.

[asolino]

Is the solution proposed by @l3m0n working for you all? What about @dtrizna?

[dtrizna]

Hi @asolino!

Sorry for late answer!
@l3m0n described a bit different situation, simply ntlmrelayx exception was the same.
In that case problem was with LDAPS setup initially - SSL/TLS there didn't worked at all as I understand.

Unfortunately this does not apply to initial description, here is the case with some prod servers as well that run LDAPS successfully in field (which was confirmed with ldp.exe over SSL in initial post)...

Still looks as case of TLS values problem in ntlmrelayx's Hello packet.
I can confirm that TLS ciphers are overlapping in failed and successful Hello packet, so this shouldn't be the case.
Presumably the key thing is that there's random time in ntlmrelayx's TLS Client Hello packet that is discarded by our LDAP (good boy, ldap!). I see that both on Kali and Ubuntu 18.04 so assume that it's tool, not environment specific:

Hope to find some time to dig further and tune ldap3 TLS time settings. Not sure when though.
If anyone here can verify why time in ntlmrelayx's Hello packet is incorrect - it would be useful.

[T3KX]

I am experiencing the same thing here
Kali 2019.2 , impacket V0.9.20-dev

I can confirm that it was working on impacket v0.19 , on the same DC

[skorov]

I did some experimenting with this bug tonight. I get the same results as a lot of people in this thread: Error relaying to LDAPS on a brand new DC.
What "fixed" it for me, was adding the CA role to the DC. This creates a certificate for the LDAPS server to use (after restarting the server).

@dirkjanm: In your lab, did you setup your DC to be a CA? If so, that might explain why it works in your lab but not others.

I guess what I'm still unsure about is how I can join other servers to the domain without a working LDAPS server... Correct me if I'm wrong, but isn't LDAPS required to add computer accounts to the DC?

[dirkjanm]

Yes you do need to have a valid certificate to use LDAPS, which gets automatically added when you add the CA role to the DC. Otherwise LDAPS will not work and will immediately reset the connection (both with impacket and with ldp.exe).
As far as I know, Windows does not use LDAPS for anything, it uses plain LDAP with integrity, which means traffic is encrypted with GSSAPI.

[skorov]

That makes sense. Wouldn't it then be possible to get ntlmrelayx to do the same thing? Using LDAP with integrity for the --add-computer switch?

[dirkjanm]

It is but the encryption key for this is derived from (I think) the encrypted session key which is encrypted based on the password during authentication, so you don't have this key if you're relaying. I'd have to look up the exact details. With LDAPs the encryption is done separate from the authentication so this isn't a problem when relaying, but it isn't always configured.

[mpgn]

EDIT solution here -> #581 (comment)

Hello @dirkjanm @hausec

I did a bit of debugging because I had the same error has everyone :

[-] Connection against target ldaps://demo.local FAILED: ('unable to open socket', [(LDAPSocketOpenError('socket ssl wrapping error: [Errno 104] Connection reset by peer',), ('172.16.60.205', 636))])

What I found is that the problem is not related to impacket but the openssl version installed in Kali.

Let's check:

Kali testing, I check if LDAPS is working:

root@kali:~# curl -vk ldaps://demo.local 
*   Trying 172.16.60.205:636...
* TCP_NODELAY set
* Connected to demo.local (172.16.60.205) port 636 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to demo.local:636 
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to demo.local:636 

root@kali:~# openssl
OpenSSL> version
OpenSSL 1.1.1d  10 Sep 2019
OpenSSL> exit

Maybe related to openssl version installed in Kali ? openssl/openssl#9566 (comment)

I've tested on my laptop with an older version of openssl =>

⋊> ~/T/ on master ⨯ openssl                                                                          
OpenSSL> version
OpenSSL 1.1.1  11 Sep 2018
OpenSSL> 

And this is where the magic happens =>

⋊> ~/T/Responder on master ⨯ curl -k ldaps://demo.local                                                       
* Rebuilt URL to: ldaps://demo.local/
*   Trying 172.16.60.205...
* TCP_NODELAY set
* Connected to demo.local (172.16.60.205) port 636 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384
* Server certificate:
*  subject: CN=DEMO-DC.demo.local
*  start date: Jan 29 13:45:50 2020 GMT
*  expire date: Jan 28 13:45:50 2021 GMT
*  issuer: DC=local; DC=demo; CN=demo-DEMO-DC-CA
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* LDAP local: ldaps://demo.local/
DN: 
	currentTime: 20200129152203.0Z

	subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=demo,DC=local

With an older version of openssl I can use the LDAPS service of my AD.
I can use ntlmrelayx with ldaps service on my local computer !!!

---

How did I generate my certificate ? Well I've just use the Active Directory Certificates Services and click Next Next Next all the time without touching anything.

Then I simply restart the AD and check if the certificat was on the Personal Certificat (local computer)

Then using LDP.exe I was able to connect to the LDAPS service on port 636

But using Kali, I cannot connect to LDAPS with openssl v1.1.1d (sep 2019) but only with openssl 1.11.1 (sep 2018)

Hope it helps ! :)

---

EDIT Further debugging on Kali

root@kali:~# openssl s_client -connect demo.local:636 
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 302 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
root@kali:~# 

But with option TLS1_1

root@kali:~# openssl s_client -connect demo.local:636 -tls1_1
CONNECTED(00000003)
depth=0 CN = DEMO-DC.demo.local
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = DEMO-DC.demo.local
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:CN = DEMO-DC.demo.local
   i:DC = local, DC = demo, CN = demo-DEMO-DC-CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF4zCCBMugAwIBAgITQwAAAAKO1sbNSCoO0gAAAAAAAjANBgkqhkiG9w0BAQUF
ADBHMRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFDASBgoJkiaJk/IsZAEZFgRkZW1v
MRgwFgYDVQQDEw9kZW1vLURFTU8tREMtQ0EwHhcNMjAwMTI5MTM0NTUwWhcNMjEw
MTI4MTM0NTUwWjAdMRswGQYDVQQDExJERU1PLURDLmRlbW8ubG9jYWwwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCXBhIZ85WcPB1qt4xTM9nK6uYlI8kR
UBNDstBebtsn9SMj07JuyOusphzF4jUVu5FqaLsWLYAwaS19sOtcfyf6cLH66bHD
YLDHdTqzr6bQcuYAaGM/hTTkTAHI31//Lszv06gmD012ntrx/EG+5Eg9PVhNogSu
kWCcZC9nR3CmaHBJ3PqWh8nwEbSIF7d8U/DghKYpTSTdeWURX1KWklHX9tmRn1t/
gGsefIsyPiMN5us/VBAFZUC79umc+3kNkjzjpOb/4uGDZnciDjJ2aWO6nBeS/8oG
CLm+DyBLlTbTj3pEsDk5V+SIu9iZruGiB85IeSd+YyaPOd2Q8RG5XOx1AgMBAAGj
ggLwMIIC7DAvBgkrBgEEAYI3FAIEIh4gAEQAbwBtAGEAaQBuAEMAbwBuAHQAcgBv
AGwAbABlAHIwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMA4GA1UdDwEB
/wQEAwIFoDB4BgkqhkiG9w0BCQ8EazBpMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG
9w0DBAICAIAwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQMEAQIw
CwYJYIZIAWUDBAEFMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBS78Vzd
VDRcKFxIHyHNdVgmVkG9PjAfBgNVHSMEGDAWgBS78AtERJebqsL6Fv4xuU/tQpLl
1DCBzAYDVR0fBIHEMIHBMIG+oIG7oIG4hoG1bGRhcDovLy9DTj1kZW1vLURFTU8t
REMtQ0EsQ049REVNTy1EQyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2Vydmlj
ZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1kZW1vLERDPWxvY2Fs
P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxE
aXN0cmlidXRpb25Qb2ludDCBwAYIKwYBBQUHAQEEgbMwgbAwga0GCCsGAQUFBzAC
hoGgbGRhcDovLy9DTj1kZW1vLURFTU8tREMtQ0EsQ049QUlBLENOPVB1YmxpYyUy
MEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9
ZGVtbyxEQz1sb2NhbD9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2Vy
dGlmaWNhdGlvbkF1dGhvcml0eTA+BgNVHREENzA1oB8GCSsGAQQBgjcZAaASBBC8
Zt8j3CHpSL9aFdGfnHolghJERU1PLURDLmRlbW8ubG9jYWwwDQYJKoZIhvcNAQEF
BQADggEBAHfjbmAKiu1FSQSkdi89qFf1gb/H4DlaUVuXQuBgo9HcoPW3kWQ14TP0
pROGjGWFPQMnH7n1orCg7Pki6j2SKQO8fcm/ZOM+2B4CItsaNKiN93GDu3BOtBbQ
/LK9+VIF9AZa9eY1C0qGdMqvGkOaxwGlY+C1FqbPCfBIihjaVcvgV5o1sE7AGGrq
sL62pGfOVfPL34qtYDcftm+2JMohiQLMaGVvQ77Aea2oRPcuT9THVv+uq4Ur24cg
CkEZScLj9lzJOw8EQYdSfrfc+1czamzQCJea+P+aUFa+rhhwZ2PnWHvGoHsnoHcn
AfatiTdFngiRar37GKm5p52KHaBlLwg=
-----END CERTIFICATE-----
subject=CN = DEMO-DC.demo.local

issuer=DC = local, DC = demo, CN = demo-DEMO-DC-CA

---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Peer signing digest: MD5-SHA1
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2027 bytes and written 285 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.0, 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.1
    Cipher    : ECDHE-RSA-AES256-SHA
    Session-ID: AC0E0000D41E956FA4A36E4C2A40AEA0B361540D2EB774836B8624CB662BEBCD
    Session-ID-ctx: 
    Master-Key: 07ABE7792DF8F07C9CBB4CC2A35BB4B6D478FA0F3FA8118BAF3E43E28C23D217DF8FC2FB3B7B174E0F199C06D67552B0
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1580379026
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: no
---

Full ntlmrelay stacktrace:

root@kali:~# ntlmrelayx.py -t ldaps://demo.local --no-acl -debug
Impacket v0.9.20-dev - Copyright 2019 SecureAuth Corporation

[*] Protocol Client SMB loaded..
[*] Protocol Client SMTP loaded..
[*] Protocol Client MSSQL loaded..
[*] Protocol Client HTTPS loaded..
[*] Protocol Client HTTP loaded..
[*] Protocol Client IMAP loaded..
[*] Protocol Client IMAPS loaded..
[*] Protocol Client LDAPS loaded..
[*] Protocol Client LDAP loaded..
[+] Protocol Attack SMB loaded..
[+] Protocol Attack MSSQL loaded..
[+] Protocol Attack LDAP loaded..
[+] Protocol Attack LDAPS loaded..
[+] Protocol Attack IMAP loaded..
[+] Protocol Attack IMAPS loaded..
[+] Protocol Attack HTTP loaded..
[+] Protocol Attack HTTPS loaded..
[*] Running in relay mode to single host
[*] Setting up SMB Server
[*] Setting up HTTP Server

[*] Servers started, waiting for connections
[*] SMBD-Thread-3: Received connection from 172.16.60.177, attacking target ldaps://demo.local
[-] Connection against target ldaps://demo.local FAILED: ('unable to open socket', [(LDAPSocketOpenError('socket ssl wrapping error: [Errno 104] Connection reset by peer',), ('172.16.60.205', 636))])
[*] HTTPD: Received connection from 172.16.60.177, attacking target ldaps://demo.local
[*] HTTPD: Client requested path: /
[*] HTTPD: Client requested path: /
[*] HTTPD: Received connection from 172.16.60.177, attacking target ldaps://demo.local
[*] HTTPD: Client requested path: /
[+] Exception:
Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/impacket/examples/ntlmrelayx/servers/httprelayserver.py", line 72, in handle_one_request
    http.server.SimpleHTTPRequestHandler.handle_one_request(self)
  File "/usr/lib/python2.7/BaseHTTPServer.py", line 325, in handle_one_request
    self.send_error(501, "Unsupported method (%r)" % self.command)
  File "build/bdist.linux-x86_64/egg/impacket/examples/ntlmrelayx/servers/httprelayserver.py", line 84, in send_error
    return self.do_GET()
  File "build/bdist.linux-x86_64/egg/impacket/examples/ntlmrelayx/servers/httprelayserver.py", line 198, in do_GET
    if not self.do_ntlm_negotiate(token, proxy=proxy):
  File "build/bdist.linux-x86_64/egg/impacket/examples/ntlmrelayx/servers/httprelayserver.py", line 266, in do_ntlm_negotiate
    if not self.client.initConnection():
  File "build/bdist.linux-x86_64/egg/impacket/examples/ntlmrelayx/clients/ldaprelayclient.py", line 144, in initConnection
    self.session.open(False)
  File "/usr/local/lib/python2.7/dist-packages/ldap3/strategy/sync.py", line 56, in open
    BaseStrategy.open(self, reset_usage, read_server_info)
  File "/usr/local/lib/python2.7/dist-packages/ldap3/strategy/base.py", line 147, in open
    raise LDAPSocketOpenError('unable to open socket', exception_history)
LDAPSocketOpenError: ('unable to open socket', [(LDAPSocketOpenError('socket ssl wrapping error: [Errno 104] Connection reset by peer',), ('172.16.60.205', 636))])
[-] Exception in HTTP request handler: ('unable to open socket', [(LDAPSocketOpenError('socket ssl wrapping error: [Errno 104] Connection reset by peer',), ('172.16.60.205', 636))])
[*] HTTPD: Received connection from 172.16.60.177, attacking target ldaps://demo.local

EDIT AGAIN

I remove the version 1.1.1d of openssl and install an old one : 1.1.1 (sep 2018) and everything is working fine on my side :)

[0xdeaddood]

Great explanation @mpgn. I had the same issue and resolved it downgrading the version of OpenSSL from 1.1.1c (May 2019) to 1.1.1 (Sep 2018).

[jgilgan]

How did you accomplish the downgrade without destroying all dependencies? I have same issue with ntlmrelayx (even after upgrade to version 3 of openssl)

Soooo guys I think I know why the connection does not establish. In openssl > 1.1.1 the default setting for TLS was changed to TLSv1.2 in openssl.cnf. This is reproducable!

open /etc/ssl/openssl.cnf
look for section [system_default_sect]
change MinProtocol = TLSv1.2
to MinProtocol = TLSv1.0

That did work for me to get it running!

[mpgn]

Nice catch @Sateng ! looks better than downgrading openssl 💯

[moj0-bf]

Man - I ran into this same thing on another project and it completely slipped my mind while troubleshooting this one! Thank you @Sateng !

[mpgn]

Hello @asolino I think you can close this issue :)

[n00py]

Nice catch @Sateng ! looks better than downgrading openssl 💯

Is there a deleted comment here? I really was enjoying this thread and then the solution seems to be missing

[0xdeaddood]

Hi @n00py!

The solution is in the previous comment (modify the config file):

How did you accomplish the downgrade without destroying all dependencies? I have same issue with ntlmrelayx (even after upgrade to version 3 of openssl)

Soooo guys I think I know why the connection does not establish. In openssl > 1.1.1 the default setting for TLS was changed to TLSv1.2 in openssl.cnf. This is reproducable!

open /etc/ssl/openssl.cnf
look for section [system_default_sect]
change MinProtocol = TLSv1.2
to MinProtocol = TLSv1.0

That did work for me to get it running!

I think there was a username change...