On my LAN I run Squid on a Raspberry Pi, and have my personal laptop configured to use that as a HTTP and HTTPS proxy.
All TLS HTTP connections going through the Squid proxy are intercepted.
This only requires that my laptop trusts a self-signed TLS certificate that Squid uses.
Someone could easily run the same kind of thing on the internet, providing free proxy service and telling their users to trust a certificate signed by them, without properly explaining the consequences of that. And a lot of novice users would likely use that proxy service. Gleefully unaware that even the “encrypted” traffic is completely visible to the proxy.
In fact, I would be extremely surprised if there aren’t a whole gazillion of services out there doing exactly that.
But in many jurisdictions running a service like that would likely be cybercrime. And even if it wasn’t illegal, it’s still not nice. So, you know, don’t go and actually create a service like that.
The word "only" is doing a lot of work there.
So I just put up with clicking through the TLS cert errors every now and then.
This blog (not mine) goes into how to do it: https://systemoverlord.com/2020/06/14/private-ca-with-x-509-...
With ubiquitous support, I hope that one day we'll be able to routinely get "subdomain CA certificates" issued by something like Letsencrypt, just like it's already possible to get wildcard certificates.
For example let’s say that I am hosting a website at somewhere.example.com
Today I would be able to get a Let’s Encrypt TLS cert for somewhere.example.com and if I control the DNS for somewhere.example.com I can get a wild card cert for *.somewhere.example.com
But from what parent is saying, with name constraints it would be possible for Let’s Encrypt to give me a cert that would allow me to act as CA for anything under my somewhere.example.com
Meaning that I could for example issue a TLS cert for treehouse.internal.somewhere.example.com using the restricted CA certificate that was given to me.
I think.
Even just using a VM for the CA would likely be sufficient. Only fire it up for signing, then keep its storage encrypted. I do this on my Proxmox server.
This, to me, is worth it for local stuff. The trusted self CA certs are better than blindly trusting an invalid cert, and some browsers require trusted certs to autofills passwords.
If you have local DNS, you can e.g. request a wildcard subdomain Letsencrypt certificate and then distribute the corresponding key and certificate to your LAN hosts.
Just because someone does not know how to do something does not mean it is difficult. It just means they did not try to learn how to do it. This is very common comment on HN. It's quite silly.
Learning how to set up a localhost proxy on a laptop is far easier than learning a programming language. But it is not something that many people on HN want to learn, cf., e.g., programming languages.
IMO not necessarily. See this part of what I said:
> telling their users to trust a certificate signed by them, without properly explaining the consequences of that. And a lot of novice users would likely use that proxy service. Gleefully unaware that even the “encrypted” traffic is completely visible to the proxy.
But in addition to that, note that where I was using the word “only” was specifically in the part of my comment where I was talking about how I set up Squid for myself using my own Raspberry Pi and my own personal computer.
Honestly, whats even more common and more silly are these kinds of comments:
"blah blah blah its easy, i did it blah blah i don't understand the problem"
Ever consider that other people are somehow different than you? Have different strengths, weaknesses and abilities? Have different needs from software? It's like, why do we even make software, you could just learn binary duh.
Somebody already did do this, except as a paid service, and had their special 'client' simulate user clicks to install the self-signed root CA cert in your OS' cert store for you.
I prefer using Firefox on my laptop so I didn’t check to see what the process is like for Chrome-based browsers to add trusted certificates (or if Chrome-based browsers only use OS-level certs).
But at least with Firefox, the user doesn’t have to go fiddling with OS level stuff.
VPNs are good at encrypting/redirecting all of your device's traffic, since they're per-computer by default. They're accordingly good at preventing metadata leaks (e.g. visited sites or used apps) on untrusted networks.
Proxies are opt-in, but can accordingly be much more fine-grained. For example, Firefox supports per-domain (via various extensions) or per-tab (via the built-in "containers" feature) proxies – VPNs usually can't do that.
These bridges/adapters do have their applications though – I have a home router that supports Wireguard natively, but not any of the higher-level protocols; this lets me use my per-tab approach with it.
It is trivial to run a socks proxy on one of the peers and have your browser point to that. Both chrome and firefox can do this on demand and for the sites you select.
SOCKS is also usually not encrypted.
> 3.13.7 Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
> DISCUSSION
> Split tunneling might be desirable by remote users to communicate with local system resources such as printers or file servers. However, split tunneling allows unauthorized external connections, making the system more vulnerable to attack and to exfiltration of organizational information. This requirement is implemented in remote devices (e.g., notebook computers, smart phones, and tablets) through configuration settings to disable split tunneling in those devices, and by preventing configuration settings from being readily configurable by users. This requirement is implemented in the system by the detection of split tunneling (or of configuration settings that allow split tunneling) in the remote device, and by prohibiting the connection if the remote device is using split tunneling.
And yep, it does indeed cause all of the problems you describe.
That said, I'm aware of at least one that tries to support an "exempt/excluded hosts" feature, but it does this via some hack using its local DNS resolver and modifying the routing table on the fly, which does not work reliably.
https://support.mozilla.org/en-US/kb/protect-your-container-...