"VTPP" is a home server project I've been working on which, in short, automatically downloads videos, extracts their audio, and makes the audio available for me to listen as a podcast feed.

It's been a few years since I marked the v0.2.0 milestone.

I've finally gotten around to fixing some of the project's basic security issues, so it felt right to mark this point as the v0.3.0 release!

HTTPS and proper hostnames

As noted all the way back in the v0.1.0 release, I've connected to my VTPP feed and server over HTTP and using a static, private IP address.

After more than two years, this has still yet to cause a real problem, but it's a pretty significant security gap: Using a static, private IP address from a mobile device exposed me to the possibility of using a public WiFi network with a similar private IP range and accidentally connecting to someone or something I did not intend to.

And using HTTP meant that if I did connect to something, my phone wouldn't make any attempt to authenticate that it was the VTPP feed my phone was expecting.

Both issues have now been addressed.

Over the christmas break, I coincidentally set up a Pi-Hole DNS server on my home network. Fixing the "connect-via-IP" problem was as simple as adding a new vtpp.lemonpie.home.arpa entry to the DNS server's records that mapped back to the VTPP server's static IP address. For a long time, I thought fixing the hostname issue would require registering (and paying for) a real public hostname which isn't really what I wanted or needed. Discovering the home.arpa domain made the solution so easy!

And I chose to fix the HTTPS problem by setting up my own private certificate authority (CA), installing it as a trusted root on the devices which use VTPP, and then issuing a server leaf certificate for my VTPP server to use. The server certificate encodes both the hostname, vtpp.lemonpie.home.arpa, and the static IP as SANs (subject alternative names).

For now this is a workable situation for me. I would prefer to get my leaf cert issued from a more widely available trust anchor like LetsEncrypt, but I haven't yet figured out how to get one issued for a service only reachable on my private network. I think specialized tools like localcert.net exist to help bridge this gap, but I have not yet had the time to explore what the trade-offs are or how to use it.

I'd bet dollars to donuts that I'll get tired of managing my private CA after the first time I have to deal with a certificate expiration.

Oh well, for now I'm satisfied.

A quick reflection

It's funny. Now that the work is done, it feels like it was easy enough that I really shouldn't have put off this bare-minimum security work for over two years.

But I think this is a feeling that only makes sense with those two years of experience under my belt. Despite being an engineer on a team that primarily develops, troubleshoots, and maintains networking software/tooling, DNS and PKI have always been two significant gaps in my skillset. I've fixed bugs rooted to problems in both areas in the past, but there's a real difference between having an abstract understanding of those systems and getting your hands up close and dirty with them. So, I suppose it's more of a happy accident that my job has put me face-to-face with these systems more directly and more consistently over the last two years.

I feel both embarassed and re-assured that I have no reason to be. Such is life.

¯\_(ツ)_/¯

The full changelog

Here's a more complete summary of what's changed since v0.2.0:

• The VTPP homepage now reports the last time the fetcher ran and, uniquely, the last time the fetcher ran with errors.
• Discord reports are only generated when something changes or the fetcher encounters an error.
• I added support for enabling/disabling the fetcher schedule from the VTPP homepage.
  • YouTube breaks youtube-dl often enough that when something is broken for more than a day, it's more practical to just disable the fetcher until I can try to fix things over the next weekend.
• I improved my "YouTube Shorts" recognition heuristic.
  • Instead of looking for a maximum time, I just look for a "shorts"-path in the video URL. This seems to be both simpler and doesn't require successfully downloading any part of the video.
• VTPP now serves its feed and media from an HTTPS endpoint.
  • HTTPS support is provided by putting an Nginx reverse proxy in front of the VTPP feed.
• The VTPP feed is now reachable from a DNS name resolvable on my local network.
• The VTPP feed is now behind an Nginx reverse proxy and exposed on the proper 443 HTTPS port.