3

I've been looking at several data leak/loss prevention suites but, in their documentation, I'm unable to find how they treat HTTPS.

One of the 'leakage vectors' is sending information to webapps through HTTPS. In which case, the only way to detect the leakage would be to decrypt it.

But, to do that, it would have to impersonate the remote server, using fake certificates, like a man in the middle attack. To avoid users being suspicious or complaining, I guess the coroporation needs to insert their certificate as a valid CA on the company owned devices' browsers.

My questions are:

  • Has anyone first-hand experience on this kind of scenario? Can you tell us how do you implemented it?
  • Am I right or is there another way of managing HTTPS (for example, detecting the data in use at the desktop level with an agent)?
chmeee
  • 7,270
  • 3
  • 29
  • 43
  • When you say "data leakage", do you mean that people are stealing information by transferring information from a company to another place over https? – Bart Silverstrim Nov 22 '11 at 13:19
  • Stealing.. or just, transfering (maybe not for malicious purposes) – chmeee Nov 22 '11 at 13:28
  • This might be an example of a problem better solved through monitoring and policies/user education than technology and outright blocking. Efforts you put in place to restrict HTTPS will interfere with legitimate use (banking?) and will cause more headaches, unless you don't trust your employee(s) to follow policy. – Bart Silverstrim Nov 22 '11 at 13:33
  • Odious as what you're doing seems to me (and others) I know that there are businesses who require this level of scrutiny of their network traffic (often because of legal requirements of dubious value to track all information sent to clients, etc). Be sure that you're not allowing client computers any access to Internet DNS or to send arbitrary ICMP datagrams to the Internet or you're leaving massive holes for data exfiltration open. – Evan Anderson Nov 22 '11 at 18:50

3 Answers3

7

That's not "like" a man in the middle attack, it IS a man in the middle attack.

You implement it using a proxy server that will substitute your own cert for the remote cert. In the process, their browser will throw up errors about the cert not being valid. That is the point behind HTTPS and certification. So if you have a savvy user, they will know that you're intercepting the information.

You can use proxies that just record a person's activity so you can record what is happening and where they are browsing, but really, if you're implementing draconian measures to prevent the possibility that someone's stealing your information, you're probably making a workplace that fosters the kind of attitude that justifies, to the employee, doing this in the first place. And you'll also have to have HR firing policies for cell phones (recording with cameras), USB drives, and maybe making sure they don't memorize things as well.

Anyway, there's no "simple" way to break the HTTPS monitoring without some way of it being discovered unless you simply block outgoing access to that port with a firewall rule or proxy filter. Otherwise the whole point of HTTPS is pointless.

Bart Silverstrim
  • 31,092
  • 9
  • 65
  • 87
  • There are proxies out there where you can configure the client and it will not throw SSL errors. We use one in-house and it's a fairly common requirement of many security sensitive organizations. – Chris S Nov 22 '11 at 13:32
  • @Chris S do you use opensource proxies? If so, any chance for an example config posted somewhere? – dyasny Nov 22 '11 at 13:37
  • @dyasny Sorry, we're an MS Partner, we use FF-TMG and it would be pricey if we didn't get it free. – Chris S Nov 22 '11 at 13:38
  • I should have said that for *most* applications you won't find proxies that will do it. Obviously there are those out there that can and do break it for their own purposes (some say the government already does.../me whistles and walks away...) – Bart Silverstrim Nov 22 '11 at 13:44
3

But, to do that, it would have to impersonate the remote server, using fake certificates

Yes - not only would you need a certificate signed by an authority acceptable to the client but you would also need to poison the DNS for the client or redirect the IP packet stream.

I suspect it may be technically possible to implement an HTTPS proxy which would generate a certificate on the fly signed by a local CA and proxy the requests using that, but very difficult.

If you're concerned about data leaking over HTTPS, just don't allow your users access to HTTPS.

It doesn't solve the problem of them writing stuff down on bits of paper.

The only practical solution is to keep a good audit trail - preferably with honey pots.

symcbean
  • 19,931
  • 1
  • 29
  • 49
  • @symvbean: Hopefully no DNS "poisoning" will be needed because the clients won't have access to Internet DNS anyway. (If they do, then there's no point in doing the whole MiTM game w/ HTTPS since exfiltrating data over DNS is easy as pie...) – Evan Anderson Nov 22 '11 at 18:48
1

The https issue is resolved by the MiM type of solution indeed. Usually it means a proxy is catching outgoing https sessions, and serves those to the user signed by it's own ssl cert, while conducting the https comms towards the outside world on it's own.

The free myDLP solution can do that using it's own config of squid, and the more complex solutions, like Websense and symantec, iirc do the same thing, if slightly more powerful (load balancing between such proxies, fine grained cert management etc...)

dyasny
  • 18,482
  • 6
  • 48
  • 63