Hacker News Reader

Comment by FuriouslyAdrift | Hacker News Reader

Because of all my internal systems that use certs to connect (switches, routers, iot, etc) that have manual only interfaces (most are tftp), I have had to go back to just running my own CA infrastructure and only using public CAs for non-corporate or mixed audience sites/services.

It's really annoying because I have to carve outs for browsers and other software that refuse to connect to things with unverifiable certs and adding my CA to some software or devices is a either a pain or impossible.

It's created a hodge podge of systems and policies and made our security posture full of holes. Back when we just did a fully delegated digicert wildcard (big expense) on a 3 or 5 year expiration, it was easy to manage. Now, I've got execs in other depts asking about crazy long expirations because of the hassle.

View on HN

Why is fronting these systems with a central haproxy with TLS termination or similar not an option?

Fronting a switch management interface with haproxy? Are you sure that is a good idea?

Yes. If we're talking about handling TLS termination and putting an IP behind a sensible hostname, I don't see what's wrong about using a reverse proxy. Note that this does not imply making it accessible on the internet.

Yet more infra that must now be managed and a point of failure. No thank you.

Well. That, or maintaining bespoke PKI and internal CA, along with manually renewing certificates with ever-shortened expiration periods as demanded by browsers.

Pick your poison.

Windows infra so certificate services is already baked in for 802.1x, etc.

Because then you have plain HTTP running over your network. The issue here (I presume) is not how to secure access over the Internet, but within an internal network.

Plenty of people leave these devices without encrypted connections, because they are in a "secure network", but you should never rely on such a thing.

Nothing stops you from using a self-signed certificate with a ridiculous expiration period for HTTPS between the reverse proxy and the device in question.

Except browsers and other software that are becoming hard-coded to block access to such devices.

We used to use Firefox solely for internal problem devices with IP and subnet exclusions but even that is becoming difficult.

Use the self-signed cert between the proxy and the problem device; everything else talks to the proxy.

Or Wireguard.

Using VPNs on server infrastructure to punch a hole is a resume generating event.

Wireguard is not a VPN, it’s a protocol that can be used for a lot of things.

The wireguard protocol is an encapsulation or tunneling protocol... which is, by definition, a virtualized private network protocol.

It's not different from IPSec, GRE, VXLAN, etc. It's just the new hotness.

We use VXLAN extensively in our network, btw, and IKEv2/IPSec tunnels between sites.

WireGuard can be used to create a virtualised private network, but doesn't do so on its own, or without additional infrastructure. WireGuard tunnels network packages securely, with high throughput, from an arbitrary point A to an arbitrary point B. No more, no less.

Just because it can be used to recreate VPNs traditionally used to remotely dial into a secure network zone doesn't mean it shouldn't be used in far smaller use-cases. WireGuard doesn't constitute anything like a full VPN solution on its own.

Reply on news.ycombinator.com