Hacker News new | past | comments | ask | show | jobs | submit login
A case against Layer 4 security tools (pomerium.com)
23 points by CKMo on March 3, 2023 | hide | past | favorite | 12 comments



Uh, no. Maybe their tools have value, but their arguments are simply wrong. Nothing they say about L4 is true as far as cons. They link to another article about VPNs being "bad" where they said VPNs:

Disrupt productivity Increase workload and margin of error No monitoring capability Poor security, utilizing a flawed and incomplete security model

None of which are true. I have hundreds of healthcare employees all over the country and they're highly productive, we have LOTS of monitoring abilities, highly secure and does not have an "incomplete" security model for whatever that means. The workload increase thing is silly, clicking a single button is not an increased workload.


VPNs use the perimeter-based security model, which has been declared faulty by NIST.

https://www.nccoe.nist.gov/sites/default/files/2022-12/zta-n...

Line 259:

"It is no longer feasible to simply enforce access controls at the perimeter of the enterprise environment and assume that all subjects (e.g., end users, applications, and other non-human entities that request information from resources) within it can be trusted."

A VPN has security at the gate, aka, it keeps people out of the network perimeter. The assumption is that if someone gets within the perimeter, they passed most checks and can be trusted. Or, if something is already within the perimeter, that entity is to be trusted.

Insider threats are very real. Negligent/malicious employees cause damages. BYOD stands for both Device and Disaster. Supply chain attacks work through ways that the perimeter cannot defend against, and that is why the National Institute of Standards and Technology calls for a shift away from the perimeter-based security.


Except, you can combine VPNs with other tech. There is nothing exclusionary about it. It's defense-in-depth which, tada, NIST recommends.


I agree that the VPN can be combined with other tech, such as layer 7 tooling to get best of both worlds (VPN for layer 4 data, layer 7 tooling for layer 7 data). What NIST recommends is shifting away from VPN-only infrastructure, and if one were to reevaluate the modern digital infrastructure stack for the current threat landscape, probably sparingly.

Page 22 of https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

"Remote enterprise assets should be able to access enterprise resources without needing to traverse enterprise network infrastructure first. For example, a remote subject should not be required to use a link back to the enterprise network (i.e., virtual private network [VPN]) to access services utilized by the enterprise and hosted by a public cloud provider (e.g., email)."


Right, VPN-only is bad. But VPNs are still needed because getting every last application to use TLS or whatever is a non-trivial project. So no, VPNs aren't bad, VPNs are only bad when it's all you use. We don't have to keep going on and on around this. It's very very simple.


You've misunderstood the quoted paragraph. They are saying that services that aren't on the corporate network behind the VPN or PEP should not require being routed through the corporate network to access, ideally.


I think VPNs can work great as you say but I don't think that is universal. It is very easy for them to become a bottleneck. And performance and stability issues are not always obvious to the end user so get ignored. Obviously these issues can be resolved but there is always a limit on time and resources.


"Less reliable: Layer 7 does not provide the same level of reliability as Layer 4, as it does not have the same error-checking mechanisms."

Uh, doesn't stuff like HTTP run on top of layer 4? (eg, tcp). This article doesn't seem entirely correct, but I'm a dunce with this stuff.


Yes. If you need reliability guarantees (guaranteed in-order delivery and retransmission of lost packets,) TCP provides that, and by extension, anything built on top of TCP, inherits TCP’s reliability guarantees.

If you cannot accept the overhead of TCP’s reliability guarantees (or just don’t need it,) but still want service multiplexing, you’d typically use UDP for your protocol.


If its layer 7, then you have to push a cert to the endpoints and MITM the traffic since everything is running SSL/TLS. Not sure that is exactly safer since now your security monitoring tools have access to everyone's password and authentication credentials.


In the picture, can someone explain FTP and MPG and JPEG at layer 6? I don't understand this.

Edit: I am not exactly sure of the distinction between HTTP and FTP in the layers.


The picture is stupid. IP networks were not designed with the seven-layer OSI model in mind, and, generally speaking, whenever someone talks about layers five and six in the context of a IP-based protocol they don’t understand what they are talking about.

In the OSI reference model, it was opined that people would build common session and presentation management protocols on top of the transport layer. That, by and large, didn’t happen with IP.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: