You're totally right. Although in my experience this is much easier to maintain with "upstream root certificates" (not sure how you'd call them) then self-signed certs. Applications like Home Assistant are already TLS aware and simply trust all root certs which are available on the host. With self signed certs, you have to distribute them all by yourself.
Besides this trade-off, you have to check all clients to be TLS aware on beforehand. In my setup, all clients were capable of TLS. The only hassle are my NodeMCU devices which need to swap the WifiClient to a WifiSSLClient and you need to embed the public DST Root CA X3 yourselves.
That's exactly what this post does only with Traefik instead of haproxy. The TLS of Mosquitto is just too much of a maintenance burden.
A cross post from what I replied at a Reddit topic:
> Mosquitto does have TLS support by itself, but the manual only deals with self-signed certificates. Self-signed certificates do involve a maintenance burden I don't want to deal with. All my applications/devices which expose a HTTP frontend (or other TCP stream) are encrypted via Let's Enncrypt certificates. They are automatically trusted by a lot of platforms (pc's, phones and other devices).
> I was using acme.sh before and the post-install hook can refresh every service, but it just wasn't working properly on every occasion. You also have to reload all your applications for loading the new certs (that is, Home Assistant, Unifi, Pi-hole, mosquitto, my smart meter readings platform and so on). Just reloading everything for a cert renew felt cumbersome, and Traefik dealing with TLS termination decouples the TLS part from the application itself.
> Since I used Traefik already, it was really straightforward to put Mosquitto behind Traefik too. Of course every situation is different, this post is mainly geared towards users which do not authenticate or encrypt Mosquitto at all.
I'll have to give Traefik a peek. I've used haproxy for a long time, and it's my go-to tool for my TLS termination and proxy needs, but it's always good to have more tools.
I was continuously fighting my recipe planning. I did it for a long time in Google Keep. I can't manage recipes there, I have to add items to the shopping list manually. Changes in menu planning don't keep up with the shopping list, I forget to check the pantry. Etc. This time looked right to create something to mitigate the frustrations.
The technology is quite simple, it is a CRUD app in Flask with SQL backend. Everything is a docker container with data in a volume. UX is now quite limited, based on Fomantic UI. There is no goal to make it Saas, for friends I will just spin up a second instance.
I have been a software engineer for over a decade, but haven't been programming the last 5 years. Besides I am a fanatic home cook. So this looked like the perfect opportunity to have some fun again.
Yes. I have a Google Custom Search engine which I dispatch via javascript. It just displays the results formatted from a json list. It is just a matter of preference, since DDG can't integrate search with an API as far as I know.
Mycroft as software is used by a small group of users and seems pretty stable. More features are continuously added and the design principles look promising (open source, as private as possible).
The biggest problem is their hardware: they have a Mycroft v1, (to me personally) a prototype alike piece of hardware. There have been successful campaigns for a v2 release, with new hardware and an improved design.
However, they fail to work with reliable partners and there's still no working device which resembles the final production level. I have been a backer of the indigogo campaign but it's frustrating they postpone their Mycroft v2 every time again. I really hope the can deliver the device at some point, but they keep rewriting software and if they ship, the hardware is pretty outdated probably.
It's true v1 was more of a proof of concept device. The core hardware target has always been the raspberry pi family of devices since they are pretty well ubiquitous. 2-3 is the current set. Base software is linux so if your audio devices, mic and speaker, work with Linux then you're pretty well good to go. Most microphone hats for Pi are supported. I use the Google Voicekit AIY v1 with raspberry pi 3 b+. Works a treat.
As with most open source efforts(especially early on) there's a lot of tinkering and DIY at the get go and they've designed their product to be supportive of this. Their "retail" devices are, much like Googles intent with Nexus, intended to be a best possible target for other vendors to target including the DIY crowd. Whether that's the right way to come at it is open to debate but the premise that they don't have a set hardware target is at best misleading.
I think perhaps it’s hard to hit a hardware target when the software is still in a pretty big state of change. It’s hard to say what hardware will be needed and what is the best compromise between hardware performance and the DeepSpeech NN for STT. DeepSpeech is still in development as well.
I think the priority needs to be getting the STT to a good, neural net backed, open source engine. Once the software is stabilized I think there’s room for a whole ecosystem of hardware interfaces.
Yes but that's a whole different 2FA implementation, where sites must support U2F (webauthn). Unfortunately, the implementation of TOTP is far more common than U2F.
Ideally all sites will implement U2F as two factor authentication, but there aren't that many users who have a U2F compatible token. The reach of TOTP is far more beyond U2F, which is probably why sites use TOTP more than U2F.
When sites offer both, choose U2F. When sites offer TOTP only, use it. It is better than nothing. When you have a yubikey already, use the Yubico authenticator app to store the TOTP secret to make your TOTP attack surface less and to have the availability to change your phone without losing TOTP secrets.
>When sites offer both, choose U2F. When sites offer TOTP only, use it.
This, 100%
In some sense TOTP, basically HMAC, seems like it would be harder to screw up than a public key system. RSA is amazingly hard to get right. I wonder if the order of preference should be:
Use the Yubico Authenticator app. The main difference is the (secured) storaged of the shared secret. With Google Authenticator, your keys are stored on the phone.
With Yubico's authenticator, you store the secrets ontp your Yubikey. This means you can reset your phone and still be able to use the same TOTP shared secrets. Or if that matters, ask a friend to install the app and use your Yubikeys to get the TOTP.
PiHole is a fantastic system and works really well.
The only issue I have is its installer works on a bare system. I prefer to use the Pi as a multi purpose system: for home-assistent, as unifi controller and for pi-hole. It will costs you some time to get it running with all the pi-hole features (auto update and so on) operational.
Obviously port 53 needs to be mapped externally - port 80 inside the container you can map to something else, and then use nginx on the host to redirect to that port.
The app looks great, but I just am not in favor of piping everything I have with email through your servers. Just a standalone app as basic version with opt-in for Google OAUth would justify its use case.
Besides this trade-off, you have to check all clients to be TLS aware on beforehand. In my setup, all clients were capable of TLS. The only hassle are my NodeMCU devices which need to swap the WifiClient to a WifiSSLClient and you need to embed the public DST Root CA X3 yourselves.