Sprinkle some security on your internet facing HeaterMeter


 

Steve_M

TVWBB Guru
This only works on the v14 release and newer of the HeaterMeter software.

Rather than forwarding port 80 (http) to your HeateMeter, you can forward port 443 (https) for a secure, encrypted connection. With the help of the hm-letsencrypt script below, you can now have a free, valid certificate if you're using a Dynamic DNS name ie: duckdns.org, noip.com or any number of DDNS providers.

All of the details are here

Cheers!
 
Last edited:

Steve_M

TVWBB Guru
For those wondering what the before / after of this looks like.

Before:

kgFFFv5l.png


After:

aRcJNrhl.png
 
Last edited:

Steve_M

TVWBB Guru
Hopefully this functionality can make it into a release in the near future. Something else that would also be nice is having the HM create a port forward via UPnP.
 

Steve_M

TVWBB Guru
Due to the way some large hosting providers have been working, the TLS SNI mode that this uses is no longer available. It's too bad, as being able to only use port 443 and not a combination of both 80 and 443 is a much cleaner solution.
 
Last edited:

Craig Hiebert

New member
Hi there - brand new here, hoping to run my first HM smoke this weekend. Meanwhile, I'm working on all the networking magic.

@Steve_M, would your comment above be why I'm still getting the 'untrusted' warnings in the browser(s)? I've followed the instructions in your GitHub link to the letter, and confirmed that the /etc/uhttpd.crt and .key files are fresh, and I've rebooted several times, but I'm still getting the untrusted message/symbol (although I can override and still view the HM from internal and external). I've set port forwarding of 443 to 443, FYI. Am I missing anything, or are there ways to troubleshoot? (FYI I'm a unix adolescent - from web developer days long past.)
 

GrantT

TVWBB Member
Even with an HTTPS connection, you will still get an untrusted warning unless your web site (the device) has a bound SSL certificate that is valid, trusted publicly etc. This can be a finicky process so make sure everything was done perfectly.

Most importantly is to get traffic flowing over the encrypted/port 443 protocol so it is not easily possible to see any data in transit. "Trusted" really means nothing if you are using this within your own environment....we have many internal web servers that do not have valid certificates as we don't need to "prove" their identity to any outside source. The traffic is still secured.

To be honest, if there is really no actual personal data flowing OVER the internet link to one of these devices, even having it encrypted is really not that big of a deal. Someone that get access to the data might see the data from the device...but really, who cares if it is just temperature data.

Example...but if you are "signing in" to the web site using an ID/password to maybe adjust settings etc...then you certainly want to force HTTPS. Using HTTP could result in someone gaining access to the credentials that were used if they are sniffing your traffic.

Also very important is to ensure that there are no open back doors/holes in their web server so someone could possibly hack into the device to gain further access to devices on your network. MOST network hacks with IoT devices occur not because someone snooped the actual traffic, but because the web server or device has known vulnerabilities.

Personally, if you only need access from specific other locations, firewall rules/access control lists which prevent anyone, other than trusted IP addresses to even see the IP address of your device is a more effective means of securing the actual device.

For example, if you only need access from work...lock your firewall so ONLY the public IP address of your work computer is permitted to see the IP address of your device/firewall port. Deny everything else.
 
Last edited:

Craig Hiebert

New member
Thanks, @Steve_M! I can live with the warning, except that one downside of the current 'glitch' (in my system, at least) is that I can't configure the iOS Heatermeter app to connect, since that developer hasn't provided a fallback for when there's a trust issue.
 

Steve_M

TVWBB Guru
@Craig Hiebert I fired up my HM, updated it to the latest v15 software and tried things out. Looks like there's an issue with the stopping of uhttpd, so when my script checks to see if it should start uhttpd, it doesn't because it thinks it's already started.

I've updated the script so that it's more forceful and looks to be working ok.

After a reboot it came up ok, which makes sense as uhttpd would be starting up from scratch. Have you rebooted your HM since installing the cert?

You can try the whole process again if you want, which will download and install the updated script.
 

Craig Hiebert

New member
@Steve_M Thanks for looking into that. I have indeed rebooted 3 or 4 times since installing the cert. I'll try again now.

(Meantime I enjoyed a practically flawless first HM cook, and was able to share the joy with friends who also enjoy food + automation.)
 

Craig Hiebert

New member
Nope - I refreshed everything: new letsencrypt.sh, deleted and renewed certs, three reboots. I'm still getting "This website does not supply ownership information." as the error in Firefox (85.0 64-bit, latest), and ""LEDE" Certificate is not trusted" in Safari (MacOS). I'll leave HM up overnight (my time) if you want to see for yourself.
 

Steve_M

TVWBB Guru
Ok, I made 1 more change to the script. If that doesn't fix it, you'll need to ssh into the HM and check some things.

These are the commands I'd like to see the output of from your HM.

1) grep VER /mnt/mmcblk0p4/letsencrypt.sh
This should return:
Code:
VER="2021-01-31-r01"

If you don't see that, then let's manually download the script and try and issue a cert by running these 3 commands:
Code:
curl -so /mnt/mmcblk0p4/letsencrypt.sh https://raw.githubusercontent.com/shmick/hm-letsencrypt/master/letsencrypt.sh
Code:
chmod +x /mnt/mmcblk0p4/letsencrypt.sh
Code:
/mnt/mmcblk0p4/letsencrypt.sh craigsgrill.freeddns.org force

2) ls -l /opt/acme/acme.sh
Should look like
Code:
-rwxr-xr-x    1 root     root        207190 Jan 30 15:42 /opt/acme/acme.sh

3) ls -l /root/.acme.sh/craigsgrill.freeddns.org/
Should look like:
Code:
drwxr-xr-x    2 root     root          1024 Jan 30 15:43 backup
-rw-r--r--    1 root     root          1866 Jan 30 16:10 craigsgrill.freeddns.org.cer
-rw-r--r--    1 root     root           845 Jan 30 16:10 craigsgrill.freeddns.org.conf
-rw-r--r--    1 root     root          1001 Jan 30 16:10 craigsgrill.freeddns.org.csr
-rw-r--r--    1 root     root           219 Jan 30 16:10 craigsgrill.freeddns.org.csr.conf
-rw-r--r--    1 root     root          1675 Jan 30 15:42 craigsgrill.freeddns.org.key
-rw-r--r--    1 root     root          1587 Jan 30 16:10 ca.cer
-rw-r--r--    1 root     root          3453 Jan 30 16:10 fullchain.cer

4) ls -l /etc/uhttpd.*
Should look like:
Code:
-rw-r--r--    1 root     root          3453 Jan 30 16:10 /etc/uhttpd.crt
-rw-r--r--    1 root     root          1675 Jan 30 16:10 /etc/uhttpd.key

5) openssl x509 -in /etc/uhttpd.crt -text -noout | grep -e Issuer: -e CN
Should look like:
Code:
        Issuer: C=US, O=Let's Encrypt, CN=R3
        Subject: CN=craigsgrill.freeddns.org
 
Last edited:

Steve_M

TVWBB Guru
Did a little more experimenting. The problem I was experiencing with /etc/init.d/uhttpd stop not working properly seems to have fixed itself and works every time now.

If the acme.sh pre-hook isn't able to stop uhttpd properly, it won't be able to start the openssl listener on port 443 for doing the validation of the cert. If you forcefully kill the uhttpd process, uhttpd will get restarted in 5 seconds. This is sometimes long enough for acme.sh to start the openssl listener, but sometimes it's not and then the validation will fail.

I decided to revamp my script to simply remove the https/443 listener from uhttpd prior to generating a cert and then adding it back after. Gives the added bonus of leaving the http/80 uhttpd service running during the process.
 
Last edited:

Top