DDNS: "Unable to establish SSL connection"

[Island]

We've used the dynamic DNS routine in FREESCO for several years, first with DynDNS but, when they removed their free service, we used a DDNS update service provided for a domain we own, using a modified version of the FREESCO DDNS client which Lewis kindly altered to use a DDNS API provided by the DNS hosting service we use, GratisDNS. One of the changes was to employ 'wget' to operate the https command to update the DNS record, and the background to the changes can be found on an older thread, here,
viewtopic.php?f=40&t=17696

That has worked well for a year or so but recently the dynamic updates have failed; the log reports

Code: Select all

unsupported: failed to update '1.2.3.4'  # obfuscated

Directly running the wget command (which is part of the modified script) at a shell prompt gives:

Code: Select all

[root@freesco] wget https://ssl.gratisdns.dk/ddns.phtml?u=<username>&p=<pword>&d=<ourdomain>&h=<theddnshost>&i=127.0.0.1
[root@ freesco] --15:20:14--  https://ssl.gratisdns.dk/ddns.phtml?u=******
           => `ddns.phtml?u=******'
Resolving ssl.gratisdns.dk... 91.221.196.4
Connecting to ssl.gratisdns.dk[91.221.196.4]:443... connected.

Unable to establish SSL connection.

Unable to establish SSL connection.

# and hangs, requiring a CTRL-C to release

[1] 13137 Exit 0              wget https://ssl.gratisdns.dk/ddns.phtml?u=***...
[root@freesco]


The DNS provider now also happens to provide its own script (https://github.com/lsim/gratisddns/blob ... tisddns.sh) for client update. Reading through that, the https command still looks to be the same as we're already using in the FREESCO DDNS script. So I don't think anything has changed in the API, and nothing has changed in our FREESCO (I've rechecked the 'setup'). I also used the https command in a current vesion of Firefox, and the DDNS response page was the text 'OK'; the DNS record for that host now has '127.0.0.1', illustrating that the https command indeed worked. Firefox reports the SSL connection:

Code: Select all

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys, TLS 1.2


I was thinking about the failure to make an SSL connection. I wonder if GratisDNS may be dropping support for TLS lower than TLS 1.1 (many sites are, now).

How could I check which TLS versions are supported in our current FREESCO build?

This particular FREESCO runs 0.4.2, and we are using the openssl package openssl-0.9.7e-lightning .

Regards, Island

[Lightning]

The current version of wget does not support TLS 1.2 and I am not positive it even supports 1.1
According to the wget source you have to have at least version 1.16.1 before TLS 1.2 is supported. So I downloaded the source for 1.17 and tried to compile it. Unfortunately it requires gnutls to compile, so I downloaded gnutls and tried to configure it and it requires libnettle 3.1 to compile. So I downloaded nettle 3.1 and it configured fine, but failed to compile with a multitude of compile errors.

At least part of the problem is the version of gcc installed on my development machine, which it is required to keep version 2.7.3 on this machine to compile kernels. However I have a Zipslack machine that I should be able to update the gcc to at least a 3.x and try to compile these various aplications on. But it will take me a while before I have enough time to get this all sorted out.

Unfortunately I don't have a good solution to your problem at the moment. However I also used to use dyndns and changed to http://freedns.afraid.org/ when dyndns wanted to charge me for my domains. However if you own your own domain and want to keep it strictly a private domain it does require a premium account, although if you want to share your domain with others it is still free. Unless of course like me you make a deal with the owner of afraid.org offer free advertising on the FREESCO web sites in exchange for a premium account.

[Island]

The current version of wget does not support TLS 1.2 and I am not positive it even supports 1.1

I was guessing about the TLS version but I've done a bit more testing and it seems as though that might be the issue. The DNS provider declines an SSLv3 handshake. Further, the wget version on my 0.4.2 FREESCO does not support the TLSv1 proocol option, exactly as you said. Here's the trial result

Code: Select all

[root@freesco] wget -d https://ssl.gratisdns.dk/ddns.phtml?u=<obfuscated>&i=127.0.0.1
[root@freesco] DEBUG output created by Wget 1.9.1 on linux-gnulibc1.

--13:07:10--  https://ssl.gratisdns.dk/ddns.phtml?u=******
           => `ddns.phtml?u=******'
Resolving ssl.gratisdns.dk... 91.221.196.4
Caching ssl.gratisdns.dk => 91.221.196.4
Connecting to ssl.gratisdns.dk[91.221.196.4]:443... connected.
Created socket 3.
Releasing 0x81165b0 (new refcount 1).
OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

Unable to establish SSL connection.
Closing fd 3

Unable to establish SSL connection.

[1] 6376 Exit 0               wget -d https://ssl.gratisdns.dk/ddns.phtml?u=...

# SSLv3 fails, so
# trying with TLSv1 specified

[root@freesco] wget --secure-protocol=TLSv1 -d https://ssl.gratisdns.dk/ddns.phtml?u=<...>&i=127.0.0.1
[root@freesco] wget: unrecognized option `--secure-protocol=TLSv1'
Usage: wget [OPTION]... [URL]...

Try `wget --help' for more options.

[1] 6569 Exit 0               wget --secure-protocol=TLSv1 -d https://ssl.gr...
[root@freesco]


According to the wget source you have to have at least version 1.16.1 before TLS 1.2 is supported.

The man page for a different version of wget (1.13.4), on one of our Debian systems behind FREESCO, mentions the protocol selection option

Code: Select all

   HTTPS (SSL/TLS) Options
       To support encrypted HTTP (HTTPS) downloads, Wget must be compiled with
       an external SSL library, currently OpenSSL.  If Wget is compiled
       without SSL support, none of these options are available.

       --secure-protocol=protocol
           Choose the secure protocol to be used.  Legal values are auto,
           SSLv2, SSLv3, and TLSv1.  If auto is used, the SSL library is given
           the liberty of choosing the appropriate protocol automatically,
           which is achieved by sending an SSLv2 greeting and announcing
           support for SSLv3 and TLSv1.  This is the default.

           Specifying SSLv2, SSLv3, or TLSv1 forces the use of the
           corresponding protocol.  This is useful when talking to old and
           buggy SSL server implementations that make it hard for OpenSSL to
           choose the correct protocol version.  Fortunately, such servers are
           quite rare.


But (again, as you say), the version we are using probably doesn't support this option.

So I downloaded the source for 1.17 and tried to compile it. Unfortunately it requires gnutls to compile, so I downloaded gnutls and tried to configure it and it requires libnettle 3.1 to compile. So I downloaded nettle 3.1 and it configured fine, but failed to compile with a multitude of compile errors.

At least part of the problem is the version of gcc installed on my development machine, which it is required to keep version 2.7.3 on this machine to compile kernels. However I have a Zipslack machine that I should be able to update the gcc to at least a 3.x and try to compile these various aplications on. But it will take me a while before I have enough time to get this all sorted out.

Lewis, thank you for trying that, escpecially since it obviously developed into something more complicated.

In case 1.17 proves difficult to compile, I thought I'd try that wget version 1.13.4 we have on a server. Here's the result, with a litle debug output as well

Code: Select all

island@Server:~$ wget -d https://ssl.gratisdns.dk/ddns.phtml?u=<...>&i=127.0.0.1
[1] 3623
[2] 3624
[3] 3625
[4] 3626
island@Server:~$ DEBUG output created by Wget 1.13.4 on linux-gnu.

URI encoding = `UTF-8'
--2015-12-05 14:32:24--  https://ssl.gratisdns.dk/ddns.phtml?u=******
Resolving ssl.gratisdns.dk (ssl.gratisdns.dk)... 91.221.196.4
Caching ssl.gratisdns.dk => 91.221.196.4
Connecting to ssl.gratisdns.dk (ssl.gratisdns.dk)|91.221.196.4|:443... connected.
Created socket 4.
Releasing 0x0a0045b0 (new refcount 1).

---request begin---
GET /ddns.phtml?u=****** HTTP/1.1
User-Agent: Wget/1.13.4 (linux-gnu)
Accept: */*
Host: ssl.gratisdns.dk
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Date: Sat, 05 Dec 2015 14:32:27 CET
Content-Type: text/html; charset=ISO8859-1
Content-Length: 25
Connection: keep-alive
Server: Protected by COMODO WAF
X-Anycast-Location: here

---response end---
200 OK
Registered socket 4 for persistent reuse.
URI content encoding = `ISO8859-1'
Length: 25 [text/html]
Saving to: `ddns.phtml?u=******'

100%[======================================>] 25          --.-K/s   in 0s

2015-12-05 14:32:30 (8.50 MB/s) - `ddns.phtml?u=******' saved [25/25]

q
-bash: q: command not found
[1]   Done                    wget -d https://ssl.gratisdns.dk/ddns.phtml?u=******
[2]   Done                    p=<..>
[3]-  Done                    d=<..>
[4]+  Done                    h=<..>
island@Server:~$


The 'OK' response in HTTP means the DNS update transaction was successful.

We can take this hostname offline for a while. The FREESCO gateway sits on what is our alternate uplink and is used mostly during (temporary) failures of our primary link. (There are a couple of other minor uses of it.) If wget 1.17 proves too problematic, and even 1.13.4 (say) is too demanding on the toolchain or the kernel, then on our side we can look into running a DDNS script on a server behind this FREESCO (at the moment there isn't one gateway'd through this FREESCO box, though). It a wget upgrade worked out, it would be good to have a DDNS service on the box that could handle TLS for the updates, especially since the FREESCO box is the gateway server for that alternate link but, if it's not practical, I think we could cope. And, anyway, scheduling any sort of change is entirely up to you, as the dev so, please, don't let the issue be any burden. We're more than pleased with the FREESCO(s) we've got.

Thanks for the suggestion about freedns.afraid.org; I think I'd prefer to stay with GratisDNS because they look after our registration as well, and we can sort out a work-around for our situation, if needed.

regards, Island

[Lightning]

For the moment the latest version of wget that will compile is version 1.10.2
So I think it might be worth a try.

To install it use these commands

Code: Select all

cd /boot/bin
snarf  lewis.freesco.net/test/wget.gz
zcat  <wget.gz >wget
rm wget.gz
chmod +x wget


Here is the output of the "wget --help" http://lewis.freesco.net/test/wget.help
The big thing to note that was not in the older versions is these lines

HTTPS (SSL/TLS) options:
--secure-protocol=PR choose secure protocol, one of auto, SSLv2,
SSLv3, and TLSv1.

[Island]

For the moment the latest version of wget that will compile is version 1.10.2
So I think it might be worth a try.

...

Here is the output of the "wget --help" http://lewis.freesco.net/test/wget.help
The big thing to note that was not in the older versions is these lines

HTTPS (SSL/TLS) options:
--secure-protocol=PR choose secure protocol, one of auto, SSLv2,
SSLv3, and TLSv1.

Lewis, thank you for recompiling a newer version of wget. It's taken us forward, but we still seem to fail with, (very) oddly, an SSLv3 handshake failure. The new wget version does accept a "--secure-protocol=TLSv1" option but, despite this, seems to be offering an SSLv3 handshake, which the server rejects because SSLv3 is (probably) disallowed on the server side. I've found a clue, though.

Here's the log of our attempt with wget 1.10.2, also trying --no-check-certificate in case that had been an issue (it wasn't).

Code: Select all

[root@freesco] ./wget --no-check-certificate --secure-protocol=TLSv1 -d https://ssl.gratisdns.dk/ddns.phtml?u=<USER>&p=<pass>&d=<dmn>&h=<host>&i=127.0.0.1
[root@freesco] DEBUG output created by Wget 1.10.2 on linux-gnulibc1.

--14:13:00--  https://ssl.gratisdns.dk/ddns.phtml?u=<USER>
           => `ddns.phtml?u=<USER>'
Resolving ssl.gratisdns.dk... 91.221.196.4
Caching ssl.gratisdns.dk => 91.221.196.4
Connecting to ssl.gratisdns.dk|91.221.196.4|:443... connected.
Created socket 3.
Releasing 0x0811aae8 (new refcount 1).
Initiating SSL handshake.
SSL handshake failed.
OpenSSL: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
Closed fd 3
Unable to establish SSL connection.
q
q: No such file or directory
[1] 6059 Exit 2               ./wget --no-check-certificate --secure-protoco...
[root@freesco]


I also checked wget with --secure-protocol=tlsv1 (same result) and --secure-protocol=tlsv1_1 (which failed because tlsv1_1 wasn't a recognised protocol). Those tests confirmed that wget 1.10.2 is seeing the --secure-protocol option.

Yet, despite being asked to use TLSv1, wget is trying to set up an SSLv3 connection. Looking around, I found some comment on an open-bsd list engaging this issue:
http://openbsd-archive.7691.n7.nabble.c ... 59957.html

The gist of that exchange is that wget is asking openssl to use TLSv1, but openssl is using TLSv1.0 (which is SSLv3, actually) and not TLS1.1. As you can see, the postings cite parts of the openssl source they are using, and also discuss possible patches. In our case, although TLSv1 is flagged to wget, FREESCO is presenting an SSLv3 handshake. SSLv3 is TLS1.0 so we could also say that FREESCO is presenting a TLS1.0 handshake. The server is seeing FREESCO's handshake as SSLv3, and rejecting it. Does openssl in FREESCO perform the SSL link establishment for wget, in FREESCO? (Edit: Yes, looking at the log I posted, the SSL failure is reported by openssl.) If so, I wondered whether a similar issue might be occurring in the openssl version that we're using?

regards, Island

[Lightning]

I happen to have libssl.so.0.9.7 on my development machine. So I made a quick package out of it to try and see what happens.

Code: Select all

pkg -i http://lewis.freesco.net/test/ssl-0.9.7-lewis.pkg

If it has problems be aware that I did not test the package to make certain it will install, but I did include an uninstall for the library. Make certain to let it replace the existing ssl libraries on the system.

[Island]

I happen to have libssl.so.0.9.7 on my development machine. So I made a quick package out of it to try and see what happens.

Code: Select all

pkg -i http://lewis.freesco.net/test/ssl.0.9.7-lewis.pkg

If it has problems be aware that I did not test the package to make certain it will install, but I did include an uninstall for the library

Lewis, thank you I'm trying this. I'm not getting through the 'pkg' command, though. Here's the log:

Code: Select all

[root@freesco] pkg -i http://lewis.freesco.net/test/libssl.0.9.7-lewis.pkg

Installing...                                   libssl.0.9.7-lewis
ERROR: Not found using:
http://lewis.freesco.net/test/

Do you want to search globally for this package (y/n)? [n]
ERROR- file was not found. libssl.0.9.7-lewis.pkg
Installation aborted...

[root@freesco]


I think I've solved the pkg issue. Using a browser, the file in 'test' is named "ssl.0.9.7-lewis.pkg". Will it matter if the package file isn't called 'lib....'?

May I also ask, do I need to uninstall the existing openssl that we have? We're already using openssl-0.9.7e-lightning.

regards, Island

[Lightning]

The package name does not matter because the libraries are named correctly. It also won't matter if the other ssl package is installed or not, but if there is any issue you may need to reinstall the other 0.9.7e package again after removing this one.

However as I recall from years ago there was some sort of issue with the 0.9.7e specific library and on my own system I use the 0.9.6g version because of some sort of problem and I had removed the 0.9.7 package from my own system. Unfortunately the old package still remains on the main FREESCOsoft web site. The 0.9.7 version in the package however was just compiled, so it is a different library. If you still have issues even with the new library I would recommend installing the openssl-0.9.6g-lightning.pkg version and NOT install the old 0.9.7 version.

In reality even if you remove all of the openssl packages the libraries are still there. But depending on which one was last installed the links will not be pointed to the correct main library. The ones of importance are actually libssl.so.0, libssl.so and libcrypto.so, libcrypto.so.0 which are symlinks that point to the specific versions.

[Island]

The package name does not matter because the libraries are named correctly. It also won't matter if the other ssl package is installed or not, but if there is any issue you may need to reinstall the other 0.9.7e package again after removing this one.

Lewis, thank you for the clarification (and the info about how packages link up internally). As you earlier thought might happen, we have hit an install script problem. The package wants to install to "/bin/pkg" which doesn't exist. Am I ok to just create that directory and let it install there, or will that mess things up? Here're the last few lines of the log:

Code: Select all

Checking versions...                            Pv0.4.x
Checking required space 'disk'                  Ok
Checking dependencies...                        Ok
Checking if package is installed...             Ok
/bin/pkg: install: No such file or directory
Install this package (y/n)? [y]
Unpacking ssl-0.9.7-lewis.tgz ..                Done
Checking for library conflicts...               Done
/bin/pkg: /boot/22023~/install: No such file or directory
/bin/pkg: /boot/22023~/install: No such file or directory
Installation aborted...
[root@freesco]


Regards, Island

[Island]

The package wants to install to "/bin/pkg" which doesn't exist. Am I ok to just create that directory and let it install there, or will that mess things up?

I couldn't create a directory /bin/pkg, because in /bin there is already a (script?) file named 'pkg'.

I think I need to edit the install script, to install the devel openssl pkg somewhere else. I think I would have to save the .pkg file somewhere (I already have it, now, in /www/packages), expand it to reveal its install script, and change that. I don't know what to do to expand the .pkg file. I'd probably put it into a subdirectory ('testssl'), first, as well, so as not to crowd out the rest of the contents of /www/packages. Once expanded and its 'install' directory changed to something else, I'd expect to execute its modified install script from its place in /www/packages/testssl.

is there a way to expand the ssl-0.9.7-lewis.pkg file?

regards, Island

[Lightning]

If you have the "mc 4.6" package installed you can just hit "enter" on the file and it will open. Then highlight the .tgz file inside that file and go to the pkg/lib-pack directory and you will see the new libraries and the links. Just put the other side of the mc window in your /pkg/lib directory using the tab key and copy each of those files to that directory. When finished type "pkg -rescan" on a command line and you will have the new libraries.

If that still does not work for your update script install the 0.9.6g package and it will overwrite any of the modifications and you can try it with that ssl version.

The .pkg extension is in reality just a .tgz file with some extra things added in, so it is possible to just change the extension and uncompress it as a normal compressed tar file.

[Island]

If you have the "mc 4.6" package installed you can just hit "enter" on the file and it will open. Then highlight the .tgz file inside that file and go to the pkg/lib-pack directory and you will see the new libraries and the links. Just put the other side of the mc window in your /pkg/lib directory using the tab key and copy each of those files to that directory. When finished type "pkg -rescan" on a command line and you will have the new libraries.

Lewis, managed to copy those files across from the pkg file 'lib-pack' directory, choosing to 'overwrite' the target.

When I ran 'pkg rescan', FREESCO responded by going to the (internet) repositories and fetching the package list, asking me if I wanted to install each file, more or less on a 1 by 1 basis running through 156 files. Should I expect the 'pkg rescan' command to offer that? It seemed unexpected to me. The 'pkg rescan' file behaved this way whether I was in /pkg/lib direcory, or not. So I'm not sure it's updated its links properly. I checked with mc, and the links do point to libcrypto and libssl097 dated Aug 2008 so, maybe the rescan was ok.

The wget command with =TLSv1 failed again, using an SSLv3 handshake, which is what I would expect it to do either if 'pkg rescan' had not been able to update its ssl library links, or if the repackaged 0.9.7 still had the TLSv1 error which results in a TLSv0 (SSLv3) handshake.

I'll also try with the slightly older 0.9.6 package, as you suggest.

regards, Island

[Lightning]

When I ran 'pkg rescan', FREESCO responded by going to the (internet) repositories and fetching the package list, asking me if I wanted to install each file, more or less on a 1 by 1 basis running through 156 files. Should I expect the 'pkg rescan' command to offer that? It seemed unexpected to me. The 'pkg rescan' file behaved this way whether I was in /pkg/lib direcory, or not. So I'm not sure it's updated its links properly. I checked with mc, and the links do point to libcrypto and libssl097 dated Aug 2008 so, maybe the rescan was ok.

Use "pkg -rescan" (the dash is critical) and it should just come back quickly with no responses at all. The directory it effects is the /lib directory. However because you were already running 0.9.7 it probably didn't make a difference.

[Island]

Use "pkg -rescan" (the dash is critical).

So it is, Lewis, sorry about that.

Well I've installed and uninstalled and re-installed all 3 packages this morning, and they all give the same result, where GratisDNS (our domain DNS provider) rejects the SSL handshake because it is using SSLv3.

I think this means:

(i) We have a dyndns script in FEESCO that will try to make TLSv1 connections for dynamic DNS updates
(ii) We have a WGET version that appears to accept being told to ask openssl to use a TLSv1 connection
(iii) openssl v0.9.7e results in TLSv1 connection requests being made as SSLv3

Actually, it's not clear that the problem is in openssl, or in wget. Looking very closely at that open-bsd dialogue, the posting that notes a cause implies that the issue is a problem in wget, where wget is issuing a request for TLSv0, and noting that the problem changes between wget v1.15, and v1.16 (neither of which will compile for FREESCO, anyway). Here's the relevant part of that posting

Code: Select all

Hmm, I'm not sure.  Here's the diff between wget-1.15 and wget-1.16:

--8<--
   switch (opt.secure_protocol)
     {
-    case secure_protocol_auto:
-      meth = SSLv23_client_method ();
-      break;
 #ifndef OPENSSL_NO_SSL2
     case secure_protocol_sslv2:
       meth = SSLv2_client_method ();
       break;
 #endif
     case secure_protocol_sslv3:
       meth = SSLv3_client_method ();
       break;
+    case secure_protocol_auto:
     case secure_protocol_pfs:
     case secure_protocol_tlsv1:
       meth = TLSv1_client_method ();
       break;
+#if OPENSSL_VERSION_NUMBER >= 0x01001000
+    case secure_protocol_tlsv1_1:
+      meth = TLSv1_1_client_method ();
+      break;
+    case secure_protocol_tlsv1_2:
+      meth = TLSv1_2_client_method ();
+      break;
+#endif
     default:
       abort ();
     }
-->8--

TLSv1_client_method() forces the use of TLSv1.0 only.  oops.

  wget --secure-protocol=tlsv1_2 --debug -O /dev/null \
    https://www.secure.io/

works fine, --secure-protocol=tlsv1_1 fails (appropriately according to
the OP's nginx config).

where unless the caller asks for "TLSv1_1" (or _2), the client gets TLSv0, so TLSv1 calls result in TLSv0. Further, that seems to be a wget problem.

But, as I reported above, an earlier version of wget (1.13 on a Debian system) does work ok - so I don't think wget 1.16 is 'strictly necessary' - but on a system using openssl 1.0.1e-2.

Lewis, at this stage it looks as though the problem could only be solved on FREESCO with openssl 1.0.1e (and, possibly wget 1.13 as well). Unless there's a more general need for an openssl on FREESCO that can limit SSL handshakes to TLSv1.1 and above, the effort to solve our specific application would seem disproportionate. If you agree, we'll just use a work-around on a server behind FREESCO for our case.

And I'd like to say thanks, very much indeed, for the support (especially finding a wget update) and the various ideas, to say nothing of your patience when folks cannot even be relied on to use a command as written clearly for them

regards, Island

[Lightning]

There is no problems from me regarding time relative to the number of people who might use it or patience. So with that in mind I will do some more checking of various versions and see what can be done. For certain a newer version of openssl will not compile, but if I have some time this weekend or next week I will take a look at another version of wget and/or possibly just patching a specific section of code with a newer version.