62

My company has just introduced a new VPN policy whereby once connected all traffic is routed the company network. This is to allow for improved monitoring of data theft.

It would appear that this policy also performs a man in the middle attack on HTTPS traffic. What this practically means for me is visiting "https://google.com" will give me a certificate error. Upon inspection of the certificate it is signed by my company's (self-signed) certificate.

To me this is hurting security in one area to help it in another. Is this common practice in big companies? Can someone point me to an ISO standard?

Improve this question
7
  • 3
    It might be that your company is too strict and does not expect its employees to use its internet for their personal use. As per my knowledge, most companies does not perform MITM intercept.
    – roguesecurity
    Commented Dec 8, 2015 at 10:24
  • interesting, I actually built a system that does this also. I wouldn't say its a very common practise but clearly it is known. Doing this ironically could increase their chances of data theft from other users
    – TheHidden
    Commented Dec 8, 2015 at 10:25
  • I've seen this done before, it's not really in the realms of an ISO though as it's a specific technical solution to a problem rather than good practice.
    – Arlix
    Commented Dec 8, 2015 at 11:50
  • This is really a question of locality. I believe it would be illegal here.
    – mirabilos
    Commented Dec 8, 2015 at 12:08
  • 1
    This approach would only catch the most basic means of communication. Even if HTTPS communication to a 3rd party (e. g. Google) is intercepted, you still could crypt and decrypt information on a higher layer and send it via this now untrusted network without any fear of interception. If the MITM recognizes encrypted data and denies its transfer, you could even use steganography to hide the encrypted data while being transfered. Thus the whole approach of MITM'ing seems brittle to me.
    – Alfe
    Commented Dec 9, 2015 at 10:45

3 Answers 3

Reset to default
70

Is this common practice in big companies?

Yes. The feature is available in most enterprise firewalls and also several firewalls for smaller companies. It is even available in the free web proxy Squid. And several personal firewalls have implemented it too.

As more and more sites, (both harmless and harmful), move to https://, expect that the usage of SSL interception will increase too, because nobody likes to have a firewall which fails to protect a system because it is blind regarding encrypted traffic.

Can someone point me to an ISO standard?

SSL interception just makes use of the existing SSL and PKI standards. There is no need to have a new standard which defines how SSL interception works.

As for the Cyber Security Standards: I'm not aware of any which explicitly require SSL interception, but I don't have much knowledge of these kind of standards. But even if it is not explicitly required it might be implicitly expected that you either block access to a SSL site or do SSL interception when the standard demands traffic monitoring.

will give me a certificate error.

SSL interception needs you to trust the intercepting CA. In most companies these CA certificates are centrally managed and installed on all computers, but if you use a browser like Firefox it might not help because Firefox has its own CA store and does not use the systems CA store.

To me this is hurting security in one area to help it in another.

Yes, it is breaking end-to-end encryption to detect malware and data leakage which use encrypted connections. But since the breakage of end-to-end encryption is done in full control of the company and you still have encryption to the outside world this is a trade off most companies are willing to take.

But note that in the past bugs were detected in several SSL interception products (like same CA between different companies, no revocation checks...) which additionally weakened the security.

Improve this answer
10
  • 1
    @AndySmith: I don't know if this is currently part of any of the Cyber Security Standards. Maybe it is covered by some phrases like "state-of-the-art security" but I've never heard that SSL interception is explicitly required by some of these standards.
    – Steffen Ullrich
    Commented Dec 8, 2015 at 12:49
  • 6
    Many standards do however require malware detection procedures, including the scanning of files/webpages/etc. that are downloaded or visited by employees. (e.g. ISO 27002:2013 12.2.1) Thus, SSL interception might implicitly be assumed.
    – Michael
    Commented Dec 8, 2015 at 14:05
  • 3
    ISO 27001, but in general terms: if you identify this (un-inspectable data) as a risk, you must take action according to your risk treatment plan, and 27002 is typically circumspect (not even using the word "proxy"). An action may be to adopt a default-deny with white-listing, or to MITM/inspect traffic (or both). The Australians are more direct, the ASD ISM control 0263 states exactly those options (there's a short section "Web Content and Connections") on this topic).
    – mr.spuratic
    Commented Dec 8, 2015 at 14:29
  • 3
    Doesn't this mean the company could log any passwords to sites I log into? The answer to personal accounts would, of course, be, "Don't use them on that network," but this would also expose passwords for anything I might legitimately need to log into (e.g., Atlassian, Slack, or any number of tools that might be hosted externally).
    – jpmc26
    Commented Dec 9, 2015 at 0:50
  • 2
    "But since the breakage of end-to-end encryption is done in full control of the company and you still have encryption to the outside world this is a trade off most companies are willing to take." Nothing that is connected to the Internet can be assumed to be in full control of the company. Using SSL interception is creating a single point of failure by which anyone who can compromise said point can compromise every bit of traffic that goes over the network. Not to mention the issues of some of these appliances using the same CA certs for every device...
    – reirab
    Commented Dec 9, 2015 at 19:25
10

This practice is becoming more common as organizations try to control things more, and as manufacturers market features to be able to spy on user activity.

To me this is hurting security in one area to help it in another.

Yes, but this MITM may be hurting security in an area that the organization doesn't care about (like being decent to employees/customers/etc.) in order to focus on an area that they do care about (like being able to be controlling).

Presumably, you can stop getting those web browser errors by installing a certificate published by your company. This can expose you to problems, as I note in chat room about college requiring SSL certification. In that case, the certificate was from Cyberoam, which had this vulnerability: "It is therefore possible to intercept traffic from any victim of a Cyberoam device with any other Cyberoam device - or to extract the key from the device and import it into other DPI devices". (DPI="Deep Packet Inspection") Therefore, installing that certificate is not recommended.

A better option is to simply not browse the web when connected to the VPN. Not browsing the web may be inconvenient: the workaround is to minimize time connected to the VPN. Briefly use the VPN for only the sensitive communications that need to be encrypted, and then stop using it. If that gets to be too inconvenient, then report the troubles. If there are sufficient complaints, perhaps the VPN will be perceived as being too troublesome with the current policy, which can lead to people considering a change in the policy.

Per some other comments (like one by Arlix), ISO might not provide any standards about this. However, a standards organization that has responded is the IETF, which noted this "Best Current Practice" document: IETF BCP 188 (currently RFC 7258: "Pervasive Monitoring Is an Attack"). This might be your best bet if you're looking for an official resource describing why this should not be done. Companies performing this MITM attack are not being standards-compliant.

Improve this answer
6
  • 6
    Employees should never expect privacy when utilizing employer equipment. Furthermore, when dealing with sensitive information such as healthcare -- institutions are more worried about huge fines.
    – Nathan Goings
    Commented Dec 9, 2015 at 4:15
  • Another option might be to setup a route so that internet browsing does not go through the VPN at all, thereby allowing you to remain connected for email/file/other access but still get the benefit of faster and non-MITM communications otherwise.
    – Coxy
    Commented Dec 9, 2015 at 7:52
  • @NathanGoings : Whether privacy on employer equipment is a sensible expectation could depend on an End User agreement. If I am to trust a computer, I want it to have no unannounced keyloggers or other malicious designs such as breaking the HTTPS protocol by violating the chain of trust. Institutions should find ways to avoid fines other than lying, such as using technology to falsify a technical identity. (If legitimate HTTPS is unfeasible due to security concerns, I'd rather HTTPS be honestly blocked than having a dishonest service mimics the valid service of relaying HTTPS data.)
    – TOOGAM
    Commented Dec 9, 2015 at 13:06
  • @Coxy : That violates the question's first sentence : "a new VPN policy whereby once connected all traffic is routed the company network." Such a workaround would technically function, but be a policy violation. Better to fix a broken policy than to break it.
    – TOOGAM
    Commented Dec 9, 2015 at 13:06
  • 3
    this MITM may be hurting security in an area that the organization doesn't care about. Maybe, but teaching employees to bypass certificate warnings can only be something the company doesn't care about out of willful ignorance.
    – kojiro
    Commented Dec 9, 2015 at 19:09
3

Please bear in mind that the two greatest roadblocks to the adoption of SSL Intercept features are the following:

  1. Corporate or Public privacy requirements (Policies) - you will want to ensure that whatever SSL intercept solution you go with allows for policy based (URL categorization and whitelist features) to ensure that you can excempt sites that you will not want to be monitoring. Banking is a great example, do you want obe liable if your network or device is hacked and employee/friends banking credentials are compromised? Consider archive and compliance requirements as part of that discussion.

  2. Future SSL changes - aka certificate validation. Example - Many website are going to be moving to certificate verification in code. This is where the website checks to ensure that the certificate that the client is using actually matches the certificate that it send. This completely breaks almost all SSL Intercept implementations that perform MITM as a core functions. Future standards changes or industry best practice like this may impact you spend or even viability of SSL Intercept.

Improve this answer
8
  • I think in [2] you refer to certificate and public key pinning. Current browsers explicitly disable pinning if the certificate is signed by an explicitly added CA, which is the the case when you use SSL interception. Thus pinning is at least not for browsers a problem. But some other clients (like Dropbox) will not weaken the pinning in this case and will thus fail or have to be explicitly exempted.
    – Steffen Ullrich
    Commented Dec 8, 2015 at 20:49
  • Yes, but many website are now implementing java and other code to test certificates as well. Not trusting the browser vendors or end users to implement required security options.
    – C. Harden
    Commented Dec 8, 2015 at 20:51
  • 2
    I've never heard of such cases. Do you have examples?
    – Steffen Ullrich
    Commented Dec 8, 2015 at 20:53
  • I don't think 2 is valid in any possible scenario because it's implies a remote party restricting the client within the client's domain. That's not possible. If it were, believe me, some DRM vendor would have it patented already.
    – user7933
    Commented Dec 9, 2015 at 0:58
  • @TechnikEmpire I believe point 2 is where the software maker (not a remote party) verifies the cert fingerprint, in addition to verifying that the OS's CA Certs agree that the cert is valid.
    – whitehat101
    Commented Dec 9, 2015 at 1:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .