3 ms·

> In the name of "security", this undermines the very purpose of what HTTPS is about, knowingly endangering their users. It doesn't have to be insecure. If the

> In the name of "security", this undermines the very purpose of what HTTPS is about, knowingly endangering their users. It doesn't have to be insecure. If the software that does the MITM checks the certificates correctly, I don't see how it would be worse than letting the browser handle it. Not that I'd ever use an antivirus, of course.

raesene6 10y ago
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.
- akjainaj 10y ago
  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.
  - raesene6 10y ago
    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?)
    - akjainaj 10y ago
      Of course there are lots of what-ifs, but how do you tamper with HTTPS traffic if you don't MITM?
      - raesene6 10y ago
        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.
        jerf 10y ago
        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.)
- Neil44 10y ago
  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.
  - raesene6 10y ago
    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.
- Elhana 10y ago
  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.

raesene6 10y ago

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.

akjainaj 10y ago
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.
- raesene6 10y ago
  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?)
  - akjainaj 10y ago
    Of course there are lots of what-ifs, but how do you tamper with HTTPS traffic if you don't MITM?
    - raesene6 10y ago
      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.
      - jerf 10y ago
        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.)
Neil44 10y ago
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.
- raesene6 10y ago
  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.
Elhana 10y ago
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.