Hacker News Reader

Comment by einrealist | Hacker News Reader

No. Network level security, if correctly installed, cannot be avoided by just running some code on your local workstation. If you have it installed on the station itself, then it is easier to avoid by just shutting it down. Also network based security can isolate workstations that are suspicious.

And your 'monolithic' is a symptom of architecture, that is either outdated ("not hipster") or just bad. But that does not mean that someone can't build hipster and good network level security. I guess, Google does not buy that off the shelf.

View on HN

>> No. Network level security, if correctly installed, cannot be avoided by just running some code on your local workstation.

Don't you have to intercept/reject TLS to make that workable? Otherwise the user (or malware) can upload or download anything and all you see at the network level is a destination IP address. If a user has admin rights (which is common in corporate environments) then they can install software which can mimic a browser using HTTPS.

At the network level it is difficult to identify what program generated a request and which user was running that program. I am very sceptical of the heuristic approaches that try and solve this problem (Palo Alto App-ID for example) that display quite shocking emergent properties.

Surely it is technically preferable to track network requests within the OS and browser where you can actually get at information reliably without any hocus pocus. If a user can avoid it by just "shutting it down" then they can also remove the AV, connect to a proxy and spend the afternoon uploading client lists to a porn site.

Yes, the proxy has to offload the original TLS connection in order to do that. And the network owner must deploy its own certificate to the clients.

The whole X.509 infrastructure is based on trust. You have to trust your certificate store, the certificates, the network and its components and CAs need to trust those who request certificates. If you have to use a network that uses a proxy, you have to trust it aswell. If you do not, then just do not use it or at least don't do your online banking over that network (or use a VPN if allowed (sigh)). So a good network security deployment is not only well maintained, but also transparent to its users on what it does. The user must have a choice on whether a network is trustworthy or not.

The problem with SuperFish is that it shipped not only the root certificate, but the private key to sign new certificates on the fly. And the user was not informed about it and not given a choice. This is the problem here.

Most clients I worked for provided me with a separate network for unfiltered internet access (guest networks) in which I used a VPN to a network which I trusted. I was given a choice.

Edit: A thing that bugs me often is when I see a network proxy that does not use TLS for the proxy connections. Unfortunately that is happening in the majority of networks, I see. And that affects my trust, so I rather avoid accessing certain services when I cannot have my VPN.

I guess that corporations need lots of network level security because they have so much unencrypted sensitive data on their networks which places a lot of implicit trust in that network.

That is true. That is why attackers (like the NSA) would be happy to infiltrate routers (less changes from the outside like administrators) instead of clients (more changes). A proxy is a quality target, too. But a proxy is also more visible and tampering is usually easier/faster to detect. Corporations need to TLS and/or message encrypt everything. But that is often not priced into (project) budgets and a hard thing to do (key exchange, managing certificates).

Why does Superfish sign new certificates on the fly? Why not just use wildcard certificates?

That is possible. But that depends on how TLS clients approve wildcard certificates. Wildcard certificates are considered harmful. And AFAIK, browsers will not accept 'star.star' (correct me if I'm wrong). So if I host a MITM proxy, I at least use FQDNs as subjects. It also works better with revocation lists/protocols.

An example for why wildcard certificates are bad is Microsoft. A couple of years ago, they had problems with subdomains which delivered malicious code through hijacked web pages that were hosted on those domains. Microsoft used a wildcard certificate...

https://tools.ietf.org/html/rfc6125#section-7.2

Reply on news.ycombinator.com