[Frage] Freetz in https

[frater]

Although I warned many others to be careful about enabling the directive "IncludeSubDomains" in their HSTS-configuration I enabled it myself today.
I did this to increase the security of my domain for which I have a wildcard certificate.

For those that do not know what HSTS is.

In short it means that a domain on which HSTS effective cannot be accessed over http://

Before I did this I was thinking of all the sites on which I'm using my domain and that wildcard certificate. But that was wrong.
I should have though of all the devices that I access using the domain name I have.
I was not thinking of the +70 Fritzboxes with their Freetz WebIF.
How Stupid.
Now it's too late as I submitted my domain for preloading HSTS
https://hstspreload.org/

It means that I can NOT use my domain anymore to access my Fritzboxes over http:// from today on.

This leads me to the question that's relevant here.
Will there be a change of the Freetz WebIF any time soon so it supports https?

If not, can or will there be a change so it binds on localhost instead of all the interfaces so I can run a reverse proxy to do this?
This binding to localhost is not imperative. It would of course be enough to not open it up to the WAN-interface.

Which reverse proxies are available for Freetz?
I used to have "Pound" on my DD-WRT, but that one is not available?

If no reverse proxy is available and the WebIF does not handle https how can we safely login from a remote location?

 

[frater]

I will check if "tinyproxy" will bring me where I want.
Tomorrow I will investigate this and will post my findings here.

I have never used "tinyproxy".
From what I gather it can not, like "pound", do load balancing nor act as a traffic agent and proxy for many servers based on the domain name.

Maybe one of the developers would be interested to add this?
Ashamed to admit that I still don't know what the procedure for this is, exactly.

 

[f666]

I'm using stunnel to get https encryption of my freetz web interface. It works nicely with LetsEncrypt certificates.

 

[frater]

I'm using stunnel to get https encryption of my freetz web interface. It works nicely with LetsEncrypt certificates.

Thanks... I will investigate that as well.
It will probably have a smaller footprint. For the 7390 I have no space left.

 

[koyaanisqatsi]

Hello

Tinyproxy works like a vpn and leads into the local network without encryption.
(You have to protect local addresses with url filter method)
(Using of "Allow" is recommended if access to local devices needed and therefor not filtered)
...but is a good proxy and serve/convert also ipv6 to ipv4 only clients.
...and can filter any protokoll (ftp/http/https) with url filtering method.
I show you my old tinyproxy.conf for an impression...
tinyproxy.conf ("stealth proxy")

DisableViaHeader yes
ViaProxyName "yourhostname.dyn.dns"
XTinyproxy no
User root
Group root
Port 8088
#Listen 192.168.178.1
#BindSame Yes
#ConnectPort 80
#ConnectPort 443
#ConnectPort 500
#ConnectPort 1011
#ConnectPort 1012
#ConnectPort 2002
#ConnectPort 4500
#ConnectPort 5060
#ConnectPort 5061
#ConnectPort 49000
#ConnectPort 49443
#ConnectPort 8080
Timeout 600

ErrorFile 400 "/var/media/ftp/SanDisk-Cruzer-01/error/e400.htKml"
ErrorFile 401 "/var/media/ftp/SanDisk-Cruzer-01/error/e401.html"
ErrorFile 403 "/var/media/ftp/SanDisk-Cruzer-01/error/e403.html"
ErrorFile 404 "/var/media/ftp/SanDisk-Cruzer-01/error/e404.html"
ErrorFile 500 "/var/media/ftp/SanDisk-Cruzer-01/error/e500.html"
DefaultErrorFile "/var/media/ftp/SanDisk-Cruzer-01/error/etp.html"
StatFile "/var/media/ftp/SanDisk-Cruzer-01/html/test.html"
StatHost "play"

Syslog On
#LogFile "/var/media/NEW_LINK/mips/tinyproxy.log"
# Set the logging level. Allowed settings are:
#       Critical        (least verbose)
#       Error
#       Warning
#       Notice
#       Connect         (to log connections without Info's noise)
#       Info            (most verbose)
# The LogLevel logs from the set level and above. For example, if the LogLevel
# was set to Warning, than all log messages from Warning to Critical would be
# output, but Notice and below would be suppressed.
#
LogLevel Info
PidFile "/var/media/ftp/SanDisk-Cruzer-01/mips/tinyproxy.pid"

MaxClients 100
MinSpareServers 30
MaxSpareServers 200
StartServers 50
MaxRequestsPerChild 100000

#Allow localhost
#Allow 217.183.5.214
#Allow 192.168.178.0/24
#Allow fritz.box
#Allow 10.10.10.0/24
#Allow yourhostname.dyn.dns

#upstream 10.10.10.20:8088
#no upstream "yourhostname.dyn.dns"

Filter "/var/media/ftp/SanDisk-Cruzer-01/mips/tinyproxy.filter"
FilterURLs On
FilterExtended On
FilterCaseSensitive Off
FilterDefaultDeny No

#Anonymous "Host"
#Anonymous "Authorization"
#Anonymous "Cookie"
#Anonymous "User-Agent"
#Anonymous "Accept"
#Anonymous "Accept-Charset"
#Anonymous "Accept-Encoding"
#Anonymous "Accept-Language"
#Anonymous "Cache-Control"
#Anonymous "Connection"
#Anonymous "Content-Length"
#Anonymous "Content-Type"
#Anonymous "Expect"
#Anonymous "HTTP-Host"
#Anonymous "HTTP_CACHE_INFO"
#Anonymous "If-Match"
#Anonymous "If-Modified-Since"
#Anonymous "If-None-Match"
#Anonymous "If-Range"
#Anonymous "If-Unmodified-Since"
#Anonymous "Pragma"
#Anonymous "Range"
#Anonymous "TE"
#Anonymous "Upgrade"
#Anonymous "DNT"
#Anonymous "X-Forwarded-For"
#Anonymous "Client_Ip"
#Anonymous "Via"

#AddHeader "Cache-Control" "max-age=0"
#AddHeader "HTTP-Host" "google.com"
#AddHeader "Host" "google.com"
#AddHeader "From" "[email protected]"
#AddHeader "Connection" "keep-alive"
#AddHeader "User-Agent" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
#AddHeader "User-Agent" "Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20140429 Firefox/24.0 Iceweasel/24.5.0"
#AddHeader "User-Agent" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36"
AddHeader "User-Agent" "Godzilla/2.0 (Windows NT 5.1; rv:33.0) Gecko/20100101 Firefox/33.0"
#AddHeader "Referer" "https://www.google.com/"
AddHeader "DNT" "1"
#AddHeader "Accept" "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"
#AddHeader "Accept-Language" "de-DE;en;q=0.5"
#AddHeader "Accept-Encoding" "gzip,deflate"
#AddHeader "Via" "Googlebot/2.1"
#Addheader "Proxy-agent" "Googlebot/2.1"
#AddHeader "X-Forwarded-For" "127.0.0.1"
#AddHeader "XProxy_Connection" "127.0.0.1"
#AddHeader "Forwarded-For" "127.0.0.1"
#AddHeader "Proxy_Connection" "127.0.0.1"
#AddHeader "Client_Ip" "123.123.123.123"

#ReversePath "/test/" "http://yourhostname.dyn.dns/html/"
#ReverseOnly Yes
#ReverseMagic Yes
#ReverseBaseURL "http://10.10.10.10:8088"
#EOF

And the included url filters...
tinyproxy.filter (extended example with regex)
Dont allow what hits some local dns and ipv4 (no dns).

local[a-z]{1,99}
fritz.[a-z]{1,99}
data[a-z]{1,99}
deep[a-z]{1,99}
vien[a-z]{1,99}
open[a-z]{1,99}
snom[0-9]{1,1}
epso[a-z]{1,99}
busy[a-z]{1,99}
dark[a-z]{1,99}
sams[a-z]{1,99}
base[a-z]{1,99}
[h,f]{1,1}[t]{1,2}[p]{1,1}[s]{0,1}[:]{1,1}[/]{2,2}[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}

(dns, ipv4, ipv6 and also (mixed with) regular expressions)

Dont start tinyproxy as root, exception: running on a root only embedded device

 

[frater]

I'm using stunnel to get https encryption of my freetz web interface. It works nicely with LetsEncrypt certificates.

How easy that was to implement.

https://freetz.org/wiki/packages/stunnel

I only expected to get a binary, but this one also has an entry in the webif...
I now understand why the webIF has never been changed to https.

I now have to do some rewriting of my config backup script so it supports https and then I have to prepare firmwares for all the Fritzboxes in the field....
It is still some 150 KB
I hope it fits on the 7390's that have no space left after they get Zabbix-agent.

 

[f666]

It's easy:
To get the freetz webinterface via https on port 12381, just enter this into the services field in the webinterface:

[freetz https Web-Interface]
client = no
accept = 12381
connect = 81

Add a private key and certificate chain and start stunnel.

 

[frater]

I have both the stunnel and the AVM-interface working with the same wildcard certificate.
But now I want the config to be simpler by letting the stunnel use the certificate that's also in use by the AVM interface.
In makemenuconfig there's an option "build with support for FRITZ!OS certificate " which I selected, but this is not explained further....

I was able to find to find several pem's and these seem to be relevant:

/var/flash/websrv_ssl_cert.pem
/var/flash/websrv_ssl_key.pem
/var/tmp/websrv_ssl_cert.pem
/var/tmp/flash/stunnel/key.pem
/var/tmp/flash/stunnel/certs.pem

Using the websrv_* directly is not possible. It starts with permission problems and after solving these the key also needs a password.
Implementing this seem to be more work than just use duplicate entries, but I can't believe that's how it is intended.

What am I missing????

To be clear:
I have no problem running stunnel using a manual entry of the certificate with the appropriate private key!!!

 

[PeterPawn]

The private key file is encrypted ... but with the mentioned option (FRITZ!OS certificate) it should become decrypted automatically, if you specify the two files in "/var/flash/websrv_ssl_*.pem" in your configuration (the decision for decryption is based on the "character device" property for the private key file).

This needs an older version of "privatekeypassword" (meanwhile I've published the (real) way, how this password is computed from the "maca" variable in the "urlader environment") yet, IIRC - but it should be able to run.

Meanwhile I've prepared a new version of "libprivatekeypassword" (https://github.com/PeterPawn/privatekeypassword) without additional dependencies (the "static vs. dynamic" problem w or w/o the "proxy" binary was/is terrible), but it's untested yet and AFAIK it's not updated in the Freetz trunk. There's some (minor) work to do ... first at all, the new library has to be tested. I'll try to do it this afternoon ... it's anyway an open "to-do" for me.

If you prefer to decode the private key completely and store it in a (volatile, but secure) manner, you can use "decrypt-fritzos-cfg" with the "privatekeypassword" applet ... but this would need additional space in your image, as long as you do not build a "crippled version" with only this single applet (and you haven't selected this package yet) - I'm unsure, how/wether the Freetz version can be used to build an "incomplete" version of "decoder" (https://github.com/PeterPawn/decoder) or wether only the symlinks for unneeded applets are omitted.

EDIT: To write it clearly ... the "decoder" utility will only provide the password to decrypt the private key. If you want to get a decrypted version of this file, you still need additional support (e.g. an "openssl" binary), which needs even more space in your image. The best approach is it, to use the "FRITZ!OS certificate support" patch for "stunnel", if you want to use the box certificate for your own TLS connection - that's why it was incorporated.

 

[PeterPawn]

@er13:
I did not receive your "ping" from ticket #2750 five month ago, 'cause I had no account for the Freetz Trac at this time. Meanwhile I've even closed the newly created account (once again) ... if you think there're "communication needs", use GitHub or the (known) e-mail account(s) please.

If you expect additional (and promised) changes for the "stunnel" CGI interface, we have to talk about them first - I want to avoid duplicate work (and Freetz isn't really my preferred "mod"). So we should agree, how to realize the missing parts.

 

[frater]

EDIT: To write it clearly ... the "decoder" utility will only provide the password to decrypt the private key. If you want to get a decrypted version of this file, you still need additional support (e.g. an "openssl" binary), which needs even more space in your image. The best approach is it, to use the "FRITZ!OS certificate support" patch for "stunnel", if you want to use the box certificate for your own TLS connection - that's why it was incorporated.

Yes... But I chose that...
It's however not working.. probably because I don't know how.
If I leave the 2 blocks empty the stunnel is not running as it misses the certificate & key

 

[PeterPawn]

@frater:
It's possible, that the CGI interface configures wrong path names for the files (see #10 above) ... I use the patched binary only outside of "freetz mod" and with an own configuration file. If there's no option "use own configuration" instead of the provided configuration interface, we need to bypass the preparation of the "stunnel.conf" file (the name is also a "guess only") and replace it with an own version (or overwrite the generated one, before the "stunnel" service is about to start).

 

[PeterPawn]

@frater:
I had a look into the "stunnel" package and found, that the (multiple) "stunnel" services are configurable with a "services" file.

If you take the example from the (german) description of the "stunnel" package (https://freetz.org/wiki/packages/stunnel), you should be able to add a service definition like this:

[freetz https]
client = no
cert = /var/flash/websrv_ssl_cert.pem
key = /var/flash/websrv_ssl_key.pem
accept = 4433
connect = 81

Each "stunnel" service can have its own certificate and key and the (usually) provided "textbox" controls for (server) certificate (+ chain, if needed) and key will create files under "/tmp/flash/stunnel/..." - but your service may use its own definition at this place.

EDIT: This means: If the missing certificate and key from the "textbox" controls are the reason for "stunnel" to abandon the start, simply create a (valid) key and certificate as "dummy" data - as long as the GUI doesn't provide an option to use the "box certificate" instead of data from the "textbox" controls.

 

[frater]

I'm now underway, but I did test that setup and it first crashed for the permissions of the key file.
After I did a "chmod 600" it still crashed after reading the certificate.

Later I will post the error output.
This problem could of course be specific to my certificate.

 

[PeterPawn]

My main problem: I haven't a "ready-to-use" device with a Freetz based installation. The older 7390 devices can hold only one version and the newer devices (where switching between systems is possible with "linux_fs_start") are "in use" usually.

So any changes/suggestions are made by me only due to "code reviews" - that may lead to severe "communication problems".

Such an (untested) suggestion would look like this:

diff --git a/make/stunnel/files/root/etc/default.stunnel/stunnel.cfg b/make/stunnel/files/root/etc/default.stunnel/stunnel.cfg
index 4dff6ab..73554c7 100644
--- a/make/stunnel/files/root/etc/default.stunnel/stunnel.cfg
+++ b/make/stunnel/files/root/etc/default.stunnel/stunnel.cfg
@@ -1,3 +1,4 @@
 export STUNNEL_ENABLED="no"
 export STUNNEL_SSLOPTIONS="ALL"
 export STUNNEL_VERBOSE="warning"
+export STUNNEL_USE_BOX_CERT="no"
diff --git a/make/stunnel/files/root/etc/default.stunnel/stunnel_conf b/make/stunnel/files/root/etc/default.stunnel/stunnel_conf
index ce8708a..e0871b1 100755
--- a/make/stunnel/files/root/etc/default.stunnel/stunnel_conf
+++ b/make/stunnel/files/root/etc/default.stunnel/stunnel_conf
@@ -7,9 +7,6 @@ foreground = no
 pid = /var/run/stunnel.pid
 client = yes

-cert = /tmp/flash/stunnel/certs.pem
-key = /tmp/flash/stunnel/key.pem
-
 RNDbytes = 1024
 RNDfile = /var/tmp/.stunnel_rnd
 RNDoverwrite = yes
@@ -24,3 +21,12 @@ fi
 if [ ! -z "$STUNNEL_VERBOSE" ]; then
        echo "debug = $STUNNEL_VERBOSE"
 fi
+
+if [ "$STUNNEL_USE_BOX_CERT" = "yes" ]; then
+       echo "cert = /var/flash/websrv_ssl_cert.pem"
+       echo "key = /var/flash/websrv_ssl_key.pem"
+else
+       echo "cert = /tmp/flash/stunnel/certs.pem"
+       echo "key = /tmp/flash/stunnel/key.pem"
+fi
+
diff --git a/make/stunnel/files/root/etc/init.d/rc.stunnel b/make/stunnel/files/root/etc/init.d/rc.stunnel
index b43defa..35d6778 100755
--- a/make/stunnel/files/root/etc/init.d/rc.stunnel
+++ b/make/stunnel/files/root/etc/init.d/rc.stunnel
@@ -19,8 +19,10 @@ case $1 in
                modreg cgi 'stunnel' 'Stunnel'
                modreg daemon $DAEMON
                modreg file stunnel svcs 'services' 0 "stunnel_svcs"
-               modreg file stunnel key 'Private Key' 0 "stunnel_key"
-               modreg file stunnel certchain 'Certificate Chain' 0 "stunnel_certchain"
+               if ! [ "$STUNNEL_USE_BOX_CERT" = "yes" ]; then
+                       modreg file stunnel key 'Private Key' 0 "stunnel_key"
+                       modreg file stunnel certchain 'Certificate Chain' 0 "stunnel_certchain"
+               fi

                modlib_start $STUNNEL_ENABLED
                ;;
diff --git a/make/stunnel/files/root/usr/lib/cgi-bin/stunnel.cgi b/make/stunnel/files/root/usr/lib/cgi-bin/stunnel.cgi
index 09c0fab..42d2f2d 100755
--- a/make/stunnel/files/root/usr/lib/cgi-bin/stunnel.cgi
+++ b/make/stunnel/files/root/usr/lib/cgi-bin/stunnel.cgi
@@ -14,6 +14,11 @@ sec_end

 sec_begin '$(lang de:"Konfiguration" en:"Configuration")'

+cgi_print_radiogroup \
+       "use_box_cert" "$STUNNEL_USE_BOX_CERT" "" "$(lang de:"Standard-Zertifikat für Server-Dienste" en:"default certificate for 'client=no' services"): " \
+               "yes::$(lang de:"Geräte-Zertifikat verwenden" en:"use device certificate")" \
+               "no::$(lang de:"Eigenes Zertifikat verwenden (s.u. zum Bearbeiten)" en:"use an own certificate (see below for links to edit it)")"
+
 cat << EOF
 <h2>$(lang de:"Erweiterte Einstellungen" en:"Advanced settings"):</h2>
 EOF
@@ -36,8 +41,8 @@ sec_begin '$(lang de:"Dienste" en:"Services")'
 cat << EOF
 <ul>
 <li><a href="$(href file stunnel svcs)">$(lang de:"Dienste bearbeiten" en:"Edit services file")</a></li>
-<li><a href="$(href file stunnel certchain)">$(lang de:"Zertifikats-Kette bearbeiten" en:"Edit certificate chain")</a></li>
-<li><a href="$(href file stunnel key)">$(lang de:"Privaten Schl&uuml;ssel bearbeiten" en:"Edit private key")</a></li>
+<li><a href="$(href file stunnel certchain)">$(lang de:"Eigene Zertifikats-Kette bearbeiten" en:"Edit own certificate chain")</a></li>
+<li><a href="$(href file stunnel key)">$(lang de:"Eigenen privaten Schl&uuml;ssel bearbeiten" en:"Edit own private key")</a></li>
 </ul>
 EOF
 sec_end

- but it's UNTESTED and some assumptions (e.g., that $STUNNEL_USE_BOX_CERT is visible as setting in the init script) may be wrong.

I've commited this patch to my Freetz fork, if you want to try it yourself ... it's the "diff" between fd5bb5fc9d3dc464161550208b8e77172e20468d and d95c396094cd0176b55420accf325951ce2b70a3 (there were two commits due to a wrong option name for the radiogroup at first attempt).

 

[frater]

I tried your stunnel.
I did a checkout of yours, moved ~/trunk/make/stunnel out of the way and copied yours to that folder... Still, after years and years, I haven't investigated github properly.

Your additions now gave me the ability to choose between the AVM-certificate and the manually entered.
It acts the same as before when I used "services" to point to the AVM-certificate and AVM-key.
The AVM-key is hashed with a passphrase.

Does your code attempt to decode that passphrase? Or is it just wrongfully assumed that the AVM-key can be used without a passphrase?

It's sure that the plain private key is different than the one AVM is using.
Or is that file created by Freetz and is it derived from AVM's key and did something just go wrong when decoding?
In short... can you explain how it's supposed to work?

After setting stunnel to the AVM certificate I get this:

Enter /var/flash/websrv_ssl_key.pem pass phrase:
[ ] Clients allowed=500
[.] stunnel 5.42 on mips-unknown-linux-gnu platform
[.] Compiled/running with OpenSSL 1.0.2l  25 May 2017
[.] Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI
[ ] errno: (*__errno_location ())
[.] Reading configuration from file /var/mod/etc/stunnel.conf
[.] UTF-8 byte order mark not detected
[.] FIPS mode disabled
[ ] Compression disabled
[ ] PRNG seeded successfully
[ ] Initializing service [https]
[ ] Ciphers: HIGH:!DH:!aNULL:!SSLv2
[ ] TLS options: 0x83004BFF (+0x83004BFF, -0x00000000)
[ ] Loading certificate from file: /var/flash/websrv_ssl_cert.pem
[ ] Certificate loaded from file: /var/flash/websrv_ssl_cert.pem
[ ] Loading private key from file: /var/flash/websrv_ssl_key.pem
[:] Insecure file permissions on /var/flash/websrv_ssl_key.pem
[!] error queue: 140B0009: error:140B0009:lib(20):func(176):reason(9)
[!] error queue: 906A068: error:0906A068:lib(9):func(106):reason(104)
[!] SSL_CTX_use_PrivateKey_file: 906406D: error:0906406D:lib(9):func(100):reason(109)
[!] Service [https]: Failed to initialize TLS context
Starting stunnel ... failed.

Note the the "/var/flash/websrv_ssl_key.pem pass phrase" and the "Insecure file permissions on /var/flash/websrv_ssl_key.pem".
So, the private key I have entered in plain is somehow hashed and can't be used without a passphrase.

Can I do some tests so you know what is wrong?

I solved the "insecure file permissions" with... (but I don't know if that's merely a warning or a fatal error)

ls -l /var/flash/websrv_ssl_key.pem
crw-r--r--    1 root     root      250, 201 Jan  1  1970 /var/flash/websrv_ssl_key.pem
chmod go-r /var/flash/websrv_ssl_key.pem
ls -l /var/flash/websrv_ssl_key.pem
crw-------    1 root     root      250, 201 Jan  1  1970 /var/flash/websrv_ssl_key.pem

Everything works again by choosing the certificate/key I uploaded in Freetz.

 

[PeterPawn]

I tried your stunnel.
I did a checkout of yours, moved ~/trunk/make/stunnel out of the way and copied yours to that folder... Still, after years and years, I haven't investigated github properly.

Sorry, bad idea ... somewhere in one of the last merge requests, the needed patch "900-box_certificate.patch" was lost - I've no idea, why it happens. But I had no time (and no need) so far to fix it.

My idea was, that you create a "diff" between the shown commits (their hash values were in the last writing) and call "patch" for the original Freetz trunk. This should/could fix the startup error, if the certificate and/or key are invalid.

In the "stunnel" directory from my fork the subdirectory "patches/boxcert" is missing yet and therefore no code to use the box certificate will be included into the binary.

If the patch was applied, the problem with file permissions vanishes too:

https://github.com/Freetz/freetz/bl...patches/boxcert/900-box_certificate.patch#L33

If the patched version finds a character device as "key file", it assumes, it's running on a FRITZ!Box (and ignores any other file permissions) and gets the password to decrypt the private key file. This password is then provided to the callback routine and if it's now possible to decrypt the key, the console prompt will never be shown.

EDIT: Meanwhile I've re-added the patch to my fork ... but there were so much changes to other settings, that now the toolchain needs a rebuild - this will take some time and so I did not test, if adding the patch is enough to solve all open problems.

 

[frater]

If I would just wait for you to commit the patches you made into the trunk would that last a long time?
I can get a working situation by inserting the certificate twice.
It would be just more elegant to do that only once. It's not a show-stopper.

I would rather give you feedback based on your commits than on my patches where I may have done something wrong.

 

[PeterPawn]

After the "900-..." patch was re-added, you can copy the whole sub-directory from my fork and replace the "stunnel" directory from the trunk.

I'm not a Freetz developer and I have no write-access to the Freetz repository - all of my suggested changes are still untested. I have no Freetz installation and it's possible, that they (a) do not work or (b) do not match with the opinion of the (stunnel) CGI author(s).

I'd bet, it's a "chicken or the egg" dilemma ... as long as the patches are untested, they aren't imported into the trunk (usually) and if you want to wait for them to be incorporated there, nobody will test it ever.

This looks a little bit unfavorable/passive ... but my patches to the binaries were only an offer. I do not use Freetz myself, but I wanted to provide a solution for others (with the hope, it could be useful in Freetz too) to use the (secured) box certificate and key instead of an own and insecurely stored pair. After I gave up control over this patch, the Freetz maintainers are in charge now to adapt it to newer versions of the original software - this makes it easier (and faster for Freetz users) and I'm anyway unable to introduce/execute updates in the trunk.

Together with the patch for the binary I had offered to do further changes to the (existing) GUI, if the patch was applied to the trunk - the "ping" from @er13 in this ticket (5 month ago) wasn't noticed, because I have no Trac account anymore (it's another story not to tell here) and so I don't get any notifications. But I feel obliged to offer (adjusted) changes to the GUI, as I promised in the past - but I need someone to test them.

Even if I have not used Freetz in the past myself already, I still had somewhere a Freetz installation for any tests - but "the times, they are a-changing" (the author has gotten the Nobel Prize for Literature) and meanwhile I will not use a Freetz system anymore.

That makes it difficult to test a patch - so I need some help/support or the patch will never reach the trunk. [ And no, it's not a solution, that I create a Freetz image myself again to test anything. ]

 

[PeterPawn]

@frater:
Are there any news? Is the suggested patch for the CGI working as expected?

Meanwhile I have a new version of the (current) Freetz toolchain and my fork on GitHub should be in sync with the newest Freetz commits. It uses now a new version of "privatekeypassword" to compute the password for the "box key" (with less dependencies and possible problems) and my own tests were successful for the modified versions of "dropbear", "shellinabox" and "stunnel" (all of them built with my fork) with the new libprivatekeypassword.so.

So I would think, my changes to these packages are complete ... the only open question is the patch to the Freetz GUI for "stunnel".

"shellinabox" was already patched in the past and the "dropbear" package was patched by me to create a special (crippled) version with limited capabilities and presumably this patch will never find its way into the trunk.

To finish this, I'd like to know, if the "stunnel" patch is working - I did not understand, what you meant with "inserting the certificate twice" some posts above.

But if it's correct and usable (the patch), the package maintainer has to decide, if it's acceptable or not and if there are any further requests/preconditions to be fulfilled by this patch, what has to be done exactly. I tried to make my changes using the same style as the original code ... but there may be different views on it (and Freetz GUI packages aren't really my primary interest).

Otherwise this theme gets closed (this means: for me and not in the BBS).