SSLv2 in DirectAdmin API request calls

roman_m

roman_m

Verified User
Joined
May 5, 2005
Messages
192
Location
Ukraine, Kiev
Hello, DirectAdmin developers team!

I developed & maintain a set of free software for secondary DNS management called DirectSlave (my thread in forum is https://forum.directadmin.com/showthread.php?t=43924)
and I noticed that SSL calls inside of DirectAdmin, when calling external services, is still SSLv2 :(

For example, when DirectAdmin server send API call to my service on SSL port 2224, it originate SSLv2 handshake and not even try to upgrade it to SSLv3 nor the TLS1.x

DS code writen about 5 years ago in perl, and for Net::Server it's ok to accept SSLv2 connections, but not in 2017, where DROWNING and many more types of attack is possible on all SSLvX protocols. So I decide to rewrite it in golang. And this is what I see on my side, when using Multiserver Cluster setup with SSL:

2017/05/25 12:59:58 http: TLS handshake error from 91.194.2**.1**:46759: tls: unsupported SSLv2 handshake received

And there is no way to fix outgoing connections in directadmin.conf, I tried many of ssl_cipher, but this parameter only affects incoming connections to DirectAdmin webinterface itself, but not the outgoing.
I'm using
$ ./directadmin v
Version: DirectAdmin v.1.51.3 (which is actually 1.51.4-pre-release binary with Percona support)
on
FreeBSD 10.3-RELEASE-p11 #0: Mon Oct 24 18:49:24 UTC 2016 [email protected]:/usr/obj/usr/src/sys/GENERIC amd64
with
OpenSSL 1.0.1s-freebsd 1 Mar 2016

Can you please make outgoing connections TLSvX ready?

Thank you very much!
 
Last edited:
Hi Roman,

Thanks for the report.
Would you be able to create a ticket? Might be a bit of back-and-forth to confirm a fix, then we can follow up here again once it's sorted.
Shouldn't be too difficult to resolve, either way :)

Thanks!
John
 
I've done some poking, and added:
Code: 
CustomLog /var/log/httpd/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
to the 443 VH in /etc/httpd/conf/extra/httpd-vhost.conf,
and I'm getting:
Code: 
[27/May/2017:00:20:43 -0600] 1.2.3.4 [B]TLSv1[/B] DHE-RSA-AES128-SHA "GET /CMD_API_LOGIN_TEST HTTP/1.0" -
Reading up on the call DA makes to
Code: 
ssl_ctx = SSL_CTX_new(SSLv23_client_method());
which just tells SSL to use the newest protocol it can (the naming of v23 is just for backwards compatibility. TLS didn't exist yet). (Note, this is on an older CentOS 5 box, so ignore the fact that it's not TLSv12)

So to actually duplicate the step-down to get this in the apache log
Code: 
[27/May/2017:00:29:35 -0600] 1.2.3.4 SSLv3 DHE-RSA-AES128-SHA "GET /CMD_API_LOGIN_TEST HTTP/1.0" -
I had to actively shut off TLS in apache by using:
Code: 
SSLProtocol SSLv3
in the /etc/httpd/conf/extra/httpd-ssl.conf.

I have changed DA to not use SSLv2 or SSLv3 anymore for outbound requests, but I think the bigger issue in your case is why the SSL negotiation to use TLSv1 didn't go through.
OpenSSL will negotiate to use the highest possible protocol.... so the fact I've currently shut off the SSLv2/SSLv3, this might have actually broken your connection if your DirectSlave server doesn't support TLSv1....
Just a guess at the moment.

To test this theory, I'm uploading the new pre-release binaries which have SSLv2/SSLv3 fully disabled for outbound calls, eg:
Code: 
SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION);
so give them a try to see what that does in your case. If it doesn't give us what we want, still create the ticket, as mentioned above, so we can see what's actually going on.

Also try connecting to your server with a browser (eg: Chrome) to see which protocol the browser is using.
Chrome is a quick and easy way to do a basic evaluation of the DirectSlaves server's SSL protocols.

John
 
Hello, John! Thank you very much, again :)

I conducted a thorough investigation of this problem and found that the problem only occurs on a statically linked DA version 1.51.3 for FreeBSD 9.1. I'm sorry if it looks slightly confusing, my testing server running FreeBSD 10.3, but installed DA binary was

$ ./directadmin -v ; file directadmin
Version: DirectAdmin v.1.51.3
directadmin: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 9.1, not stripped

This error does not occurs at same FreeBSD box with dinamically linked DA for FreeBSD 11. So I think this error is only produced by statically linked binary for FreeBSD 9.x, may be linked against old libssl version, or you just leaved it for backwards compatibility with too old DA versions. I understand it, one of my boxes is FreeBSD 8 - too old, but too much users with productive sites on it and no way to up it to 10 or 11.

So, another questin is follows: can I have a new statically linked binary for FreeBSD 9.х with SSLv2 disabled (because no libc++.so.1 in FreeBSD 9)?

>Also try connecting to your server with a browser (eg: Chrome) to see which protocol the browser is using.
>Chrome is a quick and easy way to do a basic evaluation of the DirectSlaves server's SSL protocols.
Of course I know it ^_^ Better way is to use openssl binary as a s_client.
I'm already done all the tests I can about TLS & SSL support in DS binary and this is strong TLSv12 support. Also, no support for SSLv2 in golang 1.8.

Thank you for all the support, again and again!
Great job, great software, great you! :)
 
Hi Roman!

Thanks for the feedback.
Try now, it should be uploaded.

The updated file should be:
-rw-r--r--. 1 root root 8028575 May 28 00:08 packed_freebsd91_64.tar.gz
with md5sum 7a3c55f34b1e77c5c1c4bda164394e3d.
Code: 
root@freebsd9-64:/usr/local/directadmin # ./directadmin oCompiled on 'FreeBSD 9.1 64-bit'
Compile time: May 28 2017 at 00:08:15
Compiled with IPv6
root@freebsd9-64:/usr/local/directadmin # ldd directadmin
ldd: directadmin: not a dynamic ELF executable


John
 
Hello, John,

Everything all right now!

128.0.1**.2** DirectSlave GO/3.0 beta connection OK.

Just great work!
Thank you!
 
You must log in or register to reply here.
Back
Top