Hacker News Reader

Comment by raesene6 | Hacker News Reader

It actually is worse. The problem comes "what does the interception do when it encounters an invalid certificate"?

So for example a self-signed cert. does it

a) create a "valid" cert itself, hiding the error from the user? This is obviously dangerous

b) create an "invalid" self-signed cert. This is messy as a user will then see a self-signed cert from the A-V vendor, which they may be more or less inclined to trust

c) Pass the traffic through without inspection, missing any potential threats

And that's just one case. SSL/TLS interception is very hard to get right and easy to make the user's security worse as a result.

View on HN

With Eset you get a message explaining the issue, similar to if your connection was blocked because malware was detected.

I don't think this practice is a big issue because the local machine would have to be compromised for it to be an issue, in which case it's irrelevant because the game is over already. Also the alternative is not scanning ssl traffic for malware which has it's own very real risks.

The issues I've mentioned (problems dealing with self-signed certs, Cert pinning and EV-SSL) don't have much to do with the client being compromised. They're examples of how SSL MITM (even assuming no implementation flaws) can damage user security by breaking the operation of SSL for user web access.

I think what bluecoat proxy at my work does in this case is just inspect traffic and pass invalid cert to the client, since it is invalid already. If the cert is valid, replaces it with its own cert.

It can simply stop the connection and show the user, under the normal certificate, a message telling him there's a problem with the cert.

So to do that it's going to stop the users browsing session, redirect them to a local web page and then present something to let them make a decision about carrying on? not the best user experience in the world..

But remember like I said that's just one example of why it's a bad idea, there's others, e.g. what do you do about EV-SSL certificates? You can't fake the browser element for them (remember this is the case where the A-V product hasn't hooked the browser), so where you want to MITM a EV-SSL connection you have to downgrade it to Non-EV.

Also what do you do with certificate pinning (either browser in-built or HPKP headers?)

Of course there are lots of what-ifs, but how do you tamper with HTTPS traffic if you don't MITM?

Easy, you don't tamper with HTTPS traffic, it's innately a very bad idea.

Consider the goals that are trying to be achieved. You're attempting to stop the user either downloading malicious content or perhaps getting hit with a browser exploit or possibly you're trying to stop users going to a "bad" site.

The first one can be covered off with traditional on-access scanning of files.

The second one is much better addressed by improvements in browser sandboxing or general app. security.

The third one can be handled at a DNS level with reputation based block lists.

That doesn't work for corporate communications, though. There are numerous use cases where a corporation must be able to penetrate HTTPS internally in order to comply with regulations, both for direct reasons such as regulations regarding corporate communications, and indirectly for things such as internal security, protection against insider threats, and a lot of other second-order issues like intrusion detection.

And, rolling back around to the main topic, preventing internal machines from being compromised by viruses, since a lot of people end up having to hit at least one website of some sort that has at least one tracking or advertising widget that could by three layers of indirection get compromised to serve viruses, which is, alas, not some sort of far out scenario nowadays, but just another day of the week on the web. (That is, even perfectly safe browsing habits can still get you owned on the modern web. And saying that a modern network can't count on "firewalls" and must have defense in depth still doesn't mean it's just peachy keen if an internal machine gets compromised.)

If you're going to insist those corporations can't penetrate HTTPS for compliance and security reasons, you're going to have to be willing to lift those restrictions and deal with it when their security fails. There's no two ways about this; either you grant them the necessary tools for compliance and security, or you stop complaining when they can't comply and aren't secure. (And at scale, let's be honest; the latter isn't on the table.)

I know corps need to do that, and they get to handle the trade-offs that it generates (although I'd argue that HTTPS interception doesn't in any way provide a panacea for the internal security issues you've mentioned).

The advantage is that they should have informed professional security people who can understand the trade-offs and make intelligent decisions about them.

Even then this strategy fails against certificate pinning which is becoming ever more common in mobile and also web space, so corps need other solutions to those problems (likely endpoint based)

However what we're talking about here is end-user A-V products and their use of HTTPS interception at a desktop level and the trade-offs that this forces on individual end users who are less equipped to handle this.

Realistically the A-V product will likely choose to cause "less noise" to the user so won't present them detailed technical information about the errors their masking, potentially making the user's security worse.

Reply on news.ycombinator.com