Hacker News Reader

Comment by lima | Hacker News Reader

The company also should have restricted network access to the port in the conference room so that an unknown device like a Raspberry Pi could not make an Ethernet connection from that spot

Bad take - the actual problem is that there was a trusted network in the first place. This kind of network access control is trivial to bypass, and trusted devices can get compromised.

View on HN

It's not my field, but at least at my work the network can somehow tell the difference between an authorized user and not. It is not simply using the MAC address.

A guest device connected to the ethernet port in the conference room has the same access as a device connected to the guest wifi, a staff laptop has it's usual access.

Probably a RADIUS server setup.

Basically staff machines get a certificate to present to the server and the server controls the network.

So, if your machine does nothing, it's on the guest vlan and has limited access. If it presents a valid certificate that network port is reassigned to the staff vlan and you get full access.

If someone leaves, you just revoke the certificate and they have guest access again.

Not rocket science once you know it :)

Still better to do that same thing (cert based auth) at the application layer instead of the network layer.

Yes, you can do it by MAC address instead but that can be changed so you can spoof a legitimate device.

Edit: oh wait, you mean have the applications check the certificate? Yes, but then you need support from the application. Does your printer do that, for example? You need to make sure everything does. You can of course do both.

Reverse proxy

That's great when you have control of your applications. For most corporate IT you're stuck with COTS applications and whatever their built-in auth functionality is. Sure, you can probably bolt a reverse proxy in front (if you're lucky enough for it to be a web app and not a thick native code client) but you get to argue with the vendor when they refuse support because you're not using their recommended configuration.

802.1x certificate-based authentication at layer 2 is a good defense in depth strategy.

Use envoy or some other reverse proxy and do per-app auth there

Even if you can't authenticate at the application level, it's still much better to encrypt/authenticate traffic on the wire (using a VPN or something like Tailscale) instead of 802.1x auth.

How is an overlay network "much better" (or meaningfully different) than a device-based certificate and 802.1x when the user is accessing an application delivered over HTTPS using a publicly-verifiable certificate authenticating via SAML w/ MFA (Entra ID)? The source subnet attests successful device authentication in the 802.1x example but that's irrelevant beyond, perhaps, a firewall granting access for the device to terminate a TCP connection to the server's TCP port 443. That's no different than the request coming to the server from an authenticated overlay network, to my eye.

I guess if you want to tie the network layer authentication to the user make it 802.1x with a user certificate. Either way you know the request is coming from authenticated endpoint and the user still authenticates to the application independent of the network layer. In all cases HTTPS protects the traffic from MiTM end-to-end.

Probably 802.1x, but it's easy to bypass if you have access to an authorized device. This kind of authentication has to be done at the application level, treating the network as a perimeter doesn't work.

Reply on news.ycombinator.com