I am still very much a novice in the self-hosting space, Linux etc. having fairly recently switched from using macOS as my daily driver and not tinkering much at all.
One of the things that often confuses me is networking and making sure my setup is secure. This is currently holding me back from hosting more stuff locally that I would require access to from outside my home, as I am afraid I am doing something that could severely compromise my data. It can sometimes be difficult to follow explanations from more advanced users due to the many different components of networking and security, and different layers of abstraction, which prevents me from following completely. I might understand one particular case, but then be unable to make connections to another one. So I would want to research this more intensively, and ideally I would end up being able to easily understand the data flows - the paths the data takes (e.g. I make a HTTPS request to some server from my laptop, how is that traffic routed correctly through my local area network and later the wide area network), in what forms (i.e. different protocols, encryption layers etc.).
In communities like this, I see there are a lot of very knowledgeable people who maybe could recommended any resources that cover this from the basics and onto more advanced stuff? Maybe a textbook from a university course on ICT that is considered particularly good? A YouTube channel with great explanations and visualizations? I am looking both at home LAN and internet in general. Enterprise level networks are not very interesting to me (at the moment).
Reading is fine and all, but in my experience of learning about networking and security, I have always learnt the best when I have a need for it.
Let's take the example you posted on your post. Now, we know that HTTPS is important so that nobody has access to the traffic you're forwarding to the Internet. Encryption usually just requires two things: the data (your traffic) and a key to encrypt it.
When you're visiting a website with a valid certificate, it sends its public key and the valid certificate to your browser. Your browser validates that the website you're trying to visit seems OK (not sure about the internals of the process), and encrypts your traffic with the public key of the website.
The website can now decrypt your traffic with its private key. Nobody gets to snoop on your data (but they do get to snoop on your metadata, which I'll come to in a bit). That's how the process works, and I have essentially provided an overview of the TLS handshake in my explanation.
Why did I say that your data isn't exactly secure even though you encrypt it? Well that's because your metadata isn't encrypted yet. It is only recently that the masses are picking up on ECH and ESNI (SNI - server name indicator; this is the DNS record of your request, which means your ISP knows which website you went to, but it doesn't know what you did on said website). With that said, I was talking about the broader Internet, which seems to be out of scope for this discussion.
Let's talk about another use-case of TLS in your homelab, since we're on the subject.
Problem: you want to find the padlock symbol on your browser every time you visit an internal website, but since you're using plain HTTP on your network, your browsers considers it fit to annoy you with a warning that your destination might be a malicious website (it's not, unless you don't know what you're hosting).
Immediate solution: use a reverse-proxy! Most reverse-proxies have integrations with certificate automation software (certbot FTW) which handles TLS on the client side and deals with the warnings (if you have understood the paragraphs that I have written till now, you will understand why this is the case).
Background: Have you heard of reverse-proxies? If not, a bit of reading on Wikipedia should do the trick, but basically, reverse proxies map a subdomain (slight understanding of DNS is required for this since certificates and DNS are tied closely) to a specific IP and port. This is important if you're hosting containers on a single machine since the only way to reach out a specific container is through the combination of IP:Port, but who wants to remember random numbers? Too lazy to do that.
Question: why not just use my DNS server to map subdomains and IPs? This might not be obvious to everyone if you don't know about DNS and its limitations (in this scenario).
Let me know if you're facing issues with anything that I typed here. It's a long, long journey (I've been learning for years now and I still don't get things right), but you'll get there. Just take your time, make sure to not get overwhelmed, and you'll make it.
Cheers