4 ms·

All good points (though to me, option 1 is more preferable to option 3 :) I'd like to point out, if you're not aware already, that tor additionally supports au

All good points (though to me, option 1 is more preferable to option 3 :) I'd like to point out, if you're not aware already, that tor additionally supports authentication for hidden services on the network layer. You can put a "HidServAuth" line in your torrc, which will then create a key line you must place into your clients torrc. Only clients with the key can connect to the hidden service. You could use that either in place of or in addition to bespoke web app auth and SSL. That way you also prevent people enumerating tor hidden services from knowing what's running behind your service.

kefka 11y ago
Oh, of course option 1 is the most palatable, until everyone gets their shit together regarding standards. No, I know I'm going down the "Here ye be dragons" path of making my own IoT infrastructure. It's been one hell of a wild ride, seeing this and that offering, and how they fall flat on 'If internet is down, you have a doorstop'. I show people at the hackerspace and other tech groups, and they really see value in it. I'll certainly have to look into the HidServAuth option. However, I've been watching to see if Ca.Cert is going to get off their collective asses and revoke the "Only EV2 certs can be provided for .onion addresses" rule. My biggest problem with certs on .onion is that they fail to work. Ideally, I want a LetsEncrypt cert on all of my services (Node-Red, Mosquitto via MQTTSSL, email). And just be done with it. I'm certainly trying an orthogonal way of setting up IoT vs the Corporate way of remote data centers and oppressive data handling techniques. :)