4 ms·

This is a frequently-touted solution, but now somebody compromising printer.lan.example.com can impersonate auth.lan.example.com, which isn't great either.

by ahlCVA 3y ago

8organicbits 3y ago
One approach is to put the wildcard certificate on a proxy. Clients connect to the proxy, and see a valid TLS certificate. The connection from the proxy can use whatever you'd like, including a self-signed certificate that you pin. You have the impersonation problem if the proxy is compromised, but that's a smaller attack surface than "printer", etc.
noirscape 3y ago
To be frank that's one of those things where it depends on how much you care about what gets compromised. For a purely internal homelab, the main use is to get software working; the HTTPS is only needed because modern browsers get upset about a compromised secure context if you don't, which leads to them disabling all sorts of random APIs. The actual security component is pretty much secondary for the usecase where you're dealing with devices that exist solely on an intranet - you're already gating off access by different means. Personally, the way I'd solve the problem in the situation where it'd be a problem is to not put auth on the same domain; auth would go to auth.secondexample.com. That's generally speaking the better choice to begin with due to browser weirdness regarding domain isolation (which is also why you often see software with CDNs use completely different domain names; reddit images being hosted on redd.it for example but also YouTube thumbnails being on ytimg. If they didn't, a maliciously formed file could read out browser storage for different subdomains).
throw0101b 3y ago
> somebody compromising printer.lan.example.com can impersonate auth.lan.example.com Nope: one can setup ACLs so that the script that can update the records for printer.lan… cannot also do foo.lan… or any *.lan….
- Arch-TK 3y ago
  If someone is on your network, you have to start worrying about traffic spoofing, unless you've got a seriously locked down switch (I do). But even so. Poor security practice to use a wildcard. I completely agree there. But I can understand how wildcard certs work well for the average Joe who just wants internal stuff to be served over TLS without having to think about it too hard. I work in security, so in my view, having the most secure internal network possible (think ZTA) is certainly up there. Although I have come up with an alternative approach to achieve this.

This is a frequently-touted solution, but now somebody compromising printer.lan.example.com can impersonate auth.lan.example.com, which isn't great either.

by ahlCVA 3y ago

This is a frequently-touted solution, but now somebody compromising printer.lan.example.com can impersonate auth.lan.example.com, which isn't great either.

8organicbits 3y ago

One approach is to put the wildcard certificate on a proxy. Clients connect to the proxy, and see a valid TLS certificate. The connection from the proxy can use whatever you'd like, including a self-signed certificate that you pin. You have the impersonation problem if the proxy is compromised, but that's a smaller attack surface than "printer", etc.

noirscape 3y ago

To be frank that's one of those things where it depends on how much you care about what gets compromised. For a purely internal homelab, the main use is to get software working; the HTTPS is only needed because modern browsers get upset about a compromised secure context if you don't, which leads to them disabling all sorts of random APIs. The actual security component is pretty much secondary for the usecase where you're dealing with devices that exist solely on an intranet - you're already gating off access by different means. Personally, the way I'd solve the problem in the situation where it'd be a problem is to not put auth on the same domain; auth would go to auth.secondexample.com. That's generally speaking the better choice to begin with due to browser weirdness regarding domain isolation (which is also why you often see software with CDNs use completely different domain names; reddit images being hosted on redd.it for example but also YouTube thumbnails being on ytimg. If they didn't, a maliciously formed file could read out browser storage for different subdomains).

throw0101b 3y ago

> somebody compromising printer.lan.example.com can impersonate auth.lan.example.com Nope: one can setup ACLs so that the script that can update the records for printer.lan… cannot also do foo.lan… or any *.lan….

Arch-TK 3y ago
If someone is on your network, you have to start worrying about traffic spoofing, unless you've got a seriously locked down switch (I do). But even so. Poor security practice to use a wildcard. I completely agree there. But I can understand how wildcard certs work well for the average Joe who just wants internal stuff to be served over TLS without having to think about it too hard. I work in security, so in my view, having the most secure internal network possible (think ZTA) is certainly up there. Although I have come up with an alternative approach to achieve this.