58

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?

Stevoisiak
  • 1,515
  • 1
  • 11
  • 27
Andy Smith
  • 2,742
  • 18
  • 24
  • 2
    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 Dec 08 '15 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 Dec 08 '15 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 Dec 08 '15 at 11:50
  • This is really a question of locality. I believe it would be illegal here. – mirabilos Dec 08 '15 at 12:08
  • The worst security problems occur when CA's help out with this kind of thing. [This has actually happened](http://arstechnica.com/security/2015/04/google-chrome-will-banish-chinese-certificate-authority-for-breach-of-trust/). – Kevin Dec 09 '15 at 05:35
  • 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 Dec 09 '15 at 10:45
  • Related: [My college is forcing me to install their SSL certificate. How to protect my privacy?](http://security.stackexchange.com/q/104576/46674) – reirab Dec 09 '15 at 19:30

3 Answers3

66

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.

Stevoisiak
  • 1,515
  • 1
  • 11
  • 27
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Great answer, thankyou! I suppose when I was asking about ISO standards I was referring to standards companies comply with. i.e. one stating "You must MITM SSL traffic". – Andy Smith Dec 08 '15 at 12:37
  • 1
    @AndySmith: I don't know if this is currently part of any of the [Cyber Security Standards](https://en.wikipedia.org/wiki/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 Dec 08 '15 at 12:49
  • 5
    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 Dec 08 '15 at 14:05
  • 2
    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](http://www.asd.gov.au/infosec/ism/) control 0263 states exactly those options (there's a short section "*Web Content and Connections*") on this topic). – mr.spuratic Dec 08 '15 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 Dec 09 '15 at 00:50
  • 1
    @jpmc26 Yes, the traffic before leaving the network is entirely decrypted. That is, your employer (and anyone else for that matter) could passively log anything and everything going in to and coming from your device. –  Dec 09 '15 at 00:51
  • 1
    @Michael, That could be done on the client computer after decryption without MitMing SSL. – reirab Dec 09 '15 at 19:22
  • 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 Dec 09 '15 at 19:25
  • 1
    @reirab: This statements tries to point out that the decryption and re-encryption is done inside the company and that encrypted data leave the companies network and thus the traffic is protected against any attacker *outside* the companies network. But of course it is a trade-off like I said: you might either weaken the security by doing SSL interception or you might weaken it by not inspecting traffic for malware or data leakage. And in lots of cases the latter problem is the worse problem. – Steffen Ullrich Dec 09 '15 at 19:44
  • It's good to keep in mind that the downside of the security trade-off here may be larger than it appears at a surface glance. While in-transit decryption of the traffic for scanning may be relatively low risk, it's also possible (as pointed out above) for companies to be logging the traffic which can bring in a whole host of new attack vectors. (At-rest data is [notoriously hard to secure](http://money.cnn.com/2017/10/03/technology/business/yahoo-breach-3-billion-accounts/index.html).) – cjs Jun 02 '18 at 03:46
9

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.

TOOGAM
  • 372
  • 1
  • 5
  • 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 Dec 09 '15 at 04: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 Dec 09 '15 at 07: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 Dec 09 '15 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 Dec 09 '15 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 Dec 09 '15 at 19:09
  • @TOOGAM it doesn't sound like a capital P Policy to me but I guess that would be up to the OP to determine. – Coxy Dec 09 '15 at 23:58
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.

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
C. Harden
  • 31
  • 3
  • 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 Dec 08 '15 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 Dec 08 '15 at 20:51
  • 2
    I've never heard of such cases. Do you have examples? – Steffen Ullrich Dec 08 '15 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. –  Dec 09 '15 at 00: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 Dec 09 '15 at 01:13
  • @SteffenUllrich Here is a detailed implementation by IBM using node.js - http://www.ibm.com/developerworks/library/se-verify-server-certificates-nodejs-bluemix/index.html and here is a javascript one: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/How_to_check_the_secruity_state_of_an_XMLHTTPRequest_over_SSL – C. Harden Dec 09 '15 at 22:42
  • @C.Harden: I would say the second link is not relevant because it deals with validation of client certificates in a nodejs application, not with the validation of server certificates inside the browser. Apart from that SSL interception will not work with client certificates anyway. The first link is an example from Mozilla and they use an API which as far as I can see is only available in Firefox. Apart from that, this is only example code - are you aware of any sites which actually use it? Because that's what you claimed in "many website are now implementing ... test certificates as well." – Steffen Ullrich Dec 10 '15 at 06:17
  • Issue #2 can come up even outside of standards changes or explicit attempts to verify that the remote end of a connection is using a "real" certificate. For example, if you [configure Git for Windows to use OpenSSL instead of Windows Secure Channel](https://stackoverflow.com/a/46332681) you may find that `git clone https://...` produces a certificate error when using the company's MITM proxies because the OpenSSL cert list doesn't include the corporate cert that the WSC list does. As per the link, users may simply disable all authentication for Git, causing new security problem. – cjs Jun 03 '18 at 05:00